From lmesnik at openjdk.org Wed Nov 1 00:14:25 2023 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Wed, 1 Nov 2023 00:14:25 GMT Subject: RFR: 8319200: Don't use test thread factory in ProcessTools.createLimitedTestJavaProcessBuilder() Message-ID: <3damdMQpRBrkUN2S32tBD0Tmrl2tmSqA31NniV8FzHU=.d3a36aa7-d5f4-4a63-b2ff-8b9b616a9637@github.com> Test thread factory is a mode similar to VM flags and should not be used in ProcessTools.createLimitedTestJavaProcessBuilder(). Only createTestJavaProcessBuilder() should use it like jtreg VM options. Adding the test thread factory requires the injection of arguments in the middle of the list. I don't think it makes sense to modify arguments in several places so I replaced it with the flag isLimited and moved all modifications in createJavaProcessBuilder(). Testing tier1-5. ------------- Commit messages: - Moved ttf from limited builder. Changes: https://git.openjdk.org/jdk/pull/16442/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16442&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8319200 Stats: 15 lines in 1 file changed: 8 ins; 3 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/16442.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16442/head:pull/16442 PR: https://git.openjdk.org/jdk/pull/16442 From jiefu at openjdk.org Wed Nov 1 01:37:04 2023 From: jiefu at openjdk.org (Jie Fu) Date: Wed, 1 Nov 2023 01:37:04 GMT Subject: RFR: JDK-8319195: Move tier 1 vector API regression tests to tier 2 In-Reply-To: References: Message-ID: <_xfg6_ESxhgr-bMhJj9rWU9JNrsR94SMuWl9W7dUlVI=.51e83e78-3538-49d6-8e10-50e3a23186a6@github.com> On Tue, 31 Oct 2023 20:14:45 GMT, Joe Darcy wrote: > Due to their longer-than-typical running time and because the vector API is not (yet) in the base module, move the vector API tests in tier 1 to tier 2. May I ask how long it will take to run jdk_vector_sanity? My testing in JDK-8295970 was less than 2min. See https://github.com/openjdk/jdk/pull/10879#issuecomment-1298126965 ------------- PR Comment: https://git.openjdk.org/jdk/pull/16437#issuecomment-1788263345 From darcy at openjdk.org Wed Nov 1 02:37:02 2023 From: darcy at openjdk.org (Joe Darcy) Date: Wed, 1 Nov 2023 02:37:02 GMT Subject: RFR: JDK-8319195: Move tier 1 vector API regression tests to tier 2 In-Reply-To: References: Message-ID: On Tue, 31 Oct 2023 20:14:45 GMT, Joe Darcy wrote: > Due to their longer-than-typical running time and because the vector API is not (yet) in the base module, move the vector API tests in tier 1 to tier 2. > May I ask how long it will take to run jdk_vector_sanity? > > My testing in JDK-8295970 was less than 2min. See [#10879 (comment)](https://github.com/openjdk/jdk/pull/10879#issuecomment-1298126965) The time taken is going to vary of course. That set of tests took about 2 minutes when run with 4 way concurrency on the configuration I use for development, 3 minutes 21 seconds when run serially. About 10 of the individual tests took more than 25 seconds latency to run on that config. I don't think it would be hard to find, say 30 different API areas in the JDK outside of the base module, that might want "just 2 minutes of testing in tier1," which would cause tier 1 to take another hour to run. Until the vector API is in the base module, I think a total tier 1 time budget of at most 10 seconds _total_, but being only in tier 2 and later tiers would be fine too IMO. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16437#issuecomment-1788307308 From dholmes at openjdk.org Wed Nov 1 03:01:00 2023 From: dholmes at openjdk.org (David Holmes) Date: Wed, 1 Nov 2023 03:01:00 GMT Subject: RFR: 8319200: Don't use test thread factory in ProcessTools.createLimitedTestJavaProcessBuilder() In-Reply-To: <3damdMQpRBrkUN2S32tBD0Tmrl2tmSqA31NniV8FzHU=.d3a36aa7-d5f4-4a63-b2ff-8b9b616a9637@github.com> References: <3damdMQpRBrkUN2S32tBD0Tmrl2tmSqA31NniV8FzHU=.d3a36aa7-d5f4-4a63-b2ff-8b9b616a9637@github.com> Message-ID: On Wed, 1 Nov 2023 00:06:35 GMT, Leonid Mesnik wrote: > Test thread factory is a mode similar to VM flags and should not be used in ProcessTools.createLimitedTestJavaProcessBuilder(). I'm not sure I agree with that. I think the test factory is a separate testing dimension, independent of JVM flags. test/lib/jdk/test/lib/process/ProcessTools.java line 447: > 445: * Create ProcessBuilder using the java launcher from the jdk to be tested. > 446: * > 447: * @param isLimited Defines if jtreg options and test thread factory should be added Suggestion: @param isLimited If true, prevents the addition of jtreg options to the command, and ignores any available test thread factory ------------- PR Review: https://git.openjdk.org/jdk/pull/16442#pullrequestreview-1707505556 PR Review Comment: https://git.openjdk.org/jdk/pull/16442#discussion_r1378344276 From jiefu at openjdk.org Wed Nov 1 03:06:05 2023 From: jiefu at openjdk.org (Jie Fu) Date: Wed, 1 Nov 2023 03:06:05 GMT Subject: RFR: JDK-8319195: Move tier 1 vector API regression tests to tier 2 In-Reply-To: References: Message-ID: On Tue, 31 Oct 2023 20:14:45 GMT, Joe Darcy wrote: > Due to their longer-than-typical running time and because the vector API is not (yet) in the base module, move the vector API tests in tier 1 to tier 2. Okay. If 2min testing time is not acceptable in tier1 for vector api, I agree with @AlanBateman that `jdk_vector_sanity` should be removed. Also, it would be better to hear from @vnkozlov . ------------- PR Comment: https://git.openjdk.org/jdk/pull/16437#issuecomment-1788330730 From ccheung at openjdk.org Wed Nov 1 04:34:35 2023 From: ccheung at openjdk.org (Calvin Cheung) Date: Wed, 1 Nov 2023 04:34:35 GMT Subject: RFR: 8316969: Improve CDS module graph support for --module option [v8] In-Reply-To: References: Message-ID: <48Cg1jcgwdrXwlEB4uFoxVyB6Adug9kL2zTNhtzuMp8=.e6f7d190-3b66-4e7e-8c52-9e67dfdd0f6d@github.com> > Please review this changeset for adding support for `--module` (-m) option for CDS. > Changes in the `ModuleBootstrap.java` are needed so that the `ArchivedModuleGraph.archive` and `ArchivedBootLayer.archive` are called if the main module is specified. The module name will be stored in the ro region of the CDS archive. During runtime, the archived module name will be compared with the runtime module name. If comparison fails, the archived full module graph won't be used. > > Note: this RFE is a subtask of [JDK-8266329](https://bugs.openjdk.org/browse/JDK-8266329). More subtask(s) will be created to support other options such as `--add-modules`. > > Passed tiers 1 - 4 testing. Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: more comments from Alan and Ioi; copyright year update ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16016/files - new: https://git.openjdk.org/jdk/pull/16016/files/daec9915..b214fa7c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16016&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16016&range=06-07 Stats: 27 lines in 3 files changed: 23 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/16016.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16016/head:pull/16016 PR: https://git.openjdk.org/jdk/pull/16016 From ccheung at openjdk.org Wed Nov 1 04:36:06 2023 From: ccheung at openjdk.org (Calvin Cheung) Date: Wed, 1 Nov 2023 04:36:06 GMT Subject: RFR: 8316969: Improve CDS module graph support for --module option [v6] In-Reply-To: <_kRxr4CnDC2ouiocb43oqSNVPOI1xeJ4LTRhXwWeeYg=.eef409db-3a40-483d-9e54-9914bb524520@github.com> References: <_kRxr4CnDC2ouiocb43oqSNVPOI1xeJ4LTRhXwWeeYg=.eef409db-3a40-483d-9e54-9914bb524520@github.com> Message-ID: On Fri, 27 Oct 2023 16:34:20 GMT, Ioi Lam wrote: >> Calvin Cheung has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits: >> >> - Merge master >> - skip archiving full module graph is there is an incubator module >> - fix typo >> - simplify some code in modules.cpp >> - comments from Alan and Ioi; add missing @run tag in the test >> - Merge branch 'master' into improve-CDS-module-graph >> - better way to check if a module is a JDK module >> - initial review comments from Ioi >> - 8316969: Improve CDS module graph support for --module option > > The new version looks really good now. I found one merge error and have a suggestion for adding one more test. @iklam, @AlanBateman, I've pushed another small update. Please re-review. Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/16016#issuecomment-1788393639 From stefank at openjdk.org Wed Nov 1 07:03:58 2023 From: stefank at openjdk.org (Stefan Karlsson) Date: Wed, 1 Nov 2023 07:03:58 GMT Subject: RFR: 8319200: Don't use test thread factory in ProcessTools.createLimitedTestJavaProcessBuilder() In-Reply-To: <3damdMQpRBrkUN2S32tBD0Tmrl2tmSqA31NniV8FzHU=.d3a36aa7-d5f4-4a63-b2ff-8b9b616a9637@github.com> References: <3damdMQpRBrkUN2S32tBD0Tmrl2tmSqA31NniV8FzHU=.d3a36aa7-d5f4-4a63-b2ff-8b9b616a9637@github.com> Message-ID: On Wed, 1 Nov 2023 00:06:35 GMT, Leonid Mesnik wrote: > Test thread factory is a mode similar to VM flags and should not be used in ProcessTools.createLimitedTestJavaProcessBuilder(). Only createTestJavaProcessBuilder() should use it like jtreg VM options. > > Adding the test thread factory requires the injection of arguments in the middle of the list. I don't think it makes sense to modify arguments in several places so I replaced it with the flag isLimited and moved all modifications in createJavaProcessBuilder(). > > Testing tier1-5. It seems like the code would be cleaner if you moved the threadFactory injection to `createTestJavaProcessBuilder`. ------------- Changes requested by stefank (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16442#pullrequestreview-1707671922 From shade at openjdk.org Wed Nov 1 09:54:28 2023 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 1 Nov 2023 09:54:28 GMT Subject: RFR: 8309622: Re-examine the cache mechanism in BaseLocale In-Reply-To: References: <5MqmN4P1TLKDCfXPhKWrH1b2FTgOXmjtKgd1bVXDd_M=.2000f20d-365d-48dc-bc37-45d8bcb9447f@github.com> Message-ID: On Mon, 12 Jun 2023 17:28:44 GMT, Naoto Sato wrote: >> One other thing to consider... >> If the BaseLocale entries are being GC'd sooner, then perhaps the value of the String.intern() is reduced. >> Eliminating `.intern90` would make creating a normalized BaseLocale faster. > >> One other thing to consider... If the BaseLocale entries are being GC'd sooner, then perhaps the value of the String.intern() is reduced. Eliminating `.intern90` would make creating a normalized BaseLocale faster. > > Some code inside the Locale still relies on `intern` and do `==` comparison. Yes, it would be faster but I think that would be out of the scope of this fix @naotoj, we are still seeing the CI failures due to this. Are you planning to finish this work? Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/14404#issuecomment-1788686569 From pminborg at openjdk.org Wed Nov 1 10:33:23 2023 From: pminborg at openjdk.org (Per Minborg) Date: Wed, 1 Nov 2023 10:33:23 GMT Subject: RFR: 8318678: Vector access on heap MemorySegments only works for byte[] [v4] In-Reply-To: References: Message-ID: > This PR proposes removing the restriction that only heap `MemorySegment` wrapping a `byte` array can be accessed by Vectors. Now any array type can be used provided the element alignment constraints are respected. Per Minborg has updated the pull request incrementally with one additional commit since the last revision: Remove IntrinsicHeapTest ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16360/files - new: https://git.openjdk.org/jdk/pull/16360/files/c104051c..7f4a1871 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16360&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16360&range=02-03 Stats: 160 lines in 1 file changed: 0 ins; 160 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/16360.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16360/head:pull/16360 PR: https://git.openjdk.org/jdk/pull/16360 From alanb at openjdk.org Wed Nov 1 11:31:06 2023 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 1 Nov 2023 11:31:06 GMT Subject: RFR: 8316969: Improve CDS module graph support for --module option [v8] In-Reply-To: <48Cg1jcgwdrXwlEB4uFoxVyB6Adug9kL2zTNhtzuMp8=.e6f7d190-3b66-4e7e-8c52-9e67dfdd0f6d@github.com> References: <48Cg1jcgwdrXwlEB4uFoxVyB6Adug9kL2zTNhtzuMp8=.e6f7d190-3b66-4e7e-8c52-9e67dfdd0f6d@github.com> Message-ID: On Wed, 1 Nov 2023 04:34:35 GMT, Calvin Cheung wrote: >> Please review this changeset for adding support for `--module` (-m) option for CDS. >> Changes in the `ModuleBootstrap.java` are needed so that the `ArchivedModuleGraph.archive` and `ArchivedBootLayer.archive` are called if the main module is specified. The module name will be stored in the ro region of the CDS archive. During runtime, the archived module name will be compared with the runtime module name. If comparison fails, the archived full module graph won't be used. >> >> Note: this RFE is a subtask of [JDK-8266329](https://bugs.openjdk.org/browse/JDK-8266329). More subtask(s) will be created to support other options such as `--add-modules`. >> >> Passed tiers 1 - 4 testing. > > Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: > > more comments from Alan and Ioi; copyright year update Marked as reviewed by alanb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/16016#pullrequestreview-1708018487 From alanb at openjdk.org Wed Nov 1 11:31:06 2023 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 1 Nov 2023 11:31:06 GMT Subject: RFR: 8316969: Improve CDS module graph support for --module option [v3] In-Reply-To: References: <5lYwJpqhgq2MEJ17xpslna437GsmZFAH5v3FyWRhh-Q=.83077177-f238-4cdb-b65d-06e013b4edaf@github.com> <6Uy4_u0RQeGKXwUYk8REFcRYlx1AuSgbyQSClrlwFLU=.8c21fcdb-89b4-4bfc-a812-e0bed27d0efe@github.com> Message-ID: On Tue, 31 Oct 2023 20:45:11 GMT, Calvin Cheung wrote: > Do you prefer the `canArchive` setting be inside `if (CDS.isDumpingStaticArchive())` like the following? > > ``` > if (CDS.isDumpingStaticArchive()) > canArchive = true; > ``` That's fine. It has been harmless to have canArchive be true when not dumping but with the other changes in this PR then I think it's clearer to only set it when dumping. So I think your changes are good. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16016#discussion_r1378678681 From rgiulietti at openjdk.org Wed Nov 1 12:40:40 2023 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Wed, 1 Nov 2023 12:40:40 GMT Subject: RFR: 8319174: Enhance robustness of some j.m.BigInteger constructors Message-ID: <0iccBwbAhAmIPGxnz1bhry2Sj_Kz2xngZmb2lPFCUpU=.c2b7c8ef-4e77-4c8f-a7ec-7c5c0980e59e@github.com> Enhance `java.math.BigInteger` constructors taking a `byte[]` argument by improving guarantees of internal invariants. ------------- Commit messages: - Added @bug to test. - Refactored test to JUnit. - 8319174: Enhance robustness of some j.m.BigInteger constructors - Merge branch 'master' - Merge branch 'master' into bigint - Enhance BigInteger constructors taking byte[] Changes: https://git.openjdk.org/jdk/pull/16449/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16449&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8319174 Stats: 327 lines in 3 files changed: 255 ins; 18 del; 54 mod Patch: https://git.openjdk.org/jdk/pull/16449.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16449/head:pull/16449 PR: https://git.openjdk.org/jdk/pull/16449 From rriggs at openjdk.org Wed Nov 1 13:25:02 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 1 Nov 2023 13:25:02 GMT Subject: RFR: 8318962: Update ProcessTools javadoc with suggestions in 8315097 [v2] In-Reply-To: <4QdnYoO6FPy2EtXd2zl_jCShZrUOyV-ZgMrYstHr_Io=.d66188a4-1b00-410f-a14c-b91a3afba6ea@github.com> References: <7TkgaSk5gD1NZ3OkkHiQWITGjvdmN8HSOulObRcAjWw=.8b660bc2-e604-40b0-a06b-09c25bd0fe79@github.com> <4QdnYoO6FPy2EtXd2zl_jCShZrUOyV-ZgMrYstHr_Io=.d66188a4-1b00-410f-a14c-b91a3afba6ea@github.com> Message-ID: On Tue, 31 Oct 2023 17:15:50 GMT, Leo Korinth wrote: >> Updates to javadoc after improvement ideas in the review of 8315097. I have also removed the incomplete invocation command line. I also removed incomplete information in `executeTestJvm` and added a link to `createLimitedTestJavaProcessBuilder` > > Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: > > executeTestJvm has never used the 'limited' api, fix my bad documentation Marked as reviewed by rriggs (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/16430#pullrequestreview-1708214902 From mcimadamore at openjdk.org Wed Nov 1 14:17:11 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Wed, 1 Nov 2023 14:17:11 GMT Subject: RFR: 8319211: Regression in LoopOverNonConstantFP Message-ID: This PR fixes an inexact var handle call that sneaked in as part of https://git.openjdk.org/jdk/pull/16224. As some default methods were moved from `MemorySegment` to `AbstractMemorySegmentImpl`, the type of `this` has changed, and this made all the var handle calls in the memory segment accessors inexact. To prevent this issue from occurring again, I've added a new JDK flag to create _exact_ segment view var handles, so that we can test that segment accessors work even when using the stricter behavior. I've considered using a flag for _all_ var handles (even non-FFM ones), but gave up when I saw that there is some JDK code that needs to pass `null` to some var handles, in which case exact behavior is not possible (at least not without fixing the use site to cast the `null` to the right type). This might be pursued as a separate effort. ------------- Commit messages: - Initial push Changes: https://git.openjdk.org/jdk/pull/16451/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16451&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8319211 Stats: 42 lines in 4 files changed: 5 ins; 0 del; 37 mod Patch: https://git.openjdk.org/jdk/pull/16451.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16451/head:pull/16451 PR: https://git.openjdk.org/jdk/pull/16451 From jvernee at openjdk.org Wed Nov 1 14:37:03 2023 From: jvernee at openjdk.org (Jorn Vernee) Date: Wed, 1 Nov 2023 14:37:03 GMT Subject: RFR: 8319211: Regression in LoopOverNonConstantFP In-Reply-To: References: Message-ID: On Wed, 1 Nov 2023 14:10:10 GMT, Maurizio Cimadamore wrote: > This PR fixes an inexact var handle call that sneaked in as part of https://git.openjdk.org/jdk/pull/16224. > > As some default methods were moved from `MemorySegment` to `AbstractMemorySegmentImpl`, the type of `this` has changed, and this made all the var handle calls in the memory segment accessors inexact. > > To prevent this issue from occurring again, I've added a new JDK flag to create _exact_ segment view var handles, so that we can test that segment accessors work even when using the stricter behavior. > > I've considered using a flag for _all_ var handles (even non-FFM ones), but gave up when I saw that there is some JDK code that needs to pass `null` to some var handles, in which case exact behavior is not possible (at least not without fixing the use site to cast the `null` to the right type). This might be pursued as a separate effort. Nice catch! Thanks for fixing. ------------- Marked as reviewed by jvernee (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16451#pullrequestreview-1708353739 From rgiulietti at openjdk.org Wed Nov 1 14:52:23 2023 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Wed, 1 Nov 2023 14:52:23 GMT Subject: RFR: 8319174: Enhance robustness of some j.m.BigInteger constructors [v2] In-Reply-To: <0iccBwbAhAmIPGxnz1bhry2Sj_Kz2xngZmb2lPFCUpU=.c2b7c8ef-4e77-4c8f-a7ec-7c5c0980e59e@github.com> References: <0iccBwbAhAmIPGxnz1bhry2Sj_Kz2xngZmb2lPFCUpU=.c2b7c8ef-4e77-4c8f-a7ec-7c5c0980e59e@github.com> Message-ID: > Enhance `java.math.BigInteger` constructors taking a `byte[]` argument by improving guarantees of internal invariants. Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: Static Random instance. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16449/files - new: https://git.openjdk.org/jdk/pull/16449/files/4fcd905d..af2e4158 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16449&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16449&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/16449.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16449/head:pull/16449 PR: https://git.openjdk.org/jdk/pull/16449 From abimpoudis at openjdk.org Wed Nov 1 15:55:44 2023 From: abimpoudis at openjdk.org (Aggelos Biboudis) Date: Wed, 1 Nov 2023 15:55:44 GMT Subject: RFR: 8303374: Compiler Implementation for Primitive types in patterns, instanceof, and switch (Preview) [v28] In-Reply-To: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com> References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com> Message-ID: > This is the proposed patch for Primitive types in patterns, instanceof, and switch (Preview). > > Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/jep455-20231030/specs/instanceof-jls.html Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision: Add test for instanceof as a pattern on with record patterns ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15638/files - new: https://git.openjdk.org/jdk/pull/15638/files/b437373b..a7f778ca Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=27 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=26-27 Stats: 192 lines in 4 files changed: 162 ins; 18 del; 12 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 Wed Nov 1 17:24:02 2023 From: duke at openjdk.org (null) Date: Wed, 1 Nov 2023 17:24:02 GMT Subject: RFR: 8317545: AIX PPC64: Implementation of Foreign Function & Memory API [v5] In-Reply-To: References: Message-ID: On Tue, 17 Oct 2023 14:17:20 GMT, Martin Doerr wrote: >> The AIX linker has a few minor diffs to the linux ABIv1 linker. In addition, double values have only 4 Byte alignment within structures. This PR is based on JDK22 version of the FFI. > > Martin Doerr has updated the pull request incrementally with two additional commits since the last revision: > > - Improve handling of layouts in NativeType.java > - Check byte order of 4-byte aligned double. Tested Martins changes using symbol resolution fix. ============================== Test summary ============================== TEST TOTAL PASS FAIL ERROR >> jtreg:test/jdk/java/foreign 91 86 5 0 << ============================== TEST FAILURE Some of the test cases have passed after using pragma natural directive. Rest of the Failing test cases are as below, which need to be investigated later on. # newfailures.txt java/foreign/TestUpcallAsync.java java/foreign/enablenativeaccess/TestEnableNativeAccess.java java/foreign/enablenativeaccess/TestEnableNativeAccessJarManifest.java java/foreign/loaderLookup/TestLoaderLookupJNI.java java/foreign/stackwalk/TestAsyncStackWalk.java#default_gc However, majority of the test cases are passing now. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16179#issuecomment-1789353270 From rgiulietti at openjdk.org Wed Nov 1 17:47:19 2023 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Wed, 1 Nov 2023 17:47:19 GMT Subject: RFR: 8318915: Enhance checks in BigDecimal.toPlainString() Message-ID: Prevent a `NegativeArraySizeException` in `BigDecimal.toPlainString()`, throwing `OutOfMemoryError` instead to indicate that the resulting `String` would be too large. ------------- Commit messages: - 8318915: Enhance checks in BigDecimal.toPlainString() Changes: https://git.openjdk.org/jdk/pull/16457/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16457&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8318915 Stats: 56 lines in 2 files changed: 43 ins; 1 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/16457.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16457/head:pull/16457 PR: https://git.openjdk.org/jdk/pull/16457 From mcimadamore at openjdk.org Wed Nov 1 17:52:11 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Wed, 1 Nov 2023 17:52:11 GMT Subject: Integrated: 8319211: Regression in LoopOverNonConstantFP In-Reply-To: References: Message-ID: On Wed, 1 Nov 2023 14:10:10 GMT, Maurizio Cimadamore wrote: > This PR fixes an inexact var handle call that sneaked in as part of https://git.openjdk.org/jdk/pull/16224. > > As some default methods were moved from `MemorySegment` to `AbstractMemorySegmentImpl`, the type of `this` has changed, and this made all the var handle calls in the memory segment accessors inexact. > > To prevent this issue from occurring again, I've added a new JDK flag to create _exact_ segment view var handles, so that we can test that segment accessors work even when using the stricter behavior. > > I've considered using a flag for _all_ var handles (even non-FFM ones), but gave up when I saw that there is some JDK code that needs to pass `null` to some var handles, in which case exact behavior is not possible (at least not without fixing the use site to cast the `null` to the right type). This might be pursued as a separate effort. This pull request has now been integrated. Changeset: f262f06c Author: Maurizio Cimadamore URL: https://git.openjdk.org/jdk/commit/f262f06c97b9ea94cd6119b3a8beb16bf804d083 Stats: 42 lines in 4 files changed: 5 ins; 0 del; 37 mod 8319211: Regression in LoopOverNonConstantFP Reviewed-by: jvernee ------------- PR: https://git.openjdk.org/jdk/pull/16451 From mchung at openjdk.org Wed Nov 1 18:00:11 2023 From: mchung at openjdk.org (Mandy Chung) Date: Wed, 1 Nov 2023 18:00:11 GMT Subject: RFR: 8317965: TestLoadLibraryDeadlock.java fails with "Unable to load native library.: expected true, was false" Message-ID: <4MnsR63BS2cwUGcy8uJBBJyLIiNE4j40wih5PIAqDlg=.b5f45615-8923-487e-a44f-ac2cbe4d0629@github.com> `TestLoadLibraryDeadlock.java` test runs `LoadLibraryDeadlock` and wait for 5 seconds and then grab the output. Then run `jcmd` to dump the thread stacks in case there is a deadlock. The test ignores and swallows any exception which makes it hard to diagnose test issues. This PR simplifies the test to use `jdk.test.lib.process.ProcessTools` to launch `LoadLibraryDeadlock` test so that the output and error will be captured in the same way as other tools are run by this test. Also update the test to propagate exceptions where appropriate. This hopes to collect more information to diagnose the issue if this test fails next time. ------------- Commit messages: - 8317965: TestLoadLibraryDeadlock.java fails with "Unable to load native library.: expected true, was false" Changes: https://git.openjdk.org/jdk/pull/16459/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16459&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8317965 Stats: 69 lines in 2 files changed: 5 ins; 57 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/16459.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16459/head:pull/16459 PR: https://git.openjdk.org/jdk/pull/16459 From rriggs at openjdk.org Wed Nov 1 18:38:01 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 1 Nov 2023 18:38:01 GMT Subject: RFR: 8317965: TestLoadLibraryDeadlock.java fails with "Unable to load native library.: expected true, was false" In-Reply-To: <4MnsR63BS2cwUGcy8uJBBJyLIiNE4j40wih5PIAqDlg=.b5f45615-8923-487e-a44f-ac2cbe4d0629@github.com> References: <4MnsR63BS2cwUGcy8uJBBJyLIiNE4j40wih5PIAqDlg=.b5f45615-8923-487e-a44f-ac2cbe4d0629@github.com> Message-ID: On Wed, 1 Nov 2023 17:54:00 GMT, Mandy Chung wrote: > `TestLoadLibraryDeadlock.java` test runs `LoadLibraryDeadlock` and wait for 5 seconds and then grab the output. Then run `jcmd` to dump the thread stacks in case there is a deadlock. The test ignores and swallows any exception which makes it hard to diagnose test issues. > > This PR simplifies the test to use `jdk.test.lib.process.ProcessTools` to launch `LoadLibraryDeadlock` test so that the output and error will be captured in the same way as other tools are run by this test. Also update the test to propagate exceptions where appropriate. This hopes to collect more information to diagnose the issue if this test fails next time. test/jdk/java/lang/ClassLoader/loadLibraryDeadlock/TestLoadLibraryDeadlock.java line 115: > 113: Collections.addAll(commands, java); > 114: Collections.addAll(commands, Utils.getTestJavaOpts()); > 115: Collections.addAll(commands, command); The prose description talks about using ProcessTools, but the runCommand code doesn't use ProcessTools.createTestJavaProcessBuilder. It could save a few steps. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16459#discussion_r1379167496 From kvn at openjdk.org Wed Nov 1 18:42:03 2023 From: kvn at openjdk.org (Vladimir Kozlov) Date: Wed, 1 Nov 2023 18:42:03 GMT Subject: RFR: JDK-8319195: Move tier 1 vector API regression tests to tier 2 In-Reply-To: References: Message-ID: <9gE1TTFC8Wiglbi4Nwf9IckVzJNQgehRhS8ldrD5d1A=.13dd88ac-8b13-451e-aee7-21afd0034029@github.com> On Tue, 31 Oct 2023 20:14:45 GMT, Joe Darcy wrote: > Due to their longer-than-typical running time and because the vector API is not (yet) in the base module, move the vector API tests in tier 1 to tier 2. jdk_vector_sanity was added to tier1 to catch issues early in GHA. See #10879 and discussion [#10807-review](https://github.com/openjdk/jdk/pull/10807#pullrequestreview-1150314487) If some tests run for long time they could be excluded from jdk_vector_sanity list. ------------- Changes requested by kvn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16437#pullrequestreview-1708812488 From mdoerr at openjdk.org Wed Nov 1 18:46:03 2023 From: mdoerr at openjdk.org (Martin Doerr) Date: Wed, 1 Nov 2023 18:46:03 GMT Subject: RFR: 8317545: AIX PPC64: Implementation of Foreign Function & Memory API [v5] In-Reply-To: References: Message-ID: On Tue, 17 Oct 2023 14:17:20 GMT, Martin Doerr wrote: >> The AIX linker has a few minor diffs to the linux ABIv1 linker. In addition, double values have only 4 Byte alignment within structures. This PR is based on JDK22 version of the FFI. > > Martin Doerr has updated the pull request incrementally with two additional commits since the last revision: > > - Improve handling of layouts in NativeType.java > - Check byte order of 4-byte aligned double. Thanks for testing! This sounds good. We need to handle the failing tests separately as they are not immediately related to the up-/downcalls. TestUpcallAsync is failing because of problems with AttachCurrentThreadAsDaemon on AIX. The other ones because libLoaderLookupInvoker.so seems to be broken on AIX. @JornVernee: You had mentioned a javadoc update. Do we have to wait for anything or can we ship it? @suchismith1993: Please approve it when you think it's good to go. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16179#issuecomment-1789469814 From jlaskey at openjdk.org Wed Nov 1 19:02:18 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Wed, 1 Nov 2023 19:02:18 GMT Subject: RFR: JDK-8315458 Implementation of Implicitly Declared Classes and Instance Main Method (Second Preview) Message-ID: Address changes from JEP 445 to JEP 463. - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. - Don't mark class on read. - Remove reflection and annotation processing related to unnamed classes. - Simplify main method search. ------------- Commit messages: - Implicit classes and instance main methods Changes: https://git.openjdk.org/jdk/pull/16461/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16461&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8315458 Stats: 344 lines in 36 files changed: 12 ins; 231 del; 101 mod Patch: https://git.openjdk.org/jdk/pull/16461.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16461/head:pull/16461 PR: https://git.openjdk.org/jdk/pull/16461 From kvn at openjdk.org Wed Nov 1 19:14:03 2023 From: kvn at openjdk.org (Vladimir Kozlov) Date: Wed, 1 Nov 2023 19:14:03 GMT Subject: RFR: JDK-8319195: Move tier 1 vector API regression tests to tier 2 In-Reply-To: References: Message-ID: On Tue, 31 Oct 2023 20:14:45 GMT, Joe Darcy wrote: > Due to their longer-than-typical running time and because the vector API is not (yet) in the base module, move the vector API tests in tier 1 to tier 2. I would suggest to determine the set of tests which run "at most 10 seconds total" and run only them in tier1. Also taking into account API coverage. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16437#issuecomment-1789507891 From jlaskey at openjdk.org Wed Nov 1 19:14:22 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Wed, 1 Nov 2023 19:14:22 GMT Subject: RFR: JDK-8315458 Implementation of Implicitly Declared Classes and Instance Main Method (Second Preview) [v2] In-Reply-To: References: Message-ID: > Address changes from JEP 445 to JEP 463. > > - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. > > - Don't mark class on read. > > - Remove reflection and annotation processing related to unnamed classes. > > - Simplify main method search. Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: Remove obsolete tests ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16461/files - new: https://git.openjdk.org/jdk/pull/16461/files/4a34a4e8..a07b8d29 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16461&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16461&range=00-01 Stats: 320 lines in 3 files changed: 0 ins; 320 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/16461.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16461/head:pull/16461 PR: https://git.openjdk.org/jdk/pull/16461 From mchung at openjdk.org Wed Nov 1 19:18:07 2023 From: mchung at openjdk.org (Mandy Chung) Date: Wed, 1 Nov 2023 19:18:07 GMT Subject: RFR: 8317965: TestLoadLibraryDeadlock.java fails with "Unable to load native library.: expected true, was false" In-Reply-To: References: <4MnsR63BS2cwUGcy8uJBBJyLIiNE4j40wih5PIAqDlg=.b5f45615-8923-487e-a44f-ac2cbe4d0629@github.com> Message-ID: <_vus9GqCnUn_0nKV5-kTGZOUhNE5UxPyO9N_n4l9kh4=.d1e819d1-01b1-44d2-844f-f2c3b00bd5be@github.com> On Wed, 1 Nov 2023 18:35:00 GMT, Roger Riggs wrote: >> `TestLoadLibraryDeadlock.java` test runs `LoadLibraryDeadlock` and wait for 5 seconds and then grab the output. Then run `jcmd` to dump the thread stacks in case there is a deadlock. The test ignores and swallows any exception which makes it hard to diagnose test issues. >> >> This PR simplifies the test to use `jdk.test.lib.process.ProcessTools` to launch `LoadLibraryDeadlock` test so that the output and error will be captured in the same way as other tools are run by this test. Also update the test to propagate exceptions where appropriate. This hopes to collect more information to diagnose the issue if this test fails next time. > > test/jdk/java/lang/ClassLoader/loadLibraryDeadlock/TestLoadLibraryDeadlock.java line 115: > >> 113: Collections.addAll(commands, java); >> 114: Collections.addAll(commands, Utils.getTestJavaOpts()); >> 115: Collections.addAll(commands, command); > > The prose description talks about using ProcessTools, but the runCommand code doesn't use ProcessTools.createTestJavaProcessBuilder. It could save a few steps. `runCommand` sets the working directory whereas `ProcessTools.createTestJavaProcessBuilder` does not. Either way is okay with me if we want to use `createTestJavaProcessBuilder` (which will set the VM options). + ProcessBuilder pb = ProcessTools.createTestJavaProcessBuilder("-cp", + "a.jar" + classPathSeparator + + "b.jar" + classPathSeparator + + "c.jar", + "-Djava.library.path=" + testLibraryPath, + "LoadLibraryDeadlock") + .directory(new File(testClassPath)); + OutputAnalyzer outputAnalyzer = ProcessTools.executeCommand(pb) + .shouldHaveExitValue(0); or set the class path to the explicit path of the JAR files. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16459#discussion_r1379206601 From mchung at openjdk.org Wed Nov 1 19:46:33 2023 From: mchung at openjdk.org (Mandy Chung) Date: Wed, 1 Nov 2023 19:46:33 GMT Subject: RFR: 8317965: TestLoadLibraryDeadlock.java fails with "Unable to load native library.: expected true, was false" [v2] In-Reply-To: <4MnsR63BS2cwUGcy8uJBBJyLIiNE4j40wih5PIAqDlg=.b5f45615-8923-487e-a44f-ac2cbe4d0629@github.com> References: <4MnsR63BS2cwUGcy8uJBBJyLIiNE4j40wih5PIAqDlg=.b5f45615-8923-487e-a44f-ac2cbe4d0629@github.com> Message-ID: <2dMynqzX0IDUwjdSxUJFW67L2qYRapQL0OQ4olr8wa8=.14a49c61-7270-4732-8082-0c2c5c6e932b@github.com> > `TestLoadLibraryDeadlock.java` test runs `LoadLibraryDeadlock` and wait for 5 seconds and then grab the output. Then run `jcmd` to dump the thread stacks in case there is a deadlock. The test ignores and swallows any exception which makes it hard to diagnose test issues. > > This PR simplifies the test to use `jdk.test.lib.process.ProcessTools` to launch `LoadLibraryDeadlock` test so that the output and error will be captured in the same way as other tools are run by this test. Also update the test to propagate exceptions where appropriate. This hopes to collect more information to diagnose the issue if this test fails next time. Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: review feedback: use ProcessTools.createTestJavaProcessBuilder ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16459/files - new: https://git.openjdk.org/jdk/pull/16459/files/a4c8ebae..962690fa Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16459&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16459&range=00-01 Stats: 49 lines in 2 files changed: 15 ins; 20 del; 14 mod Patch: https://git.openjdk.org/jdk/pull/16459.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16459/head:pull/16459 PR: https://git.openjdk.org/jdk/pull/16459 From mchung at openjdk.org Wed Nov 1 19:46:33 2023 From: mchung at openjdk.org (Mandy Chung) Date: Wed, 1 Nov 2023 19:46:33 GMT Subject: RFR: 8317965: TestLoadLibraryDeadlock.java fails with "Unable to load native library.: expected true, was false" [v2] In-Reply-To: <_vus9GqCnUn_0nKV5-kTGZOUhNE5UxPyO9N_n4l9kh4=.d1e819d1-01b1-44d2-844f-f2c3b00bd5be@github.com> References: <4MnsR63BS2cwUGcy8uJBBJyLIiNE4j40wih5PIAqDlg=.b5f45615-8923-487e-a44f-ac2cbe4d0629@github.com> <_vus9GqCnUn_0nKV5-kTGZOUhNE5UxPyO9N_n4l9kh4=.d1e819d1-01b1-44d2-844f-f2c3b00bd5be@github.com> Message-ID: <5HXU9MEvZsEypnvFYknKVKOIW6bMQhWl6EjSB4jCKhM=.0306f017-7e75-456b-8a82-769091e9a6ad@github.com> On Wed, 1 Nov 2023 19:15:15 GMT, Mandy Chung wrote: >> test/jdk/java/lang/ClassLoader/loadLibraryDeadlock/TestLoadLibraryDeadlock.java line 115: >> >>> 113: Collections.addAll(commands, java); >>> 114: Collections.addAll(commands, Utils.getTestJavaOpts()); >>> 115: Collections.addAll(commands, command); >> >> The prose description talks about using ProcessTools, but the runCommand code doesn't use ProcessTools.createTestJavaProcessBuilder. It could save a few steps. > > `runCommand` sets the working directory whereas `ProcessTools.createTestJavaProcessBuilder` does not. Either way is okay with me if we want to use `createTestJavaProcessBuilder` (which will set the VM options). > > > + ProcessBuilder pb = ProcessTools.createTestJavaProcessBuilder("-cp", > + "a.jar" + classPathSeparator + > + "b.jar" + classPathSeparator + > + "c.jar", > + "-Djava.library.path=" + testLibraryPath, > + "LoadLibraryDeadlock") > + .directory(new File(testClassPath)); > + OutputAnalyzer outputAnalyzer = ProcessTools.executeCommand(pb) > + .shouldHaveExitValue(0); > > > or set the class path to the explicit path of the JAR files. Updated to use `createTestJavaProcessBuilder` and more clean up. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16459#discussion_r1379231980 From rriggs at openjdk.org Wed Nov 1 19:53:02 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 1 Nov 2023 19:53:02 GMT Subject: RFR: 8317965: TestLoadLibraryDeadlock.java fails with "Unable to load native library.: expected true, was false" [v2] In-Reply-To: <2dMynqzX0IDUwjdSxUJFW67L2qYRapQL0OQ4olr8wa8=.14a49c61-7270-4732-8082-0c2c5c6e932b@github.com> References: <4MnsR63BS2cwUGcy8uJBBJyLIiNE4j40wih5PIAqDlg=.b5f45615-8923-487e-a44f-ac2cbe4d0629@github.com> <2dMynqzX0IDUwjdSxUJFW67L2qYRapQL0OQ4olr8wa8=.14a49c61-7270-4732-8082-0c2c5c6e932b@github.com> Message-ID: On Wed, 1 Nov 2023 19:46:33 GMT, Mandy Chung wrote: >> `TestLoadLibraryDeadlock.java` test runs `LoadLibraryDeadlock` and wait for 5 seconds and then grab the output. Then run `jcmd` to dump the thread stacks in case there is a deadlock. The test ignores and swallows any exception which makes it hard to diagnose test issues. >> >> This PR simplifies the test to use `jdk.test.lib.process.ProcessTools` to launch `LoadLibraryDeadlock` test so that the output and error will be captured in the same way as other tools are run by this test. Also update the test to propagate exceptions where appropriate. This hopes to collect more information to diagnose the issue if this test fails next time. > > Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: > > review feedback: use ProcessTools.createTestJavaProcessBuilder Looks good. ------------- Marked as reviewed by rriggs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16459#pullrequestreview-1708972035 From darcy at openjdk.org Wed Nov 1 20:39:01 2023 From: darcy at openjdk.org (Joe Darcy) Date: Wed, 1 Nov 2023 20:39:01 GMT Subject: RFR: JDK-8319195: Move tier 1 vector API regression tests to tier 2 In-Reply-To: References: Message-ID: <4Qu905vt0-2akeWVDiNjGi86S3-8K3tvjh5WHmWvqIY=.1e9033ff-9848-470d-8cef-904f1dc6b70b@github.com> On Wed, 1 Nov 2023 19:11:28 GMT, Vladimir Kozlov wrote: > I would suggest to determine the set of tests which run "at most 10 seconds total" and run only them in tier1. Also taking into account API coverage. Okay; I think preserving a handful of tests to check for a dead-on-arrival vector change is acceptable. Here are the sorted running times from my machine, times in milliseconds: VectorHash.jtr:2190 PreferredSpeciesTest_id0.jtr:2545 VectorRuns.jtr:2790 PreferredSpeciesTest_id1.jtr:3228 MethodOverideTest.jtr:3864 CovarOverrideTest.jtr:3993 MismatchTest.jtr:4013 LoadJsvmlTest.jtr:4112 ImageTest.jtr:6074 LongMaxVectorLoadStoreTests.jtr:6197 DoubleMaxVectorLoadStoreTests.jtr:6445 ShortMaxVectorLoadStoreTests.jtr:6692 IntMaxVectorLoadStoreTests.jtr:6868 FloatMaxVectorLoadStoreTests.jtr:6952 ByteMaxVectorLoadStoreTests.jtr:7098 AddTest.jtr:7303 -=-=-=-=-=-=-=-=-=- VectorMaxConversionTests_ZSinglegen.jtr:24001 LongMaxVectorTests.jtr:27290 IntMaxVectorTests.jtr:27349 VectorMaxConversionTests_id0.jtr:27588 VectorMaxConversionTests_ZGenerational.jtr:29138 ShortMaxVectorTests.jtr:29220 FloatMaxVectorTests.jtr:30849 ByteMaxVectorTests.jtr:31206 DoubleMaxVectorTests.jtr:32384 VectorReshapeTests.jtr:39873 The tests below the line take 24 or more seconds to run so would be out of consideration. @vnkozlov , which subset of the above the line regressions tests would be most helpful to preserve? ------------- PR Comment: https://git.openjdk.org/jdk/pull/16437#issuecomment-1789640621 From jlu at openjdk.org Wed Nov 1 21:33:10 2023 From: jlu at openjdk.org (Justin Lu) Date: Wed, 1 Nov 2023 21:33:10 GMT Subject: Integrated: JDK-8317612: ChoiceFormat and MessageFormat constructors call non-final public method In-Reply-To: References: Message-ID: On Thu, 5 Oct 2023 20:44:55 GMT, Justin Lu wrote: > Please review this PR which updates ChoiceFormat and MessageFormat to no longer call overridable methods in their constructors. > > The overridable methods called in the constructors are: _ChoiceFormat::applyPattern_, _ChoiceFormat::setChoices_, and _MessageFormat::applyPattern_. The code should be updated so that both the methods and constructors call a separate private method. Some other drive-by cleanup changes were included in the change as well. This pull request has now been integrated. Changeset: ee57e731 Author: Justin Lu URL: https://git.openjdk.org/jdk/commit/ee57e731d03101ba6508297ef7d895082b04b427 Stats: 53 lines in 2 files changed: 36 ins; 3 del; 14 mod 8317612: ChoiceFormat and MessageFormat constructors call non-final public method Reviewed-by: naoto, lancea ------------- PR: https://git.openjdk.org/jdk/pull/16064 From jlu at openjdk.org Wed Nov 1 21:35:10 2023 From: jlu at openjdk.org (Justin Lu) Date: Wed, 1 Nov 2023 21:35:10 GMT Subject: RFR: 8318466: Improve spec of NumberFormat's methods with unsupported operations Message-ID: Please review this simple change which refines the specification of some NumberFormat methods (with unsupported operations) to separate the API and implementation specification. ------------- Commit messages: - cleanup setRoundingMode() - Merge branch 'master' into JDK-8318466-NumberFormat-Unsupported - reflect review - init Changes: https://git.openjdk.org/jdk/pull/16464/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16464&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8318466 Stats: 36 lines in 1 file changed: 9 ins; 11 del; 16 mod Patch: https://git.openjdk.org/jdk/pull/16464.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16464/head:pull/16464 PR: https://git.openjdk.org/jdk/pull/16464 From kvn at openjdk.org Wed Nov 1 22:03:01 2023 From: kvn at openjdk.org (Vladimir Kozlov) Date: Wed, 1 Nov 2023 22:03:01 GMT Subject: RFR: JDK-8319195: Move tier 1 vector API regression tests to tier 2 In-Reply-To: <4Qu905vt0-2akeWVDiNjGi86S3-8K3tvjh5WHmWvqIY=.1e9033ff-9848-470d-8cef-904f1dc6b70b@github.com> References: <4Qu905vt0-2akeWVDiNjGi86S3-8K3tvjh5WHmWvqIY=.1e9033ff-9848-470d-8cef-904f1dc6b70b@github.com> Message-ID: On Wed, 1 Nov 2023 20:36:38 GMT, Joe Darcy wrote: >> I would suggest to determine the set of tests which run "at most 10 seconds total" and run only them in tier1. >> Also taking into account API coverage. > >> I would suggest to determine the set of tests which run "at most 10 seconds total" and run only them in tier1. Also taking into account API coverage. > > Okay; I think preserving a handful of tests to check for a dead-on-arrival vector change is acceptable. Here are the sorted running times from my machine, times in milliseconds: > > VectorHash.jtr:2190 > PreferredSpeciesTest_id0.jtr:2545 > VectorRuns.jtr:2790 > PreferredSpeciesTest_id1.jtr:3228 > MethodOverideTest.jtr:3864 > CovarOverrideTest.jtr:3993 > MismatchTest.jtr:4013 > LoadJsvmlTest.jtr:4112 > ImageTest.jtr:6074 > LongMaxVectorLoadStoreTests.jtr:6197 > DoubleMaxVectorLoadStoreTests.jtr:6445 > ShortMaxVectorLoadStoreTests.jtr:6692 > IntMaxVectorLoadStoreTests.jtr:6868 > FloatMaxVectorLoadStoreTests.jtr:6952 > ByteMaxVectorLoadStoreTests.jtr:7098 > AddTest.jtr:7303 > -=-=-=-=-=-=-=-=-=- > VectorMaxConversionTests_ZSinglegen.jtr:24001 > LongMaxVectorTests.jtr:27290 > IntMaxVectorTests.jtr:27349 > VectorMaxConversionTests_id0.jtr:27588 > VectorMaxConversionTests_ZGenerational.jtr:29138 > ShortMaxVectorTests.jtr:29220 > FloatMaxVectorTests.jtr:30849 > ByteMaxVectorTests.jtr:31206 > DoubleMaxVectorTests.jtr:32384 > VectorReshapeTests.jtr:39873 > > The tests below the line take 24 or more seconds to run so would be out of consideration. > > @vnkozlov , which subset of the above the line regressions tests would be most helpful to preserve? @jddarcy I think next 3 tests are good for sanity check in tier1: VectorHash.java VectorRuns.java PreferredSpeciesTest.java ------------- PR Comment: https://git.openjdk.org/jdk/pull/16437#issuecomment-1789750419 From darcy at openjdk.org Wed Nov 1 22:07:03 2023 From: darcy at openjdk.org (Joe Darcy) Date: Wed, 1 Nov 2023 22:07:03 GMT Subject: RFR: 8319174: Enhance robustness of some j.m.BigInteger constructors [v2] In-Reply-To: References: <0iccBwbAhAmIPGxnz1bhry2Sj_Kz2xngZmb2lPFCUpU=.c2b7c8ef-4e77-4c8f-a7ec-7c5c0980e59e@github.com> Message-ID: <01UMpUqsOA8YvfKPngunkXo4uSv0wv1Uzv6jwFw-14k=.0fd6663a-af33-41a8-a031-6cb973d36b10@github.com> On Wed, 1 Nov 2023 14:52:23 GMT, Raffaello Giulietti wrote: >> Enhance `java.math.BigInteger` constructors taking a `byte[]` argument by improving guarantees of internal invariants. > > Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: > > Static Random instance. src/java.base/share/classes/java/math/BigInteger.java line 350: > 348: */ > 349: public BigInteger(byte[] val, int off, int len) { > 350: Objects.checkFromIndexSize(off, len, val.length); Does this change which exception get thrown if multiple pre-conditions are violated? That is okay, but if that is the case, the issue should get a quick CSR for the behavioral change. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16449#discussion_r1379377580 From mchung at openjdk.org Wed Nov 1 22:23:13 2023 From: mchung at openjdk.org (Mandy Chung) Date: Wed, 1 Nov 2023 22:23:13 GMT Subject: Integrated: 8317965: TestLoadLibraryDeadlock.java fails with "Unable to load native library.: expected true, was false" In-Reply-To: <4MnsR63BS2cwUGcy8uJBBJyLIiNE4j40wih5PIAqDlg=.b5f45615-8923-487e-a44f-ac2cbe4d0629@github.com> References: <4MnsR63BS2cwUGcy8uJBBJyLIiNE4j40wih5PIAqDlg=.b5f45615-8923-487e-a44f-ac2cbe4d0629@github.com> Message-ID: On Wed, 1 Nov 2023 17:54:00 GMT, Mandy Chung wrote: > `TestLoadLibraryDeadlock.java` test runs `LoadLibraryDeadlock` and wait for 5 seconds and then grab the output. Then run `jcmd` to dump the thread stacks in case there is a deadlock. The test ignores and swallows any exception which makes it hard to diagnose test issues. > > This PR simplifies the test to use `jdk.test.lib.process.ProcessTools` to launch `LoadLibraryDeadlock` test so that the output and error will be captured in the same way as other tools are run by this test. Also update the test to propagate exceptions where appropriate. This hopes to collect more information to diagnose the issue if this test fails next time. This pull request has now been integrated. Changeset: 5207443b Author: Mandy Chung URL: https://git.openjdk.org/jdk/commit/5207443b360cfe3ee9c53ece55da3464c13f6a9f Stats: 108 lines in 2 files changed: 16 ins; 73 del; 19 mod 8317965: TestLoadLibraryDeadlock.java fails with "Unable to load native library.: expected true, was false" Reviewed-by: rriggs ------------- PR: https://git.openjdk.org/jdk/pull/16459 From mchung at openjdk.org Thu Nov 2 01:06:19 2023 From: mchung at openjdk.org (Mandy Chung) Date: Thu, 2 Nov 2023 01:06:19 GMT Subject: RFR: 8319265: TestLoadLibraryDeadlock.java fails on windows-x64 "Unable to load b.jar" Message-ID: The test fails on windows because unmatched comparison of `Path.toString()` vs `URL.getPath().toString()` after JDK-8317965. A simple fix is to evaluate the JAR file path in the same way as `LoadLibraryDeadlock` does. ------------- Commit messages: - 8319265: TestLoadLibraryDeadlock.java fails on windows-x64 "Unable to load b.jar" Changes: https://git.openjdk.org/jdk/pull/16466/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16466&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8319265 Stats: 8 lines in 1 file changed: 4 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/16466.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16466/head:pull/16466 PR: https://git.openjdk.org/jdk/pull/16466 From darcy at openjdk.org Thu Nov 2 02:02:18 2023 From: darcy at openjdk.org (Joe Darcy) Date: Thu, 2 Nov 2023 02:02:18 GMT Subject: RFR: JDK-8319195: Move tier 1 vector API regression tests to tier 2 [v2] In-Reply-To: References: Message-ID: > Due to their longer-than-typical running time and because the vector API is not (yet) in the base module, move the vector API tests in tier 1 to tier 2. Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Respond to review feedback. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16437/files - new: https://git.openjdk.org/jdk/pull/16437/files/1bcf2e37..209e9c5e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16437&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16437&range=00-01 Stats: 22 lines in 1 file changed: 1 ins; 21 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/16437.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16437/head:pull/16437 PR: https://git.openjdk.org/jdk/pull/16437 From darcy at openjdk.org Thu Nov 2 02:02:19 2023 From: darcy at openjdk.org (Joe Darcy) Date: Thu, 2 Nov 2023 02:02:19 GMT Subject: RFR: JDK-8319195: Move tier 1 vector API regression tests to tier 2 In-Reply-To: <4Qu905vt0-2akeWVDiNjGi86S3-8K3tvjh5WHmWvqIY=.1e9033ff-9848-470d-8cef-904f1dc6b70b@github.com> References: <4Qu905vt0-2akeWVDiNjGi86S3-8K3tvjh5WHmWvqIY=.1e9033ff-9848-470d-8cef-904f1dc6b70b@github.com> Message-ID: On Wed, 1 Nov 2023 20:36:38 GMT, Joe Darcy wrote: >> I would suggest to determine the set of tests which run "at most 10 seconds total" and run only them in tier1. >> Also taking into account API coverage. > >> I would suggest to determine the set of tests which run "at most 10 seconds total" and run only them in tier1. Also taking into account API coverage. > > Okay; I think preserving a handful of tests to check for a dead-on-arrival vector change is acceptable. Here are the sorted running times from my machine, times in milliseconds: > > VectorHash.jtr:2190 > PreferredSpeciesTest_id0.jtr:2545 > VectorRuns.jtr:2790 > PreferredSpeciesTest_id1.jtr:3228 > MethodOverideTest.jtr:3864 > CovarOverrideTest.jtr:3993 > MismatchTest.jtr:4013 > LoadJsvmlTest.jtr:4112 > ImageTest.jtr:6074 > LongMaxVectorLoadStoreTests.jtr:6197 > DoubleMaxVectorLoadStoreTests.jtr:6445 > ShortMaxVectorLoadStoreTests.jtr:6692 > IntMaxVectorLoadStoreTests.jtr:6868 > FloatMaxVectorLoadStoreTests.jtr:6952 > ByteMaxVectorLoadStoreTests.jtr:7098 > AddTest.jtr:7303 > -=-=-=-=-=-=-=-=-=- > VectorMaxConversionTests_ZSinglegen.jtr:24001 > LongMaxVectorTests.jtr:27290 > IntMaxVectorTests.jtr:27349 > VectorMaxConversionTests_id0.jtr:27588 > VectorMaxConversionTests_ZGenerational.jtr:29138 > ShortMaxVectorTests.jtr:29220 > FloatMaxVectorTests.jtr:30849 > ByteMaxVectorTests.jtr:31206 > DoubleMaxVectorTests.jtr:32384 > VectorReshapeTests.jtr:39873 > > The tests below the line take 24 or more seconds to run so would be out of consideration. > > @vnkozlov , which subset of the above the line regressions tests would be most helpful to preserve? > @jddarcy I think next 3 tests are good for sanity check in tier1: > > VectorHash.java VectorRuns.java PreferredSpeciesTest.java Changeset implementing that pushed. Double-check on tier1: $ diff tier1.txt tier1-patched.txt 108,123d107 < jdk/incubator/vector/AddTest.java < jdk/incubator/vector/ByteMaxVectorLoadStoreTests.java < jdk/incubator/vector/ByteMaxVectorTests.java < jdk/incubator/vector/CovarOverrideTest.java < jdk/incubator/vector/DoubleMaxVectorLoadStoreTests.java < jdk/incubator/vector/DoubleMaxVectorTests.java < jdk/incubator/vector/FloatMaxVectorLoadStoreTests.java < jdk/incubator/vector/FloatMaxVectorTests.java < jdk/incubator/vector/ImageTest.java < jdk/incubator/vector/IntMaxVectorLoadStoreTests.java < jdk/incubator/vector/IntMaxVectorTests.java < jdk/incubator/vector/LoadJsvmlTest.java < jdk/incubator/vector/LongMaxVectorLoadStoreTests.java < jdk/incubator/vector/LongMaxVectorTests.java < jdk/incubator/vector/MethodOverideTest.java < jdk/incubator/vector/MismatchTest.java 126,127d109 < jdk/incubator/vector/ShortMaxVectorLoadStoreTests.java < jdk/incubator/vector/ShortMaxVectorTests.java 129,132d110 < jdk/incubator/vector/VectorMaxConversionTests.java#id0 < jdk/incubator/vector/VectorMaxConversionTests.java#ZGenerational < jdk/incubator/vector/VectorMaxConversionTests.java#ZSinglegen < jdk/incubator/vector/VectorReshapeTests.java 2410c2388 < Tests found: 2,408 --- > Tests found: 2,386 Tier 2 is unchanged from before the PR. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16437#issuecomment-1789941119 From jiefu at openjdk.org Thu Nov 2 02:14:05 2023 From: jiefu at openjdk.org (Jie Fu) Date: Thu, 2 Nov 2023 02:14:05 GMT Subject: RFR: JDK-8319195: Move tier 1 vector API regression tests to tier 2 [v2] In-Reply-To: References: Message-ID: On Thu, 2 Nov 2023 02:02:18 GMT, Joe Darcy wrote: >> Due to their longer-than-typical running time and because the vector API is not (yet) in the base module, move the vector API tests in tier 1 to tier 2. > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > Respond to review feedback. LGTM If tier2 is unchanged after this patch, it would be good to change the JBS title. Thanks. ------------- Marked as reviewed by jiefu (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16437#pullrequestreview-1709332381 From ccheung at openjdk.org Thu Nov 2 02:48:34 2023 From: ccheung at openjdk.org (Calvin Cheung) Date: Thu, 2 Nov 2023 02:48:34 GMT Subject: RFR: 8316969: Improve CDS module graph support for --module option [v9] In-Reply-To: References: Message-ID: > Please review this changeset for adding support for `--module` (-m) option for CDS. > Changes in the `ModuleBootstrap.java` are needed so that the `ArchivedModuleGraph.archive` and `ArchivedBootLayer.archive` are called if the main module is specified. The module name will be stored in the ro region of the CDS archive. During runtime, the archived module name will be compared with the runtime module name. If comparison fails, the archived full module graph won't be used. > > Note: this RFE is a subtask of [JDK-8266329](https://bugs.openjdk.org/browse/JDK-8266329). More subtask(s) will be created to support other options such as `--add-modules`. > > Passed tiers 1 - 4 testing. Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: cleanup suggested by Ioi ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16016/files - new: https://git.openjdk.org/jdk/pull/16016/files/b214fa7c..7a34c6ef Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16016&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16016&range=07-08 Stats: 6 lines in 2 files changed: 0 ins; 1 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/16016.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16016/head:pull/16016 PR: https://git.openjdk.org/jdk/pull/16016 From iklam at openjdk.org Thu Nov 2 03:36:08 2023 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 2 Nov 2023 03:36:08 GMT Subject: RFR: 8316969: Improve CDS module graph support for --module option [v9] In-Reply-To: References: Message-ID: On Thu, 2 Nov 2023 02:48:34 GMT, Calvin Cheung wrote: >> Please review this changeset for adding support for `--module` (-m) option for CDS. >> Changes in the `ModuleBootstrap.java` are needed so that the `ArchivedModuleGraph.archive` and `ArchivedBootLayer.archive` are called if the main module is specified. The module name will be stored in the ro region of the CDS archive. During runtime, the archived module name will be compared with the runtime module name. If comparison fails, the archived full module graph won't be used. >> >> Note: this RFE is a subtask of [JDK-8266329](https://bugs.openjdk.org/browse/JDK-8266329). More subtask(s) will be created to support other options such as `--add-modules`. >> >> Passed tiers 1 - 4 testing. > > Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: > > cleanup suggested by Ioi The latest changes look good. ------------- Marked as reviewed by iklam (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16016#pullrequestreview-1709394704 From darcy at openjdk.org Thu Nov 2 03:52:00 2023 From: darcy at openjdk.org (Joe Darcy) Date: Thu, 2 Nov 2023 03:52:00 GMT Subject: RFR: JDK-8319195: Move most tier 1 vector API regression tests to tier 3 [v2] In-Reply-To: References: Message-ID: On Thu, 2 Nov 2023 02:11:19 GMT, Jie Fu wrote: > LGTM > > If tier2 is unchanged after this patch, it would be good to change the JBS title. Thanks. Good point; bug and PR titles updated accordingly. Thanks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16437#issuecomment-1790019451 From kvn at openjdk.org Thu Nov 2 05:17:06 2023 From: kvn at openjdk.org (Vladimir Kozlov) Date: Thu, 2 Nov 2023 05:17:06 GMT Subject: RFR: JDK-8319195: Move most tier 1 vector API regression tests to tier 3 [v2] In-Reply-To: References: Message-ID: On Thu, 2 Nov 2023 02:02:18 GMT, Joe Darcy wrote: >> Due to their longer-than-typical running time and because the vector API is not (yet) in the base module, move the vector API tests in tier 1 to tier 2. > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > Respond to review feedback. Good ------------- Marked as reviewed by kvn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16437#pullrequestreview-1709468707 From jpai at openjdk.org Thu Nov 2 06:41:01 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 2 Nov 2023 06:41:01 GMT Subject: RFR: 8319265: TestLoadLibraryDeadlock.java fails on windows-x64 "Unable to load b.jar" In-Reply-To: References: Message-ID: On Thu, 2 Nov 2023 01:00:38 GMT, Mandy Chung wrote: > The test fails on windows because unmatched comparison of `Path.toString()` vs `URL.getPath().toString()` after JDK-8317965. A simple fix is to evaluate the JAR file path in the same way as `LoadLibraryDeadlock` does. Marked as reviewed by jpai (Reviewer). test/jdk/java/lang/ClassLoader/loadLibraryDeadlock/TestLoadLibraryDeadlock.java line 185: > 183: > 184: private static String toLocationString(Path path) { > 185: return path.toUri().getPath(); Hello Mandy, this looks OK to me. Because the `LoadLibraryDeadlock.getLocation()` uses `URL.getPath()` to print the message in the logs, maybe for consistency and to rule out any unexpected differences, perhaps use `path.toUri().toURL().getPath()` instead? ------------- PR Review: https://git.openjdk.org/jdk/pull/16466#pullrequestreview-1709542898 PR Review Comment: https://git.openjdk.org/jdk/pull/16466#discussion_r1379653401 From jpai at openjdk.org Thu Nov 2 06:46:00 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 2 Nov 2023 06:46:00 GMT Subject: RFR: 8319153: Fix: Class is a raw type in ProcessTools In-Reply-To: References: Message-ID: On Tue, 31 Oct 2023 07:43:43 GMT, Leo Korinth wrote: > Changing from `Class c` to `Class c` removes two warnings. Marked as reviewed by jpai (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/16431#pullrequestreview-1709548049 From jpai at openjdk.org Thu Nov 2 06:51:00 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 2 Nov 2023 06:51:00 GMT Subject: RFR: 8315680: java/lang/ref/ReachabilityFenceTest.java should run with -Xbatch In-Reply-To: References: Message-ID: On Tue, 3 Oct 2023 07:47:30 GMT, Gerg? Barany wrote: > This test requires certain methods to be compiled, but without `-Xbatch` the compiler races against the test code, which can lead to intermittent failures. Adding hotspot label because from the looks of this change, it appears to require someone from that area to review this. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16023#issuecomment-1790163370 From pminborg at openjdk.org Thu Nov 2 07:45:18 2023 From: pminborg at openjdk.org (Per Minborg) Date: Thu, 2 Nov 2023 07:45:18 GMT Subject: RFR: 8319166: Typos in the JavaDocs for MemorySegment Message-ID: This PR proposes to fix a number of JavaDoc typos in the `MemorySegment::getAtIndex` and `::setAtIndex`. ------------- Commit messages: - Fix typos in the JavaDocs for MemorySegment Changes: https://git.openjdk.org/jdk/pull/16469/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16469&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8319166 Stats: 36 lines in 1 file changed: 0 ins; 0 del; 36 mod Patch: https://git.openjdk.org/jdk/pull/16469.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16469/head:pull/16469 PR: https://git.openjdk.org/jdk/pull/16469 From alanb at openjdk.org Thu Nov 2 07:48:05 2023 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 2 Nov 2023 07:48:05 GMT Subject: RFR: JDK-8315458 Implementation of Implicitly Declared Classes and Instance Main Method (Second Preview) [v2] In-Reply-To: References: Message-ID: On Wed, 1 Nov 2023 19:14:22 GMT, Jim Laskey wrote: >> Address changes from JEP 445 to JEP 463. >> >> - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. >> >> - Don't mark class on read. >> >> - Remove reflection and annotation processing related to unnamed classes. >> >> - Simplify main method search. > > Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: > > Remove obsolete tests There's a number of .orig files that seem to have been checked in by mistake. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16461#issuecomment-1790224015 From duke at openjdk.org Thu Nov 2 10:40:03 2023 From: duke at openjdk.org (null) Date: Thu, 2 Nov 2023 10:40:03 GMT Subject: RFR: 8317545: AIX PPC64: Implementation of Foreign Function & Memory API [v5] In-Reply-To: References: Message-ID: <5TmIjDioT9Hglhpi2Nf5_FOgv_bUdehiWK9z-gvJlMI=.d4c82032-508a-431a-bfa5-d488942167b2@github.com> On Tue, 17 Oct 2023 14:17:20 GMT, Martin Doerr wrote: >> The AIX linker has a few minor diffs to the linux ABIv1 linker. In addition, double values have only 4 Byte alignment within structures. This PR is based on JDK22 version of the FFI. > > Martin Doerr has updated the pull request incrementally with two additional commits since the last revision: > > - Improve handling of layouts in NativeType.java > - Check byte order of 4-byte aligned double. looks good to me. Tested the changes from my end. ------------- Marked as reviewed by suchismith1993 at github.com (no known OpenJDK username). PR Review: https://git.openjdk.org/jdk/pull/16179#pullrequestreview-1709930836 From hannesw at openjdk.org Thu Nov 2 10:57:15 2023 From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Thu, 2 Nov 2023 10:57:15 GMT Subject: RFR: JDK-8315921: Invalid CSS declarations in java.lang class documentation [v2] In-Reply-To: References: 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. Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision: Find and fix more invalid CSS declarations ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15762/files - new: https://git.openjdk.org/jdk/pull/15762/files/cf60279a..29b2065f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15762&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15762&range=00-01 Stats: 40 lines in 4 files changed: 0 ins; 0 del; 40 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 mcimadamore at openjdk.org Thu Nov 2 11:04:06 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Thu, 2 Nov 2023 11:04:06 GMT Subject: RFR: JDK-8315458 Implementation of Implicitly Declared Classes and Instance Main Method (Second Preview) [v2] In-Reply-To: References: Message-ID: On Wed, 1 Nov 2023 19:14:22 GMT, Jim Laskey wrote: >> Address changes from JEP 445 to JEP 463. >> >> - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. >> >> - Don't mark class on read. >> >> - Remove reflection and annotation processing related to unnamed classes. >> >> - Simplify main method search. > > Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: > > Remove obsolete tests src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java line 4057: > 4055: Name name = names.fromString(simplename); > 4056: JCModifiers implicitMods = F.at(Position.NOPOS) > 4057: .Modifiers(Flags.FINAL|Flags.MANDATED|Flags.IMPLICIT_CLASS, List.nil()); I don't think the JVMS allows for a flag to have ACC_MANDATED flags? It is a limitation of the class file format that only formal parameters and modules can be flagged as ACC_MANDATED ([?4.7.24](https://docs.oracle.com/javase/specs/jvms/se21/html/jvms-4.html#jvms-4.7.24), [?4.7.25](https://docs.oracle.com/javase/specs/jvms/se21/html/jvms-4.html#jvms-4.7.25)) to indicate that, despite being compiler-generated, they are not considered implementation artifacts. There is no way to flag other compiler-generated constructs so that they too are not considered implementation artifacts (JLS ?13.1). This limitation means that reflective APIs of the Java SE Platform may not accurately indicate the "mandated" status of such constructs. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16461#discussion_r1379931703 From mcimadamore at openjdk.org Thu Nov 2 11:15:04 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Thu, 2 Nov 2023 11:15:04 GMT Subject: RFR: JDK-8315458 Implementation of Implicitly Declared Classes and Instance Main Method (Second Preview) [v2] In-Reply-To: References: Message-ID: On Wed, 1 Nov 2023 19:14:22 GMT, Jim Laskey wrote: >> Address changes from JEP 445 to JEP 463. >> >> - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. >> >> - Don't mark class on read. >> >> - Remove reflection and annotation processing related to unnamed classes. >> >> - Simplify main method search. > > Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: > > Remove obsolete tests src/jdk.compiler/share/classes/com/sun/tools/javac/code/Source.java line 249: > 247: STRING_TEMPLATES(JDK21, Fragments.FeatureStringTemplates, DiagKind.PLURAL), > 248: UNNAMED_CLASSES(JDK21, Fragments.FeatureUnnamedClasses, DiagKind.PLURAL), > 249: IMPLICIT_CLASSES(JDK21, Fragments.FeatureImplicitClasses, DiagKind.PLURAL), Should this be JDK22? src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Enter.java line 442: > 440: Errors.ClassPublicShouldBeInFile(topElement, tree.name)); > 441: } > 442: if ((tree.mods.flags & IMPLICIT_CLASS) != 0) { I'm not 100% sure about this. Another option would be to tweak Resolve::findType and make sure that `typeNotFound` (or some more specific message!) is returned when an implicit class is referred to by name. If you look at the first few lines in that method you will see: if (name == names.empty) return typeNotFound; // do not allow inadvertent "lookup" of anonymous types So, there's already some logic there for skipping some types. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16461#discussion_r1379942927 PR Review Comment: https://git.openjdk.org/jdk/pull/16461#discussion_r1379940717 From mcimadamore at openjdk.org Thu Nov 2 11:21:08 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Thu, 2 Nov 2023 11:21:08 GMT Subject: RFR: JDK-8315458 Implementation of Implicitly Declared Classes and Instance Main Method (Second Preview) [v2] In-Reply-To: References: Message-ID: <5_K9YYjKcoj4kFnNXrHm_f2GbX1gCZrv60BeBTreEWY=.6b0f0615-4c5e-4200-a8d2-5ce5825b391a@github.com> On Wed, 1 Nov 2023 19:14:22 GMT, Jim Laskey wrote: >> Address changes from JEP 445 to JEP 463. >> >> - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. >> >> - Don't mark class on read. >> >> - Remove reflection and annotation processing related to unnamed classes. >> >> - Simplify main method search. > > Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: > > Remove obsolete tests test/langtools/tools/javac/processing/model/element/TestUnnamedClass.java line 1: > 1: /* Is the implicit class no longer discoverable through annotation processing? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16461#discussion_r1379949276 From hannesw at openjdk.org Thu Nov 2 11:21:07 2023 From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Thu, 2 Nov 2023 11:21:07 GMT Subject: RFR: JDK-8315921: Invalid CSS declarations in java.lang class documentation [v2] In-Reply-To: <7QjkX0HCOF65hls1-LgZqqr9MblbizFVp7ZFwkQ85XM=.dd128603-e487-4f04-a01d-8219bc720f7f@github.com> References: <7QjkX0HCOF65hls1-LgZqqr9MblbizFVp7ZFwkQ85XM=.dd128603-e487-4f04-a01d-8219bc720f7f@github.com> Message-ID: On Wed, 25 Oct 2023 09:04:37 GMT, Jaikiran Pai wrote: >> Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision: >> >> Find and fix more invalid CSS declarations > > Hello Hannes, the changes look fine to me. I wasn't aware we had custom CSS usage within javadoc tags in the JDK. Thanks for the review, @jaikiran. I had found the issues in the original commit just by accidental browsing of the API docs and had assumed they were one-off errors. Now searching over OpenJDK sources again for these errors I found a lot more, most of them in `java.text.MessageFormat`. I fixed these in a second commit. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15762#issuecomment-1790536378 From hannesw at openjdk.org Thu Nov 2 11:27:04 2023 From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Thu, 2 Nov 2023 11:27:04 GMT Subject: RFR: JDK-8315921: Invalid CSS declarations in java.lang class documentation [v2] In-Reply-To: References: <7QjkX0HCOF65hls1-LgZqqr9MblbizFVp7ZFwkQ85XM=.dd128603-e487-4f04-a01d-8219bc720f7f@github.com> Message-ID: On Wed, 25 Oct 2023 09:09:07 GMT, Jaikiran Pai wrote: >> src/java.base/share/classes/java/lang/Thread.java line 192: >> >>> 190: * with the following system properties: >>> 191: * >>> 192: * >> >> Just out of curiosity, is that semi-colon even needed, or would `display:none` be enough? > > Now that I think about it, do you know why the `display:none` is being set here? I have very limited knowledge of CSS, wouldn't the use of `display:none` make the `System Properties` caption text invisible? Indeed, the semi-colon is optional at the end of an inline CSS attribute. I removed it in my follow-up commit. Regarding the presence of invisible ` Gatherer> windowSliding(int windowSize) { > > From my experience, sliding window with windowSize = 2 is the most important and deserves the explicit support (I have such an operation in my StreamEx library and it's used quite often). Please consider adding (name subject to discussions): > > `public static Gatherer pairMap(BiFunction functionToApplyToTwoAdjacentElements)`. It could be more optimal, as you only need to store the previous element. Moreover, I believe one can implement a proper combiner to make it parallel-friendly. Could be added separately after this PR is merged. I can contribute it. @amaembo pairMap should be straight-forward to implement. And regarding parallelization I don't think that will necessarily work since it would not be able to run incrementally (depth-first). > src/java.base/share/classes/java/util/stream/Gatherers.java line 403: > >> 401: // Integrator >> 402: Integrator.ofGreedy((window, e, downstream) -> { >> 403: window.addLast(e); > > Too bad it will reject null elements in the current implementation. This should be documented, or better fixed. We can use ArrayList and keep track of the current start index, and export slides manually using arraycopy twice and `listFromTrustedArrayNullsAllowed`. It's only a little bit trickier and should not be slower than the current implementation. I can write it if you don't want to do it by yourself :-) Took a stab at reimplementing both windowFixed and windowSliding to allow null elements in the stream: https://github.com/openjdk/jdk/pull/16420/commits/57fea44ce71ae94107f3fb6d7f104d35839371d9 > src/java.base/share/classes/java/util/stream/Gatherers.java line 436: > >> 434: * Stream.of(1,2,3,4,5,6,7,8,9) >> 435: * .gather( >> 436: * Gatherers.fold(() -> "", (string, number) -> string + number) > > This particular sample is not great, as it's totally replaceable with reduce() (`map(String::valueOf).reduce(String::concat)`), so users may wonder why using fold instead. I can suggest another sample which I show everywhere: > `anyList.stream().gather(Gatherers.fold(() -> 1, (acc, e) -> acc * 31 + Objects.hashCode(e))).findFirst().get();` > (haven't tested, but the idea is like this) > It computes the hashCode of the list, according to the list specification. Here, the accumulator is inherently non-associative, so if you replace it with `reduce()` and make the stream parallel, it will yield the wrong result. But `Gatherers.fold` will work! > > If you don't like it, we can think up something else, but concatenation sample is certainly not good. Perhaps the best thing here is to change such that the supplier supplies something non-zero like "String: "? > src/java.base/share/classes/java/util/stream/Gatherers.java line 450: > >> 448: * @throws NullPointerException if any of the parameters are null >> 449: */ >> 450: public static Gatherer fold( > > Should it be explicitly named as `foldLeft`? Because `foldRight` is also possible (though will require complete stream buffering). Also see [JDK-8133680](https://bugs.openjdk.org/browse/JDK-8133680) and [JDK-8292845](https://bugs.openjdk.org/browse/JDK-8292845) (probably should be linked to gatherer's issue, and read the comment about naming) TBH I don't think `foldRight` makes much sense for potentially unbounded structures such as Stream. In the case you need it, it might be better to export it to a List and then reversing it. > src/java.base/share/classes/java/util/stream/Gatherers.java line 482: > >> 480: * @throws NullPointerException if any of the parameters are null >> 481: */ >> 482: public static Gatherer scan( > > Similarly, probably should be named `scanLeft`? That's a good question, and here's my thinking?`scanRight` doesn't make any sense for a construct which supports unboundedness, so if we were discussing *Collections* I'd be more inclined to agree (but it is more likely that reversing the collection and then calling scanLeft would be better). ------------- PR Comment: https://git.openjdk.org/jdk/pull/16420#issuecomment-1798197056 PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1382925138 PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1382927064 PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1383126657 PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1383135200 PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1383597640 PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1383603310 PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1383147855 PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1383605841 PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1383151321 From vklang at openjdk.org Wed Nov 8 15:41:27 2023 From: vklang at openjdk.org (Viktor Klang) Date: Wed, 8 Nov 2023 15:41:27 GMT Subject: RFR: JDK-8319123 : Implementation of JEP-461: Stream Gatherers (Preview) In-Reply-To: References: Message-ID: On Mon, 30 Oct 2023 15:38:35 GMT, Viktor Klang wrote: > This is a Draft PR for [JEP-461](https://openjdk.org/jeps/461) src/java.base/share/classes/java/util/stream/AbstractPipeline.java line 88: > 86: */ > 87: @SuppressWarnings("rawtypes") > 88: protected final AbstractPipeline previousStage; Making this accessible in subclasses allows to avoid having to store this reference twice, and since this value is passed in during ctor it doesn't expose something previously hidden. src/java.base/share/classes/java/util/stream/AbstractPipeline.java line 223: > 221: previousStage.linkedOrConsumed = true; > 222: > 223: previousPreviousStage.nextStage = this; This allows subclasses to replace the "end" of a pipeline with a new "end" presuming that the previous "end" is not linked nor consumed. As an example, it allows a GathererOp(gathererA) to be replaced with a GathererOp(gathererA.andThen(gathererB)) src/java.base/share/classes/java/util/stream/AbstractPipeline.java line 242: > 240: } > 241: > 242: // Terminal evaluation methods This is needed in order to let subclasses override terminal operations such as, but not limited to, `collect`. (since a terminal operation needs to mark the entire pipeline as consumed). src/java.base/share/classes/java/util/stream/AbstractPipeline.java line 444: > 442: spliterator = sourceStage.sourceSpliterator; > 443: sourceStage.sourceSpliterator = null; > 444: } Needed to make this visible to subclasses in order to implement terminal-operations. src/java.base/share/classes/java/util/stream/Gatherer.java line 171: > 169: * parallelized by initializing each partition in separation, invoking > 170: * the integrator until it returns {@code false}, and then joining each > 171: * partitions state using the combiner, and then invoking the finalizer on Suggestion: * partitions state using the combiner, and then invoking the finisher on src/java.base/share/classes/java/util/stream/ReferencePipeline.java line 692: > 690: && (collector.characteristics().contains(Collector.Characteristics.CONCURRENT)) > 691: && (!isOrdered() || collector.characteristics().contains(Collector.Characteristics.UNORDERED))) { > 692: container = collector.supplier().get(); Un-final:ed to allow GathererOp to implement fusion of gather + collect ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1377573665 PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1377572502 PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1377574668 PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1377575538 PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1378972593 PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1377576412 From tvaleev at openjdk.org Wed Nov 8 15:41:15 2023 From: tvaleev at openjdk.org (Tagir F. Valeev) Date: Wed, 8 Nov 2023 15:41:15 GMT Subject: RFR: JDK-8319123 : Implementation of JEP-461: Stream Gatherers (Preview) In-Reply-To: References: Message-ID: On Mon, 30 Oct 2023 15:38:35 GMT, Viktor Klang wrote: > This is a Draft PR for [JEP-461](https://openjdk.org/jeps/461) Very solid work, thank you! See some minor comments inline. I actually have much more ideas of specific gatherers, but they could be discussed separately. One thing that bothers me is that Gatherer is similar to Collector, yet the APIs are totally different, so users may be confused. I like the Gatherer API much more and I see that evolving current Collector API might be hard, given tons of third-party implementations, so I don't see a good way to fix this. But probably we should provide Collector-to-Gatherer adapter (producing one-element stream)? And in general, it would be nice to use exactly-one-element-producing-gatherers as terminal operations, without explicit findFirst().get(). src/java.base/share/classes/java/util/stream/AbstractPipeline.java line 191: > 189: * existing pipeline. > 190: * > 191: * The previous stage must be unlinked and unconsumed. Note that linebreak in Javadoc is normally ignored. It's probably better to add an explicit `

`. This way it will be rendered better in IDE documentation view. src/java.base/share/classes/java/util/stream/Gatherer.java line 99: > 97: * public static Gatherer map(Function mapper) { > 98: * return Gatherer.of( > 99: * (unused, element, downstream) -> // integrator As [JEP 456](https://openjdk.org/jeps/456) is already integrated, probably it's reasonable to use `(_, element, downstream) ->` here? src/java.base/share/classes/java/util/stream/Gatherer.java line 118: > 116: * } > 117: * > 118: * AS an example, in order to create a gatherer to implement a sequential AS -> As (lowercase 's') src/java.base/share/classes/java/util/stream/Gatherer.java line 119: > 117: * > 118: * AS an example, in order to create a gatherer to implement a sequential > 119: * Prefix Scan as a Gatherer, it could be done the following way: Do we need 'Prefix Scan' in title case? src/java.base/share/classes/java/util/stream/Gatherer.java line 252: > 250: * Gatherer as input that Gatherer > 251: */ > 252: default Gatherer andThen(Gatherer that) { It would be great to remove AA type parameter, which is mentioned only once, so could be replaced with `?`. This will improve user experience if they happen to need to specify type parameters explicitly. src/java.base/share/classes/java/util/stream/Gatherer.java line 272: > 270: * Returns a combiner which is the default combiner of a Gatherer. > 271: * The returned combiner identifies that the owning Gatherer must only > 272: * be evaluated sequentially. Should we specify that a single shared instance is guaranteed to be returned, so clients may use `combiner == defaultCombiner()`, rather than `combiner.equals(defaultCombiner())`? src/java.base/share/classes/java/util/stream/Gatherer.java line 308: > 306: */ > 307: static Gatherer ofSequential( > 308: Integrator integrator) { Probably PECS signature `? super T, ? extends R` could be useful here? src/java.base/share/classes/java/util/stream/Gatherer.java line 330: > 328: static Gatherer ofSequential( > 329: Integrator integrator, > 330: BiConsumer> finisher) { Probably, accepting `Consumer>` and adapting it would be more user-friendly? src/java.base/share/classes/java/util/stream/Gatherer.java line 351: > 349: * @return the new {@code Gatherer} > 350: */ > 351: static Gatherer ofSequential( There are two two-function overloads: > ofSequential(Integrator, BiConsumer>) and > ofSequential(Supplier, Integrator) While the functional parameters have clearly different signatures, and one will have no problems with lambdas, it's possible that resolve will fail if you use overloaded method references: > ofSequential(A::b, C::d) Assume that there are several A::b and C::d methods accepting different number of parameters. In this case, one cannot use method references. This is probably a minor problem, but I prefer to avoid overloads accepting the same number of functions. Probably we may use more descriptive names, like `ofSequentialStateless` for stateless overloads? src/java.base/share/classes/java/util/stream/GathererOp.java line 162: > 160: * consideration at this point doesn't yield any performance gains. > 161: */ > 162: proceed &= integrator.integrate(state, t, this); Note that you are exposing the `GatherSink` object to the clients, and it implements a public `Consumer` interface. Clients may use `((Consumer)downstream).accept(something)`, which may produce unpredictable results. Not sure if this is considered to be a problem, but somebody will certainly try to do this! src/java.base/share/classes/java/util/stream/Gatherers.java line 347: > 345: return Gatherer.ofSequential( > 346: // Initializer > 347: () -> new ArrayList<>(windowSize), Note that if `windowSize` happens to be much bigger than the stream size (e.g., 1_000_000_000), we will waste a lot of memory and may fail with OutOfMemoryError for no reason, instead of collecting the whole stream into a single window. Not sure whether we should do anything with this. Probably using `SpinedBuffer` and limiting the initial size, like `Math.min(windowSize, 1_000_000)` will be better. WDYT? src/java.base/share/classes/java/util/stream/Gatherers.java line 355: > 353: return true; > 354: } else { > 355: var full = List.copyOf(window); Here, we are rejecting `null` stream elements for no particular reason. Let's use `SharedSecrets.getJavaUtilCollectionAccess().listFromTrustedArrayNullsAllowed(window.toArray())` instead? src/java.base/share/classes/java/util/stream/Gatherers.java line 364: > 362: (window, downstream) -> { > 363: if(!downstream.isRejecting() && !window.isEmpty()) > 364: downstream.push(List.copyOf(window)); Similarly, let's use `SharedSecrets.getJavaUtilCollectionAccess().listFromTrustedArrayNullsAllowed(window.toArray())` src/java.base/share/classes/java/util/stream/Gatherers.java line 389: > 387: * @throws IllegalArgumentException when windowSize is less than 1 > 388: */ > 389: public static

Gatherer> windowSliding(int windowSize) { >From my experience, sliding window with windowSize = 2 is the most important and deserves the explicit support (I have such an operation in my StreamEx library and it's used quite often). Please consider adding (name subject to discussions): `public static Gatherer pairMap(BiFunction functionToApplyToTwoAdjacentElements)`. It could be more optimal, as you only need to store the previous element. Moreover, I believe one can implement a proper combiner to make it parallel-friendly. Could be added separately after this PR is merged. I can contribute it. src/java.base/share/classes/java/util/stream/Gatherers.java line 403: > 401: // Integrator > 402: Integrator.ofGreedy((window, e, downstream) -> { > 403: window.addLast(e); Too bad it will reject null elements in the current implementation. This should be documented, or better fixed. We can use ArrayList and keep track of the current start index, and export slides manually using arraycopy twice and `listFromTrustedArrayNullsAllowed`. It's only a little bit trickier and should not be slower than the current implementation. I can write it if you don't want to do it by yourself :-) src/java.base/share/classes/java/util/stream/Gatherers.java line 426: > 424: * transformation for scenarios where no combiner-function can be > 425: * implemented, or for reductions which are intrinsically > 426: * order-dependent. I think, we should highlight the most important difference between `fold` and `reduce`: `reduce` must provide an associative function, while `fold` does not require this restriction. src/java.base/share/classes/java/util/stream/Gatherers.java line 436: > 434: * Stream.of(1,2,3,4,5,6,7,8,9) > 435: * .gather( > 436: * Gatherers.fold(() -> "", (string, number) -> string + number) This particular sample is not great, as it's totally replaceable with reduce() (`map(String::valueOf).reduce(String::concat)`), so users may wonder why using fold instead. I can suggest another sample which I show everywhere: `anyList.stream().gather(Gatherers.fold(() -> 1, (acc, e) -> acc * 31 + Objects.hashCode(e))).findFirst().get();` (haven't tested, but the idea is like this) It computes the hashCode of the list, according to the list specification. Here, the accumulator is inherently non-associative, so if you replace it with `reduce()` and make the stream parallel, it will yield the wrong result. But `Gatherers.fold` will work! If you don't like it, we can think up something else, but concatenation sample is certainly not good. src/java.base/share/classes/java/util/stream/Gatherers.java line 450: > 448: * @throws NullPointerException if any of the parameters are null > 449: */ > 450: public static Gatherer fold( Should it be explicitly named as `foldLeft`? Because `foldRight` is also possible (though will require complete stream buffering). Also see [JDK-8133680](https://bugs.openjdk.org/browse/JDK-8133680) and [JDK-8292845](https://bugs.openjdk.org/browse/JDK-8292845) (probably should be linked to gatherer's issue, and read the comment about naming) src/java.base/share/classes/java/util/stream/Gatherers.java line 482: > 480: * @throws NullPointerException if any of the parameters are null > 481: */ > 482: public static Gatherer scan( Similarly, probably should be named `scanLeft`? ------------- PR Review: https://git.openjdk.org/jdk/pull/16420#pullrequestreview-1714010997 PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1382600262 PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1382601067 PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1382601204 PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1382601289 PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1382612744 PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1382607035 PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1382604080 PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1382604256 PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1382606016 PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1382607830 PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1382613728 PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1382613989 PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1382614003 PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1382615261 PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1382615861 PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1382616606 PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1382617752 PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1382616313 PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1382617857 From vklang at openjdk.org Wed Nov 8 15:41:23 2023 From: vklang at openjdk.org (Viktor Klang) Date: Wed, 8 Nov 2023 15:41:23 GMT Subject: RFR: JDK-8319123 : Implementation of JEP-461: Stream Gatherers (Preview) In-Reply-To: References: Message-ID: On Mon, 6 Nov 2023 16:57:24 GMT, ExE Boss wrote: > These?should probably?use `{@snippet?...}`: Good idea?I might do so when I have the opportunity. > src/java.base/share/classes/java/util/stream/Gatherer.java line 549: > >> 547: return greedy; >> 548: } >> 549: > > Since?[GH?16213] was?closed in?favour of?adding diamond?inference to?casts (e.g.:?`(Integrator<>) Foo::bar` or?`(Integrator.Greedy<>) Foo::bar`), these?should?probably be?removed as?well: > Suggestion: > > > > [GH?16213]: https://github.com/openjdk/jdk/pull/16213 @ExE-Boss Since there is no diamond casts yet, and this is a Preview, I think it is safe enough to keep things as is and re-assess if/when such capabilities are supported. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16420#issuecomment-1798238236 PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1380639052 From briangoetz at openjdk.org Wed Nov 8 15:41:30 2023 From: briangoetz at openjdk.org (Brian Goetz) Date: Wed, 8 Nov 2023 15:41:30 GMT Subject: RFR: JDK-8319123 : Implementation of JEP-461: Stream Gatherers (Preview) In-Reply-To: References: Message-ID: On Tue, 31 Oct 2023 13:17:51 GMT, Viktor Klang wrote: >> This is a Draft PR for [JEP-461](https://openjdk.org/jeps/461) > > src/java.base/share/classes/java/util/stream/AbstractPipeline.java line 223: > >> 221: previousStage.linkedOrConsumed = true; >> 222: >> 223: previousPreviousStage.nextStage = this; > > This allows subclasses to replace the "end" of a pipeline with a new "end" presuming that the previous "end" is not linked nor consumed. As an example, it allows a GathererOp(gathererA) to be replaced with a GathererOp(gathererA.andThen(gathererB)) The constraint of "not linked or consumed" should be stated in the spec here, and probably documented with an `@throws` tag. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1378966890 From liach at openjdk.org Wed Nov 8 15:41:28 2023 From: liach at openjdk.org (Chen Liang) Date: Wed, 8 Nov 2023 15:41:28 GMT Subject: RFR: JDK-8319123 : Implementation of JEP-461: Stream Gatherers (Preview) In-Reply-To: References: Message-ID: On Tue, 31 Oct 2023 13:18:43 GMT, Viktor Klang wrote: >> This is a Draft PR for [JEP-461](https://openjdk.org/jeps/461) > > src/java.base/share/classes/java/util/stream/AbstractPipeline.java line 88: > >> 86: */ >> 87: @SuppressWarnings("rawtypes") >> 88: protected final AbstractPipeline previousStage; > > Making this accessible in subclasses allows to avoid having to store this reference twice, and since this value is passed in during ctor it doesn't expose something previously hidden. Since stream facilities are package-private, we can just use no access modifier and remove all new `protected` access modifier (on methods, fields, constructors) in this PR. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1381730283 From vklang at openjdk.org Wed Nov 8 15:41:30 2023 From: vklang at openjdk.org (Viktor Klang) Date: Wed, 8 Nov 2023 15:41:30 GMT Subject: RFR: JDK-8319123 : Implementation of JEP-461: Stream Gatherers (Preview) In-Reply-To: References: Message-ID: <11-WiDUglsNQb4vNj5DuXscdI3gY-GbODupTFT7VFhA=.cd737114-e7b0-4fbb-b47a-1de5c815c54f@github.com> On Fri, 3 Nov 2023 14:04:23 GMT, Chen Liang wrote: >> src/java.base/share/classes/java/util/stream/AbstractPipeline.java line 88: >> >>> 86: */ >>> 87: @SuppressWarnings("rawtypes") >>> 88: protected final AbstractPipeline previousStage; >> >> Making this accessible in subclasses allows to avoid having to store this reference twice, and since this value is passed in during ctor it doesn't expose something previously hidden. > > Since stream facilities are package-private, we can just use no access modifier and remove all new `protected` access modifier (on methods, fields, constructors) in this PR. @liach We could do that, yet I'm not sure that is strictly an improvement. What would be the benefit in doing so specifically for this PR? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1381975631 From vklang at openjdk.org Wed Nov 8 15:41:32 2023 From: vklang at openjdk.org (Viktor Klang) Date: Wed, 8 Nov 2023 15:41:32 GMT Subject: RFR: JDK-8319123 : Implementation of JEP-461: Stream Gatherers (Preview) In-Reply-To: References: Message-ID: On Wed, 1 Nov 2023 15:40:23 GMT, Brian Goetz wrote: >Since you validate that previous^2.next == previous, you might just omit the previousStage parameter and derive it in the body. @briangoetz It was a bit of additional safety to make sure that the caller gets what they want. If the prev-prev was omitted here then this ctor would have the same signature as the other ctor. (Note that this is internal API.) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1379094384 From briangoetz at openjdk.org Wed Nov 8 15:41:31 2023 From: briangoetz at openjdk.org (Brian Goetz) Date: Wed, 8 Nov 2023 15:41:31 GMT Subject: RFR: JDK-8319123 : Implementation of JEP-461: Stream Gatherers (Preview) In-Reply-To: References: Message-ID: On Wed, 1 Nov 2023 15:39:11 GMT, Brian Goetz wrote: >> src/java.base/share/classes/java/util/stream/AbstractPipeline.java line 223: >> >>> 221: previousStage.linkedOrConsumed = true; >>> 222: >>> 223: previousPreviousStage.nextStage = this; >> >> This allows subclasses to replace the "end" of a pipeline with a new "end" presuming that the previous "end" is not linked nor consumed. As an example, it allows a GathererOp(gathererA) to be replaced with a GathererOp(gathererA.andThen(gathererB)) > > The constraint of "not linked or consumed" should be stated in the spec here, and probably documented with an `@throws` tag. Since you validate that previous^2.next == previous, you might just omit the `previousStage` parameter and derive it in the body. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1378968421 From briangoetz at openjdk.org Wed Nov 8 15:41:38 2023 From: briangoetz at openjdk.org (Brian Goetz) Date: Wed, 8 Nov 2023 15:41:38 GMT Subject: RFR: JDK-8319123 : Implementation of JEP-461: Stream Gatherers (Preview) In-Reply-To: References: Message-ID: On Mon, 30 Oct 2023 15:38:35 GMT, Viktor Klang wrote: > This is a Draft PR for [JEP-461](https://openjdk.org/jeps/461) src/java.base/share/classes/java/util/stream/Gatherer.java line 44: > 42: * > 43: *

Examples of gathering operations include, but is not limited to: > 44: * grouping elements into batches, also known as windowing functions; Suggest for 1st sentence: "An intermediate operation that transforms a stream of input elements into a stream of output elements, optionally applying a final action when the end of the upstream is reached. The transformation may be stateless or stateful, and a Gatherer may buffer arbitrarily much input before producing any output." src/java.base/share/classes/java/util/stream/Gatherer.java line 49: > 47: * {@link java.util.stream.Gatherers} provides implementations of common > 48: * gathering operations. > 49: * incremental accumulation functions (prefix scan) src/java.base/share/classes/java/util/stream/Gatherer.java line 61: > 59: * > 60: *

Each invocation to {@link #initializer()}, {@link #integrator()}, > 61: * {@link #combiner()}, and {@link #finisher()} must return a semantically consistency: either all should be like "creation of a", or all should be an "ing" term (integrating, combining, performing)" src/java.base/share/classes/java/util/stream/Gatherer.java line 137: > 135: * }) > 136: * ); > 137: * } As a matter of style, I find it weird that `current` is assigned in both the constructor and in the lambda. I'd be inclined to put all assignments in the State class (and expose more methods) or put all assignments in the lambdas (and ditch the ctor). For an example this trivial, it doens't make so much differnce, but it gives a gentle push towards doing things more consistenly. src/java.base/share/classes/java/util/stream/Gatherers.java line 516: > 514: * evaluation can be out-of-sequence compared to the sequential encounter > 515: * order of the stream. > 516: * How does this differ from Stream::peek? src/java.base/share/classes/java/util/stream/ReferencePipeline.java line 113: > 111: @Override > 112: final StreamShape getOutputShape() { > 113: return StreamShape.REFERENCE; Not all parameters documented? src/java.base/share/classes/java/util/stream/Stream.java line 1110: > 1108: * } > 1109: * > 1110: *

Like {@link #reduce(Object, BinaryOperator)}, {@code collect} operations A brief description of what a Gatherer is here (around the time you say "extension point") would be helpful, something general like "Gatherers are highly flexible, expressing a many-to-many transformation on the elements of a stream, and support short-circuiting, blah blah blah". ENough to make people want to read either the linked section or the Gatherer doc. The @impleNote is a little unclear; I'd use the format for other ops added after 8, such as takeWhile or mapMulti. I'd add `@see Gatherer`. src/java.base/share/classes/java/util/stream/package-info.java line 636: > 634: * produces a {@code Map}, such as: > 635: *

{@code
> 636:  *     Map> salesByBuyer

Did you mean Gatherer.ofSequential?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1378997403
PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1379001492
PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1379003153
PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1379015289
PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1379028898
PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1378969982
PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1378989827
PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1378991117

From tvaleev at openjdk.org  Wed Nov  8 15:41:41 2023
From: tvaleev at openjdk.org (Tagir F. Valeev)
Date: Wed, 8 Nov 2023 15:41:41 GMT
Subject: RFR: JDK-8319123 : Implementation of JEP-461: Stream Gatherers
 (Preview)
In-Reply-To: <3z8IYhG73DKYCv_643Jtb-nDyNRlaLPyvqoPTDeI6SM=.b336d2d0-29ea-4ee2-98e9-3d89f4f85a7d@github.com>
References: 
 
 <3z8IYhG73DKYCv_643Jtb-nDyNRlaLPyvqoPTDeI6SM=.b336d2d0-29ea-4ee2-98e9-3d89f4f85a7d@github.com>
Message-ID: <8U_gZrZdfBEfUJm394moAzoPXayVE6Sdh5rxWXVdcDc=.7731cb78-927f-4661-881e-c1b539bb6590@github.com>

On Mon, 6 Nov 2023 11:08:08 GMT, Viktor Klang  wrote:

>> src/java.base/share/classes/java/util/stream/Gatherer.java line 308:
>> 
>>> 306:      */
>>> 307:     static  Gatherer ofSequential(
>>> 308:             Integrator integrator) {
>> 
>> Probably PECS signature `? super T, ? extends R` could be useful here?
>
> I've thought about that, and since we don't use that for the other parameters (like `initializer`) I don't think it helps changing it here. And the reason this has little effect is that the code calling the factory typically controls the components/parameters/return type.

It's still possible to have a situation where PECS signature could be useful, and I don't see any downsides. A user may want to reuse the same static integrator instead of creating several identical lambdas just because the target type is more specific. Sometimes, people complain later, and you'll have to fix this. For example, see that `Stream.generate()` [was fixed separately](https://bugs.openjdk.org/browse/JDK-8132097). So why not doing this from the very beginning?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1386688266

From vklang at openjdk.org  Wed Nov  8 15:41:33 2023
From: vklang at openjdk.org (Viktor Klang)
Date: Wed, 8 Nov 2023 15:41:33 GMT
Subject: RFR: JDK-8319123 : Implementation of JEP-461: Stream Gatherers
 (Preview)
In-Reply-To: 
References: 
 
 
 
 
Message-ID: <3QKlM-2Xj6_2yqh6kVpDFXAbTcUruP0mlMEmSLVzIEA=.8d30ea7f-875b-4420-afe3-11e4183edf93@github.com>

On Wed, 1 Nov 2023 17:22:09 GMT, Viktor Klang  wrote:

>> Since you validate that previous^2.next == previous, you might just omit the `previousStage` parameter and derive it in the body.
>
>>Since you validate that previous^2.next == previous, you might just omit the previousStage parameter and derive it in the body.
> 
> @briangoetz It was a bit of additional safety to make sure that the caller gets what they want. If the prev-prev was omitted here then this ctor would have the same signature as the other ctor.
> (Note that this is internal API.)

>The constraint of "not linked or consumed" should be stated in the spec here, and probably documented with an @throws tag.

I can definitely do that. I'll amend the original ctor as well then since it also does not have that.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1379095926

From vklang at openjdk.org  Wed Nov  8 15:41:40 2023
From: vklang at openjdk.org (Viktor Klang)
Date: Wed, 8 Nov 2023 15:41:40 GMT
Subject: RFR: JDK-8319123 : Implementation of JEP-461: Stream Gatherers
 (Preview)
In-Reply-To: 
References: 
 
 
Message-ID: 

On Wed, 8 Nov 2023 14:19:47 GMT, Tagir F. Valeev  wrote:

>> src/java.base/share/classes/java/util/stream/Gatherer.java line 252:
>> 
>>> 250:      *         Gatherer as input that Gatherer
>>> 251:      */
>>> 252:     default  Gatherer andThen(Gatherer that) {
>> 
>> It would be great to remove AA type parameter, which is mentioned only once, so could be replaced with `?`. This will improve user experience if they happen to need to specify type parameters explicitly.
>
> This is especially important given that often you don't know the AA type at all. E.g., imagine that you are doing `.andThen(Gatherers.fold(...))`, but `fold` returns `Gatherer`, so you can specify explicit `RR`, but not `AA`.

Has this proven to be a problem for things like [Collectors.mapping(?)](https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/util/stream/Collectors.html#mapping(java.util.function.Function,java.util.stream.Collector)) ? ? 

There's one implication on turning it into a wildcard?it may actually cause issues implementing the composition directly in the override, as you won't have a typename to refer to.

Do you have a concrete example of where the current "encoding" causes a caller-problem?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1386796562

From tvaleev at openjdk.org  Wed Nov  8 15:41:40 2023
From: tvaleev at openjdk.org (Tagir F. Valeev)
Date: Wed, 8 Nov 2023 15:41:40 GMT
Subject: RFR: JDK-8319123 : Implementation of JEP-461: Stream Gatherers
 (Preview)
In-Reply-To: 
References: 
 
Message-ID: 

On Sun, 5 Nov 2023 17:17:43 GMT, Tagir F. Valeev  wrote:

>> This is a Draft PR for [JEP-461](https://openjdk.org/jeps/461)
>
> src/java.base/share/classes/java/util/stream/Gatherer.java line 252:
> 
>> 250:      *         Gatherer as input that Gatherer
>> 251:      */
>> 252:     default  Gatherer andThen(Gatherer that) {
> 
> It would be great to remove AA type parameter, which is mentioned only once, so could be replaced with `?`. This will improve user experience if they happen to need to specify type parameters explicitly.

This is especially important given that often you don't know the AA type at all. E.g., imagine that you are doing `.andThen(Gatherers.fold(...))`, but `fold` returns `Gatherer`, so you can specify explicit `RR`, but not `AA`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1386696219

From vklang at openjdk.org  Wed Nov  8 15:41:41 2023
From: vklang at openjdk.org (Viktor Klang)
Date: Wed, 8 Nov 2023 15:41:41 GMT
Subject: RFR: JDK-8319123 : Implementation of JEP-461: Stream Gatherers
 (Preview)
In-Reply-To: <_KHZf3d1ghZ4vlvFSNKFGa7o4LhMFxcm2sGE_A7xFSo=.afa5f77c-0e17-4c09-91f2-a9afcae07d4a@github.com>
References: 
 
 <_KHZf3d1ghZ4vlvFSNKFGa7o4LhMFxcm2sGE_A7xFSo=.afa5f77c-0e17-4c09-91f2-a9afcae07d4a@github.com>
Message-ID: 

On Wed, 1 Nov 2023 18:10:28 GMT, Viktor Klang  wrote:

>> src/java.base/share/classes/java/util/stream/Gatherers.java line 516:
>> 
>>> 514:      * evaluation can be out-of-sequence compared to the sequential encounter
>>> 515:      * order of the stream.
>>> 516:      *
>> 
>> How does this differ from Stream::peek?
>
> @briangoetz Basically the same as `Stream::parallel().forEach` vs `Stream.parallel().forEachOrdered`.

peek and peekOrdered have been removed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1383205789

From vklang at openjdk.org  Wed Nov  8 15:41:41 2023
From: vklang at openjdk.org (Viktor Klang)
Date: Wed, 8 Nov 2023 15:41:41 GMT
Subject: RFR: JDK-8319123 : Implementation of JEP-461: Stream Gatherers
 (Preview)
In-Reply-To: <8U_gZrZdfBEfUJm394moAzoPXayVE6Sdh5rxWXVdcDc=.7731cb78-927f-4661-881e-c1b539bb6590@github.com>
References: 
 
 <3z8IYhG73DKYCv_643Jtb-nDyNRlaLPyvqoPTDeI6SM=.b336d2d0-29ea-4ee2-98e9-3d89f4f85a7d@github.com>
 <8U_gZrZdfBEfUJm394moAzoPXayVE6Sdh5rxWXVdcDc=.7731cb78-927f-4661-881e-c1b539bb6590@github.com>
Message-ID: 

On Wed, 8 Nov 2023 14:14:35 GMT, Tagir F. Valeev  wrote:

>> I've thought about that, and since we don't use that for the other parameters (like `initializer`) I don't think it helps changing it here. And the reason this has little effect is that the code calling the factory typically controls the components/parameters/return type.
>
> It's still possible to have a situation where PECS signature could be useful, and I don't see any downsides. A user may want to reuse the same static integrator instead of creating several identical lambdas just because the target type is more specific. Sometimes, people complain later, and you'll have to fix this. For example, see that `Stream.generate()` [was fixed separately](https://bugs.openjdk.org/browse/JDK-8132097). So why not doing this from the very beginning?

@amaembo In this case, given that it is intended as Preview, I think it makes sense to receive some user feedback on this. Note that Collector has been without PECS for Collector.of since 1.8: [of](https://docs.oracle.com/javase/8/docs/api/java/util/stream/Collector.html#of-java.util.function.Supplier-java.util.function.BiConsumer-java.util.function.BinaryOperator-java.util.function.Function-java.util.stream.Collector.Characteristics...-)

Right now I don't want to deviate from the Collector-heritage until there's more usage feedback, and I'm definitely not ruling out that PECS:ing the factories might be worth it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1386788253

From vklang at openjdk.org  Wed Nov  8 15:41:39 2023
From: vklang at openjdk.org (Viktor Klang)
Date: Wed, 8 Nov 2023 15:41:39 GMT
Subject: RFR: JDK-8319123 : Implementation of JEP-461: Stream Gatherers
 (Preview)
In-Reply-To: 
References: 
 
Message-ID: <_KHZf3d1ghZ4vlvFSNKFGa7o4LhMFxcm2sGE_A7xFSo=.afa5f77c-0e17-4c09-91f2-a9afcae07d4a@github.com>

On Wed, 1 Nov 2023 16:16:38 GMT, Brian Goetz  wrote:

>> This is a Draft PR for [JEP-461](https://openjdk.org/jeps/461)
>
> src/java.base/share/classes/java/util/stream/Gatherer.java line 137:
> 
>> 135:  *          })
>> 136:  *     );
>> 137:  * }
> 
> As a matter of style, I find it weird that `current` is assigned in both the constructor and in the lambda.  I'd be inclined to put all assignments in the State class (and expose more methods) or put all assignments in the lambdas (and ditch the ctor).  For an example this trivial, it doens't make so much differnce, but it gives a gentle push towards doing things more consistenly.

making `integrate` a method on State in this case is a bit of extra noise, which I wanted to avoid for something embedded in the Javadoc. I'll reduce some of the noise by assigning `current` in the member declaration instead of in an explicit ctor.

> src/java.base/share/classes/java/util/stream/Gatherers.java line 516:
> 
>> 514:      * evaluation can be out-of-sequence compared to the sequential encounter
>> 515:      * order of the stream.
>> 516:      *
> 
> How does this differ from Stream::peek?

@briangoetz Basically the same as `Stream::parallel().forEach` vs `Stream.parallel().forEachOrdered`.

> src/java.base/share/classes/java/util/stream/ReferencePipeline.java line 113:
> 
>> 111:     @Override
>> 112:     final StreamShape getOutputShape() {
>> 113:         return StreamShape.REFERENCE;
> 
> Not all parameters documented?

Good catch -- that was the same for [the other ctor](https://github.com/openjdk/jdk/pull/16420/files/6a7d16a1ffcf26a10ce443cf6bf1f5dd8695b808#diff-761882141e64725ba36ab6cb28dc7ea65deefa32f7b9810355de42126efefc6bR93) so it was carried over, I'll add params for both of the ctors:

> src/java.base/share/classes/java/util/stream/Stream.java line 1110:
> 
>> 1108:      * }
>> 1109: * >> 1110: *

Like {@link #reduce(Object, BinaryOperator)}, {@code collect} operations > > A brief description of what a Gatherer is here (around the time you say "extension point") would be helpful, something general like "Gatherers are highly flexible, expressing a many-to-many transformation on the elements of a stream, and support short-circuiting, blah blah blah". ENough to make people want to read either the linked section or the Gatherer doc. > > The @impleNote is a little unclear; I'd use the format for other ops added after 8, such as takeWhile or mapMulti. > > I'd add `@see Gatherer`. @briangoetz >A brief description of what a Gatherer is here (around the time you say "extension point") would be helpful, something general like "Gatherers are highly flexible, expressing a many-to-many transformation on the elements of a stream, and support short-circuiting, blah blah blah". ENough to make people want to read either the linked section or the Gatherer doc. Good point. I went with: `Gatherers are highly flexible and can describe a vast array of possibly stateful operations, with support for short-circuiting, and parallelization.` >The @impleNote is a little unclear; I'd use the format for other ops added after 8, such as takeWhile or mapMulti. Do you mean the implSpec? Because the implNote just states: "Implementations of this interface should provide their own implementation of this method." >I'd add @see Gatherer. ? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1379142852 PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1379143608 PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1379102144 PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1379120702 From duke at openjdk.org Wed Nov 8 15:49:18 2023 From: duke at openjdk.org (Konrad Windszus) Date: Wed, 8 Nov 2023 15:49:18 GMT Subject: RFR: 8308753: Class-File API transition to Preview [v24] In-Reply-To: References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com> Message-ID: <83E89Gq0Rn3H-WTsUJPx6L37WggoVHo7piExlpMSmMg=.82768fa9-9262-4fad-b87b-7c94a71d2d84@github.com> On Wed, 8 Nov 2023 14:07:04 GMT, Chen Liang wrote: > You can simply call `ClassFile.of().parse(inputStream.readAllBytes())` instead. I know, but for memory consumption reasons everyone should prefer just passing an InputStream. Is the memory consumption with `ClassFile.of().parse(Path)` any better (i.e. are you using a `java.io.RandomAccessFile` or `java.nio.channels.SeekableByteChannel` under the hood)? I think that deserves a sentence in the javadoc. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15706#issuecomment-1802159417 From duke at openjdk.org Wed Nov 8 16:06:15 2023 From: duke at openjdk.org (Ryan Wallace) Date: Wed, 8 Nov 2023 16:06:15 GMT Subject: RFR: 8318971: jar v17 should either exit on error immediately or create archive as jar v1.8 did [v3] In-Reply-To: References: Message-ID: > Hi all, > > Please review this fix for jar tool not producing archive if there is a missing file supplied. Fix is to throw an exception and exit processing when a missing file is supplied. Current behaviour will recognise missing file as an error but continue processing and not produce the archive. Updated ClassPath test to verify jar is not created. > > Thanks, > Ryan. Ryan Wallace has updated the pull request incrementally with one additional commit since the last revision: 8318971: jar v17 should either exit on error immediately or create archive as jar v1.8 did ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16423/files - new: https://git.openjdk.org/jdk/pull/16423/files/612f4c05..c7b18741 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16423&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16423&range=01-02 Stats: 5 lines in 2 files changed: 4 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/16423.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16423/head:pull/16423 PR: https://git.openjdk.org/jdk/pull/16423 From duke at openjdk.org Wed Nov 8 16:06:20 2023 From: duke at openjdk.org (Ryan Wallace) Date: Wed, 8 Nov 2023 16:06:20 GMT Subject: RFR: 8318971: jar v17 should either exit on error immediately or create archive as jar v1.8 did [v2] In-Reply-To: <8OdwloG5cSRKPoHhdOloNgOngp0NIBhXroLW_BjAkAc=.17c74b0a-8b7f-453f-b138-7f764a1cf425@github.com> References: <8OdwloG5cSRKPoHhdOloNgOngp0NIBhXroLW_BjAkAc=.17c74b0a-8b7f-453f-b138-7f764a1cf425@github.com> Message-ID: On Wed, 8 Nov 2023 09:42:25 GMT, Ryan Wallace wrote: >> Hi all, >> >> Please review this fix for jar tool not producing archive if there is a missing file supplied. Fix is to throw an exception and exit processing when a missing file is supplied. Current behaviour will recognise missing file as an error but continue processing and not produce the archive. Updated ClassPath test to verify jar is not created. >> >> Thanks, >> Ryan. > > Ryan Wallace has updated the pull request with a new target base 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: > > - 8318971: jar v17 should either exit on error immediately or create archive as jar v1.8 did > - Merge branch 'master' into 8318971 > - 8318971: jar v17 should either exit on error immediately or create archive as jar v1.8 did > - 8318971: jar v17 should either exit on error immediately or create archive as jar v1.8 did Added and tested and it still works as expected. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16423#issuecomment-1802195024 From alanb at openjdk.org Wed Nov 8 16:09:56 2023 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 8 Nov 2023 16:09:56 GMT Subject: RFR: 8318971: jar v17 should either exit on error immediately or create archive as jar v1.8 did [v2] In-Reply-To: References: <8OdwloG5cSRKPoHhdOloNgOngp0NIBhXroLW_BjAkAc=.17c74b0a-8b7f-453f-b138-7f764a1cf425@github.com> Message-ID: On Wed, 8 Nov 2023 16:03:22 GMT, Ryan Wallace wrote: > Added and tested and it still works as expected. @ryawalla Would it be possible to update the PR description so there's a clear summary on the updated proposal? I think it aligns the behavior with what happens when a bad file path is specified on the jar command line, right? As I mentioned, we'll need to add tests, release note, and see what docs (jar man page?) need to be updated. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16423#issuecomment-1802202054 From asotona at openjdk.org Wed Nov 8 16:20:19 2023 From: asotona at openjdk.org (Adam Sotona) Date: Wed, 8 Nov 2023 16:20:19 GMT Subject: RFR: 8308753: Class-File API transition to Preview [v26] In-Reply-To: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com> References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com> Message-ID: <1Tzm6V5U8360jlN6QksTfSxpCswVhEFbfpNcgNtOvzs=.0c0a444c-f5a6-4207-9e5e-a292eb514304@github.com> > Classfile API is an internal library under package `jdk.internal.classfile`?in JDK 21. > This pull request turns the Classfile API into a preview feature and moves it into `java.lang.classfile`. > It repackages all uses across JDK and tests and adds lots of missing Javadoc. > > This PR goes in sync with?[JDK-8308754](https://bugs.openjdk.org/browse/JDK-8308754): Class-File API (Preview) (CSR) > and?[JDK-8280389](https://bugs.openjdk.org/browse/JDK-8280389): Class-File API (Preview) (JEP). > > Online javadoc is available at:? > https://cr.openjdk.org/~asotona/JDK-8308753-preview/api/java.base/java/lang/classfile/package-summary.html > > In addition to the primary transition to preview, this pull request also includes: > - All?Classfile*?classes ranamed to?ClassFile*?(based on JEP discussion). > - A new preview feature, `CLASSFILE_API`, has been added. > - Buildsystem tool required a little patch to support annotated modules. > - All JDK modules using the Classfile API are newly participating in the preview. > - All tests that use the Classfile API now have preview enabled. > - A few Javac tests not allowing preview have been partially reverted; their conversion can be re-applied when the Classfile API leaves preview mode. > > Despite the number of affected files, this pull request is relatively straight-forward. The preview version of the Classfile API is based on the internal version of the library from the JDK master branch, and there are no API features added. > > Please review this pull request to help the Classfile API turn into a preview. > > Any comments are welcome. > > Thanks, > Adam Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: fixed SignaturesTest ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15706/files - new: https://git.openjdk.org/jdk/pull/15706/files/29c8fad3..af441580 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15706&range=25 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15706&range=24-25 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/15706.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15706/head:pull/15706 PR: https://git.openjdk.org/jdk/pull/15706 From asotona at openjdk.org Wed Nov 8 16:20:23 2023 From: asotona at openjdk.org (Adam Sotona) Date: Wed, 8 Nov 2023 16:20:23 GMT Subject: RFR: 8308753: Class-File API transition to Preview [v25] In-Reply-To: <1O6wmxmmlST1cR3SkMDbz6AQPxQPQzR9LQ2lLX-Gfn4=.04c03978-f129-496e-831e-fdbfe8adf255@github.com> References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com> <1O6wmxmmlST1cR3SkMDbz6AQPxQPQzR9LQ2lLX-Gfn4=.04c03978-f129-496e-831e-fdbfe8adf255@github.com> Message-ID: On Wed, 8 Nov 2023 15:22:54 GMT, Chen Liang 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 360 commits: >> >> - fixed condy tests >> - Merge branch 'master' into JDK-8308753-preview >> - Merge branch 'master' into JDK-8308753-preview >> >> # Conflicts: >> # test/jdk/tools/lib/tests/JImageValidator.java >> - fixed jdk.jfr >> - Merge branch 'master' into JDK-8308753-preview >> >> # Conflicts: >> # src/java.base/share/classes/module-info.java >> - applied javadoc fix suggestions >> - fixed new benchmark >> - Merge branch 'master' into JDK-8308753-preview >> >> # Conflicts: >> # src/java.base/share/classes/jdk/internal/classfile/impl/AbstractPoolEntry.java >> - removed trailing space >> - Merge branch 'master' into JDK-8308753-preview >> >> # Conflicts: >> # src/java.base/share/classes/module-info.java >> - ... and 350 more: https://git.openjdk.org/jdk/compare/7bc8e4c8...29c8fad3 > > test/jdk/jdk/classfile/SignaturesTest.java line 1: > >> 1: /* > > The new test in this file for classDesc bug needs a migration too. Good point, thank you. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15706#discussion_r1386878583 From duke at openjdk.org Wed Nov 8 16:31:16 2023 From: duke at openjdk.org (Eirik Bjorsnos) Date: Wed, 8 Nov 2023 16:31:16 GMT Subject: RFR: 8314891: Additional Zip64 extra header validation [v8] In-Reply-To: References: Message-ID: On Mon, 23 Oct 2023 19:12:57 GMT, Lance Andersen wrote: >> Please review this PR which improves the Zip64 extra header validation: >> >> - Throw a ZipException If the extra len field is 0 and : >> -- size, csize, or loc offset are set to 0xFFFFFFFF >> -- disk starting number is set to 0xFFFF >> >> - We have a valid size for the Zip64 extra header but we are missing the csize or loc fields if they are expected to be part of the header >> >> Mach5 tiers 1-3 are clean > > Lance Andersen has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains ten additional commits since the last revision: > > - Merge branch 'master' into JDK-8314891 > - Add missing space > - Revamp isZip64ExtBlockSizeValid > - Merge branch 'master' into JDK-8314891 > - Merge branch 'master' into JDK-8314891 > - Remove tab(s) from comment > - Added additional tests, along with additional cleanup and refactoring > - Clean up some minor formatting issues > - Additional Zip64 extra header validation @LanceAndersen I noticed that this PR did not update `ZipInputStream.readLOC` to perform consistency validation between expected and actual extra field size and values. Any particular reason why processing of LOC headers was not made consistent with CEN? ------------- PR Comment: https://git.openjdk.org/jdk/pull/15650#issuecomment-1802241544 From tvaleev at openjdk.org Wed Nov 8 16:34:06 2023 From: tvaleev at openjdk.org (Tagir F. Valeev) Date: Wed, 8 Nov 2023 16:34:06 GMT Subject: RFR: JDK-8319123 : Implementation of JEP-461: Stream Gatherers (Preview) In-Reply-To: <3z8IYhG73DKYCv_643Jtb-nDyNRlaLPyvqoPTDeI6SM=.b336d2d0-29ea-4ee2-98e9-3d89f4f85a7d@github.com> References: <3z8IYhG73DKYCv_643Jtb-nDyNRlaLPyvqoPTDeI6SM=.b336d2d0-29ea-4ee2-98e9-3d89f4f85a7d@github.com> Message-ID: On Mon, 6 Nov 2023 16:18:22 GMT, Viktor Klang wrote: >> src/java.base/share/classes/java/util/stream/Gatherers.java line 389: >> >>> 387: * @throws IllegalArgumentException when windowSize is less than 1 >>> 388: */ >>> 389: public static

Gatherer> windowSliding(int windowSize) { >> >> From my experience, sliding window with windowSize = 2 is the most important and deserves the explicit support (I have such an operation in my StreamEx library and it's used quite often). Please consider adding (name subject to discussions): >> >> `public static Gatherer pairMap(BiFunction functionToApplyToTwoAdjacentElements)`. It could be more optimal, as you only need to store the previous element. Moreover, I believe one can implement a proper combiner to make it parallel-friendly. Could be added separately after this PR is merged. I can contribute it. > > @amaembo pairMap should be straight-forward to implement. And regarding parallelization I don't think that will necessarily work since it would not be able to run incrementally (depth-first). Sorry, I'm not sure what do you mean by incrementally. But I've realized that to implement this you may need to push to downstream during combining. E.g., imagine the stream of numbers 1...1000, and you want to make `parallel().gather(pairMap((left, right) -> left+"->"+right)).collect(toList())`, creating a list of "1->2", "2->3", ..., "999->1000" strings. Now, let's assume that the stream was split into four parts during the parallelization: `1..250`, `251..500`, `501..750`, `751..1000`. So you create downstream accumulators and push the pairs there with integrator, like: "1->2", ..., "249->250" into first toList() accumulator, "251->252", ..., "499->500" into second toList() accumulator "501->502", ..., "749->750" into third toList() accumulator "751->752", ..., "999->1000" into fourth toList() accumulator At this point we have four independent gatherer states, and they keep the first and last element from the upstream. Now, you combine for example, first and second gatherer states. The first one is [first=1, last=250], and the second is [first=251, last=500]. The combined gatherer should be [first=1, last=500] and at the same time during the combining it should push the "250->251" object to the downstream, which will land into the first toList() accumulator. Hopefully my explanation is clear. Will it be possible to extend the combiner function and provide the Downstream there as well, so combiner can also work as a finisher for the first combined chunk? >> src/java.base/share/classes/java/util/stream/Gatherers.java line 436: >> >>> 434: * Stream.of(1,2,3,4,5,6,7,8,9) >>> 435: * .gather( >>> 436: * Gatherers.fold(() -> "", (string, number) -> string + number) >> >> This particular sample is not great, as it's totally replaceable with reduce() (`map(String::valueOf).reduce(String::concat)`), so users may wonder why using fold instead. I can suggest another sample which I show everywhere: >> `anyList.stream().gather(Gatherers.fold(() -> 1, (acc, e) -> acc * 31 + Objects.hashCode(e))).findFirst().get();` >> (haven't tested, but the idea is like this) >> It computes the hashCode of the list, according to the list specification. Here, the accumulator is inherently non-associative, so if you replace it with `reduce()` and make the stream parallel, it will yield the wrong result. But `Gatherers.fold` will work! >> >> If you don't like it, we can think up something else, but concatenation sample is certainly not good. > > Perhaps the best thing here is to change such that the supplier supplies something non-zero like "String: "? Such an example still looks artificial for me, as it's easy to rewrite with `reduce()` (just prepend with prefix outside of the stream). Well, it's up to you. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1386896007 PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1386898587 From vklang at openjdk.org Wed Nov 8 16:34:08 2023 From: vklang at openjdk.org (Viktor Klang) Date: Wed, 8 Nov 2023 16:34:08 GMT Subject: RFR: JDK-8319123 : Implementation of JEP-461: Stream Gatherers (Preview) In-Reply-To: References: <3z8IYhG73DKYCv_643Jtb-nDyNRlaLPyvqoPTDeI6SM=.b336d2d0-29ea-4ee2-98e9-3d89f4f85a7d@github.com> Message-ID: On Wed, 8 Nov 2023 16:28:55 GMT, Tagir F. Valeev wrote: >> Perhaps the best thing here is to change such that the supplier supplies something non-zero like "String: "? > > Such an example still looks artificial for me, as it's easy to rewrite with `reduce()` (just prepend with prefix outside of the stream). Well, it's up to you. But you might not want to exit the stream just yet, and have to create a whole new stream. In any case, I think it would be great to have a better example, I'm just not sure what that'd be just yet. Open to suggestions! :) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1386901231 From dfenacci at openjdk.org Wed Nov 8 16:36:01 2023 From: dfenacci at openjdk.org (Damon Fenacci) Date: Wed, 8 Nov 2023 16:36:01 GMT Subject: RFR: 8311906: Improve robustness of String constructors with mutable array inputs In-Reply-To: <6SKlGLh5MmxoEx07wHCCUc8KWbbhcspLJmcc1uxQ_FI=.ca33bfb4-fa5c-45f0-b49f-ee6c5c6b68b4@github.com> References: <6SKlGLh5MmxoEx07wHCCUc8KWbbhcspLJmcc1uxQ_FI=.ca33bfb4-fa5c-45f0-b49f-ee6c5c6b68b4@github.com> Message-ID: On Mon, 30 Oct 2023 18:34:44 GMT, Roger Riggs wrote: > Strings, after construction, are immutable but may be constructed from mutable arrays of bytes, characters, or integers. > The string constructors should guard against the effects of mutating the arrays during construction that might invalidate internal invariants for the correct behavior of operations on the resulting strings. In particular, a number of operations have optimizations for operations on pairs of latin1 strings and pairs of non-latin1 strings, while operations between latin1 and non-latin1 strings use a more general implementation. > > The changes include: > > - Adding a warning to each constructor with an array as an argument to indicate that the results are indeterminate > if the input array is modified before the constructor returns. > The resulting string may contain any combination of characters sampled from the input array. > > - Ensure that strings that are represented as non-latin1 contain at least one non-latin1 character. > For latin1 inputs, whether the arrays contain ASCII, ISO-8859-1, UTF8, or another encoding decoded to latin1 the scanning and compression is unchanged. > If a non-latin1 character is found, the string is represented as non-latin1 with the added verification that a non-latin1 character is present at the same index. > If that character is found to be latin1, then the input array has been modified and the result of the scan may be incorrect. > Though a ConcurrentModificationException could be thrown, the risk to an existing application of an unexpected exception should be avoided. > Instead, the non-latin1 copy of the input is re-scanned and compressed; that scan determines whether the latin1 or the non-latin1 representation is returned. > > - The methods that scan for non-latin1 characters and their intrinsic implementations are updated to return the index of the non-latin1 character. > > - String construction from StringBuilder and CharSequence must also be guarded as their contents may be modified during construction. It would also be good to have the **aarch64** and **x64** intrinsics properly reviewed. @theRealAph could I ask you to have a look at **aarch64** and @TobiHartmann at **x64** please? (you seem to be the last ones that made major changes in the intrinsics) ------------- PR Comment: https://git.openjdk.org/jdk/pull/16425#issuecomment-1802251889 From vklang at openjdk.org Wed Nov 8 16:42:03 2023 From: vklang at openjdk.org (Viktor Klang) Date: Wed, 8 Nov 2023 16:42:03 GMT Subject: RFR: JDK-8319123 : Implementation of JEP-461: Stream Gatherers (Preview) In-Reply-To: References: <3z8IYhG73DKYCv_643Jtb-nDyNRlaLPyvqoPTDeI6SM=.b336d2d0-29ea-4ee2-98e9-3d89f4f85a7d@github.com> Message-ID: On Wed, 8 Nov 2023 16:26:56 GMT, Tagir F. Valeev wrote: >> @amaembo pairMap should be straight-forward to implement. And regarding parallelization I don't think that will necessarily work since it would not be able to run incrementally (depth-first). > > Sorry, I'm not sure what do you mean by incrementally. But I've realized that to implement this you may need to push to downstream during combining. E.g., imagine the stream of numbers 1...1000, and you want to make `parallel().gather(pairMap((left, right) -> left+"->"+right)).collect(toList())`, creating a list of "1->2", "2->3", ..., "999->1000" strings. Now, let's assume that the stream was split into four parts during the parallelization: `1..250`, `251..500`, `501..750`, `751..1000`. So you create downstream accumulators and push the pairs there with integrator, like: > "1->2", ..., "249->250" into first toList() accumulator, > "251->252", ..., "499->500" into second toList() accumulator > "501->502", ..., "749->750" into third toList() accumulator > "751->752", ..., "999->1000" into fourth toList() accumulator > At this point we have four independent gatherer states, and they keep the first and last element from the upstream. Now, you combine for example, first and second gatherer states. The first one is [first=1, last=250], and the second is [first=251, last=500]. The combined gatherer should be [first=1, last=500] and at the same time during the combining it should push the "250->251" object to the downstream, which will land into the first toList() accumulator. > > Hopefully my explanation is clear. Will it be possible to extend the combiner function and provide the Downstream there as well, so combiner can also work as a finisher for the first combined chunk? Ah, now I see what you mean. In this specific case you might be able to create a combiner (which would also need a Downstream) such that you can add the missing combinations (the end of the "left" and the beginning of the "right"). But imagine something like `windowFixed(3)`, where the presence of 1 or 2 elements to the "left" will skew all the elements to the "right", potentially rippling through the entire stream. I think the Preview is a perfect place to see if the combiner would be made even better with a Downstream reference or not. Logically, the output of said Downstream would be placed *after* the "left"'s output, and *before* the "right"'s output (so in the middle of the two). But then someone might want to be able to inject elements outside of that order, but I guess that remains to be seen. Great thoughts, @amaembo ? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1386910345 From tvaleev at openjdk.org Wed Nov 8 16:42:08 2023 From: tvaleev at openjdk.org (Tagir F. Valeev) Date: Wed, 8 Nov 2023 16:42:08 GMT Subject: RFR: JDK-8319123 : Implementation of JEP-461: Stream Gatherers (Preview) In-Reply-To: <3z8IYhG73DKYCv_643Jtb-nDyNRlaLPyvqoPTDeI6SM=.b336d2d0-29ea-4ee2-98e9-3d89f4f85a7d@github.com> References: <3z8IYhG73DKYCv_643Jtb-nDyNRlaLPyvqoPTDeI6SM=.b336d2d0-29ea-4ee2-98e9-3d89f4f85a7d@github.com> Message-ID: <_lzZlI6Wypm7nnK6HF90jALtL50nRS-egAjy6vNqlAk=.68544b66-b213-46ae-ba8f-607328f8ba7f@github.com> On Mon, 6 Nov 2023 16:24:12 GMT, Viktor Klang wrote: >> src/java.base/share/classes/java/util/stream/Gatherers.java line 450: >> >>> 448: * @throws NullPointerException if any of the parameters are null >>> 449: */ >>> 450: public static Gatherer fold( >> >> Should it be explicitly named as `foldLeft`? Because `foldRight` is also possible (though will require complete stream buffering). Also see [JDK-8133680](https://bugs.openjdk.org/browse/JDK-8133680) and [JDK-8292845](https://bugs.openjdk.org/browse/JDK-8292845) (probably should be linked to gatherer's issue, and read the comment about naming) > > TBH I don't think `foldRight` makes much sense for potentially unbounded structures such as Stream. In the case you need it, it might be better to export it to a List and then reversing it. Well, the unboundness argument does not hold, as it can be equally applied to any operation except the short-circuiting ones. Yes, this includes your `fold()`. The only difference is that `foldRight()` will fail with OutOfMemoryError while `fold()` will be stuck in the endless loop. Or probably also fail depending on the folder function (for example, if it's a string concatenation, like in the Javadoc example). You may not like the fact the `foldRight()` buffers the whole stream content, but we already have operations like this, namely `sorted()` and parallel ordered `distinct()`. I'm not convincing you to add `foldRight()` to the JDK. But if we don't have it, somebody will surely write it in third-party libraries. After all, this is what third-party libraries are for. In this case, simple name `fold()` can be confusing. Note that Haskell has separate foldl, foldr, scanl, scanr, so the order is always clear. Scala has `fold()` (which is like `reduce()` and can fold in any order), `foldLeft()` and `foldRight()`. Naming this method simply `fold()` sounds quite confusing. It should be either `foldLeft()` or `reduceLeft()` (even if we don't provide the -right versions) >> src/java.base/share/classes/java/util/stream/Gatherers.java line 482: >> >>> 480: * @throws NullPointerException if any of the parameters are null >>> 481: */ >>> 482: public static Gatherer scan( >> >> Similarly, probably should be named `scanLeft`? > > That's a good question, and here's my thinking?`scanRight` doesn't make any sense for a construct which supports unboundedness, so if we were discussing *Collections* I'd be more inclined to agree (but it is more likely that reversing the collection and then calling scanLeft would be better). See the previous comment. Even if we don't provide `scanRight` for symmetry, the name `scanLeft` for this method would be clearer. As an alternative, consider the `prefix` name, as we already have `Arrays.parallelPrefix`, which performs the same operation on arrays. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1386910684 PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1386913105 From forax at openjdk.org Wed Nov 8 17:08:03 2023 From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax) Date: Wed, 8 Nov 2023 17:08:03 GMT Subject: RFR: JDK-8319123 : Implementation of JEP-461: Stream Gatherers (Preview) In-Reply-To: <11-WiDUglsNQb4vNj5DuXscdI3gY-GbODupTFT7VFhA=.cd737114-e7b0-4fbb-b47a-1de5c815c54f@github.com> References: <11-WiDUglsNQb4vNj5DuXscdI3gY-GbODupTFT7VFhA=.cd737114-e7b0-4fbb-b47a-1de5c815c54f@github.com> Message-ID: On Fri, 3 Nov 2023 16:51:34 GMT, Viktor Klang wrote: >> Since stream facilities are package-private, we can just use no access modifier and remove all new `protected` access modifier (on methods, fields, constructors) in this PR. > > @liach We could do that, yet I'm not sure that is strictly an improvement. What would be the benefit in doing so specifically for this PR? It is an improvement, it reduces the visibility and `protected` is rarely used in modern code because inheriting from a class from a package you do not control means that the API of the subclass is not stable. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1386943330 From forax at openjdk.org Wed Nov 8 17:08:05 2023 From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax) Date: Wed, 8 Nov 2023 17:08:05 GMT Subject: RFR: JDK-8319123 : Implementation of JEP-461: Stream Gatherers (Preview) In-Reply-To: References: Message-ID: On Mon, 30 Oct 2023 15:38:35 GMT, Viktor Klang wrote: > This Pull-Request implements [JEP-461](https://openjdk.org/jeps/461) src/java.base/share/classes/java/util/stream/AbstractPipeline.java line 223: > 221: * consumed > 222: */ > 223: protected AbstractPipeline(AbstractPipeline previousPreviousStage, AbstractPipeline previousStage, int opFlags) { Same here ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1386943713 From forax at openjdk.org Wed Nov 8 17:08:07 2023 From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax) Date: Wed, 8 Nov 2023 17:08:07 GMT Subject: RFR: JDK-8319123 : Implementation of JEP-461: Stream Gatherers (Preview) In-Reply-To: References: Message-ID: <3Jkh_xeb_y4t2eXIkRMPpFSsvTq_Be9ScAD9YofNScU=.53a0c82a-600d-4293-8215-e9e93a86c56e@github.com> On Tue, 31 Oct 2023 13:19:30 GMT, Viktor Klang wrote: >> This Pull-Request implements [JEP-461](https://openjdk.org/jeps/461) > > src/java.base/share/classes/java/util/stream/AbstractPipeline.java line 242: > >> 240: } >> 241: >> 242: // Terminal evaluation methods > > This is needed in order to let subclasses override terminal operations such as, but not limited to, `collect`. (since a terminal operation needs to mark the entire pipeline as consumed). It's not clear in which case the exception is thrown from the POV of a user of the API. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1386945056 From vklang at openjdk.org Wed Nov 8 17:08:08 2023 From: vklang at openjdk.org (Viktor Klang) Date: Wed, 8 Nov 2023 17:08:08 GMT Subject: RFR: JDK-8319123 : Implementation of JEP-461: Stream Gatherers (Preview) In-Reply-To: <_lzZlI6Wypm7nnK6HF90jALtL50nRS-egAjy6vNqlAk=.68544b66-b213-46ae-ba8f-607328f8ba7f@github.com> References: <3z8IYhG73DKYCv_643Jtb-nDyNRlaLPyvqoPTDeI6SM=.b336d2d0-29ea-4ee2-98e9-3d89f4f85a7d@github.com> <_lzZlI6Wypm7nnK6HF90jALtL50nRS-egAjy6vNqlAk=.68544b66-b213-46ae-ba8f-607328f8ba7f@github.com> Message-ID: On Wed, 8 Nov 2023 16:37:45 GMT, Tagir F. Valeev wrote: >> TBH I don't think `foldRight` makes much sense for potentially unbounded structures such as Stream. In the case you need it, it might be better to export it to a List and then reversing it. > > Well, the unboundness argument does not hold, as it can be equally applied to any operation except the short-circuiting ones. Yes, this includes your `fold()`. The only difference is that `foldRight()` will fail with OutOfMemoryError while `fold()` will be stuck in the endless loop. Or probably also fail depending on the folder function (for example, if it's a string concatenation, like in the Javadoc example). You may not like the fact the `foldRight()` buffers the whole stream content, but we already have operations like this, namely `sorted()` and parallel ordered `distinct()`. > > I'm not convincing you to add `foldRight()` to the JDK. But if we don't have it, somebody will surely write it in third-party libraries. After all, this is what third-party libraries are for. In this case, simple name `fold()` can be confusing. > > Note that Haskell has separate foldl, foldr, scanl, scanr, so the order is always clear. Scala has `fold()` (which is like `reduce()` and can fold in any order), `foldLeft()` and `foldRight()`. Naming this method simply `fold()` sounds quite confusing. It should be either `foldLeft()` or `reduceLeft()` (even if we don't provide the -right versions) The my argument around the unboundedness was semantical (starting from the end doesn't make semantical sense for something with no defined end). In this case it doesn't necessarily need to be an infinite stream for it to cause trouble, a large collection might be enough, since you need enough memory to reverse the order which means either making a full copy or having a (very) deep stack. Having used "Left" and "Right"-named operations for a very long time, I am of the opinion that the "Left"-ones are the 98% use-case, so in this case I am inclined to be that it is going to be less confusing to developers to be "Left-biased" in the naming. I'm completely aware that I could be wrong here, yet with that said, I did give it a lot of thought before deciding. My hope is that there will be a lot of `Gatherer`s created by Java developers so that they can use Streams for more use-cases, and be able to stay within Streams for as long as they need. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1386946766 From mchung at openjdk.org Wed Nov 8 17:10:11 2023 From: mchung at openjdk.org (Mandy Chung) Date: Wed, 8 Nov 2023 17:10:11 GMT Subject: RFR: 8187655: jdk.lambda.vm.InterfaceAccessFlagsTest.testPrivateMethodCall needs update after nestmates support [v3] In-Reply-To: References: Message-ID: <97n9KC5OT1LTFsniXEpqE3vnqO8Npd-4XDjyULt-tM8=.27e8e66e-c757-4bb5-94e9-bdfcdbaec2eb@github.com> > `jdk.lambda.vm.InterfaceAccessFlagsTest` uses `ClassToInterfaceConverter` to mechanically convert a classfile for a Class into an in-memory class representation of an equivalent Interface. `testPrivateMethodCall` tests to invoke a private method. Before nestmates, invoking a private class method and a private interface method both use `Invokespecial`. With the nestmate changes, the class uses `invokevirtual` but the interface must use `invokeinterface` but this conversion is not handled by the existing `ClassToInterfaceConverter`. > > This fix converts `ClassToInterfaceConverter` to use the Class-File API to properly convert a classfile from a class to an interface including method invocation from `invokevirtual` to `invokeinterface`. The old custom bytecode manipulation code can be dropped. Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: fix whitespace and minor changes per review feedback ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16526/files - new: https://git.openjdk.org/jdk/pull/16526/files/7feb2ffc..7352ca5d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16526&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16526&range=01-02 Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/16526.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16526/head:pull/16526 PR: https://git.openjdk.org/jdk/pull/16526 From tvaleev at openjdk.org Wed Nov 8 17:14:04 2023 From: tvaleev at openjdk.org (Tagir F. Valeev) Date: Wed, 8 Nov 2023 17:14:04 GMT Subject: RFR: JDK-8319123 : Implementation of JEP-461: Stream Gatherers (Preview) In-Reply-To: References: Message-ID: On Wed, 8 Nov 2023 15:23:39 GMT, Viktor Klang wrote: >> This is especially important given that often you don't know the AA type at all. E.g., imagine that you are doing `.andThen(Gatherers.fold(...))`, but `fold` returns `Gatherer`, so you can specify explicit `RR`, but not `AA`. > > Has this proven to be a problem for things like [Collectors.mapping(?)](https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/util/stream/Collectors.html#mapping(java.util.function.Function,java.util.stream.Collector)) ? ? > > There's one implication on turning it into a wildcard?it may actually cause issues implementing the composition directly in the override, as you won't have a typename to refer to. > > Do you have a concrete example of where the current "encoding" causes a caller-problem? The API should be client-friendly, not implementor-friendly, given that it's expected to have much more clients than implementors. An implementor can easily delegate to a private method to add missing type parameters. I did exactly this in the [teeing](https://github.com/openjdk/jdk/blob/7d25f1c6cb770e21cfad8096c1637a24e65fab8c/src/java.base/share/classes/java/util/stream/Collectors.java#L1913) Collector before. There should not be a reason to expose a parameter, which is merely an implementation detail. This also complicates the public documentation of the already complex feature, specifying the parameter which is not necessary to specify. > Has this proven to be a problem for things like [Collectors.mapping(?)](https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/util/stream/Collectors.html#mapping(java.util.function.Function,java.util.stream.Collector)) ? I'm not sure how I can prove this, given that you don't usually know the downstream accumulator, so if somebody hits this problem, they will be forced to solve it in another way (e.g., extracting parts of complex collector to separate variables), so you won't find the code in the wild which uses `mapping` type arguments explicitly. Yes, `Collectors.mapping` and `groupingBy` did this mistake in the past, and there's no reason to repeat it again. > Do you have a concrete example of where the current "encoding" causes a caller-problem? For example, I want to create a reusable gatherer that performs scan-concat and wraps every resulting string with '[...]'. First try: var gatherer = Gatherers.scan(() -> "", String::concat) .andThen(Gatherer.ofSequential((_, t, pusher) -> pusher.push(STR."[{t}]"))); Now, the type of `gatherer` is `Gatherer`, but I want `Gatherer`. I have the following alternatives: 1. Specify the variable type explicitly: Gatherer gatherer = Gatherers.scan(() -> "", String::concat) .andThen(Gatherer.ofSequential((_, t, pusher) -> pusher.push(STR."[{t}]"))); 2. Specify `ofSequential` type arguments: var gatherer = Gatherers.scan(() -> "", String::concat) .andThen(Gatherer.ofSequential((_, t, pusher) -> pusher.push(STR."[{t}]"))); 3. Specify the types of lambda arguments explicitly: var gatherer = Gatherers.scan(() -> "", String::concat) .andThen(Gatherer.ofSequential((Void _, String t, Downstream pusher) -> pusher.push(STR."[{t}]"))); 4. Specify `.andThen` type arguments: var gatherer = Gatherers.scan(() -> "", String::concat) .andThen(Gatherer.ofSequential((_, t, pusher) -> pusher.push(STR."[{t}]"))); In all the cases, I need to specify explicitly more types than I need, as I need to specify only `String`. If we remove `AA`, then specifying `andThen` type arguments would be the shortest and the most readable alternative: var gatherer = Gatherers.scan(() -> "", String::concat) .andThen(Gatherer.ofSequential((_, t, pusher) -> pusher.push(STR."[{t}]"))); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1386952517 From forax at openjdk.org Wed Nov 8 17:14:05 2023 From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax) Date: Wed, 8 Nov 2023 17:14:05 GMT Subject: RFR: JDK-8319123 : Implementation of JEP-461: Stream Gatherers (Preview) In-Reply-To: References: Message-ID: On Wed, 8 Nov 2023 17:10:05 GMT, Tagir F. Valeev wrote: >> Has this proven to be a problem for things like [Collectors.mapping(?)](https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/util/stream/Collectors.html#mapping(java.util.function.Function,java.util.stream.Collector)) ? ? >> >> There's one implication on turning it into a wildcard?it may actually cause issues implementing the composition directly in the override, as you won't have a typename to refer to. >> >> Do you have a concrete example of where the current "encoding" causes a caller-problem? > > The API should be client-friendly, not implementor-friendly, given that it's expected to have much more clients than implementors. An implementor can easily delegate to a private method to add missing type parameters. I did exactly this in the [teeing](https://github.com/openjdk/jdk/blob/7d25f1c6cb770e21cfad8096c1637a24e65fab8c/src/java.base/share/classes/java/util/stream/Collectors.java#L1913) Collector before. There should not be a reason to expose a parameter, which is merely an implementation detail. This also complicates the public documentation of the already complex feature, specifying the parameter which is not necessary to specify. > >> Has this proven to be a problem for things like [Collectors.mapping(?)](https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/util/stream/Collectors.html#mapping(java.util.function.Function,java.util.stream.Collector)) ? > > I'm not sure how I can prove this, given that you don't usually know the downstream accumulator, so if somebody hits this problem, they will be forced to solve it in another way (e.g., extracting parts of complex collector to separate variables), so you won't find the code in the wild which uses `mapping` type arguments explicitly. Yes, `Collectors.mapping` and `groupingBy` did this mistake in the past, and there's no reason to repeat it again. > >> Do you have a concrete example of where the current "encoding" causes a caller-problem? > > For example, I want to create a reusable gatherer that performs scan-concat and wraps every resulting string with '[...]'. First try: > > > var gatherer = Gatherers.scan(() -> "", String::concat) > .andThen(Gatherer.ofSequential((_, t, pusher) -> pusher.push(STR."[{t}]"))); > > > Now, the type of `gatherer` is `Gatherer`, but I want `Gatherer`. I have the following alternatives: > 1. Specify the variable type explicitly: > > Gatherer gatherer = Gatherers.scan(() -> "", String::concat) > .andThen(Gatherer.ofSequential((_, t, pusher) -> pusher.push(STR."[{t}]"))); > > 2. Specify `ofSequential` type arguments: > > var gatherer = Gatherers.scan(() -> "", String::concat) > .andThen(Gatherer.ofSequential((_, t, pusher) -> pusher.push(STR."[{t}]"))); > > 3. Specify the types of lambda arguments explicitly: > > var gatherer = Gatherers.scan(() -> "", String::concat) > .andThen(Gatherer.ofSequential((Void _, String t, Downstream pusher) -> pusher.push(STR."[{t}]"))); > > 4. Specify `.andThen` type a... I agree with Tagir here, it should be an ? and if you want to capture it in a type variable you can use the standard trick of having the private method declaring the type variable and the public method with the wildcard calling the private method. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1386954327 From asotona at openjdk.org Wed Nov 8 17:18:58 2023 From: asotona at openjdk.org (Adam Sotona) Date: Wed, 8 Nov 2023 17:18:58 GMT Subject: RFR: 8187655: jdk.lambda.vm.InterfaceAccessFlagsTest.testPrivateMethodCall needs update after nestmates support [v3] In-Reply-To: <97n9KC5OT1LTFsniXEpqE3vnqO8Npd-4XDjyULt-tM8=.27e8e66e-c757-4bb5-94e9-bdfcdbaec2eb@github.com> References: <97n9KC5OT1LTFsniXEpqE3vnqO8Npd-4XDjyULt-tM8=.27e8e66e-c757-4bb5-94e9-bdfcdbaec2eb@github.com> Message-ID: On Wed, 8 Nov 2023 17:10:11 GMT, Mandy Chung wrote: >> `jdk.lambda.vm.InterfaceAccessFlagsTest` uses `ClassToInterfaceConverter` to mechanically convert a classfile for a Class into an in-memory class representation of an equivalent Interface. `testPrivateMethodCall` tests to invoke a private method. Before nestmates, invoking a private class method and a private interface method both use `Invokespecial`. With the nestmate changes, the class uses `invokevirtual` but the interface must use `invokeinterface` but this conversion is not handled by the existing `ClassToInterfaceConverter`. >> >> This fix converts `ClassToInterfaceConverter` to use the Class-File API to properly convert a classfile from a class to an interface including method invocation from `invokevirtual` to `invokeinterface`. The old custom bytecode manipulation code can be dropped. > > Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: > > fix whitespace and minor changes per review feedback Looks good. ------------- Marked as reviewed by asotona (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16526#pullrequestreview-1720882604 From forax at openjdk.org Wed Nov 8 17:29:03 2023 From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax) Date: Wed, 8 Nov 2023 17:29:03 GMT Subject: RFR: JDK-8319123 : Implementation of JEP-461: Stream Gatherers (Preview) In-Reply-To: References: <3z8IYhG73DKYCv_643Jtb-nDyNRlaLPyvqoPTDeI6SM=.b336d2d0-29ea-4ee2-98e9-3d89f4f85a7d@github.com> <8U_gZrZdfBEfUJm394moAzoPXayVE6Sdh5rxWXVdcDc=.7731cb78-927f-4661-881e-c1b539bb6590@github.com> Message-ID: On Wed, 8 Nov 2023 15:17:57 GMT, Viktor Klang wrote: >> It's still possible to have a situation where PECS signature could be useful, and I don't see any downsides. A user may want to reuse the same static integrator instead of creating several identical lambdas just because the target type is more specific. Sometimes, people complain later, and you'll have to fix this. For example, see that `Stream.generate()` [was fixed separately](https://bugs.openjdk.org/browse/JDK-8132097). So why not doing this from the very beginning? > > @amaembo In this case, given that it is intended as Preview, I think it makes sense to receive some user feedback on this. Note that Collector has been without PECS for Collector.of since 1.8: [of](https://docs.oracle.com/javase/8/docs/api/java/util/stream/Collector.html#of-java.util.function.Supplier-java.util.function.BiConsumer-java.util.function.BinaryOperator-java.util.function.Function-java.util.stream.Collector.Characteristics...-) > > Right now I don't want to deviate from the Collector-heritage until there's more usage feedback, and I'm definitely not ruling out that PECS:ing the factories might be worth it. I don't see the point of waiting here. Usually requests for PECSing signatures always comes two or three years after the API is realing when people starts to use the API in anger so the preview time is likely not enough. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1386958540 From forax at openjdk.org Wed Nov 8 17:29:05 2023 From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax) Date: Wed, 8 Nov 2023 17:29:05 GMT Subject: RFR: JDK-8319123 : Implementation of JEP-461: Stream Gatherers (Preview) In-Reply-To: References: Message-ID: On Sun, 5 Nov 2023 16:18:52 GMT, Tagir F. Valeev wrote: >> This Pull-Request implements [JEP-461](https://openjdk.org/jeps/461) > > src/java.base/share/classes/java/util/stream/Gatherer.java line 330: > >> 328: static Gatherer ofSequential( >> 329: Integrator integrator, >> 330: BiConsumer> finisher) { > > Probably, accepting `Consumer>` and adapting it would be more user-friendly? In that case the integrator should be a BiConsumer too, no ? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1386961034 From tvaleev at openjdk.org Wed Nov 8 17:29:06 2023 From: tvaleev at openjdk.org (Tagir F. Valeev) Date: Wed, 8 Nov 2023 17:29:06 GMT Subject: RFR: JDK-8319123 : Implementation of JEP-461: Stream Gatherers (Preview) In-Reply-To: References: Message-ID: On Wed, 8 Nov 2023 17:17:21 GMT, R?mi Forax wrote: >> src/java.base/share/classes/java/util/stream/Gatherer.java line 330: >> >>> 328: static Gatherer ofSequential( >>> 329: Integrator integrator, >>> 330: BiConsumer> finisher) { >> >> Probably, accepting `Consumer>` and adapting it would be more user-friendly? > > In that case the integrator should be a BiConsumer too, no ? @forax I thought so initially, but this is not so easy, as there's a `Greedy` subinterface. If you adapt the `Integrator`, you will lose the ability to specify the greediness. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1386964483 From forax at openjdk.org Wed Nov 8 17:29:10 2023 From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax) Date: Wed, 8 Nov 2023 17:29:10 GMT Subject: RFR: JDK-8319123 : Implementation of JEP-461: Stream Gatherers (Preview) In-Reply-To: References: Message-ID: On Mon, 30 Oct 2023 15:38:35 GMT, Viktor Klang wrote: > This Pull-Request implements [JEP-461](https://openjdk.org/jeps/461) src/java.base/share/classes/java/util/stream/Gatherer.java line 444: > 442: */ > 443: static Gatherer of( > 444: Supplier initializer, wildcards are missing here too, Supplier, Integrator and BiConsumer>. src/java.base/share/classes/java/util/stream/Gatherer.java line 490: > 488: * more elements sent to it, {@code false} if otherwise > 489: */ > 490: default boolean isRejecting() { return false; } Is it really a good default ? src/java.base/share/classes/java/util/stream/Gatherer.java line 530: > 528: * @param the type of results this integrator can produce > 529: */ > 530: @ForceInline If we add this kind of the methods, we should add them on all function interfaces of java.util.function and java.util.stream. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1386965623 PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1386966965 PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1386970112 From forax at openjdk.org Wed Nov 8 17:29:12 2023 From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax) Date: Wed, 8 Nov 2023 17:29:12 GMT Subject: RFR: JDK-8319123 : Implementation of JEP-461: Stream Gatherers (Preview) In-Reply-To: References: Message-ID: On Wed, 8 Nov 2023 17:22:05 GMT, R?mi Forax wrote: >> This Pull-Request implements [JEP-461](https://openjdk.org/jeps/461) > > src/java.base/share/classes/java/util/stream/Gatherer.java line 490: > >> 488: * more elements sent to it, {@code false} if otherwise >> 489: */ >> 490: default boolean isRejecting() { return false; } > > Is it really a good default ? It is not better to have 2 Downstream (Downstream and a subtype) like you hae two integrators (Integrator and Greedy) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1386972223 From lancea at openjdk.org Wed Nov 8 17:30:12 2023 From: lancea at openjdk.org (Lance Andersen) Date: Wed, 8 Nov 2023 17:30:12 GMT Subject: RFR: 8314891: Additional Zip64 extra header validation [v8] In-Reply-To: References: Message-ID: On Wed, 8 Nov 2023 16:27:56 GMT, Eirik Bjorsnos wrote: > @LanceAndersen > > I noticed that this PR did not update `ZipInputStream.readLOC` to perform consistency validation between expected and actual extra field size and values. Any particular reason why processing of LOC headers was not made consistent with CEN? Intentional, as this was a follow on to the updates which were done previously to the CEN work in August, this is follow on cleanup. Updates to ZipInputStream would be done separately under a separate PR or could be done via your work on 8303866 ------------- PR Comment: https://git.openjdk.org/jdk/pull/15650#issuecomment-1802340986 From forax at openjdk.org Wed Nov 8 17:32:04 2023 From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax) Date: Wed, 8 Nov 2023 17:32:04 GMT Subject: RFR: JDK-8319123 : Implementation of JEP-461: Stream Gatherers (Preview) In-Reply-To: References: Message-ID: On Mon, 30 Oct 2023 15:38:35 GMT, Viktor Klang wrote: > This Pull-Request implements [JEP-461](https://openjdk.org/jeps/461) src/java.base/share/classes/java/util/stream/GathererOp.java line 50: > 48: */ > 49: final class GathererOp extends ReferencePipeline { > 50: @SuppressWarnings("unchecked") Could you explain why you need a SuppressWarnings here, especially the cast to (ReferencePipeline) in the else case ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1386975669 From forax at openjdk.org Wed Nov 8 17:39:05 2023 From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax) Date: Wed, 8 Nov 2023 17:39:05 GMT Subject: RFR: JDK-8319123 : Implementation of JEP-461: Stream Gatherers (Preview) In-Reply-To: References: Message-ID: On Mon, 30 Oct 2023 15:38:35 GMT, Viktor Klang wrote: > This Pull-Request implements [JEP-461](https://openjdk.org/jeps/461) src/java.base/share/classes/java/util/stream/GathererOp.java line 95: > 93: public void accept(X x) { > 94: final var b = rightMost; > 95: (b == null ? (rightMost = new NodeBuilder.Builder<>()) : b).accept(x); I think this code is unecessarily hard to read. var rightMost = this.rightMost; if (rightMost == null) { rightMost = this.rightMost = new NodeBuilder.Builder<>(); } rightMost.accept(x); src/java.base/share/classes/java/util/stream/GathererOp.java line 99: > 97: > 98: public NodeBuilder join(NodeBuilder that) { > 99: if (isEmpty()) Please add curly braces around if and if/else ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1386982341 PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1386984238 From darcy at openjdk.org Wed Nov 8 17:39:11 2023 From: darcy at openjdk.org (Joe Darcy) Date: Wed, 8 Nov 2023 17:39:11 GMT Subject: RFR: JDK-8295391: Add discussion of binary <-> decimal conversion issues Message-ID: Add discussion of some of the common pitfalls related to decimal <-> binary conversion. ------------- Commit messages: - Appease jcheck. - JDK-8295391: Add discussion of binary <-> decimal conversion issues Changes: https://git.openjdk.org/jdk/pull/16566/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16566&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8295391 Stats: 133 lines in 1 file changed: 133 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/16566.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16566/head:pull/16566 PR: https://git.openjdk.org/jdk/pull/16566 From forax at openjdk.org Wed Nov 8 17:44:04 2023 From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax) Date: Wed, 8 Nov 2023 17:44:04 GMT Subject: RFR: JDK-8319123 : Implementation of JEP-461: Stream Gatherers (Preview) In-Reply-To: References: Message-ID: On Mon, 30 Oct 2023 15:38:35 GMT, Viktor Klang wrote: > This Pull-Request implements [JEP-461](https://openjdk.org/jeps/461) src/java.base/share/classes/java/util/stream/GathererOp.java line 180: > 178: finisher.accept(state, this); > 179: sink.end(); > 180: state = null; // GC assistance Not sure it really helps the GC, given that it may go through a GC barrier ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1386990459 From vklang at openjdk.org Wed Nov 8 17:48:01 2023 From: vklang at openjdk.org (Viktor Klang) Date: Wed, 8 Nov 2023 17:48:01 GMT Subject: RFR: JDK-8319123 : Implementation of JEP-461: Stream Gatherers (Preview) In-Reply-To: References: Message-ID: On Wed, 8 Nov 2023 17:20:56 GMT, R?mi Forax wrote: >> This Pull-Request implements [JEP-461](https://openjdk.org/jeps/461) > > src/java.base/share/classes/java/util/stream/Gatherer.java line 444: > >> 442: */ >> 443: static Gatherer of( >> 444: Supplier initializer, > > wildcards are missing here too, Supplier, Integrator and BiConsumer>. See separate discussion on PECS. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1386994559 From vklang at openjdk.org Wed Nov 8 17:48:03 2023 From: vklang at openjdk.org (Viktor Klang) Date: Wed, 8 Nov 2023 17:48:03 GMT Subject: RFR: JDK-8319123 : Implementation of JEP-461: Stream Gatherers (Preview) In-Reply-To: <_lzZlI6Wypm7nnK6HF90jALtL50nRS-egAjy6vNqlAk=.68544b66-b213-46ae-ba8f-607328f8ba7f@github.com> References: <3z8IYhG73DKYCv_643Jtb-nDyNRlaLPyvqoPTDeI6SM=.b336d2d0-29ea-4ee2-98e9-3d89f4f85a7d@github.com> <_lzZlI6Wypm7nnK6HF90jALtL50nRS-egAjy6vNqlAk=.68544b66-b213-46ae-ba8f-607328f8ba7f@github.com> Message-ID: On Wed, 8 Nov 2023 16:39:33 GMT, Tagir F. Valeev wrote: >> That's a good question, and here's my thinking?`scanRight` doesn't make any sense for a construct which supports unboundedness, so if we were discussing *Collections* I'd be more inclined to agree (but it is more likely that reversing the collection and then calling scanLeft would be better). > > See the previous comment. Even if we don't provide `scanRight` for symmetry, the name `scanLeft` for this method would be clearer. As an alternative, consider the `prefix` name, as we already have `Arrays.parallelPrefix`, which performs the same operation on arrays. I'll take that under consideration ? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1386993704 From bpb at openjdk.org Wed Nov 8 17:51:01 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 8 Nov 2023 17:51:01 GMT Subject: RFR: 8318915: Enhance checks in BigDecimal.toPlainString() [v2] In-Reply-To: References: Message-ID: On Wed, 8 Nov 2023 09:55:13 GMT, Raffaello Giulietti wrote: >> src/java.base/share/classes/java/math/BigDecimal.java line 3510: >> >>> 3508: : intVal.toString(); >>> 3509: int len = str.length() + trailingZeros; >>> 3510: if (len < 0) { >> >> One could use `Math.addExact`, which has an intrinsic, and convert any thrown `ArithmeticException` into an OOME but I am not sure it's worth it. > > Yes, I considered that but I'm not sure how the throwing and catching of `ArithmeticException` with `*Exact` intrinsics is optimized by C2, so I have a manual overflow check for the addition. I think it's fine as is. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16457#discussion_r1386998599 From vklang at openjdk.org Wed Nov 8 17:56:06 2023 From: vklang at openjdk.org (Viktor Klang) Date: Wed, 8 Nov 2023 17:56:06 GMT Subject: RFR: JDK-8319123 : Implementation of JEP-461: Stream Gatherers (Preview) In-Reply-To: References: Message-ID: <-NW4iXbwMnKozZe6_QMlUX3mcsyN_uuWUB1sdL7R_VU=.e746b322-1b4c-47df-b94c-a41a9a163c54@github.com> On Wed, 8 Nov 2023 17:26:35 GMT, R?mi Forax wrote: >> src/java.base/share/classes/java/util/stream/Gatherer.java line 490: >> >>> 488: * more elements sent to it, {@code false} if otherwise >>> 489: */ >>> 490: default boolean isRejecting() { return false; } >> >> Is it really a good default ? > > It is not better to have 2 Downstream (Downstream and a subtype) like you hae two integrators (Integrator and Greedy) Yes, it's the best possible default. The Downstream can become rejecting after any push, so any operations which do multiple pushes would not see that. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1386996877 From vklang at openjdk.org Wed Nov 8 17:56:08 2023 From: vklang at openjdk.org (Viktor Klang) Date: Wed, 8 Nov 2023 17:56:08 GMT Subject: RFR: JDK-8319123 : Implementation of JEP-461: Stream Gatherers (Preview) In-Reply-To: References: Message-ID: On Wed, 8 Nov 2023 17:24:45 GMT, R?mi Forax wrote: >> This Pull-Request implements [JEP-461](https://openjdk.org/jeps/461) > > src/java.base/share/classes/java/util/stream/Gatherer.java line 530: > >> 528: * @param the type of results this integrator can produce >> 529: */ >> 530: @ForceInline > > If we add this kind of the methods, we should add them on all function interfaces of java.util.function and java.util.stream. Seems out of scope for this JEP > src/java.base/share/classes/java/util/stream/GathererOp.java line 50: > >> 48: */ >> 49: final class GathererOp extends ReferencePipeline { >> 50: @SuppressWarnings("unchecked") > > Could you explain why you need a SuppressWarnings here, especially the cast to (ReferencePipeline) in the else case Suggested improvements are most welcome! ? > src/java.base/share/classes/java/util/stream/GathererOp.java line 95: > >> 93: public void accept(X x) { >> 94: final var b = rightMost; >> 95: (b == null ? (rightMost = new NodeBuilder.Builder<>()) : b).accept(x); > > I think this code is unecessarily hard to read. > > var rightMost = this.rightMost; > if (rightMost == null) { > rightMost = this.rightMost = new NodeBuilder.Builder<>(); > } > rightMost.accept(x); Benchmark your change first. If it is cost-neutral I'm all for changing! > src/java.base/share/classes/java/util/stream/GathererOp.java line 180: > >> 178: finisher.accept(state, this); >> 179: sink.end(); >> 180: state = null; // GC assistance > > Not sure it really helps the GC, given that it may go through a GC barrier When it helps, it helps, and when it doesn't it has negligible cost. > src/java.base/share/classes/java/util/stream/GathererOp.java line 232: > >> 230: */ >> 231: @SuppressWarnings("unchecked") >> 232: private GathererOp(Gatherer gatherer, GathererOp upstream) { > > Is it not better to use a static method named by example `fuse`, i don't understand why it has to be a constructor. It is only ever exposed via a static method. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1386998422 PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1386999183 PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1387000558 PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1387002929 PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1387003542 From forax at openjdk.org Wed Nov 8 17:56:09 2023 From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax) Date: Wed, 8 Nov 2023 17:56:09 GMT Subject: RFR: JDK-8319123 : Implementation of JEP-461: Stream Gatherers (Preview) In-Reply-To: References: Message-ID: <8-0KesPMf0kSxjf7K7pMsci9S5FSi9l1LYXH78g_nk8=.0f1f0a45-7d32-4458-8a2d-3c4990eb0463@github.com> On Mon, 30 Oct 2023 15:38:35 GMT, Viktor Klang wrote: > This Pull-Request implements [JEP-461](https://openjdk.org/jeps/461) src/java.base/share/classes/java/util/stream/GathererOp.java line 232: > 230: */ > 231: @SuppressWarnings("unchecked") > 232: private GathererOp(Gatherer gatherer, GathererOp upstream) { Is it not better to use a static method named by example `fuse`, i don't understand why it has to be a constructor. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1386996068 From bpb at openjdk.org Wed Nov 8 17:59:02 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 8 Nov 2023 17:59:02 GMT Subject: RFR: JDK-8295391: Add discussion of binary <-> decimal conversion issues In-Reply-To: References: Message-ID: On Wed, 8 Nov 2023 17:29:28 GMT, Joe Darcy wrote: > Add discussion of some of the common pitfalls related to decimal <-> binary conversion. src/java.base/share/classes/java/lang/Double.java line 212: > 210: * fraction (0.33333....); but in base 3, 1/3 is exactly > 211: * 0.1(3), that is 1 × 3-1. > 212: * Similarly, in base 10, 1/10 is exactly presentable as 0.1, but in `re`presentable? src/java.base/share/classes/java/lang/Double.java line 234: > 232: * consistent with a {@code float} value having the equivalent of 6 to > 233: * 9 digits of decimal precision and a {@code double} value having the > 234: * equivalent of 15 and 17 digits of decimal precision. (The 15 `to` 17? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16566#discussion_r1387005350 PR Review Comment: https://git.openjdk.org/jdk/pull/16566#discussion_r1387006602 From forax at openjdk.org Wed Nov 8 17:59:07 2023 From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax) Date: Wed, 8 Nov 2023 17:59:07 GMT Subject: RFR: JDK-8319123 : Implementation of JEP-461: Stream Gatherers (Preview) In-Reply-To: References: Message-ID: On Mon, 30 Oct 2023 15:38:35 GMT, Viktor Klang wrote: > This Pull-Request implements [JEP-461](https://openjdk.org/jeps/461) src/java.base/share/classes/java/util/stream/GathererOp.java line 448: > 446: private final long targetSize; > 447: private final Hybrid leftPredecessor; > 448: private final AtomicBoolean cancelled; It could be a volatile boolean and a comment is needed saying this field is only be accessed if greedy is true. And inside the constructors this should be the last field of the constructor to be initialized ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1387006826 From forax at openjdk.org Wed Nov 8 18:07:05 2023 From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax) Date: Wed, 8 Nov 2023 18:07:05 GMT Subject: RFR: JDK-8319123 : Implementation of JEP-461: Stream Gatherers (Preview) In-Reply-To: References: Message-ID: On Mon, 30 Oct 2023 15:38:35 GMT, Viktor Klang wrote: > This Pull-Request implements [JEP-461](https://openjdk.org/jeps/461) src/java.base/share/classes/java/util/stream/Gatherers.java line 64: > 62: * needlessly > 63: * 3. allows for more efficient composition and evaluation > 64: */ The downside is that if this object escape there will be spurious ClassCastException where the compiler insert cast for erasure that are hard to diagnose. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1387015480 From rgiulietti at openjdk.org Wed Nov 8 18:21:59 2023 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Wed, 8 Nov 2023 18:21:59 GMT Subject: RFR: JDK-8295391: Add discussion of binary <-> decimal conversion issues In-Reply-To: References: Message-ID: On Wed, 8 Nov 2023 17:29:28 GMT, Joe Darcy wrote: > Add discussion of some of the common pitfalls related to decimal <-> binary conversion. src/java.base/share/classes/java/lang/Double.java line 257: > 255: *
// Numeric values listed are exact values > 256: *
oneTenthApproxAsFloat = 0.100000001490116119384765625; > 257: *
ulpOfoneTenthApproxAsFloat = Math.ulp(1.0f) = 7.450580596923828125E-9; Suggestion: *
ulpOfoneTenthApproxAsFloat = Math.ulp(0.1f) = 7.450580596923828125E-9; src/java.base/share/classes/java/lang/Double.java line 264: > 262: *

In particular, a correctly rounded decimal to binary conversion > 263: * of any string representing a number in this range, say by {@link > 264: * Float#valueOf(float)}, will be converted to the same value: Suggestion: * Float#valueOf(String)}, will be converted to the same value: src/java.base/share/classes/java/lang/Double.java line 287: > 285: *

  • less than the exact result > 286: *
  • equal to the exact result > 287: * More compactly: `the same floating-point value as a result can be greater than, less than, or equal to the exact result.` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16566#discussion_r1387022202 PR Review Comment: https://git.openjdk.org/jdk/pull/16566#discussion_r1387027404 PR Review Comment: https://git.openjdk.org/jdk/pull/16566#discussion_r1387029494 From info at birkeheeren.de Wed Nov 8 18:22:08 2023 From: info at birkeheeren.de (Birke Heeren) Date: Wed, 8 Nov 2023 19:22:08 +0100 (CET) Subject: clazz deepclone = new DeepClone().do(object_to_be_copied); JEP 198: Light-Weight JSON API Message-ID: <734327874.975299.1699467728236@webmail.strato.com> Hi openjdk, I want to support JEP 198: Light-Weight JSON API with an idea: clazz deepclone = new DeepClone().do(object_to_be_copied); class DeepClone clazz do (clazz object_to_be_copied) { return new JSONDecoder().do(new JsonEncoder().do(object_to_be_copied)); } With kind regards, Birke Heeren -------------- next part -------------- An HTML attachment was scrubbed... URL: From rgiulietti at openjdk.org Wed Nov 8 18:40:07 2023 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Wed, 8 Nov 2023 18:40:07 GMT Subject: RFR: 8311906: Improve robustness of String constructors with mutable array inputs In-Reply-To: <6SKlGLh5MmxoEx07wHCCUc8KWbbhcspLJmcc1uxQ_FI=.ca33bfb4-fa5c-45f0-b49f-ee6c5c6b68b4@github.com> References: <6SKlGLh5MmxoEx07wHCCUc8KWbbhcspLJmcc1uxQ_FI=.ca33bfb4-fa5c-45f0-b49f-ee6c5c6b68b4@github.com> Message-ID: On Mon, 30 Oct 2023 18:34:44 GMT, Roger Riggs wrote: > Strings, after construction, are immutable but may be constructed from mutable arrays of bytes, characters, or integers. > The string constructors should guard against the effects of mutating the arrays during construction that might invalidate internal invariants for the correct behavior of operations on the resulting strings. In particular, a number of operations have optimizations for operations on pairs of latin1 strings and pairs of non-latin1 strings, while operations between latin1 and non-latin1 strings use a more general implementation. > > The changes include: > > - Adding a warning to each constructor with an array as an argument to indicate that the results are indeterminate > if the input array is modified before the constructor returns. > The resulting string may contain any combination of characters sampled from the input array. > > - Ensure that strings that are represented as non-latin1 contain at least one non-latin1 character. > For latin1 inputs, whether the arrays contain ASCII, ISO-8859-1, UTF8, or another encoding decoded to latin1 the scanning and compression is unchanged. > If a non-latin1 character is found, the string is represented as non-latin1 with the added verification that a non-latin1 character is present at the same index. > If that character is found to be latin1, then the input array has been modified and the result of the scan may be incorrect. > Though a ConcurrentModificationException could be thrown, the risk to an existing application of an unexpected exception should be avoided. > Instead, the non-latin1 copy of the input is re-scanned and compressed; that scan determines whether the latin1 or the non-latin1 representation is returned. > > - The methods that scan for non-latin1 characters and their intrinsic implementations are updated to return the index of the non-latin1 character. > > - String construction from StringBuilder and CharSequence must also be guarded as their contents may be modified during construction. First take ;-) More will follow. src/java.base/share/classes/java/lang/String.java line 602: > 600: } > 601: this.value = utf16; > 602: this.coder = (utf16.length == dp) ? LATIN1 : UTF16; Is it possible to have `utf16.length == dp` here? I think the `coder` can only be `UTF16`. src/java.base/share/classes/java/lang/StringLatin1.java line 37: > 35: import jdk.internal.util.ArraysSupport; > 36: import jdk.internal.util.DecimalDigits; > 37: import jdk.internal.vm.annotation.ForceInline; This annotation does not seem to be used. src/java.base/share/classes/java/lang/StringUTF16.java line 158: > 156: * {@return an encoded byte[] for the UTF16 characters in char[]} > 157: * **Only** use this if it is known that at least one character is UTF16. > 158: * Otherwise, an untrusted char array may have racy contents and really be latin1. While this is a good advice, it turns out that the `compress()` method below invokes this method _without_ knowing for sure if the provided `value` contains at least one non-latin1 `char` when this method is invoked or while it runs: it only _assumes_ so, and indeed prudentially checks afterwards. It should be suggested to check the result after invoking this method if `value` is untrusted. src/java.base/share/classes/java/lang/StringUTF16.java line 198: > 196: * @param val a char array > 197: * @param off starting offset > 198: * @param count length of chars to be compressed, length > 0 Suggestion: * @param count count of chars to be compressed, {@code count} > 0 src/java.base/share/classes/java/lang/StringUTF16.java line 214: > 212: } > 213: } > 214: return latin1; // latin1 success The original version of this `public` method can return `null` to signal failure to compress. Does this change impact callers that might expect `null`? src/java.base/share/classes/java/lang/StringUTF16.java line 226: > 224: * @param val a byte array with UTF16 coding > 225: * @param off starting offset > 226: * @param count length of chars to be compressed, length > 0 Suggestion: * @param count count of chars to be compressed, {@code count} > 0 src/java.base/share/classes/java/lang/StringUTF16.java line 232: > 230: int ndx = compress(val, off, latin1, 0, count); > 231: if (ndx != count) {// Switch to UTF16 > 232: byte[] utf16 = Arrays.copyOfRange(val, off << 1, (off + count) << 1); Not sure if the left shifts do not overflow on this `public` method. If that happens, the outcomes could be non-negative, so the copy would succeed but be kind of corrupted. src/java.base/share/classes/java/lang/StringUTF16.java line 240: > 238: } > 239: } > 240: return latin1; // latin1 success See the `compress()` above for a remark on `null` as a return value. src/java.base/share/classes/java/lang/StringUTF16.java line 319: > 317: int codePoint = val[off]; // read each codepoint from val only once > 318: int dstLimit = dstOff > 319: + (Character.isBmpCodePoint(codePoint) ? 1 : 2) Suggestion: + Character.charCount(codePoint) This method was introduced in 1.5, so should be safe to use even for backports. src/java.base/share/classes/java/lang/StringUTF16.java line 411: > 409: return 2; > 410: } else > 411: throw new IllegalArgumentException(Integer.toString(codePoint)); Maybe `Character.charCount()` can be used here, although it returns 2 even for invalid codepoints. ------------- PR Review: https://git.openjdk.org/jdk/pull/16425#pullrequestreview-1720680695 PR Review Comment: https://git.openjdk.org/jdk/pull/16425#discussion_r1386992886 PR Review Comment: https://git.openjdk.org/jdk/pull/16425#discussion_r1386829351 PR Review Comment: https://git.openjdk.org/jdk/pull/16425#discussion_r1386885841 PR Review Comment: https://git.openjdk.org/jdk/pull/16425#discussion_r1386905655 PR Review Comment: https://git.openjdk.org/jdk/pull/16425#discussion_r1386923763 PR Review Comment: https://git.openjdk.org/jdk/pull/16425#discussion_r1386905964 PR Review Comment: https://git.openjdk.org/jdk/pull/16425#discussion_r1386915873 PR Review Comment: https://git.openjdk.org/jdk/pull/16425#discussion_r1386927514 PR Review Comment: https://git.openjdk.org/jdk/pull/16425#discussion_r1386951908 PR Review Comment: https://git.openjdk.org/jdk/pull/16425#discussion_r1386997067 From darcy at openjdk.org Wed Nov 8 18:41:15 2023 From: darcy at openjdk.org (Joe Darcy) Date: Wed, 8 Nov 2023 18:41:15 GMT Subject: RFR: JDK-8295391: Add discussion of binary <-> decimal conversion issues [v2] In-Reply-To: References: Message-ID: > Add discussion of some of the common pitfalls related to decimal <-> binary conversion. Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Address issues found by reviewers. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16566/files - new: https://git.openjdk.org/jdk/pull/16566/files/f7b25c60..0ac7125c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16566&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16566&range=00-01 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/16566.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16566/head:pull/16566 PR: https://git.openjdk.org/jdk/pull/16566 From darcy at openjdk.org Wed Nov 8 18:41:17 2023 From: darcy at openjdk.org (Joe Darcy) Date: Wed, 8 Nov 2023 18:41:17 GMT Subject: RFR: JDK-8295391: Add discussion of binary <-> decimal conversion issues [v2] In-Reply-To: References: Message-ID: <916uG81StgAX7l_nKc3FSDHR-4826MFy_aGmnMKBQUI=.688e3235-a39d-45aa-a1bd-9dbb473bd50f@github.com> On Wed, 8 Nov 2023 18:17:00 GMT, Raffaello Giulietti wrote: >> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: >> >> Address issues found by reviewers. > > src/java.base/share/classes/java/lang/Double.java line 287: > >> 285: *
  • less than the exact result >> 286: *
  • equal to the exact result >> 287: * > > More compactly: > `the same floating-point value as a result can be greater than, less than, or equal to the exact result.` For presentation reasons, in this case I think it might be helpful to use more screen real estate to emphasize the point. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16566#discussion_r1387051519 From naoto at openjdk.org Wed Nov 8 18:41:59 2023 From: naoto at openjdk.org (Naoto Sato) Date: Wed, 8 Nov 2023 18:41:59 GMT Subject: RFR: 8306116: Update CLDR to Version 44.0 Message-ID: Upgrading CLDR to v44 (https://cldr.unicode.org/index/downloads/cldr-44). Besides the data upgrade, regression tests are modified to accommodate the following CLDR fixes: CLDR-16534: Suggestion to rename the Islamic Calendar to Hijri Calendar (https://unicode-org.atlassian.net/browse/CLDR-16534) CLDR-17042: Use exception list for new languages (https://unicode-org.atlassian.net/browse/CLDR-17042) CLDR-16586: en_ID shows IDR rather than Rp for currency (https://unicode-org.atlassian.net/browse/CLDR-16586) CLDR-16358: Mexico and Latin America countries should be using 12 hours time format (https://unicode-org.atlassian.net/browse/CLDR-16358) CLDR-16974: en_GB and en_AU: request to remove comma from MMMEEEEd format (https://unicode-org.atlassian.net/browse/CLDR-16974) CLDR-16857: Need updated translations for new Sierra Leone currency - SLL became SLE (https://unicode-org.atlassian.net/browse/CLDR-16857) ------------- Commit messages: - update license files - Merge branch 'master' into JDK-8306116-CLDR44 - Merge branch 'master' into JDK-8306116-CLDR44 - Fix to generate java.time.long.Eras - release-44 - release-44-beta5 - release-44-beta4 - release-44-beta3 - release-44-beta2 - native UTF-8 for `mgo` name - ... and 9 more: https://git.openjdk.org/jdk/compare/cdf33735...f286ddd3 Changes: https://git.openjdk.org/jdk/pull/16439/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16439&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8306116 Stats: 591898 lines in 499 files changed: 72642 ins; 463467 del; 55789 mod Patch: https://git.openjdk.org/jdk/pull/16439.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16439/head:pull/16439 PR: https://git.openjdk.org/jdk/pull/16439 From darcy at openjdk.org Wed Nov 8 18:45:00 2023 From: darcy at openjdk.org (Joe Darcy) Date: Wed, 8 Nov 2023 18:45:00 GMT Subject: RFR: JDK-8295391: Add discussion of binary <-> decimal conversion issues [v2] In-Reply-To: References: Message-ID: <87cV7iRKk04cQ6fNyzBz44dNOqvSB9OIg1R_UiTHMTw=.44616887-e04b-463f-92df-71a83806b87b@github.com> On Wed, 8 Nov 2023 17:54:50 GMT, Brian Burkhalter wrote: >> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: >> >> Address issues found by reviewers. > > src/java.base/share/classes/java/lang/Double.java line 212: > >> 210: * fraction (0.33333....); but in base 3, 1/3 is exactly >> 211: * 0.1(3), that is 1 × 3-1. >> 212: * Similarly, in base 10, 1/10 is exactly presentable as 0.1, but in > > `re`presentable? Fixed; thanks. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16566#discussion_r1387055226 From darcy at openjdk.org Wed Nov 8 18:45:02 2023 From: darcy at openjdk.org (Joe Darcy) Date: Wed, 8 Nov 2023 18:45:02 GMT Subject: RFR: JDK-8295391: Add discussion of binary <-> decimal conversion issues [v2] In-Reply-To: References: Message-ID: On Wed, 8 Nov 2023 18:09:52 GMT, Raffaello Giulietti wrote: >> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: >> >> Address issues found by reviewers. > > src/java.base/share/classes/java/lang/Double.java line 257: > >> 255: *
    // Numeric values listed are exact values >> 256: *
    oneTenthApproxAsFloat = 0.100000001490116119384765625; >> 257: *
    ulpOfoneTenthApproxAsFloat = Math.ulp(1.0f) = 7.450580596923828125E-9; > > Suggestion: > > *
    ulpOfoneTenthApproxAsFloat = Math.ulp(0.1f) = 7.450580596923828125E-9; Fixed; thanks. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16566#discussion_r1387054810 From naoto at openjdk.org Wed Nov 8 18:49:11 2023 From: naoto at openjdk.org (Naoto Sato) Date: Wed, 8 Nov 2023 18:49:11 GMT Subject: RFR: 8296250" Update ICU4J to Version 74.1 Message-ID: Updating the ICU4J components to v74.1 (https://icu.unicode.org/download/74). This change completes the Unicode 15.1 upgrade. The change is merely replacing binary data files used for the Nomalization and BiDi support ------------- Commit messages: - update the license file - Merge branch 'master' into JDK-8296250-ICU4J-74.1 - v74.1 final - iniital commit Changes: https://git.openjdk.org/jdk/pull/16458/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16458&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8296250 Stats: 528 lines in 12 files changed: 80 ins; 426 del; 22 mod Patch: https://git.openjdk.org/jdk/pull/16458.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16458/head:pull/16458 PR: https://git.openjdk.org/jdk/pull/16458 From srl at openjdk.org Wed Nov 8 18:50:01 2023 From: srl at openjdk.org (Steven Loomis) Date: Wed, 8 Nov 2023 18:50:01 GMT Subject: RFR: 8306116: Update CLDR to Version 44.0 In-Reply-To: References: Message-ID: On Tue, 31 Oct 2023 21:06:13 GMT, Naoto Sato wrote: > Upgrading CLDR to v44 (https://cldr.unicode.org/index/downloads/cldr-44). Besides the data upgrade, regression tests are modified to accommodate the following CLDR fixes: > > CLDR-16534: Suggestion to rename the Islamic Calendar to Hijri Calendar (https://unicode-org.atlassian.net/browse/CLDR-16534) > CLDR-17042: Use exception list for new languages (https://unicode-org.atlassian.net/browse/CLDR-17042) > CLDR-16586: en_ID shows IDR rather than Rp for currency (https://unicode-org.atlassian.net/browse/CLDR-16586) > CLDR-16358: Mexico and Latin America countries should be using 12 hours time format (https://unicode-org.atlassian.net/browse/CLDR-16358) > CLDR-16974: en_GB and en_AU: request to remove comma from MMMEEEEd format (https://unicode-org.atlassian.net/browse/CLDR-16974) > CLDR-16857: Need updated translations for new Sierra Leone currency - SLL became SLE (https://unicode-org.atlassian.net/browse/CLDR-16857) LGTM! make/jdk/src/classes/build/tools/cldrconverter/Bundle.java line 517: > 515: } > 516: map.put(realKey, value); > 517: map.put("java.time." + realKey, value); I'm assuming this was a workaround no longer needed? src/java.base/share/legal/cldr.md line 1: > 1: ## Unicode Common Local Data Repository (CLDR) v44 Short and sweet! ------------- Marked as reviewed by srl (Committer). PR Review: https://git.openjdk.org/jdk/pull/16439#pullrequestreview-1721048254 PR Review Comment: https://git.openjdk.org/jdk/pull/16439#discussion_r1387059253 PR Review Comment: https://git.openjdk.org/jdk/pull/16439#discussion_r1387059522 From naoto at openjdk.org Wed Nov 8 19:00:00 2023 From: naoto at openjdk.org (Naoto Sato) Date: Wed, 8 Nov 2023 19:00:00 GMT Subject: RFR: 8306116: Update CLDR to Version 44.0 In-Reply-To: References: Message-ID: On Wed, 8 Nov 2023 18:45:47 GMT, Steven Loomis wrote: >> Upgrading CLDR to v44 (https://cldr.unicode.org/index/downloads/cldr-44). Besides the data upgrade, regression tests are modified to accommodate the following CLDR fixes: >> >> CLDR-16534: Suggestion to rename the Islamic Calendar to Hijri Calendar (https://unicode-org.atlassian.net/browse/CLDR-16534) >> CLDR-17042: Use exception list for new languages (https://unicode-org.atlassian.net/browse/CLDR-17042) >> CLDR-16586: en_ID shows IDR rather than Rp for currency (https://unicode-org.atlassian.net/browse/CLDR-16586) >> CLDR-16358: Mexico and Latin America countries should be using 12 hours time format (https://unicode-org.atlassian.net/browse/CLDR-16358) >> CLDR-16974: en_GB and en_AU: request to remove comma from MMMEEEEd format (https://unicode-org.atlassian.net/browse/CLDR-16974) >> CLDR-16857: Need updated translations for new Sierra Leone currency - SLL became SLE (https://unicode-org.atlassian.net/browse/CLDR-16857) > > make/jdk/src/classes/build/tools/cldrconverter/Bundle.java line 517: > >> 515: } >> 516: map.put(realKey, value); >> 517: map.put("java.time." + realKey, value); > > I'm assuming this was a workaround no longer needed? Since `short` and `abbreviated` handling differ between `java.text/util` and `java.time`, this is still needed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16439#discussion_r1387071317 From rgiulietti at openjdk.org Wed Nov 8 19:03:58 2023 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Wed, 8 Nov 2023 19:03:58 GMT Subject: RFR: JDK-8295391: Add discussion of binary <-> decimal conversion issues [v2] In-Reply-To: References: Message-ID: On Wed, 8 Nov 2023 18:41:15 GMT, Joe Darcy wrote: >> Add discussion of some of the common pitfalls related to decimal <-> binary conversion. > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > Address issues found by reviewers. What about adding a link to this discussion in the doc for `j.l.Float`? After all, the discussion contains many `float` examples. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16566#issuecomment-1802480205 From msheppar at openjdk.org Wed Nov 8 19:05:04 2023 From: msheppar at openjdk.org (Mark Sheppard) Date: Wed, 8 Nov 2023 19:05:04 GMT Subject: RFR: 8319200: Don't use test thread factory in ProcessTools.createLimitedTestJavaProcessBuilder() [v3] In-Reply-To: References: <3damdMQpRBrkUN2S32tBD0Tmrl2tmSqA31NniV8FzHU=.d3a36aa7-d5f4-4a63-b2ff-8b9b616a9637@github.com> Message-ID: On Wed, 8 Nov 2023 02:33:29 GMT, Leonid Mesnik wrote: >> Test thread factory is a mode similar to VM flags and should not be used in ProcessTools.createLimitedTestJavaProcessBuilder(). Only createTestJavaProcessBuilder() should use it like jtreg VM options. >> >> Adding the test thread factory requires the injection of arguments in the middle of the list. I don't think it makes sense to modify arguments in several places so I replaced it with the flag isLimited and moved all modifications in createJavaProcessBuilder(). >> >> Testing tier1-5. > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > converted list to array. test/lib/jdk/test/lib/process/ProcessTools.java line 387: > 385: */ > 386: > 387: private static String[] addTestThreadFactoryArgs(String testThreadFactoryName, String[] command) { would it be appropriate, at this juncture, to rename the method parameter "command" here, and throughout the associated code, to commandArgs, as the actual command i.e. java is added in createJavaProcessBuilder, and the parameter references the java command's args? or is that too much hassle. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16442#discussion_r1387076880 From rgiulietti at openjdk.org Wed Nov 8 19:08:13 2023 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Wed, 8 Nov 2023 19:08:13 GMT Subject: Integrated: 8318915: Enhance checks in BigDecimal.toPlainString() In-Reply-To: References: Message-ID: <_81EozMawECKpeQomIXhMMtiLFqZPAxBP94BRFwrlPw=.81f69c1f-0f8c-48dc-b8d0-d864da579c2b@github.com> On Wed, 1 Nov 2023 17:40:04 GMT, Raffaello Giulietti wrote: > Prevent a `NegativeArraySizeException` in `BigDecimal.toPlainString()`, throwing `OutOfMemoryError` instead to indicate that the resulting `String` would be too large. This pull request has now been integrated. Changeset: a6785e4d Author: Raffaello Giulietti URL: https://git.openjdk.org/jdk/commit/a6785e4d633908596ddb6de6d2eeab1c9ebdf2c3 Stats: 63 lines in 2 files changed: 43 ins; 6 del; 14 mod 8318915: Enhance checks in BigDecimal.toPlainString() Reviewed-by: rriggs, bpb ------------- PR: https://git.openjdk.org/jdk/pull/16457 From bpb at openjdk.org Wed Nov 8 19:10:58 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 8 Nov 2023 19:10:58 GMT Subject: RFR: JDK-8295391: Add discussion of binary <-> decimal conversion issues [v2] In-Reply-To: References: Message-ID: On Wed, 8 Nov 2023 18:41:15 GMT, Joe Darcy wrote: >> Add discussion of some of the common pitfalls related to decimal <-> binary conversion. > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > Address issues found by reviewers. Looks fine. ------------- Marked as reviewed by bpb (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16566#pullrequestreview-1721085216 From lmesnik at openjdk.org Wed Nov 8 19:13:25 2023 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Wed, 8 Nov 2023 19:13:25 GMT Subject: RFR: 8319200: Don't use test thread factory in ProcessTools.createLimitedTestJavaProcessBuilder() [v4] In-Reply-To: <3damdMQpRBrkUN2S32tBD0Tmrl2tmSqA31NniV8FzHU=.d3a36aa7-d5f4-4a63-b2ff-8b9b616a9637@github.com> References: <3damdMQpRBrkUN2S32tBD0Tmrl2tmSqA31NniV8FzHU=.d3a36aa7-d5f4-4a63-b2ff-8b9b616a9637@github.com> Message-ID: > Test thread factory is a mode similar to VM flags and should not be used in ProcessTools.createLimitedTestJavaProcessBuilder(). Only createTestJavaProcessBuilder() should use it like jtreg VM options. > > Adding the test thread factory requires the injection of arguments in the middle of the list. I don't think it makes sense to modify arguments in several places so I replaced it with the flag isLimited and moved all modifications in createJavaProcessBuilder(). > > Testing tier1-5. Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: renamed arguments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16442/files - new: https://git.openjdk.org/jdk/pull/16442/files/4ba1e85e..aa93f71a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16442&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16442&range=02-03 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/16442.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16442/head:pull/16442 PR: https://git.openjdk.org/jdk/pull/16442 From lmesnik at openjdk.org Wed Nov 8 19:13:28 2023 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Wed, 8 Nov 2023 19:13:28 GMT Subject: RFR: 8319200: Don't use test thread factory in ProcessTools.createLimitedTestJavaProcessBuilder() [v3] In-Reply-To: References: <3damdMQpRBrkUN2S32tBD0Tmrl2tmSqA31NniV8FzHU=.d3a36aa7-d5f4-4a63-b2ff-8b9b616a9637@github.com> Message-ID: On Wed, 8 Nov 2023 19:02:36 GMT, Mark Sheppard wrote: >> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: >> >> converted list to array. > > test/lib/jdk/test/lib/process/ProcessTools.java line 387: > >> 385: */ >> 386: >> 387: private static String[] addTestThreadFactoryArgs(String testThreadFactoryName, String[] command) { > > would it be appropriate, at this juncture, to rename the method parameter "command" here, and throughout the associated code, to commandArgs, as the actual command i.e. java is added in createJavaProcessBuilder, and the parameter references the java command's args? or is that too much hassle. done ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16442#discussion_r1387085932 From darcy at openjdk.org Wed Nov 8 19:24:24 2023 From: darcy at openjdk.org (Joe Darcy) Date: Wed, 8 Nov 2023 19:24:24 GMT Subject: RFR: JDK-8295391: Add discussion of binary <-> decimal conversion issues [v3] In-Reply-To: References: Message-ID: <8E92LwQXTheEuEDRJRLbKJkGdWiXpAwx4kEhE2u02rw=.19424124-569e-4d61-8c5e-607edab0ae58@github.com> > Add discussion of some of the common pitfalls related to decimal <-> binary conversion. Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Switch to parseFloat from valueOf, add links. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16566/files - new: https://git.openjdk.org/jdk/pull/16566/files/0ac7125c..b0aab59d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16566&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16566&range=01-02 Stats: 20 lines in 2 files changed: 9 ins; 0 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/16566.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16566/head:pull/16566 PR: https://git.openjdk.org/jdk/pull/16566 From duke at openjdk.org Wed Nov 8 19:27:03 2023 From: duke at openjdk.org (Eirik Bjorsnos) Date: Wed, 8 Nov 2023 19:27:03 GMT Subject: RFR: JDK-8295391: Add discussion of binary <-> decimal conversion issues [v3] In-Reply-To: <8E92LwQXTheEuEDRJRLbKJkGdWiXpAwx4kEhE2u02rw=.19424124-569e-4d61-8c5e-607edab0ae58@github.com> References: <8E92LwQXTheEuEDRJRLbKJkGdWiXpAwx4kEhE2u02rw=.19424124-569e-4d61-8c5e-607edab0ae58@github.com> Message-ID: On Wed, 8 Nov 2023 19:24:24 GMT, Joe Darcy wrote: >> Add discussion of some of the common pitfalls related to decimal <-> binary conversion. > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > Switch to parseFloat from valueOf, add links. Left some minor proofreading comments. (Not a Reviewer) src/java.base/share/classes/java/lang/Double.java line 209: > 207: * decimal conversion. While integer values can be exactly represented > 208: * in any base, which fractional values can be exactly represented is > 209: * a function of the base. For example, in base 10, 1/3 is a repeating Could the first sentence be simplified and "de-aspectized"? Suggestion: "..trace back to conversions between binary and decimal representations". The second sentence has a suspicious while/which pairing and "represented is" should probably be "represented as". Suggestion: "While integer values can be exactly represented in any base, fractional values can only be exactly represented as a function of the base." src/java.base/share/classes/java/lang/Double.java line 243: > 241: * double}. Alternatives include using an integer type and storing > 242: * cents or mills or using {@link java.math.BigDecimal BigDecimal} to > 243: * store decimal fraction values exactly. The use of and/or here makes this sentence somewhat hard to parse. Perhaps a bit of punctuation could help readability? src/java.base/share/classes/java/lang/Double.java line 246: > 244: * > 245: *

    For each finite floating-point value and a given floating-point > 246: * type, there is a contiguous region of the real number line which Neither English nor floating-point are native to me, but would it be better to use "region on the real number line" here? A quick Google search of the alternatives gives 4 results for "region of.." and 22.000 for "region on.." src/java.base/share/classes/java/lang/Double.java line 275: > 273: * } > 274: * > 275: *

    An analogous range can be constructed similarly for the {@code Suggestion: *

    Similarly, an analogous range can be constructed for the {@code src/java.base/share/classes/java/lang/Double.java line 289: > 287: * > 288: * > 289: * A floating-point value doesn't "know" if it was the result of Would it be better to use "whether" in this listing of alternatives? (As recommended by Merriam-Webster: https://www.merriam-webster.com/grammar/if-vs-whether-difference-usage) src/java.base/share/classes/java/lang/Double.java line 305: > 303: * > 304: * should not be expected to be exactly equal to 1.0, but > 305: * only close to 1.0. Consequently the following code is an infinite loop: I think "Consequently" is a conjunctive adverb here, so should be followed by a comma. Or perhaps just drop it, since the previous sentence also starts with "Consequently, " src/java.base/share/classes/java/lang/Double.java line 314: > 312: * } > 313: * > 314: * Instead, for counted loops, use an integer loop count: Suggestion: * Instead, use integer loop counters for counted loops: ------------- PR Review: https://git.openjdk.org/jdk/pull/16566#pullrequestreview-1721041731 PR Review Comment: https://git.openjdk.org/jdk/pull/16566#discussion_r1387055262 PR Review Comment: https://git.openjdk.org/jdk/pull/16566#discussion_r1387060390 PR Review Comment: https://git.openjdk.org/jdk/pull/16566#discussion_r1387063710 PR Review Comment: https://git.openjdk.org/jdk/pull/16566#discussion_r1387092563 PR Review Comment: https://git.openjdk.org/jdk/pull/16566#discussion_r1387077414 PR Review Comment: https://git.openjdk.org/jdk/pull/16566#discussion_r1387086007 PR Review Comment: https://git.openjdk.org/jdk/pull/16566#discussion_r1387097101 From vklang at openjdk.org Wed Nov 8 19:28:03 2023 From: vklang at openjdk.org (Viktor Klang) Date: Wed, 8 Nov 2023 19:28:03 GMT Subject: RFR: JDK-8319123 : Implementation of JEP-461: Stream Gatherers (Preview) In-Reply-To: <3Jkh_xeb_y4t2eXIkRMPpFSsvTq_Be9ScAD9YofNScU=.53a0c82a-600d-4293-8215-e9e93a86c56e@github.com> References: <3Jkh_xeb_y4t2eXIkRMPpFSsvTq_Be9ScAD9YofNScU=.53a0c82a-600d-4293-8215-e9e93a86c56e@github.com> Message-ID: On Wed, 8 Nov 2023 17:03:38 GMT, R?mi Forax wrote: >> src/java.base/share/classes/java/util/stream/AbstractPipeline.java line 242: >> >>> 240: } >>> 241: >>> 242: // Terminal evaluation methods >> >> This is needed in order to let subclasses override terminal operations such as, but not limited to, `collect`. (since a terminal operation needs to mark the entire pipeline as consumed). > > It's not clear in which case the exception is thrown from the POV of a user of the API. I don't understand what you mean, do you have an example? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1387101910 From vklang at openjdk.org Wed Nov 8 19:34:05 2023 From: vklang at openjdk.org (Viktor Klang) Date: Wed, 8 Nov 2023 19:34:05 GMT Subject: RFR: JDK-8319123 : Implementation of JEP-461: Stream Gatherers (Preview) In-Reply-To: References: Message-ID: <71XS35xxgdnN0Ekc5DkrNQZA0idRJfhGTExTBy7gboI=.11fedb66-ff7d-4f7d-b85e-776cf7c3f018@github.com> On Sun, 5 Nov 2023 16:43:33 GMT, Tagir F. Valeev wrote: >> This Pull-Request implements [JEP-461](https://openjdk.org/jeps/461) > > src/java.base/share/classes/java/util/stream/GathererOp.java line 162: > >> 160: * consideration at this point doesn't yield any performance gains. >> 161: */ >> 162: proceed &= integrator.integrate(state, t, this); > > Note that you are exposing the `GatherSink` object to the clients, and it implements a public `Consumer` interface. Clients may use `((Consumer)downstream).accept(something)`, which may produce unpredictable results. Not sure if this is considered to be a problem, but somebody will certainly try to do this! @amaembo Sorry, I completely missed this comment. I did some research before this and, in fact, this already happens for `mapMulti` (https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/stream/ReferencePipeline.java#L450) and blind-casting to implementation details is not advisable. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1387106067 From vklang at openjdk.org Wed Nov 8 19:34:07 2023 From: vklang at openjdk.org (Viktor Klang) Date: Wed, 8 Nov 2023 19:34:07 GMT Subject: RFR: JDK-8319123 : Implementation of JEP-461: Stream Gatherers (Preview) In-Reply-To: References: Message-ID: On Wed, 8 Nov 2023 17:56:09 GMT, R?mi Forax wrote: >> This Pull-Request implements [JEP-461](https://openjdk.org/jeps/461) > > src/java.base/share/classes/java/util/stream/GathererOp.java line 448: > >> 446: private final long targetSize; >> 447: private final Hybrid leftPredecessor; >> 448: private final AtomicBoolean cancelled; > > It could be a volatile boolean and a comment is needed saying this field is only be accessed if greedy is true. And inside the constructors this should be the last field of the constructor to be initialized No, unfortunately it can't be a volatile boolean since it is a shared instance amongst a hierarchy. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1387107205 From vklang at openjdk.org Wed Nov 8 19:37:05 2023 From: vklang at openjdk.org (Viktor Klang) Date: Wed, 8 Nov 2023 19:37:05 GMT Subject: RFR: JDK-8319123 : Implementation of JEP-461: Stream Gatherers (Preview) In-Reply-To: References: Message-ID: <2D0YdufUIR-QMxCilR6TyRqkYGH5k3XCgM9yd0gGg6I=.489c4e2f-e3b7-4e11-9128-b29707ff2923@github.com> On Wed, 8 Nov 2023 18:04:07 GMT, R?mi Forax wrote: >> This Pull-Request implements [JEP-461](https://openjdk.org/jeps/461) > > src/java.base/share/classes/java/util/stream/Gatherers.java line 64: > >> 62: * needlessly >> 63: * 3. allows for more efficient composition and evaluation >> 64: */ > > The downside is that if this object escape there will be spurious ClassCastException where the compiler insert cast for erasure that are hard to diagnose. Can you show me an example? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1387110122 From bhuang at openjdk.org Wed Nov 8 19:42:07 2023 From: bhuang at openjdk.org (Bill Huang) Date: Wed, 8 Nov 2023 19:42:07 GMT Subject: Integrated: JDK-8311961 Update Manual Test Groups for ATR JDK22 In-Reply-To: References: Message-ID: On Mon, 6 Nov 2023 22:25:46 GMT, Bill Huang wrote: > Updated jdk_core_manual test groups. This pull request has now been integrated. Changeset: 4c0f6c61 Author: Bill Huang URL: https://git.openjdk.org/jdk/commit/4c0f6c6105a8c7046cc4556d23272750bd9f7682 Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod 8311961: Update Manual Test Groups for ATR JDK22 Reviewed-by: msheppar ------------- PR: https://git.openjdk.org/jdk/pull/16531 From bpb at openjdk.org Wed Nov 8 19:42:58 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 8 Nov 2023 19:42:58 GMT Subject: RFR: JDK-8295391: Add discussion of binary <-> decimal conversion issues [v3] In-Reply-To: <8E92LwQXTheEuEDRJRLbKJkGdWiXpAwx4kEhE2u02rw=.19424124-569e-4d61-8c5e-607edab0ae58@github.com> References: <8E92LwQXTheEuEDRJRLbKJkGdWiXpAwx4kEhE2u02rw=.19424124-569e-4d61-8c5e-607edab0ae58@github.com> Message-ID: <4gTU6pLxUC6VolacT8JEE5p4qBKh4b1ohvRmSCkVhms=.a49795c6-1baa-4f68-8be4-4c3d300121ad@github.com> On Wed, 8 Nov 2023 19:24:24 GMT, Joe Darcy wrote: >> Add discussion of some of the common pitfalls related to decimal <-> binary conversion. > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > Switch to parseFloat from valueOf, add links. src/java.base/share/classes/java/lang/Double.java line 752: > 750: * represented by the {@code String} argument. > 751: * @throws NumberFormatException if the string does not contain a > 752: * parsable number. Was `parsable number` supposed to be deleted? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16566#discussion_r1387116455 From darcy at openjdk.org Wed Nov 8 19:47:01 2023 From: darcy at openjdk.org (Joe Darcy) Date: Wed, 8 Nov 2023 19:47:01 GMT Subject: RFR: JDK-8295391: Add discussion of binary <-> decimal conversion issues [v3] In-Reply-To: <4gTU6pLxUC6VolacT8JEE5p4qBKh4b1ohvRmSCkVhms=.a49795c6-1baa-4f68-8be4-4c3d300121ad@github.com> References: <8E92LwQXTheEuEDRJRLbKJkGdWiXpAwx4kEhE2u02rw=.19424124-569e-4d61-8c5e-607edab0ae58@github.com> <4gTU6pLxUC6VolacT8JEE5p4qBKh4b1ohvRmSCkVhms=.a49795c6-1baa-4f68-8be4-4c3d300121ad@github.com> Message-ID: On Wed, 8 Nov 2023 19:40:11 GMT, Brian Burkhalter wrote: >> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: >> >> Switch to parseFloat from valueOf, add links. > > src/java.base/share/classes/java/lang/Double.java line 752: > >> 750: * represented by the {@code String} argument. >> 751: * @throws NumberFormatException if the string does not contain a >> 752: * parsable number. > > Was `parsable number` supposed to be deleted? My mistake in editing; I'll correct it. Thanks. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16566#discussion_r1387122837 From darcy at openjdk.org Wed Nov 8 19:54:22 2023 From: darcy at openjdk.org (Joe Darcy) Date: Wed, 8 Nov 2023 19:54:22 GMT Subject: RFR: JDK-8295391: Add discussion of binary <-> decimal conversion issues [v4] In-Reply-To: References: Message-ID: <3st4erONDPR5Y8ws-iiPhAYfjUQK9suj3gc9KvBIaiY=.30ba71bb-75fd-40d9-8b25-1bb01bc2957f@github.com> > Add discussion of some of the common pitfalls related to decimal <-> binary conversion. Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Fix typo. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16566/files - new: https://git.openjdk.org/jdk/pull/16566/files/b0aab59d..d8d6c00b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16566&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16566&range=02-03 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/16566.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16566/head:pull/16566 PR: https://git.openjdk.org/jdk/pull/16566 From alanb at openjdk.org Wed Nov 8 19:58:09 2023 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 8 Nov 2023 19:58:09 GMT Subject: RFR: JDK-8319123 : Implementation of JEP-461: Stream Gatherers (Preview) In-Reply-To: References: Message-ID: On Mon, 30 Oct 2023 15:38:35 GMT, Viktor Klang wrote: > This Pull-Request implements [JEP-461](https://openjdk.org/jeps/461) src/java.base/share/classes/java/util/stream/Gatherer.java line 38: > 36: /** > 37: * An intermediate operation that transforms a stream of input elements into a > 38: * stream of output elements, optionally applying a final action when the end of It looks like the javadoc uses "final action" in some places and "final operation" in others. src/java.base/share/classes/java/util/stream/Gatherer.java line 194: > 192: * this gathering operation. > 193: * > 194: *

    By default, this method returns {@link #defaultInitializer()} default methods usually have `@implSpec` for the text that specifies what the default implementation does. src/java.base/share/classes/java/util/stream/Stream.java line 1107: > 1105: */ > 1106: @PreviewFeature(feature = PreviewFeature.Feature.STREAM_GATHERERS) > 1107: default Stream gather(Gatherer gatherer) { This one will need an `@since`. Also I think you'll need to add this tag to the Gatherer.Integrator and the other Gatherer.* interfaces. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1387125271 PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1387131604 PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1387104906 From tom_L64 at hotmail.com Wed Nov 8 20:01:26 2023 From: tom_L64 at hotmail.com (tom L) Date: Wed, 8 Nov 2023 20:01:26 +0000 Subject: =?Windows-1252?Q?RE=A0:_[JShell]_SourceCodeAnalysis.CompletionInfo_docume?= =?Windows-1252?Q?ntation_is_really_vague?= In-Reply-To: References: Message-ID: Hello, I sent an email half a month ago explaining that CompletionInfo#source() can be null even if nothing is explained in the doc about this. But nobody responded Now, I also noticed that with this specific code, source and remaining are nearly equal ``` import jdk.jshell.*; var shell = JShell.create() var completion = shell.sourceCodeAnalysis().analyzeCompletion("while(true)") println(completion.source()) // "while(true);" println(completion.remaining()) // "while(true)\n" ``` Not only this is weird, but if I have for example " for(int i = 0; i < 10; i++) ", my program will use the result of remaining to feed the next exec, until there is nothing left, but since here source = remaining, it will execute this for loop again and again. I would want if possible why those two cases exist, and if it is possible to enhance the doc so people in the future don?t spend hours trying to figure out why there is a null in the code or why remaining = source. Regards, Tom. De : core-libs-dev de la part de tom L Envoy? : Monday, October 23, 2023 8:26:11 PM ? : core-libs-dev at openjdk.org Objet : [JShell] SourceCodeAnalysis.CompletionInfo#source() can be null but the doc doesn't say anything about it Hello, I have a problem with JShell, I don?t know if it should go in this mailing list. On JDK 21 (should be the same for any JDK version 9+), Windows 11, with this following code : ``` var jshell = JShell.create() ; jshell.sourceCodeAnalysis().analyzeCompletion("println(").source() // null ``` this second line returns null, but the doc of SourceCodeAnalysis.CompletionInfo#source() says this: ``` Source code for the first Snippet of code input. For example, first statement, or first method declaration. Trailing semicolons will be added, as needed. Returns: the source of the first encountered Snippet ``` There is no mention that it can return null. Yes it can makes sense to return null (well actually yesn?t since from what I?ve seen from the source code, it?s only null if it is incomplete, it?s not null even if it is unknown), since I gave an invalid snippet, but the doc should at least mention it. Regards, Tom. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: B61A568C0FC9409ABE94A994F1D90140.png Type: image/png Size: 144 bytes Desc: B61A568C0FC9409ABE94A994F1D90140.png URL: From mchung at openjdk.org Wed Nov 8 20:02:09 2023 From: mchung at openjdk.org (Mandy Chung) Date: Wed, 8 Nov 2023 20:02:09 GMT Subject: Integrated: 8187655: jdk.lambda.vm.InterfaceAccessFlagsTest.testPrivateMethodCall needs update after nestmates support In-Reply-To: References: Message-ID: <9vVeKzqbzLC1_sHIcFi4G6cotgE_zA_h8kFIFtU7dRo=.0946fc33-8334-45e2-9f21-672a6bd61505@github.com> On Mon, 6 Nov 2023 19:26:26 GMT, Mandy Chung wrote: > `jdk.lambda.vm.InterfaceAccessFlagsTest` uses `ClassToInterfaceConverter` to mechanically convert a classfile for a Class into an in-memory class representation of an equivalent Interface. `testPrivateMethodCall` tests to invoke a private method. Before nestmates, invoking a private class method and a private interface method both use `Invokespecial`. With the nestmate changes, the class uses `invokevirtual` but the interface must use `invokeinterface` but this conversion is not handled by the existing `ClassToInterfaceConverter`. > > This fix converts `ClassToInterfaceConverter` to use the Class-File API to properly convert a classfile from a class to an interface including method invocation from `invokevirtual` to `invokeinterface`. The old custom bytecode manipulation code can be dropped. This pull request has now been integrated. Changeset: c137b17e Author: Mandy Chung URL: https://git.openjdk.org/jdk/commit/c137b17e82f90df07f4d8a5341b836a636a63ce1 Stats: 593 lines in 5 files changed: 6 ins; 559 del; 28 mod 8187655: jdk.lambda.vm.InterfaceAccessFlagsTest.testPrivateMethodCall needs update after nestmates support Reviewed-by: liach, asotona ------------- PR: https://git.openjdk.org/jdk/pull/16526 From lancea at openjdk.org Wed Nov 8 20:06:37 2023 From: lancea at openjdk.org (Lance Andersen) Date: Wed, 8 Nov 2023 20:06:37 GMT Subject: RFR: 8316141: Improve CEN header validation checking Message-ID: Please review this PR which enhances the existing CEN header validation checking to ensure that the size of the CEN Header + name length + comment length + extra length do not exceed 65,535 bytes per the PKWare APP.NOTE 4.4.10, 4.4.11, & 4.4.12. Also check that current CEN header will not exceed the length of the CEN array. Mach 5 tiers 1-3 are clean with this change. ------------- Commit messages: - Initial changes for JDK-8316141 Changes: https://git.openjdk.org/jdk/pull/16570/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16570&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8316141 Stats: 335 lines in 4 files changed: 322 ins; 4 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/16570.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16570/head:pull/16570 PR: https://git.openjdk.org/jdk/pull/16570 From vklang at openjdk.org Wed Nov 8 20:10:06 2023 From: vklang at openjdk.org (Viktor Klang) Date: Wed, 8 Nov 2023 20:10:06 GMT Subject: RFR: JDK-8319123 : Implementation of JEP-461: Stream Gatherers (Preview) In-Reply-To: References: Message-ID: <50zYfMSnGOS8vIYD4VOHEd8pO5gTIeic-nxoM_9ZMnI=.1602f24d-2dfd-4128-a3b3-3f68a0dcea67@github.com> On Wed, 8 Nov 2023 19:52:53 GMT, Alan Bateman wrote: >> This Pull-Request implements [JEP-461](https://openjdk.org/jeps/461) > > src/java.base/share/classes/java/util/stream/Gatherer.java line 194: > >> 192: * this gathering operation. >> 193: * >> 194: *

    By default, this method returns {@link #defaultInitializer()} > > default methods usually have `@implSpec` for the text that specifies what the default implementation does. @AlanBateman Sounds good, I'll make it an implSpec. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1387145790 From vklang at openjdk.org Wed Nov 8 20:18:06 2023 From: vklang at openjdk.org (Viktor Klang) Date: Wed, 8 Nov 2023 20:18:06 GMT Subject: RFR: JDK-8319123 : Implementation of JEP-461: Stream Gatherers (Preview) In-Reply-To: References: Message-ID: On Wed, 8 Nov 2023 19:46:42 GMT, Alan Bateman wrote: >> This Pull-Request implements [JEP-461](https://openjdk.org/jeps/461) > > src/java.base/share/classes/java/util/stream/Gatherer.java line 38: > >> 36: /** >> 37: * An intermediate operation that transforms a stream of input elements into a >> 38: * stream of output elements, optionally applying a final action when the end of > > It looks like the javadoc uses "final action" in some places and "final operation" in others. Gotcha?going with "final action". > src/java.base/share/classes/java/util/stream/Stream.java line 1107: > >> 1105: */ >> 1106: @PreviewFeature(feature = PreviewFeature.Feature.STREAM_GATHERERS) >> 1107: default Stream gather(Gatherer gatherer) { > > This one will need an `@since`. Also I think you'll need to add this tag to the Gatherer.Integrator and the other Gatherer.* interfaces. Wilco ? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1387152669 PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1387153071 From duke at openjdk.org Wed Nov 8 20:26:56 2023 From: duke at openjdk.org (Eirik Bjorsnos) Date: Wed, 8 Nov 2023 20:26:56 GMT Subject: RFR: 8316141: Improve CEN header validation checking In-Reply-To: References: Message-ID: On Wed, 8 Nov 2023 19:59:34 GMT, Lance Andersen wrote: > Please review this PR which enhances the existing CEN header validation checking to ensure that the > size of the CEN Header + name length + comment length + extra length do not exceed 65,535 bytes per the PKWare APP.NOTE 4.4.10, 4.4.11, & 4.4.12. Also check that current CEN header will not exceed the length of the CEN array. > > Mach 5 tiers 1-3 are clean with this change. Perhaps the PR/issue title could be more specific in describing what is being validated? Something like "Validate the combined length of CEN header fields"? ------------- PR Comment: https://git.openjdk.org/jdk/pull/16570#issuecomment-1802596701 From rriggs at openjdk.org Wed Nov 8 20:33:00 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 8 Nov 2023 20:33:00 GMT Subject: RFR: 8311906: Improve robustness of String constructors with mutable array inputs In-Reply-To: References: <6SKlGLh5MmxoEx07wHCCUc8KWbbhcspLJmcc1uxQ_FI=.ca33bfb4-fa5c-45f0-b49f-ee6c5c6b68b4@github.com> Message-ID: On Wed, 8 Nov 2023 16:47:17 GMT, Raffaello Giulietti wrote: >> Strings, after construction, are immutable but may be constructed from mutable arrays of bytes, characters, or integers. >> The string constructors should guard against the effects of mutating the arrays during construction that might invalidate internal invariants for the correct behavior of operations on the resulting strings. In particular, a number of operations have optimizations for operations on pairs of latin1 strings and pairs of non-latin1 strings, while operations between latin1 and non-latin1 strings use a more general implementation. >> >> The changes include: >> >> - Adding a warning to each constructor with an array as an argument to indicate that the results are indeterminate >> if the input array is modified before the constructor returns. >> The resulting string may contain any combination of characters sampled from the input array. >> >> - Ensure that strings that are represented as non-latin1 contain at least one non-latin1 character. >> For latin1 inputs, whether the arrays contain ASCII, ISO-8859-1, UTF8, or another encoding decoded to latin1 the scanning and compression is unchanged. >> If a non-latin1 character is found, the string is represented as non-latin1 with the added verification that a non-latin1 character is present at the same index. >> If that character is found to be latin1, then the input array has been modified and the result of the scan may be incorrect. >> Though a ConcurrentModificationException could be thrown, the risk to an existing application of an unexpected exception should be avoided. >> Instead, the non-latin1 copy of the input is re-scanned and compressed; that scan determines whether the latin1 or the non-latin1 representation is returned. >> >> - The methods that scan for non-latin1 characters and their intrinsic implementations are updated to return the index of the non-latin1 character. >> >> - String construction from StringBuilder and CharSequence must also be guarded as their contents may be modified during construction. > > src/java.base/share/classes/java/lang/StringUTF16.java line 214: > >> 212: } >> 213: } >> 214: return latin1; // latin1 success > > The original version of this `public` method can return `null` to signal failure to compress. Does this change impact callers that might expect `null`? It is public but in a package private class; all of the uses have been updated. > src/java.base/share/classes/java/lang/StringUTF16.java line 232: > >> 230: int ndx = compress(val, off, latin1, 0, count); >> 231: if (ndx != count) {// Switch to UTF16 >> 232: byte[] utf16 = Arrays.copyOfRange(val, off << 1, (off + count) << 1); > > Not sure if the left shifts do not overflow on this `public` method. If that happens, the outcomes could be non-negative, so the copy would succeed but be kind of corrupted. These deserve the same kind of check as used in StringUTF16.newBytesFor(len). > src/java.base/share/classes/java/lang/StringUTF16.java line 411: > >> 409: return 2; >> 410: } else >> 411: throw new IllegalArgumentException(Integer.toString(codePoint)); > > Maybe `Character.charCount()` can be used here, although it returns 2 even for invalid codepoints. The check and exception is specified in the constructor `public String(int[] codePoints, int offset, int count)` so its needed in at least one pass over the input. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16425#discussion_r1387164695 PR Review Comment: https://git.openjdk.org/jdk/pull/16425#discussion_r1387163869 PR Review Comment: https://git.openjdk.org/jdk/pull/16425#discussion_r1387167119 From lancea at openjdk.org Wed Nov 8 20:38:59 2023 From: lancea at openjdk.org (Lance Andersen) Date: Wed, 8 Nov 2023 20:38:59 GMT Subject: RFR: 8304020: Speed up test/jdk/java/util/zip/ZipFile/TestTooManyEntries.java and clarify its purpose [v3] In-Reply-To: References: <8Imbn5098NjdJMPtI2UD7BNSP3oRM4q8vB5_Lq1pLhs=.4686073b-207c-4e3b-b6c0-6227037b11b6@github.com> <8-6wXmCKNsCXaOoTxmKsGycIEOcmrjMUyZWIBU9fBgg=.11832ae5-8e2f-489d-81df-291629cfc8c6@github.com> Message-ID: <6TbjjjU0GbCdyNi4ShiBEDPgPnvKy8pL1Ugsnw4tTbc=.2283eb1e-24de-40eb-9102-b673637cf647@github.com> On Wed, 8 Nov 2023 13:54:23 GMT, Eirik Bjorsnos wrote: > > > > I think the changes look good overall. Thank you for this. I am not sure that the `@requires` is needed at this point. > > > > > > > > > Was the `@requires (sun.arch.data.model == "64")` added to satisfy the 8GB memory requirement? If so, I guess we can safely remove the requires tag, even though the test still creates a ~2GB sparse file? > > > > > > We would have to run across all of the mach5 platforms to verify. You could remove it for now and we go from here > > FWIW, this test ran successfully on `linux-x86` on Github Actions (which is 32 bit?): > > ``` > TEST: java/util/zip/ZipFile/CenSizeTooLarge.java > build: 0.059 seconds > compile: 0.059 seconds > junit: 2.437 seconds > TEST RESULT: Passed. Execution successful > ``` I have an internal mach5 run going. Once it completes, I will approve once again and you can push the PR ------------- PR Comment: https://git.openjdk.org/jdk/pull/12991#issuecomment-1802637172 From lancea at openjdk.org Wed Nov 8 20:51:59 2023 From: lancea at openjdk.org (Lance Andersen) Date: Wed, 8 Nov 2023 20:51:59 GMT Subject: RFR: 8303920: Avoid calling out to python in DataDescriptorSignatureMissing test [v9] In-Reply-To: References: <78Imgp5_LcnlmPoWrqUcE7DYnbnvTeB0r7yyF8O2THE=.2abd5fe3-02a8-4bf0-9f08-27d8664446e4@github.com> Message-ID: <4jiB2Rg--oOO-P-k517DHPRfJYU1I6yWIPDrOU2xMrk=.de0d14e6-d2e8-42c4-b662-3adace3b1d9a@github.com> On Fri, 3 Nov 2023 20:01:44 GMT, Eirik Bjorsnos wrote: > > I can kick of a test run internally next week or perhaps Sunday > > Thanks for your reviews, Lance and Iris! > > FWIW, the test ran fine on Github Actions, including on `linux-x86` (which is 32-bit, right?): > > ``` > TEST: java/util/zip/DataDescriptorSignatureMissing.java > build: 0.081 seconds > compile: 0.081 seconds > junit: 0.055 seconds > TEST RESULT: Passed. Execution successful > ``` > > https://github.com/eirbjo/jdk/actions/runs/6696663322/job/18196803138 Have an internal mach5 run going and will let you know when it completes ------------- PR Comment: https://git.openjdk.org/jdk/pull/12959#issuecomment-1802653611 From duke at openjdk.org Wed Nov 8 20:53:21 2023 From: duke at openjdk.org (suchismith1993) Date: Wed, 8 Nov 2023 20:53:21 GMT Subject: RFR: JDK-8317799 : AIX PPC64: FFI symbol lookup doesn't find symbols Message-ID: 1. Adding required compiler flags. 2. Adding required symbols. JBS-ISSUE : [JDK-8317799](https://bugs.openjdk.org/browse/JDK-8317799) ------------- Commit messages: - Update symbols-aix-foreign - Symbol Resolution fix for Panama changes. Changes: https://git.openjdk.org/jdk/pull/16414/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16414&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8317799 Stats: 441 lines in 2 files changed: 441 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/16414.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16414/head:pull/16414 PR: https://git.openjdk.org/jdk/pull/16414 From mdoerr at openjdk.org Wed Nov 8 20:53:22 2023 From: mdoerr at openjdk.org (Martin Doerr) Date: Wed, 8 Nov 2023 20:53:22 GMT Subject: RFR: JDK-8317799 : AIX PPC64: FFI symbol lookup doesn't find symbols In-Reply-To: References: Message-ID: <6h24KFkTGFIEVKzjQNxEvuB1Uq3hGaFd1dej5QRCSfY=.ae83b410-4493-4ec2-aaf8-e94335597aab@github.com> On Mon, 30 Oct 2023 10:54:48 GMT, suchismith1993 wrote: > 1. Adding required compiler flags. > 2. Adding required symbols. > > JBS-ISSUE : [JDK-8317799](https://bugs.openjdk.org/browse/JDK-8317799) Changes requested by mdoerr (Reviewer). LGTM. You may want to replace the Copyright header of the new file. It was contributed by IBM. Still good. I suggest to remove the empty lines at the beginning. make/modules/java.base/Lib.gmk line 216: > 214: LDFLAGS := $(LDFLAGS_JDKLIB), \ > 215: LDFLAGS_linux := -Wl$(COMMA)--no-as-needed, \ > 216: LDFLAGS_aix := -brtl -bloadmap:/home/hotspot/openjdk/symbol.log -bE:/home/hotspot/tmp/all-libs/1.exp , \ These files need to get added somewhere. Maybe symbols could get added to make/data/hotspot-symbols/symbols-aix? Or to new files in the same directory (with aix in the file names)? Also, please remove extra whitespaces. make/modules/java.base/Lib.gmk line 256: > 254: endif > 255: > 256: ################################################################################ I guess this was done by mistake. Please revert. src/java.base/share/native/libsyslookup/syslookup.c line 37: > 35: > 36: > 37: Please avoid changing lines which you don't need to modify! Is `#include ` really needed, here? If so, please protect it by `#ifdef _AIX` and add a comment explaining why. ------------- PR Review: https://git.openjdk.org/jdk/pull/16414#pullrequestreview-1705916269 Marked as reviewed by mdoerr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16414#pullrequestreview-1716162496 PR Review: https://git.openjdk.org/jdk/pull/16414#pullrequestreview-1720838225 PR Review Comment: https://git.openjdk.org/jdk/pull/16414#discussion_r1377348834 PR Review Comment: https://git.openjdk.org/jdk/pull/16414#discussion_r1377352267 PR Review Comment: https://git.openjdk.org/jdk/pull/16414#discussion_r1377355378 From vklang at openjdk.org Wed Nov 8 21:08:04 2023 From: vklang at openjdk.org (Viktor Klang) Date: Wed, 8 Nov 2023 21:08:04 GMT Subject: RFR: JDK-8319123 : Implementation of JEP-461: Stream Gatherers (Preview) [v2] In-Reply-To: References: Message-ID: <44loz9nnmxotWbuJzrp7MxMUuF2895ab9IHRiA4BPa0=.284c37e5-a8bc-463d-a391-bae979cd01b1@github.com> On Wed, 8 Nov 2023 21:04:47 GMT, Viktor Klang wrote: >> This Pull-Request implements [JEP-461](https://openjdk.org/jeps/461) > > Viktor Klang has updated the pull request incrementally with two additional commits since the last revision: > > - Addressing review feedback > - Make Gatherer.andThen take a wildcard for the rhs Gatherer state type src/java.base/share/classes/java/util/stream/Gatherer.java line 254: > 252: * Gatherer as input that Gatherer > 253: */ > 254: default Gatherer andThen(Gatherer that) { @amaembo @forax Removing the extra type parameter for the RHS state type turned out to be remarkably trivial, so thanks for the idea! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1387195387 From vklang at openjdk.org Wed Nov 8 21:08:03 2023 From: vklang at openjdk.org (Viktor Klang) Date: Wed, 8 Nov 2023 21:08:03 GMT Subject: RFR: JDK-8319123 : Implementation of JEP-461: Stream Gatherers (Preview) [v2] In-Reply-To: References: Message-ID: > This Pull-Request implements [JEP-461](https://openjdk.org/jeps/461) Viktor Klang has updated the pull request incrementally with two additional commits since the last revision: - Addressing review feedback - Make Gatherer.andThen take a wildcard for the rhs Gatherer state type ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16420/files - new: https://git.openjdk.org/jdk/pull/16420/files/2206e04d..6c05d682 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16420&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16420&range=00-01 Stats: 43 lines in 4 files changed: 15 ins; 6 del; 22 mod Patch: https://git.openjdk.org/jdk/pull/16420.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16420/head:pull/16420 PR: https://git.openjdk.org/jdk/pull/16420 From vklang at openjdk.org Wed Nov 8 21:08:07 2023 From: vklang at openjdk.org (Viktor Klang) Date: Wed, 8 Nov 2023 21:08:07 GMT Subject: RFR: JDK-8319123 : Implementation of JEP-461: Stream Gatherers (Preview) [v2] In-Reply-To: References: Message-ID: On Sun, 5 Nov 2023 16:38:38 GMT, Tagir F. Valeev wrote: >> Viktor Klang has updated the pull request incrementally with two additional commits since the last revision: >> >> - Addressing review feedback >> - Make Gatherer.andThen take a wildcard for the rhs Gatherer state type > > src/java.base/share/classes/java/util/stream/Gatherer.java line 272: > >> 270: * Returns a combiner which is the default combiner of a Gatherer. >> 271: * The returned combiner identifies that the owning Gatherer must only >> 272: * be evaluated sequentially. > > Should we specify that a single shared instance is guaranteed to be returned, so clients may use `combiner == defaultCombiner()`, rather than `combiner.equals(defaultCombiner())`? @amaembo Something to the effect of "This method always returns the same instance."? > src/java.base/share/classes/java/util/stream/Gatherer.java line 351: > >> 349: * @return the new {@code Gatherer} >> 350: */ >> 351: static Gatherer ofSequential( > > There are two two-function overloads: >> ofSequential(Integrator, BiConsumer>) > and >> ofSequential(Supplier, Integrator) > > While the functional parameters have clearly different signatures, and one will have no problems with lambdas, it's possible that resolve will fail if you use overloaded method references: > >> ofSequential(A::b, C::d) > > Assume that there are several A::b and C::d methods accepting different number of parameters. In this case, one cannot use method references. This is probably a minor problem, but I prefer to avoid overloads accepting the same number of functions. Probably we may use more descriptive names, like `ofSequentialStateless` for stateless overloads? I tried several variations of overloading vs specific names, and beyond 2 different names it started to become more confusing than helpful. Any Gatherer can have a Void state type. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1387197102 PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1387194366 From vklang at openjdk.org Wed Nov 8 21:08:09 2023 From: vklang at openjdk.org (Viktor Klang) Date: Wed, 8 Nov 2023 21:08:09 GMT Subject: RFR: JDK-8319123 : Implementation of JEP-461: Stream Gatherers (Preview) [v2] In-Reply-To: References: Message-ID: On Wed, 8 Nov 2023 17:19:56 GMT, Tagir F. Valeev wrote: >> In that case the integrator should be a BiConsumer too, no ? > > @forax I thought so initially, but this is not so easy, as there's a `Greedy` subinterface. If you adapt the `Integrator`, you will lose the ability to specify the greediness. I think this one is something which real-world usage needs to weigh in on. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1387197786 From ihse at openjdk.org Wed Nov 8 21:10:58 2023 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 8 Nov 2023 21:10:58 GMT Subject: RFR: JDK-8317799 : AIX PPC64: FFI symbol lookup doesn't find symbols In-Reply-To: References: Message-ID: <4wOdKZkaf3aLDPb4t-0KK8SJvjHhsSUy_zpoVKROIfA=.1c028491-22b6-4d15-9c9f-911067661c6e@github.com> On Mon, 30 Oct 2023 10:54:48 GMT, suchismith1993 wrote: > 1. Adding required compiler flags. > 2. Adding required symbols. > > JBS-ISSUE : [JDK-8317799](https://bugs.openjdk.org/browse/JDK-8317799) No, no... This is bad on several accounts. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16414#issuecomment-1802682557 From rriggs at openjdk.org Wed Nov 8 21:11:10 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 8 Nov 2023 21:11:10 GMT Subject: RFR: 8319574: Exec/process tests should be marked as flagless Message-ID: Tests that directly use ProcessBuilder to spawn processes and do not pass the standard test command line arguments should be marked as `vm.flagless` to indicate to the testing infrastructure that they do not accept them and should not be run with extra test command line options `test.vm.opts` and `test.java.opts`. Add @requires vm.flagless to tests ------------- Commit messages: - 8319574: Exec/process tests should be marked as flagless Changes: https://git.openjdk.org/jdk/pull/16572/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16572&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8319574 Stats: 22 lines in 14 files changed: 13 ins; 0 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/16572.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16572/head:pull/16572 PR: https://git.openjdk.org/jdk/pull/16572 From ihse at openjdk.org Wed Nov 8 21:13:58 2023 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 8 Nov 2023 21:13:58 GMT Subject: RFR: JDK-8317799 : AIX PPC64: FFI symbol lookup doesn't find symbols In-Reply-To: References: Message-ID: <0YcwDWnMl1fH5HGhHDEl_eE_5sfyBnzesOc5WmJ-eII=.105c0c2a-09c4-4538-9d85-b7d987352d3f@github.com> On Mon, 30 Oct 2023 10:54:48 GMT, suchismith1993 wrote: > 1. Adding required compiler flags. > 2. Adding required symbols. > > JBS-ISSUE : [JDK-8317799](https://bugs.openjdk.org/browse/JDK-8317799) First and foremost, the `make/data/hotspot-symbols` directory is, as the name says, for hotspot symbols. These are not hotspot symbols. If you really do need the file, then it needs to reside in a proper location. Secondly: do you really need this file? It looks just like an enumeration of (a subset of?) standard library functions. This looks like a completely incorrect solution to the problem. How did you arrive at this list? What if in the future new functions are added to the standard library? ------------- PR Comment: https://git.openjdk.org/jdk/pull/16414#issuecomment-1802687626 From vklang at openjdk.org Wed Nov 8 21:15:08 2023 From: vklang at openjdk.org (Viktor Klang) Date: Wed, 8 Nov 2023 21:15:08 GMT Subject: RFR: JDK-8319123 : Implementation of JEP-461: Stream Gatherers (Preview) [v2] In-Reply-To: References: Message-ID: On Wed, 8 Nov 2023 21:08:03 GMT, Viktor Klang wrote: >> This Pull-Request implements [JEP-461](https://openjdk.org/jeps/461) > > Viktor Klang has updated the pull request incrementally with two additional commits since the last revision: > > - Addressing review feedback > - Make Gatherer.andThen take a wildcard for the rhs Gatherer state type src/java.base/share/classes/java/util/stream/Stream.java line 1106: > 1104: return StreamSupport.stream(spliterator(), isParallel()) > 1105: .gather(gatherer) > 1106: .onClose(this::close); @AlanBateman Also added onClose hook. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1387205090 From ihse at openjdk.org Wed Nov 8 21:16:58 2023 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 8 Nov 2023 21:16:58 GMT Subject: RFR: JDK-8317799 : AIX PPC64: FFI symbol lookup doesn't find symbols In-Reply-To: References: Message-ID: On Mon, 30 Oct 2023 10:54:48 GMT, suchismith1993 wrote: > 1. Adding required compiler flags. > 2. Adding required symbols. > > JBS-ISSUE : [JDK-8317799](https://bugs.openjdk.org/browse/JDK-8317799) Also, please don't ever force push once you have published a PR. Now it makes Martin's comment just dangling in the air. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16414#issuecomment-1802691371 From duke at openjdk.org Wed Nov 8 21:27:58 2023 From: duke at openjdk.org (Eirik Bjorsnos) Date: Wed, 8 Nov 2023 21:27:58 GMT Subject: RFR: 8316141: Improve CEN header validation checking In-Reply-To: References: Message-ID: On Wed, 8 Nov 2023 19:59:34 GMT, Lance Andersen wrote: > Please review this PR which enhances the existing CEN header validation checking to ensure that the > size of the CEN Header + name length + comment length + extra length do not exceed 65,535 bytes per the PKWare APP.NOTE 4.4.10, 4.4.11, & 4.4.12. Also check that current CEN header will not exceed the length of the CEN array. > > Mach 5 tiers 1-3 are clean with this change. LGTM, although I'm not sure I follow the underlying motivation of this stricter validation. What problem is being solved here? APPNOTE.TXT uses the phrase `SHOULD NOT`. Even if the spec is not an RFC, RFC2119 defines `SHOULD NOT` as: ```This phrase, or the phrase "NOT RECOMMENDED" mean that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label. I would expect our producer `ZipOutputStream` to be stricter than our consumers in this case, honoring Postel's law. From a implementation robustness perspective, the individual lengths are already validated, it's just the combined clause that is now enforced in this PR. That said, here are some comments inline: src/java.base/share/classes/java/util/zip/ZipFile.java line 1225: > 1223: int elen = CENEXT(cen, pos); > 1224: int clen = CENCOM(cen, pos); > 1225: long headerSize = (long)CENHDR + nlen + clen + elen; Since CENHDR is 46 and nlen, clen, elen are all unsigned shorts, this sum cannot possibly overflow an int. Is the long conversion necessary? The specification uses the term "combined length", would it be better to name the local variable `combinedLength` instead? src/java.base/share/classes/java/util/zip/ZipFile.java line 1235: > 1233: > 1234: if (elen > 0 && !DISABLE_ZIP64_EXTRA_VALIDATION) { > 1235: checkExtraFields(pos, entryPos + nlen, elen); The naming of `entryPos` confused me here. The name indicates it is the position where the CEN header starts, but we already have `pos` for that. (It actually contains the position where the encoded name starts) So perhaps it should be renamed to `namePos` or `npos` to make future maintenance less confusing? Also, I actually liked the `extraStartingOffset` local variable, having a name makes the code easier to follow than just `entryPos + nlen`. But perhaps `extraPos` is shorter and more consistent with other uses of `pos`? So perhaps: `long extraPos = pos + CENHDR + nlen` ? src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 1596: > 1594: throw new ZipException("invalid CEN header (unsupported compression method: " + method + ")"); > 1595: } > 1596: long headerSize = (long)CENHDR + nlen + clen + elen; If the corresponding ZipFile local variable is renamed, this should also be updated. src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 1668: > 1666: int tagBlockSize = SH(cen, currentOffset); > 1667: currentOffset += Short.BYTES; > 1668: long tagBlockEndingOffset = (long)currentOffset + tagBlockSize; I think my ZipFile comment also applies here. ------------- PR Review: https://git.openjdk.org/jdk/pull/16570#pullrequestreview-1721212606 PR Review Comment: https://git.openjdk.org/jdk/pull/16570#discussion_r1387163396 PR Review Comment: https://git.openjdk.org/jdk/pull/16570#discussion_r1387177874 PR Review Comment: https://git.openjdk.org/jdk/pull/16570#discussion_r1387194439 PR Review Comment: https://git.openjdk.org/jdk/pull/16570#discussion_r1387195085 From bpb at openjdk.org Wed Nov 8 21:33:55 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 8 Nov 2023 21:33:55 GMT Subject: RFR: 8319574: Exec/process tests should be marked as flagless In-Reply-To: References: Message-ID: <_CpFFYiyPnhLVyUetjs9NaYKc0_CZZZiBv-uFyZqZ0g=.f1a56bfc-cc0e-4958-a4fe-642b687e1127@github.com> On Wed, 8 Nov 2023 21:04:49 GMT, Roger Riggs wrote: > Tests that directly use ProcessBuilder to spawn processes and do not pass the standard test command line arguments should be marked as `vm.flagless` to indicate to the testing infrastructure that they do not accept them and should not be run with extra test command line options `test.vm.opts` and `test.java.opts`. > > Add @requires vm.flagless to tests Looks reasonable. ------------- Marked as reviewed by bpb (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16572#pullrequestreview-1721311131 From emcmanus at openjdk.org Wed Nov 8 22:17:04 2023 From: emcmanus at openjdk.org (Eamonn McManus) Date: Wed, 8 Nov 2023 22:17:04 GMT Subject: RFR: 8319753: Duration javadoc has "period" instead of "duration" in several places Message-ID: This change simply replaces "period" with "duration", or in one case replaces "period unit" with just "unit". ------------- Commit messages: - 8319753: Duration javadoc has "period" instead of "duration" in several places Changes: https://git.openjdk.org/jdk/pull/16573/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16573&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8319753 Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/16573.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16573/head:pull/16573 PR: https://git.openjdk.org/jdk/pull/16573 From naoto at openjdk.org Wed Nov 8 22:24:58 2023 From: naoto at openjdk.org (Naoto Sato) Date: Wed, 8 Nov 2023 22:24:58 GMT Subject: RFR: 8319574: Exec/process tests should be marked as flagless In-Reply-To: References: Message-ID: On Wed, 8 Nov 2023 21:04:49 GMT, Roger Riggs wrote: > Tests that directly use ProcessBuilder to spawn processes and do not pass the standard test command line arguments should be marked as `vm.flagless` to indicate to the testing infrastructure that they do not accept them and should not be run with extra test command line options `test.vm.opts` and `test.java.opts`. > > Add @requires vm.flagless to tests +1 ------------- Marked as reviewed by naoto (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16572#pullrequestreview-1721377335 From liach at openjdk.org Thu Nov 9 00:09:18 2023 From: liach at openjdk.org (Chen Liang) Date: Thu, 9 Nov 2023 00:09:18 GMT Subject: RFR: 8319761: Simplify fields of Array VarHandles Message-ID: 1. Primitive array VHs are now singletons and no longer need to record their array base and offset in their object themselves. 2. Moved Unsafe offset calculation to a utility method, like `index` in VarHandleByteArrayView. ------------- Commit messages: - Use the base offset and index scale constants from Unsafe directly - Simplify non-Object array VH Changes: https://git.openjdk.org/jdk/pull/15894/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15894&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8319761 Stats: 147 lines in 3 files changed: 45 ins; 37 del; 65 mod Patch: https://git.openjdk.org/jdk/pull/15894.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15894/head:pull/15894 PR: https://git.openjdk.org/jdk/pull/15894 From duke at openjdk.org Thu Nov 9 00:09:18 2023 From: duke at openjdk.org (ExE Boss) Date: Thu, 9 Nov 2023 00:09:18 GMT Subject: RFR: 8319761: Simplify fields of Array VarHandles In-Reply-To: References: Message-ID: On Sun, 24 Sep 2023 13:17:05 GMT, Chen Liang wrote: > 1. Primitive array VHs are now singletons and no longer need to record their array base and offset in their object themselves. > 2. Moved Unsafe offset calculation to a utility method, like `index` in VarHandleByteArrayView. Note?that the?first?change might?need a?**CSR** in?case there?s?user?code out?there which?currently?assumes it?gets?ownership over?the?identity of?the?result of?calling `MethodHandles::arrayElementVarHandle(Class)` with?a?primitive array?type. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15894#issuecomment-1735062158 From ihse at openjdk.org Thu Nov 9 00:09:19 2023 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Thu, 9 Nov 2023 00:09:19 GMT Subject: RFR: 8319761: Simplify fields of Array VarHandles In-Reply-To: References: Message-ID: On Sun, 24 Sep 2023 13:17:05 GMT, Chen Liang wrote: > 1. Primitive array VHs are now singletons and no longer need to record their array base and offset in their object themselves. > 2. Moved Unsafe offset calculation to a utility method, like `index` in VarHandleByteArrayView. @liach You need to create an issue in JBS, and update the PR title to include the bug number. Otherwise, this PR will not be flagged as ready for review, and will not really appear on anyone's radar. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15894#issuecomment-1802301793 From liach at openjdk.org Thu Nov 9 00:23:15 2023 From: liach at openjdk.org (Chen Liang) Date: Thu, 9 Nov 2023 00:23:15 GMT Subject: RFR: 8308753: Class-File API transition to Preview [v24] In-Reply-To: <83E89Gq0Rn3H-WTsUJPx6L37WggoVHo7piExlpMSmMg=.82768fa9-9262-4fad-b87b-7c94a71d2d84@github.com> References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com> <83E89Gq0Rn3H-WTsUJPx6L37WggoVHo7piExlpMSmMg=.82768fa9-9262-4fad-b87b-7c94a71d2d84@github.com> Message-ID: On Wed, 8 Nov 2023 15:45:56 GMT, Konrad Windszus wrote: > I know, but for memory consumption reasons everyone should prefer just passing an InputStream. Is the memory consumption with `ClassFile.of().parse(Path)` any better (i.e. are you using a `java.io.RandomAccessFile` or `java.nio.channels.SeekableByteChannel` under the hood)? I think that deserves a sentence in the javadoc. FYI `parse(Path)` is just a shortcut to read all bytes from a file, like `parse(Files.readAllBytes(path))`. Classfile implementation fetches the byte array very often (constant pool reading, lazy expansion) so keeping the bytes in a in-memory array is better. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15706#issuecomment-1802967277 From vlivanov at openjdk.org Thu Nov 9 00:35:06 2023 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Thu, 9 Nov 2023 00:35:06 GMT Subject: RFR: 8254693: Add Panama feature to pass heap segments to native code [v12] In-Reply-To: References: Message-ID: On Tue, 24 Oct 2023 15:09:57 GMT, Jorn Vernee wrote: >> Add the ability to pass heap segments to native code. This requires using `Linker.Option.critical(true)` as a linker option. It has the same limitations as normal critical calls, namely: upcalls into Java are not allowed, and the native function should return relatively quickly. Heap segments are exposed to native code through temporary native addresses that are valid for the duration of the native call. >> >> The motivation for this is supporting existing Java array-based APIs that might have to pass multi-megabyte size arrays to native code, and are current relying on Get-/ReleasePrimitiveArrayCritical from JNI. Where making a copy of the array would be overly prohibitive. >> >> Components of this patch: >> >> - New binding operator `SegmentBase`, which gets the base object of a `MemorySegment`. >> - Rename `UnboxAddress` to `SegmentOffset`. Add flag to specify whether processing heap segments should be allowed. >> - `CallArranger` impls use new binding operators when `Linker.Option.critical(/* allowHeap= */ true)` is specified. >> - `NativeMethodHandle`/`NativeEntryPoint` allow `Object` in their signatures. >> - The object/oop + offset is exposed as temporary address to native code. >> - Since we stay in the `_thread_in_Java` state, we can safely expose the oops passed to the downcall stub to native code, without needing GCLocker. These oops are valid until we poll for safepoint, which we never do (invoking pure native code). >> - Only x64 and AArch64 for now. >> - I've refactored `ArgumentShuffle` in the C++ code to no longer rely on callbacks to get the set of source and destination registers (using `CallingConventionClosure`), but instead just rely on 2 equal size arrays with source and destination registers. This allows filtering the input java registers before passing them to `ArgumentShuffle`, which is required to filter out registers holding segment offsets. Replacing placeholder registers is also done as a separate pre-processing step now. See changes in: https://github.com/openjdk/jdk/pull/16201/commits/d2b40f1117d63cc6d74e377bf88cdcf6d15ff866 >> - I've factored out `DowncallStubGenerator` in the x64 and AArch64 code to use a common `DowncallLinker::StubGenerator`. >> - Fallback linker is also supported using JNI's `GetPrimitiveArrayCritical`/`ReleasePrimitiveArrayCritical` >> >> Aside: fixed existing issue with `DowncallLinker` not properly acquiring segments in interpreted mode. >> >> Numbers for the included benchmark on my machine are: >> >> >> Benchmar... > > Jorn Vernee has updated the pull request incrementally with two additional commits since the last revision: > > - a -> an > - add note to downcallHandle about passing heap segments by-reference hotspot changes look fine. src/hotspot/cpu/aarch64/downcallLinker_aarch64.cpp line 182: > 180: ArgumentShuffle arg_shuffle(filtered_java_regs, out_regs, shuffle_reg); > 181: > 182: #ifndef PRODUCT Any particular reason to exclude the logging in product builds? `ArgumentShuffle::print_on()` is unconditionally available there. src/java.base/share/classes/java/lang/foreign/Linker.java line 792: > 790: * @param allowHeapAccess whether the linked function should allow access to the Java heap. > 791: */ > 792: static Option critical(boolean allowHeapAccess) { Speaking of public API, I'm surprised to see critical function property conflated with ability to perform on-heap accesses. These aspects look orthogonal to me. Any particular reason not to represent them as 2 separate `Option`s? Even though it's straightforward to support on-heap accesses during critical function calls, object pinning would support that for non-critical function calls as well, but proposed API doesn't cover it and new API will be required. What's the plan here? ------------- PR Review: https://git.openjdk.org/jdk/pull/16201#pullrequestreview-1693030613 PR Review Comment: https://git.openjdk.org/jdk/pull/16201#discussion_r1387130520 PR Review Comment: https://git.openjdk.org/jdk/pull/16201#discussion_r1387341549 From joehw at openjdk.org Thu Nov 9 00:46:55 2023 From: joehw at openjdk.org (Joe Wang) Date: Thu, 9 Nov 2023 00:46:55 GMT Subject: RFR: 8296250" Update ICU4J to Version 74.1 In-Reply-To: References: Message-ID: On Wed, 1 Nov 2023 17:40:09 GMT, Naoto Sato wrote: > Updating the ICU4J components to v74.1 (https://icu.unicode.org/download/74). This change completes the Unicode 15.1 upgrade. The change is merely replacing binary data files used for the Normalization and BiDi support Marked as reviewed by joehw (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/16458#pullrequestreview-1721505890 From vlivanov at openjdk.org Thu Nov 9 00:35:09 2023 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Thu, 9 Nov 2023 00:35:09 GMT Subject: RFR: 8254693: Add Panama feature to pass heap segments to native code [v11] In-Reply-To: <2mpVRiA1idUeB0AN8eAtghk_sGFu90tZyTvpYOPaBq4=.72ab5bb9-3095-4352-9aa6-9e59151e482e@github.com> References: <2mpVRiA1idUeB0AN8eAtghk_sGFu90tZyTvpYOPaBq4=.72ab5bb9-3095-4352-9aa6-9e59151e482e@github.com> Message-ID: On Sat, 21 Oct 2023 12:04:10 GMT, Jorn Vernee wrote: >> Add the ability to pass heap segments to native code. This requires using `Linker.Option.critical(true)` as a linker option. It has the same limitations as normal critical calls, namely: upcalls into Java are not allowed, and the native function should return relatively quickly. Heap segments are exposed to native code through temporary native addresses that are valid for the duration of the native call. >> >> The motivation for this is supporting existing Java array-based APIs that might have to pass multi-megabyte size arrays to native code, and are current relying on Get-/ReleasePrimitiveArrayCritical from JNI. Where making a copy of the array would be overly prohibitive. >> >> Components of this patch: >> >> - New binding operator `SegmentBase`, which gets the base object of a `MemorySegment`. >> - Rename `UnboxAddress` to `SegmentOffset`. Add flag to specify whether processing heap segments should be allowed. >> - `CallArranger` impls use new binding operators when `Linker.Option.critical(/* allowHeap= */ true)` is specified. >> - `NativeMethodHandle`/`NativeEntryPoint` allow `Object` in their signatures. >> - The object/oop + offset is exposed as temporary address to native code. >> - Since we stay in the `_thread_in_Java` state, we can safely expose the oops passed to the downcall stub to native code, without needing GCLocker. These oops are valid until we poll for safepoint, which we never do (invoking pure native code). >> - Only x64 and AArch64 for now. >> - I've refactored `ArgumentShuffle` in the C++ code to no longer rely on callbacks to get the set of source and destination registers (using `CallingConventionClosure`), but instead just rely on 2 equal size arrays with source and destination registers. This allows filtering the input java registers before passing them to `ArgumentShuffle`, which is required to filter out registers holding segment offsets. Replacing placeholder registers is also done as a separate pre-processing step now. See changes in: https://github.com/openjdk/jdk/pull/16201/commits/d2b40f1117d63cc6d74e377bf88cdcf6d15ff866 >> - I've factored out `DowncallStubGenerator` in the x64 and AArch64 code to use a common `DowncallLinker::StubGenerator`. >> - Fallback linker is also supported using JNI's `GetPrimitiveArrayCritical`/`ReleasePrimitiveArrayCritical` >> >> Aside: fixed existing issue with `DowncallLinker` not properly acquiring segments in interpreted mode. >> >> Numbers for the included benchmark on my machine are: >> >> >> Benchmar... > > Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 46 commits: > > - Merge branch 'master' into AllowHeapNoLock > - bump up argument counts in TestLargeStub to their maximum > - s390 updates > - add stub size stress test for allowHeap > - RISC-V impl > - remove leftover debug log line > - add s390 support > - add PPC impl > - add missing file > - Add xor benchmark > - ... and 36 more: https://git.openjdk.org/jdk/compare/a876beb6...2e00beff src/java.base/share/classes/java/lang/foreign/Linker.java line 783: > 781: * memory segments as addresses, where normally only off-heap memory segments would be allowed. The memory region > 782: * inside the Java heap is exposed through a temporary native address that is valid for the duration of the > 783: * function call. Use of this mechanism is therefore only recommend when a function needs to do s/recommend/recommended/ ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16201#discussion_r1368969423 From joehw at openjdk.org Thu Nov 9 02:07:57 2023 From: joehw at openjdk.org (Joe Wang) Date: Thu, 9 Nov 2023 02:07:57 GMT Subject: RFR: 8306116: Update CLDR to Version 44.0 In-Reply-To: References: Message-ID: On Tue, 31 Oct 2023 21:06:13 GMT, Naoto Sato wrote: > Upgrading CLDR to v44 (https://cldr.unicode.org/index/downloads/cldr-44). Besides the data upgrade, regression tests are modified to accommodate the following CLDR fixes: > > CLDR-16534: Suggestion to rename the Islamic Calendar to Hijri Calendar (https://unicode-org.atlassian.net/browse/CLDR-16534) > CLDR-17042: Use exception list for new languages (https://unicode-org.atlassian.net/browse/CLDR-17042) > CLDR-16586: en_ID shows IDR rather than Rp for currency (https://unicode-org.atlassian.net/browse/CLDR-16586) > CLDR-16358: Mexico and Latin America countries should be using 12 hours time format (https://unicode-org.atlassian.net/browse/CLDR-16358) > CLDR-16974: en_GB and en_AU: request to remove comma from MMMEEEEd format (https://unicode-org.atlassian.net/browse/CLDR-16974) > CLDR-16857: Need updated translations for new Sierra Leone currency - SLL became SLE (https://unicode-org.atlassian.net/browse/CLDR-16857) Marked as reviewed by joehw (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/16439#pullrequestreview-1721571315 From rriggs at openjdk.org Thu Nov 9 04:16:25 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 9 Nov 2023 04:16:25 GMT Subject: RFR: 8311906: Improve robustness of String constructors with mutable array inputs [v2] In-Reply-To: <6SKlGLh5MmxoEx07wHCCUc8KWbbhcspLJmcc1uxQ_FI=.ca33bfb4-fa5c-45f0-b49f-ee6c5c6b68b4@github.com> References: <6SKlGLh5MmxoEx07wHCCUc8KWbbhcspLJmcc1uxQ_FI=.ca33bfb4-fa5c-45f0-b49f-ee6c5c6b68b4@github.com> Message-ID: > Strings, after construction, are immutable but may be constructed from mutable arrays of bytes, characters, or integers. > The string constructors should guard against the effects of mutating the arrays during construction that might invalidate internal invariants for the correct behavior of operations on the resulting strings. In particular, a number of operations have optimizations for operations on pairs of latin1 strings and pairs of non-latin1 strings, while operations between latin1 and non-latin1 strings use a more general implementation. > > The changes include: > > - Adding a warning to each constructor with an array as an argument to indicate that the results are indeterminate > if the input array is modified before the constructor returns. > The resulting string may contain any combination of characters sampled from the input array. > > - Ensure that strings that are represented as non-latin1 contain at least one non-latin1 character. > For latin1 inputs, whether the arrays contain ASCII, ISO-8859-1, UTF8, or another encoding decoded to latin1 the scanning and compression is unchanged. > If a non-latin1 character is found, the string is represented as non-latin1 with the added verification that a non-latin1 character is present at the same index. > If that character is found to be latin1, then the input array has been modified and the result of the scan may be incorrect. > Though a ConcurrentModificationException could be thrown, the risk to an existing application of an unexpected exception should be avoided. > Instead, the non-latin1 copy of the input is re-scanned and compressed; that scan determines whether the latin1 or the non-latin1 representation is returned. > > - The methods that scan for non-latin1 characters and their intrinsic implementations are updated to return the index of the non-latin1 character. > > - String construction from StringBuilder and CharSequence must also be guarded as their contents may be modified during construction. Roger Riggs has updated the pull request incrementally with three additional commits since the last revision: - Refactored extractCodePoints to avoid multiple resizes if the array was modified - Replaced isLatin1 implementation with `getChar(buf, ndx) <= 0xff` It performs better than the single byte array access by avoiding the bounds check. - Misc updates for review comments, javadoc cleanup Extra checking on maximum string lengths when calling toBytes(). ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16425/files - new: https://git.openjdk.org/jdk/pull/16425/files/4662dec7..ad73a2a6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16425&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16425&range=00-01 Stats: 54 lines in 3 files changed: 20 ins; 20 del; 14 mod Patch: https://git.openjdk.org/jdk/pull/16425.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16425/head:pull/16425 PR: https://git.openjdk.org/jdk/pull/16425 From dholmes at openjdk.org Thu Nov 9 04:59:57 2023 From: dholmes at openjdk.org (David Holmes) Date: Thu, 9 Nov 2023 04:59:57 GMT Subject: RFR: 8319200: Don't use test thread factory in ProcessTools.createLimitedTestJavaProcessBuilder() [v4] In-Reply-To: References: <3damdMQpRBrkUN2S32tBD0Tmrl2tmSqA31NniV8FzHU=.d3a36aa7-d5f4-4a63-b2ff-8b9b616a9637@github.com> Message-ID: On Wed, 8 Nov 2023 19:13:25 GMT, Leonid Mesnik wrote: >> Test thread factory is a mode similar to VM flags and should not be used in ProcessTools.createLimitedTestJavaProcessBuilder(). Only createTestJavaProcessBuilder() should use it like jtreg VM options. >> >> Adding the test thread factory requires the injection of arguments in the middle of the list. I don't think it makes sense to modify arguments in several places so I replaced it with the flag isLimited and moved all modifications in createJavaProcessBuilder(). >> >> Testing tier1-5. > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > renamed arguments test/lib/jdk/test/lib/process/ProcessTools.java line 401: > 399: boolean expectSecondArg = false; > 400: boolean isTestThreadFactoryAdded = false; > 401: for (String cmd : commandArgs) { So `cmd` should really be `arg` right? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16442#discussion_r1387478034 From dholmes at openjdk.org Thu Nov 9 05:03:57 2023 From: dholmes at openjdk.org (David Holmes) Date: Thu, 9 Nov 2023 05:03:57 GMT Subject: RFR: 8319200: Don't use test thread factory in ProcessTools.createLimitedTestJavaProcessBuilder() [v4] In-Reply-To: References: <3damdMQpRBrkUN2S32tBD0Tmrl2tmSqA31NniV8FzHU=.d3a36aa7-d5f4-4a63-b2ff-8b9b616a9637@github.com> Message-ID: On Wed, 8 Nov 2023 19:13:25 GMT, Leonid Mesnik wrote: >> Test thread factory is a mode similar to VM flags and should not be used in ProcessTools.createLimitedTestJavaProcessBuilder(). Only createTestJavaProcessBuilder() should use it like jtreg VM options. >> >> Adding the test thread factory requires the injection of arguments in the middle of the list. I don't think it makes sense to modify arguments in several places so I replaced it with the flag isLimited and moved all modifications in createJavaProcessBuilder(). >> >> Testing tier1-5. > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > renamed arguments I remain concerned that this means that a whole swag of tests will never be run with virtual threads, which reduces our virtual thread test coverage. Hard to quantify. Do you have any stats on how many tests this will affect and which ones? ------------- PR Comment: https://git.openjdk.org/jdk/pull/16442#issuecomment-1803166547 From davidalayachew at gmail.com Thu Nov 9 05:12:08 2023 From: davidalayachew at gmail.com (David Alayachew) Date: Thu, 9 Nov 2023 00:12:08 -0500 Subject: New method on java.util.function.Function -- ternary method In-Reply-To: References: Message-ID: It has been a month since I sent this proposal. Since no one has told me that this is a terrible idea, I will submit this as an enhancement to JBS, and once the ticket is made, start work on creating a pull request. On Tue, Oct 3, 2023 at 3:13?AM David Alayachew wrote: > Whoops, bad import. > > Please replace the following line with the one after it. > > > import java.util.function.Function; > > > import java.util.function.*; > > On Tue, Oct 3, 2023 at 3:09?AM David Alayachew > wrote: > >> Hello all, >> >> I have an idea that I want to run by you all -- a new method on >> java.util.function.Function to capture ternary operations. >> >> Here is a mockup of what I wanted to do. >> >> > >> > import java.util.function.Function; >> > >> > @FunctionalInterface >> > public interface Function2 extends Function >> > { >> > >> > public static Function ternary >> > ( >> > Predicate test, >> > Function trueOutput, >> > Function falseOutput >> > ) >> > { >> > >> > return >> > (I input) -> >> > test.test(input) >> > ? trueOutput.apply(input) >> > : falseOutput.apply(input) >> > ; >> > >> > } >> > >> > } >> > >> >> I think this is useful for a few reasons. >> >> * This composes, just like the ternary operator itself. >> >> * It pairs well with Function.identity() and method references to >> clearly (but concisely) communicate intent. >> >> * Ternary operations are common, so this will find great use by >> developers of all sorts. >> >> There is at least one part I don't quite like about this design - what if >> one (or both!) of your outputs is not a functional transformation of the >> input? >> >> For example, String username = id.isBlank() ? "UNKNOWN" : lookup(id); >> >> Obviously, this is easy to work around - simply ignore the input of the >> function. But you lose clarity and simplicity that way. I would put a note >> in the javadoc that says that this method should only be used in instances >> where both outputs are a functional transformation of the input. That way, >> intent is clarified. But if we go that route, maybe this function should >> get a better name to capture that? testThenApply? ternaryTransform? >> ternaryApply? >> >> Thank you for your time and help! >> David Alayachew >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From davidalayachew at gmail.com Thu Nov 9 06:19:44 2023 From: davidalayachew at gmail.com (David Alayachew) Date: Thu, 9 Nov 2023 01:19:44 -0500 Subject: New method on java.util.function.Function -- ternary method In-Reply-To: References: Message-ID: Oh, I will also add a specialized version of this method to java.util.function.UnaryOperator. That is because UnaryOperator is a subinterface of Function. Function goes T -> R, but UnaryOperator just goes T -> T. We do not want UnaryOperator to have the T -> R static function included due to inheritance, so it will get its own version that has the same method name and parameters, but the type parameters will be different. Here is another mockup - this time for UnaryOperator2's version of the same method. > interface UnaryOperator2 extends Function2, UnaryOperator > { > > public static UnaryOperator2 ternaryApply > ( > Predicate test, > Function trueFunction, > Function falseFunction > ) > { > > return > (T input) -> > test.test(input) > ? trueFunction.apply(input) > : falseFunction.apply(input) > ; > > } > > } On Thu, Nov 9, 2023 at 12:12?AM David Alayachew wrote: > It has been a month since I sent this proposal. Since no one has told me > that this is a terrible idea, I will submit this as an enhancement to JBS, > and once the ticket is made, start work on creating a pull request. > > On Tue, Oct 3, 2023 at 3:13?AM David Alayachew > wrote: > >> Whoops, bad import. >> >> Please replace the following line with the one after it. >> >> > import java.util.function.Function; >> >> > import java.util.function.*; >> >> On Tue, Oct 3, 2023 at 3:09?AM David Alayachew >> wrote: >> >>> Hello all, >>> >>> I have an idea that I want to run by you all -- a new method on >>> java.util.function.Function to capture ternary operations. >>> >>> Here is a mockup of what I wanted to do. >>> >>> > >>> > import java.util.function.Function; >>> > >>> > @FunctionalInterface >>> > public interface Function2 extends Function >>> > { >>> > >>> > public static Function ternary >>> > ( >>> > Predicate test, >>> > Function trueOutput, >>> > Function falseOutput >>> > ) >>> > { >>> > >>> > return >>> > (I input) -> >>> > test.test(input) >>> > ? trueOutput.apply(input) >>> > : falseOutput.apply(input) >>> > ; >>> > >>> > } >>> > >>> > } >>> > >>> >>> I think this is useful for a few reasons. >>> >>> * This composes, just like the ternary operator itself. >>> >>> * It pairs well with Function.identity() and method references to >>> clearly (but concisely) communicate intent. >>> >>> * Ternary operations are common, so this will find great use by >>> developers of all sorts. >>> >>> There is at least one part I don't quite like about this design - what >>> if one (or both!) of your outputs is not a functional transformation of the >>> input? >>> >>> For example, String username = id.isBlank() ? "UNKNOWN" : lookup(id); >>> >>> Obviously, this is easy to work around - simply ignore the input of the >>> function. But you lose clarity and simplicity that way. I would put a note >>> in the javadoc that says that this method should only be used in instances >>> where both outputs are a functional transformation of the input. That way, >>> intent is clarified. But if we go that route, maybe this function should >>> get a better name to capture that? testThenApply? ternaryTransform? >>> ternaryApply? >>> >>> Thank you for your time and help! >>> David Alayachew >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jpai at openjdk.org Thu Nov 9 06:45:56 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 9 Nov 2023 06:45:56 GMT Subject: RFR: 8319574: Exec/process tests should be marked as flagless In-Reply-To: References: Message-ID: On Wed, 8 Nov 2023 21:04:49 GMT, Roger Riggs wrote: > Tests that directly use ProcessBuilder to spawn processes and do not pass the standard test command line arguments should be marked as `vm.flagless` to indicate to the testing infrastructure that they do not accept them and should not be run with extra test command line options `test.vm.opts` and `test.java.opts`. > > Add @requires vm.flagless to tests The changes look OK to me. It wasn't clear to me what "flagless" meant. I checked the implementation of how this `@requires` is implemented https://github.com/openjdk/jdk/blob/master/test/jtreg-ext/requires/VMProps.java#L657. So essentially, the definition of "flagless" comes down to "was the JVM in which jtreg is running and about to launch a test, launched using certain set of JVM arguments? If it wasn't launched with those set of JVM arguments, then it is flagless." The set of such JVM arguments appears to be wide and may change over time. ------------- Marked as reviewed by jpai (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16572#pullrequestreview-1721810091 From dholmes at openjdk.org Thu Nov 9 06:51:00 2023 From: dholmes at openjdk.org (David Holmes) Date: Thu, 9 Nov 2023 06:51:00 GMT Subject: RFR: JDK-8317799 : AIX PPC64: FFI symbol lookup doesn't find symbols In-Reply-To: References: Message-ID: On Mon, 30 Oct 2023 10:54:48 GMT, suchismith1993 wrote: > 1. Adding required compiler flags. > 2. Adding required symbols. > > JBS-ISSUE : [JDK-8317799](https://bugs.openjdk.org/browse/JDK-8317799) I agree with Magnus that we need to understand the problem first, and then review the solution. As Magnus says these are not hotspot symbols, so why is this needed and why is this math library special? Thanks ------------- PR Comment: https://git.openjdk.org/jdk/pull/16414#issuecomment-1803253157 From dholmes at openjdk.org Thu Nov 9 06:50:58 2023 From: dholmes at openjdk.org (David Holmes) Date: Thu, 9 Nov 2023 06:50:58 GMT Subject: RFR: JDK-8317799 : AIX PPC64: FFI symbol lookup doesn't find symbols In-Reply-To: References: Message-ID: On Wed, 8 Nov 2023 21:14:41 GMT, Magnus Ihse Bursie wrote: > Also, please don't ever force push once you have published a PR. Now it makes Martin's comment just dangling in the air. @magicus I think the force-push happened whilst the PR was still in draft (skara bot did not complain), which is generally acceptable, but still has the problem of leaving dangling comments made whilst in draft mode. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16414#issuecomment-1803251990 From duke at openjdk.org Thu Nov 9 07:37:57 2023 From: duke at openjdk.org (suchismith1993) Date: Thu, 9 Nov 2023 07:37:57 GMT Subject: RFR: JDK-8317799 : AIX PPC64: FFI symbol lookup doesn't find symbols In-Reply-To: References: Message-ID: On Mon, 30 Oct 2023 10:54:48 GMT, suchismith1993 wrote: > 1. Adding required compiler flags. > 2. Adding required symbols. > > JBS-ISSUE : [JDK-8317799](https://bugs.openjdk.org/browse/JDK-8317799) Problem: There is syslookup file which expects the required symbols to be exported using the compiler flags, that are mentioned in the Lib.gmk file. The math library in AIX specifically, is a static archive. Doing a -lm wont suffice, because when the symbols are looked up using dlsym or accessing native code through Java, it will lead to failures. Hence we had to come up with a list of symbols to allow math library symbols to be accesible. Also, there are parts of libc library that are static too, and hence those symbols also are present in this list. Without this change, the StdLibTest and multiple other tests which make native function calls using FFI, fail with NoSuchElementException. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16414#issuecomment-1803298688 From dholmes at openjdk.org Thu Nov 9 07:42:57 2023 From: dholmes at openjdk.org (David Holmes) Date: Thu, 9 Nov 2023 07:42:57 GMT Subject: RFR: 8319574: Exec/process tests should be marked as flagless In-Reply-To: References: Message-ID: On Thu, 9 Nov 2023 06:43:12 GMT, Jaikiran Pai wrote: >> Tests that directly use ProcessBuilder to spawn processes and do not pass the standard test command line arguments should be marked as `vm.flagless` to indicate to the testing infrastructure that they do not accept them and should not be run with extra test command line options `test.vm.opts` and `test.java.opts`. >> >> Add @requires vm.flagless to tests > > The changes look OK to me. > > It wasn't clear to me what "flagless" meant. I checked the implementation of how this `@requires` is implemented https://github.com/openjdk/jdk/blob/master/test/jtreg-ext/requires/VMProps.java#L657. So essentially, the definition of "flagless" comes down to "was the JVM in which jtreg is running and about to launch a test, launched using certain set of JVM arguments? If it wasn't launched with those set of JVM arguments, then it is flagless." The set of such JVM arguments appears to be wide and may change over time. @jaikiran "flagless" should mean that jtreg was not launched with `-javaoption` or `-vmoption` being set. But I see now (thanks for the link) it does allow for some flags to be set `` ------------- PR Comment: https://git.openjdk.org/jdk/pull/16572#issuecomment-1803302532 From pminborg at openjdk.org Thu Nov 9 07:50:57 2023 From: pminborg at openjdk.org (Per Minborg) Date: Thu, 9 Nov 2023 07:50:57 GMT Subject: RFR: 8319761: Simplify fields of Array VarHandles In-Reply-To: References: Message-ID: On Sun, 24 Sep 2023 13:17:05 GMT, Chen Liang wrote: > 1. Primitive array VHs are now singletons and no longer need to record their array base and offset in their object themselves. > 2. Moved Unsafe offset calculation to a utility method, like `index` in VarHandleByteArrayView. Sharing code might sometimes have performance issues because the shared code is used differently from different call sites. See https://bugs.openjdk.org/browse/JDK-8015417. Is this something we should check here? ------------- PR Comment: https://git.openjdk.org/jdk/pull/15894#issuecomment-1803312528 From pminborg at openjdk.org Thu Nov 9 07:57:06 2023 From: pminborg at openjdk.org (Per Minborg) Date: Thu, 9 Nov 2023 07:57:06 GMT Subject: RFR: JDK-8319123 : Implementation of JEP-461: Stream Gatherers (Preview) [v2] In-Reply-To: References: Message-ID: On Wed, 8 Nov 2023 21:08:03 GMT, Viktor Klang wrote: >> This Pull-Request implements [JEP-461](https://openjdk.org/jeps/461) > > Viktor Klang has updated the pull request incrementally with two additional commits since the last revision: > > - Addressing review feedback > - Make Gatherer.andThen take a wildcard for the rhs Gatherer state type src/java.base/share/classes/java/util/stream/Gatherer.java line 216: > 214: > 215: /** > 216: * A function which accepts two intermediate states and combines them into We could use a {@return ..} here. There might be other places too where we could do that. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1387609805 From pminborg at openjdk.org Thu Nov 9 08:04:09 2023 From: pminborg at openjdk.org (Per Minborg) Date: Thu, 9 Nov 2023 08:04:09 GMT Subject: RFR: JDK-8319123 : Implementation of JEP-461: Stream Gatherers (Preview) [v2] In-Reply-To: References: Message-ID: On Thu, 9 Nov 2023 07:54:39 GMT, Per Minborg wrote: >> Viktor Klang has updated the pull request incrementally with two additional commits since the last revision: >> >> - Addressing review feedback >> - Make Gatherer.andThen take a wildcard for the rhs Gatherer state type > > src/java.base/share/classes/java/util/stream/Gatherer.java line 216: > >> 214: >> 215: /** >> 216: * A function which accepts two intermediate states and combines them into > > We could use a {@return ..} here. There might be other places too where we could do that. Nit: I suggest using "A function that" rather than "A function which". One peculiarity with the English language is the distinction between "that" (to be used in a restrictive clause) and "which" (to be used in a non-restrictive clause). Here is a reference: https://preply.com/en/blog/when-to-use-which-or-that-the-most-common-cases This comment also applies to documentation elsewhere. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1387612537 From pminborg at openjdk.org Thu Nov 9 08:04:10 2023 From: pminborg at openjdk.org (Per Minborg) Date: Thu, 9 Nov 2023 08:04:10 GMT Subject: RFR: JDK-8319123 : Implementation of JEP-461: Stream Gatherers (Preview) [v2] In-Reply-To: References: Message-ID: On Wed, 8 Nov 2023 21:08:03 GMT, Viktor Klang wrote: >> This Pull-Request implements [JEP-461](https://openjdk.org/jeps/461) > > Viktor Klang has updated the pull request incrementally with two additional commits since the last revision: > > - Addressing review feedback > - Make Gatherer.andThen take a wildcard for the rhs Gatherer state type src/java.base/share/classes/java/util/stream/Gatherer.java line 245: > 243: > 244: /** > 245: * Returns a composed Gatherer which connects the output of this Gatherer Generally, it would if we could harmonize and consolidate return clauses using {@return ...} ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1387617766 From pminborg at openjdk.org Thu Nov 9 08:10:07 2023 From: pminborg at openjdk.org (Per Minborg) Date: Thu, 9 Nov 2023 08:10:07 GMT Subject: RFR: JDK-8319123 : Implementation of JEP-461: Stream Gatherers (Preview) [v2] In-Reply-To: References: Message-ID: On Wed, 8 Nov 2023 21:08:03 GMT, Viktor Klang wrote: >> This Pull-Request implements [JEP-461](https://openjdk.org/jeps/461) > > Viktor Klang has updated the pull request incrementally with two additional commits since the last revision: > > - Addressing review feedback > - Make Gatherer.andThen take a wildcard for the rhs Gatherer state type src/java.base/share/classes/java/util/stream/Gatherers.java line 54: > 52: @PreviewFeature(feature = PreviewFeature.Feature.STREAM_GATHERERS) > 53: public final class Gatherers { > 54: private Gatherers() { } Suggest adding the comment // Suppresses default constructor, ensuring non-instantiability. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1387623424 From pminborg at openjdk.org Thu Nov 9 08:18:06 2023 From: pminborg at openjdk.org (Per Minborg) Date: Thu, 9 Nov 2023 08:18:06 GMT Subject: RFR: JDK-8319123 : Implementation of JEP-461: Stream Gatherers (Preview) [v2] In-Reply-To: References: Message-ID: On Wed, 8 Nov 2023 21:08:03 GMT, Viktor Klang wrote: >> This Pull-Request implements [JEP-461](https://openjdk.org/jeps/461) > > Viktor Klang has updated the pull request incrementally with two additional commits since the last revision: > > - Addressing review feedback > - Make Gatherer.andThen take a wildcard for the rhs Gatherer state type src/java.base/share/classes/java/util/stream/Gatherer.java line 261: > 259: /** > 260: * Returns an initializer which is the default initializer of a Gatherer. > 261: * The returned initializer identifies that the owner Gatherer is stateless. I know the text is logically correct but is there a way to be more intuitively correct? I mean, there are other initializers that could also mean the Gather is stateless. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1387630728 From pminborg at openjdk.org Thu Nov 9 08:21:06 2023 From: pminborg at openjdk.org (Per Minborg) Date: Thu, 9 Nov 2023 08:21:06 GMT Subject: RFR: JDK-8319123 : Implementation of JEP-461: Stream Gatherers (Preview) [v2] In-Reply-To: References: Message-ID: On Wed, 8 Nov 2023 21:08:03 GMT, Viktor Klang wrote: >> This Pull-Request implements [JEP-461](https://openjdk.org/jeps/461) > > Viktor Klang has updated the pull request incrementally with two additional commits since the last revision: > > - Addressing review feedback > - Make Gatherer.andThen take a wildcard for the rhs Gatherer state type src/java.base/share/classes/java/util/stream/Gatherer.java line 306: > 304: * @param the type of input elements for the new gatherer > 305: * @param the type of results for the new gatherer > 306: * @throws NullPointerException if the argument is null I think we can specify that gatherers are null averse in a single place as we do for Stream an the likes. Then we do not have to nag about @throws NPE ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1387634245 From pminborg at openjdk.org Thu Nov 9 08:26:10 2023 From: pminborg at openjdk.org (Per Minborg) Date: Thu, 9 Nov 2023 08:26:10 GMT Subject: RFR: JDK-8319123 : Implementation of JEP-461: Stream Gatherers (Preview) [v2] In-Reply-To: References: Message-ID: On Wed, 8 Nov 2023 21:08:03 GMT, Viktor Klang wrote: >> This Pull-Request implements [JEP-461](https://openjdk.org/jeps/461) > > Viktor Klang has updated the pull request incrementally with two additional commits since the last revision: > > - Addressing review feedback > - Make Gatherer.andThen take a wildcard for the rhs Gatherer state type src/java.base/share/classes/java/util/stream/Gatherer.java line 267: > 265: * @param the type of the state of the returned initializer > 266: */ > 267: static Supplier defaultInitializer() { Would code sharing imply performance implications due to profile pollution? src/java.base/share/classes/java/util/stream/Gatherer.java line 419: > 417: * @return the new {@code Gatherer} > 418: */ > 419: static Gatherer of( Nit: In `Collector` the parameters are formatted in a different way. Should we be consistent with that existing formatting? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1387636158 PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1387638833 From pminborg at openjdk.org Thu Nov 9 08:31:08 2023 From: pminborg at openjdk.org (Per Minborg) Date: Thu, 9 Nov 2023 08:31:08 GMT Subject: RFR: JDK-8319123 : Implementation of JEP-461: Stream Gatherers (Preview) [v2] In-Reply-To: References: Message-ID: On Wed, 8 Nov 2023 21:08:03 GMT, Viktor Klang wrote: >> This Pull-Request implements [JEP-461](https://openjdk.org/jeps/461) > > Viktor Klang has updated the pull request incrementally with two additional commits since the last revision: > > - Addressing review feedback > - Make Gatherer.andThen take a wildcard for the rhs Gatherer state type src/java.base/share/classes/java/util/stream/Gatherer.java line 509: > 507: @PreviewFeature(feature = PreviewFeature.Feature.STREAM_GATHERERS) > 508: interface Integrator { > 509: /** Integrate is the method which given: Nit: Begin on a separate line ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1387643805 From pminborg at openjdk.org Thu Nov 9 08:31:08 2023 From: pminborg at openjdk.org (Per Minborg) Date: Thu, 9 Nov 2023 08:31:08 GMT Subject: RFR: JDK-8319123 : Implementation of JEP-461: Stream Gatherers (Preview) [v2] In-Reply-To: References: Message-ID: On Thu, 9 Nov 2023 08:27:26 GMT, Per Minborg wrote: >> Viktor Klang has updated the pull request incrementally with two additional commits since the last revision: >> >> - Addressing review feedback >> - Make Gatherer.andThen take a wildcard for the rhs Gatherer state type > > src/java.base/share/classes/java/util/stream/Gatherer.java line 509: > >> 507: @PreviewFeature(feature = PreviewFeature.Feature.STREAM_GATHERERS) >> 508: interface Integrator { >> 509: /** Integrate is the method which given: > > Nit: Begin on a separate line I think the spec should start with "Integrates ..." ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1387645071 From pminborg at openjdk.org Thu Nov 9 08:37:08 2023 From: pminborg at openjdk.org (Per Minborg) Date: Thu, 9 Nov 2023 08:37:08 GMT Subject: RFR: JDK-8319123 : Implementation of JEP-461: Stream Gatherers (Preview) [v2] In-Reply-To: References: Message-ID: On Wed, 8 Nov 2023 21:08:03 GMT, Viktor Klang wrote: >> This Pull-Request implements [JEP-461](https://openjdk.org/jeps/461) > > Viktor Klang has updated the pull request incrementally with two additional commits since the last revision: > > - Addressing review feedback > - Make Gatherer.andThen take a wildcard for the rhs Gatherer state type src/java.base/share/classes/java/util/stream/Gatherer.java line 535: > 533: */ > 534: @ForceInline > 535: static Integrator of(Integrator integrator) { While this idiom is very convenient, there are some trap doors in combinations with method references and compatibility which is why we backed out of https://github.com/openjdk/jdk/pull/16213 It is good that the text mentions "lambda" but maybe we should explicitly mention that method references might introduce said problems? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1387651384 From liach at openjdk.org Thu Nov 9 08:48:01 2023 From: liach at openjdk.org (Chen Liang) Date: Thu, 9 Nov 2023 08:48:01 GMT Subject: RFR: 8319761: Simplify fields of Array VarHandles In-Reply-To: References: Message-ID: On Thu, 9 Nov 2023 07:48:04 GMT, Per Minborg wrote: > Sharing code might sometimes have performance issues because the shared code is used differently from different call sites. See https://bugs.openjdk.org/browse/JDK-8015417. Is this something we should check here? This patch mainly simplifies primitive array var handles by reusing the same object instance. There's no shared bytecode in this patch. Some exist in #15854 though. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15894#issuecomment-1803387174 From asotona at openjdk.org Thu Nov 9 08:52:57 2023 From: asotona at openjdk.org (Adam Sotona) Date: Thu, 9 Nov 2023 08:52:57 GMT Subject: RFR: 8308753: Class-File API transition to Preview [v27] In-Reply-To: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com> References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com> Message-ID: > Classfile API is an internal library under package `jdk.internal.classfile`?in JDK 21. > This pull request turns the Classfile API into a preview feature and moves it into `java.lang.classfile`. > It repackages all uses across JDK and tests and adds lots of missing Javadoc. > > This PR goes in sync with?[JDK-8308754](https://bugs.openjdk.org/browse/JDK-8308754): Class-File API (Preview) (CSR) > and?[JDK-8280389](https://bugs.openjdk.org/browse/JDK-8280389): Class-File API (Preview) (JEP). > > Online javadoc is available at:? > https://cr.openjdk.org/~asotona/JDK-8308753-preview/api/java.base/java/lang/classfile/package-summary.html > > In addition to the primary transition to preview, this pull request also includes: > - All?Classfile*?classes ranamed to?ClassFile*?(based on JEP discussion). > - A new preview feature, `CLASSFILE_API`, has been added. > - Buildsystem tool required a little patch to support annotated modules. > - All JDK modules using the Classfile API are newly participating in the preview. > - All tests that use the Classfile API now have preview enabled. > - A few Javac tests not allowing preview have been partially reverted; their conversion can be re-applied when the Classfile API leaves preview mode. > > Despite the number of affected files, this pull request is relatively straight-forward. The preview version of the Classfile API is based on the internal version of the library from the JDK master branch, and there are no API features added. > > Please review this pull request to help the Classfile API turn into a preview. > > Any comments are welcome. > > Thanks, > Adam Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 363 commits: - fixed lambda tests - Merge branch 'master' into JDK-8308753-preview - fixed SignaturesTest - fixed condy tests - Merge branch 'master' into JDK-8308753-preview - Merge branch 'master' into JDK-8308753-preview # Conflicts: # test/jdk/tools/lib/tests/JImageValidator.java - fixed jdk.jfr - Merge branch 'master' into JDK-8308753-preview # Conflicts: # src/java.base/share/classes/module-info.java - applied javadoc fix suggestions - fixed new benchmark - ... and 353 more: https://git.openjdk.org/jdk/compare/b0fc8082...8c80afff ------------- Changes: https://git.openjdk.org/jdk/pull/15706/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15706&range=26 Stats: 32311 lines in 785 files changed: 14623 ins; 14113 del; 3575 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 pminborg at openjdk.org Thu Nov 9 08:53:10 2023 From: pminborg at openjdk.org (Per Minborg) Date: Thu, 9 Nov 2023 08:53:10 GMT Subject: RFR: JDK-8319123 : Implementation of JEP-461: Stream Gatherers (Preview) [v2] In-Reply-To: References: Message-ID: On Wed, 8 Nov 2023 21:08:03 GMT, Viktor Klang wrote: >> This Pull-Request implements [JEP-461](https://openjdk.org/jeps/461) > > Viktor Klang has updated the pull request incrementally with two additional commits since the last revision: > > - Addressing review feedback > - Make Gatherer.andThen take a wildcard for the rhs Gatherer state type src/java.base/share/classes/java/util/stream/Gatherers.java line 68: > 66: */ > 67: @SuppressWarnings("rawtypes") > 68: enum Value implements Supplier, BinaryOperator, BiConsumer { Can we move down this class at the end of Gatherers as it is an implementation concern? Or even better. move it to jdk.internal ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1387669918 From pminborg at openjdk.org Thu Nov 9 08:57:15 2023 From: pminborg at openjdk.org (Per Minborg) Date: Thu, 9 Nov 2023 08:57:15 GMT Subject: RFR: JDK-8319123 : Implementation of JEP-461: Stream Gatherers (Preview) [v2] In-Reply-To: References: Message-ID: On Wed, 8 Nov 2023 21:08:03 GMT, Viktor Klang wrote: >> This Pull-Request implements [JEP-461](https://openjdk.org/jeps/461) > > Viktor Klang has updated the pull request incrementally with two additional commits since the last revision: > > - Addressing review feedback > - Make Gatherer.andThen take a wildcard for the rhs Gatherer state type src/java.base/share/classes/java/util/stream/Gatherers.java line 326: > 324: > 325: /** > 326: * Gathers elements into fixed-size windows. The last window may contain Returns a ... src/java.base/share/classes/java/util/stream/Gatherers.java line 347: > 345: * @throws IllegalArgumentException when windowSize is less than 1 > 346: */ > 347: public static

  • Gatherer> windowFixed(int windowSize) { In my opinion, it would be nicer to let `Gatherers` be a shopping window for cool gatherers. Ideally, I think only the docs, methods, parameters, and invariant assertions should be visible here. The rest could be tucked away under the covers. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1387675852 PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1387674874 From lkorinth at openjdk.org Thu Nov 9 09:01:07 2023 From: lkorinth at openjdk.org (Leo Korinth) Date: Thu, 9 Nov 2023 09:01:07 GMT Subject: Integrated: 8318962: Update ProcessTools javadoc with suggestions in 8315097 In-Reply-To: <7TkgaSk5gD1NZ3OkkHiQWITGjvdmN8HSOulObRcAjWw=.8b660bc2-e604-40b0-a06b-09c25bd0fe79@github.com> References: <7TkgaSk5gD1NZ3OkkHiQWITGjvdmN8HSOulObRcAjWw=.8b660bc2-e604-40b0-a06b-09c25bd0fe79@github.com> Message-ID: On Tue, 31 Oct 2023 07:19:53 GMT, Leo Korinth wrote: > Updates to javadoc after improvement ideas in the review of 8315097. I have also removed the incomplete invocation command line. I also removed incomplete information in `executeTestJvm` and added a link to `createLimitedTestJavaProcessBuilder` This pull request has now been integrated. Changeset: 7e4cb2f0 Author: Leo Korinth URL: https://git.openjdk.org/jdk/commit/7e4cb2f09d1219c6ba7bfa77be831a7c7c9b055a Stats: 70 lines in 1 file changed: 42 ins; 4 del; 24 mod 8318962: Update ProcessTools javadoc with suggestions in 8315097 Reviewed-by: rriggs ------------- PR: https://git.openjdk.org/jdk/pull/16430 From thartmann at openjdk.org Thu Nov 9 09:03:59 2023 From: thartmann at openjdk.org (Tobias Hartmann) Date: Thu, 9 Nov 2023 09:03:59 GMT Subject: RFR: 8311906: Improve robustness of String constructors with mutable array inputs [v2] In-Reply-To: References: <6SKlGLh5MmxoEx07wHCCUc8KWbbhcspLJmcc1uxQ_FI=.ca33bfb4-fa5c-45f0-b49f-ee6c5c6b68b4@github.com> Message-ID: On Thu, 9 Nov 2023 04:16:25 GMT, Roger Riggs wrote: >> Strings, after construction, are immutable but may be constructed from mutable arrays of bytes, characters, or integers. >> The string constructors should guard against the effects of mutating the arrays during construction that might invalidate internal invariants for the correct behavior of operations on the resulting strings. In particular, a number of operations have optimizations for operations on pairs of latin1 strings and pairs of non-latin1 strings, while operations between latin1 and non-latin1 strings use a more general implementation. >> >> The changes include: >> >> - Adding a warning to each constructor with an array as an argument to indicate that the results are indeterminate >> if the input array is modified before the constructor returns. >> The resulting string may contain any combination of characters sampled from the input array. >> >> - Ensure that strings that are represented as non-latin1 contain at least one non-latin1 character. >> For latin1 inputs, whether the arrays contain ASCII, ISO-8859-1, UTF8, or another encoding decoded to latin1 the scanning and compression is unchanged. >> If a non-latin1 character is found, the string is represented as non-latin1 with the added verification that a non-latin1 character is present at the same index. >> If that character is found to be latin1, then the input array has been modified and the result of the scan may be incorrect. >> Though a ConcurrentModificationException could be thrown, the risk to an existing application of an unexpected exception should be avoided. >> Instead, the non-latin1 copy of the input is re-scanned and compressed; that scan determines whether the latin1 or the non-latin1 representation is returned. >> >> - The methods that scan for non-latin1 characters and their intrinsic implementations are updated to return the index of the non-latin1 character. >> >> - String construction from StringBuilder and CharSequence must also be guarded as their contents may be modified during construction. > > Roger Riggs has updated the pull request incrementally with three additional commits since the last revision: > > - Refactored extractCodePoints to avoid multiple resizes if the array was modified > - Replaced isLatin1 implementation with `getChar(buf, ndx) <= 0xff` > It performs better than the single byte array access by avoiding the bounds check. > - Misc updates for review comments, javadoc cleanup > Extra checking on maximum string lengths when calling toBytes(). The VM changes look good to me. ------------- Marked as reviewed by thartmann (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16425#pullrequestreview-1722030583 From liach at openjdk.org Thu Nov 9 09:10:00 2023 From: liach at openjdk.org (Chen Liang) Date: Thu, 9 Nov 2023 09:10:00 GMT Subject: RFR: 8311906: Improve robustness of String constructors with mutable array inputs [v2] In-Reply-To: References: <6SKlGLh5MmxoEx07wHCCUc8KWbbhcspLJmcc1uxQ_FI=.ca33bfb4-fa5c-45f0-b49f-ee6c5c6b68b4@github.com> <6Z8gWGyohCB0dp1gfe7-K-HDFpYHtn7jjwTsNt0XujY=.d756475b-6a44-44fc-854c-a5bd5290eb1c@github.com> Message-ID: <38KXJbU5VUW3iZk8YUdffRCQM2i7IyzHfk0q8hdYY5E=.b11199b9-7da1-4dde-bf81-ecc5cb4cd42b@github.com> On Mon, 6 Nov 2023 15:30:46 GMT, Roger Riggs wrote: >> src/java.base/share/classes/java/lang/StringUTF16.java line 202: >> >>> 200: @ForceInline >>> 201: public static byte[] compress(final char[] val, final int off, final int count) { >>> 202: byte[] latin1 = new byte[count]; >> >> Will this redundant array allocation be costly if we are working with mostly-utf16 strings, such as CJK strings with no latin characters? >> >> I suggest we can use a heuristic to read the initial char; if it's utf16 then we skip the latin-1 process altogether (and we can assign the utf16 value to the initial index to ensure it's non-latin-1 compressible. > > We can reconsider this design as a separate PR. > Every additional check has a performance impact and in this bug the goal is to avoid any regression. > > We'll need to gain some insight into the distribution of strings when used in a non-latin1 application. > How many of the strings are latin1 vs non-latin1, what is the distribution of string lengths and which APIs are in use in the applications. The implementation is already pretty good about working with strings of different coders > but there may be some different choices when converting between char arrays and int arrays and strings. Just curious, how does benchmark StringConstructor.newStringFromCharsMixedBegin change before and after this patch? If we can see how much of an impact this has on CJK strings it would be appreciated. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16425#discussion_r1387693255 From vklang at openjdk.org Thu Nov 9 09:45:16 2023 From: vklang at openjdk.org (Viktor Klang) Date: Thu, 9 Nov 2023 09:45:16 GMT Subject: RFR: JDK-8319123 : Implementation of JEP-461: Stream Gatherers (Preview) [v2] In-Reply-To: References: Message-ID: On Thu, 9 Nov 2023 08:15:02 GMT, Per Minborg wrote: >> Viktor Klang has updated the pull request incrementally with two additional commits since the last revision: >> >> - Addressing review feedback >> - Make Gatherer.andThen take a wildcard for the rhs Gatherer state type > > src/java.base/share/classes/java/util/stream/Gatherer.java line 261: > >> 259: /** >> 260: * Returns an initializer which is the default initializer of a Gatherer. >> 261: * The returned initializer identifies that the owner Gatherer is stateless. > > I know the text is logically correct but is there a way to be more intuitively correct? I mean, there are other initializers that could also mean the Gather is stateless. @minborg Not really, from an evaluation-perspective only this specific initializer indicates true statelessness (other instances will signal that it is stateful even if it happens to use `null` as its state). True statelessness means that the initializer doesn't need to be invoked, and that any state does not need to be tracked. > src/java.base/share/classes/java/util/stream/Gatherer.java line 267: > >> 265: * @param the type of the state of the returned initializer >> 266: */ >> 267: static Supplier defaultInitializer() { > > Would code sharing imply performance implications due to profile pollution? I guess that depends how deep from the callsite the profiler keeps information and how much of it gets inlined. > src/java.base/share/classes/java/util/stream/Gatherer.java line 419: > >> 417: * @return the new {@code Gatherer} >> 418: */ >> 419: static Gatherer of( > > Nit: In `Collector` the parameters are formatted in a different way. Should we be consistent with that existing formatting? Which parameters? The type parameters or the method parameters? > src/java.base/share/classes/java/util/stream/Gatherer.java line 535: > >> 533: */ >> 534: @ForceInline >> 535: static Integrator of(Integrator integrator) { > > While this idiom is very convenient, there are some trap doors in combinations with method references and compatibility which is why we backed out of https://github.com/openjdk/jdk/pull/16213 > > It is good that the text mentions "lambda" but maybe we should explicitly mention that method references might introduce said problems? This idiom is safer than casts since the casts are blind and need unchecked-annotations. I'm willing to take this approach for an evaluation during the Preview phase. > src/java.base/share/classes/java/util/stream/Gatherers.java line 68: > >> 66: */ >> 67: @SuppressWarnings("rawtypes") >> 68: enum Value implements Supplier, BinaryOperator, BiConsumer { > > Can we move down this class at the end of Gatherers as it is an implementation concern? Or even better. move it to jdk.internal What specifically are you looking to achieve? > src/java.base/share/classes/java/util/stream/Gatherers.java line 326: > >> 324: >> 325: /** >> 326: * Gathers elements into fixed-size windows. The last window may contain > > Returns a ... You mean "Returns a Gatherer which gathers elements into ..." ? > src/java.base/share/classes/java/util/stream/Gatherers.java line 347: > >> 345: * @throws IllegalArgumentException when windowSize is less than 1 >> 346: */ >> 347: public static Gatherer> windowFixed(int windowSize) { > > In my opinion, it would be nicer to let `Gatherers` be a shopping window for cool gatherers. Ideally, I think only the docs, methods, parameters, and invariant assertions should be visible here. The rest could be tucked away under the covers. @minborg While I think that would be fantastic from a theoretical standpoint -- however, as we've already seen with windowSliding and windowFixed, the need for performance and correctness will mean that the Gatherer implementations herein will likely not be "short and nice" which would be ideal from a "shopping window" perspective. And remember, it is not always the case that the cheese in the window is real. :) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1387726780 PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1387728774 PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1387730338 PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1387733407 PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1387734060 PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1387737838 PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1387736978 From tvaleev at openjdk.org Thu Nov 9 09:45:18 2023 From: tvaleev at openjdk.org (Tagir F. Valeev) Date: Thu, 9 Nov 2023 09:45:18 GMT Subject: RFR: JDK-8319123 : Implementation of JEP-461: Stream Gatherers (Preview) [v2] In-Reply-To: References: Message-ID: On Wed, 8 Nov 2023 21:03:59 GMT, Viktor Klang wrote: >> src/java.base/share/classes/java/util/stream/Gatherer.java line 272: >> >>> 270: * Returns a combiner which is the default combiner of a Gatherer. >>> 271: * The returned combiner identifies that the owning Gatherer must only >>> 272: * be evaluated sequentially. >> >> Should we specify that a single shared instance is guaranteed to be returned, so clients may use `combiner == defaultCombiner()`, rather than `combiner.equals(defaultCombiner())`? > > @amaembo Something to the effect of "This method always returns the same instance."? @viktorklang-ora yes. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1387727900 From tvaleev at openjdk.org Thu Nov 9 09:45:20 2023 From: tvaleev at openjdk.org (Tagir F. Valeev) Date: Thu, 9 Nov 2023 09:45:20 GMT Subject: RFR: JDK-8319123 : Implementation of JEP-461: Stream Gatherers (Preview) [v2] In-Reply-To: References: Message-ID: On Thu, 9 Nov 2023 08:18:33 GMT, Per Minborg wrote: >> Viktor Klang has updated the pull request incrementally with two additional commits since the last revision: >> >> - Addressing review feedback >> - Make Gatherer.andThen take a wildcard for the rhs Gatherer state type > > src/java.base/share/classes/java/util/stream/Gatherer.java line 306: > >> 304: * @param the type of input elements for the new gatherer >> 305: * @param the type of results for the new gatherer >> 306: * @throws NullPointerException if the argument is null > > I think we can specify that gatherers are null averse in a single place as we do for Stream an the likes. Then we do not have to nag about @throws NPE I think it's still better to specify this for every method. Many developers read the documentation only for the specific method they are going to call, using IDE features like quick documentation. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1387724172 From vklang at openjdk.org Thu Nov 9 09:45:21 2023 From: vklang at openjdk.org (Viktor Klang) Date: Thu, 9 Nov 2023 09:45:21 GMT Subject: RFR: JDK-8319123 : Implementation of JEP-461: Stream Gatherers (Preview) [v2] In-Reply-To: References: Message-ID: On Thu, 9 Nov 2023 09:31:50 GMT, Tagir F. Valeev wrote: >> src/java.base/share/classes/java/util/stream/Gatherer.java line 306: >> >>> 304: * @param the type of input elements for the new gatherer >>> 305: * @param the type of results for the new gatherer >>> 306: * @throws NullPointerException if the argument is null >> >> I think we can specify that gatherers are null averse in a single place as we do for Stream an the likes. Then we do not have to nag about @throws NPE > > I think it's still better to specify this for every method. Many developers read the documentation only for the specific method they are going to call, using IDE features like quick documentation. Yeah, I agree with @amaembo, I think it is important to keep the contract close to the caller. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1387727423 From vklang at openjdk.org Thu Nov 9 09:45:23 2023 From: vklang at openjdk.org (Viktor Klang) Date: Thu, 9 Nov 2023 09:45:23 GMT Subject: RFR: JDK-8319123 : Implementation of JEP-461: Stream Gatherers (Preview) [v2] In-Reply-To: References: Message-ID: On Thu, 9 Nov 2023 08:28:37 GMT, Per Minborg wrote: >> src/java.base/share/classes/java/util/stream/Gatherer.java line 509: >> >>> 507: @PreviewFeature(feature = PreviewFeature.Feature.STREAM_GATHERERS) >>> 508: interface Integrator { >>> 509: /** Integrate is the method which given: >> >> Nit: Begin on a separate line > > I think the spec should start with "Integrates ..." `Integrates is the method which given:` sounds weird :) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1387731754 From tvaleev at openjdk.org Thu Nov 9 09:45:24 2023 From: tvaleev at openjdk.org (Tagir F. Valeev) Date: Thu, 9 Nov 2023 09:45:24 GMT Subject: RFR: JDK-8319123 : Implementation of JEP-461: Stream Gatherers (Preview) [v2] In-Reply-To: References: <3z8IYhG73DKYCv_643Jtb-nDyNRlaLPyvqoPTDeI6SM=.b336d2d0-29ea-4ee2-98e9-3d89f4f85a7d@github.com> Message-ID: On Wed, 8 Nov 2023 16:37:29 GMT, Viktor Klang wrote: >> Sorry, I'm not sure what do you mean by incrementally. But I've realized that to implement this you may need to push to downstream during combining. E.g., imagine the stream of numbers 1...1000, and you want to make `parallel().gather(pairMap((left, right) -> left+"->"+right)).collect(toList())`, creating a list of "1->2", "2->3", ..., "999->1000" strings. Now, let's assume that the stream was split into four parts during the parallelization: `1..250`, `251..500`, `501..750`, `751..1000`. So you create downstream accumulators and push the pairs there with integrator, like: >> "1->2", ..., "249->250" into first toList() accumulator, >> "251->252", ..., "499->500" into second toList() accumulator >> "501->502", ..., "749->750" into third toList() accumulator >> "751->752", ..., "999->1000" into fourth toList() accumulator >> At this point we have four independent gatherer states, and they keep the first and last element from the upstream. Now, you combine for example, first and second gatherer states. The first one is [first=1, last=250], and the second is [first=251, last=500]. The combined gatherer should be [first=1, last=500] and at the same time during the combining it should push the "250->251" object to the downstream, which will land into the first toList() accumulator. >> >> Hopefully my explanation is clear. Will it be possible to extend the combiner function and provide the Downstream there as well, so combiner can also work as a finisher for the first combined chunk? > > Ah, now I see what you mean. In this specific case you might be able to create a combiner (which would also need a Downstream) such that you can add the missing combinations (the end of the "left" and the beginning of the "right"). But imagine something like `windowFixed(3)`, where the presence of 1 or 2 elements to the "left" will skew all the elements to the "right", potentially rippling through the entire stream. > > I think the Preview is a perfect place to see if the combiner would be made even better with a Downstream reference or not. Logically, the output of said Downstream would be placed *after* the "left"'s output, and *before* the "right"'s output (so in the middle of the two). > > But then someone might want to be able to inject elements outside of that order, but I guess that remains to be seen. > > Great thoughts, @amaembo ? With windowFixed, true parallelization is not possible, unless the stream is SIZED/SUBSIZED, but this information is not available for Gatherer, so we cannot solve this at all (and this is probably a reasonable limitation of the API). > But then someone might want to be able to inject elements outside of that order, but I guess that remains to be seen. Not sure where one may want to inject other elements. If you want to add something after the right output, you can do this inside the finisher, or the next combiner, when the "right" will become the "left". There are no other places to insert. E.g., you cannot insert "before left", because downstream collector has no corresponding operation. To me it looks like inserting after the "left" part is the only possibility. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1387733722 From tvaleev at openjdk.org Thu Nov 9 09:45:25 2023 From: tvaleev at openjdk.org (Tagir F. Valeev) Date: Thu, 9 Nov 2023 09:45:25 GMT Subject: RFR: JDK-8319123 : Implementation of JEP-461: Stream Gatherers (Preview) [v2] In-Reply-To: References: Message-ID: <49F40b_SxlAXt5G7LGCH-Cty6i168xNovt_3H4fMWoc=.64f148b1-f73f-4be8-9583-02211fcb8839@github.com> On Sun, 5 Nov 2023 17:40:29 GMT, Tagir F. Valeev wrote: >> Viktor Klang has updated the pull request incrementally with two additional commits since the last revision: >> >> - Addressing review feedback >> - Make Gatherer.andThen take a wildcard for the rhs Gatherer state type > > src/java.base/share/classes/java/util/stream/Gatherers.java line 426: > >> 424: * transformation for scenarios where no combiner-function can be >> 425: * implemented, or for reductions which are intrinsically >> 426: * order-dependent. > > I think, we should highlight the most important difference between `fold` and `reduce`: `reduce` must provide an associative function, while `fold` does not require this restriction. Please take a look here, probably this comment was overlooked? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1387735052 From vklang at openjdk.org Thu Nov 9 10:09:08 2023 From: vklang at openjdk.org (Viktor Klang) Date: Thu, 9 Nov 2023 10:09:08 GMT Subject: RFR: JDK-8319123 : Implementation of JEP-461: Stream Gatherers (Preview) [v2] In-Reply-To: References: Message-ID: On Wed, 8 Nov 2023 17:11:39 GMT, R?mi Forax wrote: >> The API should be client-friendly, not implementor-friendly, given that it's expected to have much more clients than implementors. An implementor can easily delegate to a private method to add missing type parameters. I did exactly this in the [teeing](https://github.com/openjdk/jdk/blob/7d25f1c6cb770e21cfad8096c1637a24e65fab8c/src/java.base/share/classes/java/util/stream/Collectors.java#L1913) Collector before. There should not be a reason to expose a parameter, which is merely an implementation detail. This also complicates the public documentation of the already complex feature, specifying the parameter which is not necessary to specify. >> >>> Has this proven to be a problem for things like [Collectors.mapping(?)](https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/util/stream/Collectors.html#mapping(java.util.function.Function,java.util.stream.Collector)) ? >> >> I'm not sure how I can prove this, given that you don't usually know the downstream accumulator, so if somebody hits this problem, they will be forced to solve it in another way (e.g., extracting parts of complex collector to separate variables), so you won't find the code in the wild which uses `mapping` type arguments explicitly. Yes, `Collectors.mapping` and `groupingBy` did this mistake in the past, and there's no reason to repeat it again. >> >>> Do you have a concrete example of where the current "encoding" causes a caller-problem? >> >> For example, I want to create a reusable gatherer that performs scan-concat and wraps every resulting string with '[...]'. First try: >> >> >> var gatherer = Gatherers.scan(() -> "", String::concat) >> .andThen(Gatherer.ofSequential((_, t, pusher) -> pusher.push(STR."[{t}]"))); >> >> >> Now, the type of `gatherer` is `Gatherer`, but I want `Gatherer`. I have the following alternatives: >> 1. Specify the variable type explicitly: >> >> Gatherer gatherer = Gatherers.scan(() -> "", String::concat) >> .andThen(Gatherer.ofSequential((_, t, pusher) -> pusher.push(STR."[{t}]"))); >> >> 2. Specify `ofSequential` type arguments: >> >> var gatherer = Gatherers.scan(() -> "", String::concat) >> .andThen(Gatherer.ofSequential((_, t, pusher) -> pusher.push(STR."[{t}]"))); >> >> 3. Specify the types of lambda arguments explicitly: >> >> var gatherer = Gatherers.scan(() -> "", String::concat) >> .andThen(Gatherer.ofSequential((Void _, String t, Downstream pusher) ->... > > I agree with Tagir here, it should be an ? and if you want to capture it in a type variable you can use the standard trick of having the private method declaring the type variable and the public method with the wildcard calling the private method. Sold! Type argument removed! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1387774512 From vklang at openjdk.org Thu Nov 9 10:09:09 2023 From: vklang at openjdk.org (Viktor Klang) Date: Thu, 9 Nov 2023 10:09:09 GMT Subject: RFR: JDK-8319123 : Implementation of JEP-461: Stream Gatherers (Preview) [v2] In-Reply-To: References: <3z8IYhG73DKYCv_643Jtb-nDyNRlaLPyvqoPTDeI6SM=.b336d2d0-29ea-4ee2-98e9-3d89f4f85a7d@github.com> Message-ID: On Thu, 9 Nov 2023 09:39:33 GMT, Tagir F. Valeev wrote: >> Ah, now I see what you mean. In this specific case you might be able to create a combiner (which would also need a Downstream) such that you can add the missing combinations (the end of the "left" and the beginning of the "right"). But imagine something like `windowFixed(3)`, where the presence of 1 or 2 elements to the "left" will skew all the elements to the "right", potentially rippling through the entire stream. >> >> I think the Preview is a perfect place to see if the combiner would be made even better with a Downstream reference or not. Logically, the output of said Downstream would be placed *after* the "left"'s output, and *before* the "right"'s output (so in the middle of the two). >> >> But then someone might want to be able to inject elements outside of that order, but I guess that remains to be seen. >> >> Great thoughts, @amaembo ? > > With windowFixed, true parallelization is not possible, unless the stream is SIZED/SUBSIZED, but this information is not available for Gatherer, so we cannot solve this at all (and this is probably a reasonable limitation of the API). > >> But then someone might want to be able to inject elements outside of that order, but I guess that remains to be seen. > > Not sure where one may want to inject other elements. If you want to add something after the right output, you can do this inside the finisher, or the next combiner, when the "right" will become the "left". There are no other places to insert. E.g., you cannot insert "before left", because downstream collector has no corresponding operation. To me it looks like inserting after the "left" part is the only possibility. @amaembo Alright, then I think we are aligned. Experimentation with combiner-downstream should be possible during the Preview-cycle ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1387776261 From vklang at openjdk.org Thu Nov 9 10:09:12 2023 From: vklang at openjdk.org (Viktor Klang) Date: Thu, 9 Nov 2023 10:09:12 GMT Subject: RFR: JDK-8319123 : Implementation of JEP-461: Stream Gatherers (Preview) [v2] In-Reply-To: <49F40b_SxlAXt5G7LGCH-Cty6i168xNovt_3H4fMWoc=.64f148b1-f73f-4be8-9583-02211fcb8839@github.com> References: <49F40b_SxlAXt5G7LGCH-Cty6i168xNovt_3H4fMWoc=.64f148b1-f73f-4be8-9583-02211fcb8839@github.com> Message-ID: On Thu, 9 Nov 2023 09:40:34 GMT, Tagir F. Valeev wrote: >> src/java.base/share/classes/java/util/stream/Gatherers.java line 426: >> >>> 424: * transformation for scenarios where no combiner-function can be >>> 425: * implemented, or for reductions which are intrinsically >>> 426: * order-dependent. >> >> I think, we should highlight the most important difference between `fold` and `reduce`: `reduce` must provide an associative function, while `fold` does not require this restriction. > > Please take a look here, probably this comment was overlooked? Yeah, I was thinking about that. I tried to word it will "less jargon" so it is easier to casually read and understand. I'm wondering if adding "associativity" helps in that regard? ? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1387773098 From msheppar at openjdk.org Thu Nov 9 10:51:00 2023 From: msheppar at openjdk.org (Mark Sheppard) Date: Thu, 9 Nov 2023 10:51:00 GMT Subject: RFR: 8319200: Don't use test thread factory in ProcessTools.createLimitedTestJavaProcessBuilder() [v4] In-Reply-To: References: <3damdMQpRBrkUN2S32tBD0Tmrl2tmSqA31NniV8FzHU=.d3a36aa7-d5f4-4a63-b2ff-8b9b616a9637@github.com> Message-ID: On Thu, 9 Nov 2023 05:01:35 GMT, David Holmes wrote: > I remain concerned that this means that a whole swag of tests will never be run with virtual threads, which reduces our virtual thread test coverage. Hard to quantify. Do you have any stats on how many tests this will affect and which ones? I thought the purpose of the createLimitedTestJavaProcessBuilder is for use where vm option are NOT being propagated to the ProcessBuilder, as such the thread factory property wont come into consideration ? the Java doc notes that test using createLimitedTestJavaProcessBuilder would be marked as vm.flagless which would suugest thread factory is not being used. createTestJavaProcessBuilder is for use when vm args are being propagated and as such thread factory can be "injected" via this method. So this change is streamlining these use cases. Is this a correct interpretation? ------------- PR Comment: https://git.openjdk.org/jdk/pull/16442#issuecomment-1803595745 From lancea at openjdk.org Thu Nov 9 11:28:01 2023 From: lancea at openjdk.org (Lance Andersen) Date: Thu, 9 Nov 2023 11:28:01 GMT Subject: RFR: 8304020: Speed up test/jdk/java/util/zip/ZipFile/TestTooManyEntries.java and clarify its purpose [v10] In-Reply-To: References: <8Imbn5098NjdJMPtI2UD7BNSP3oRM4q8vB5_Lq1pLhs=.4686073b-207c-4e3b-b6c0-6227037b11b6@github.com> Message-ID: On Mon, 30 Oct 2023 15:50:49 GMT, Eirik Bjorsnos wrote: >> Please review this PR which speeds up TestTooManyEntries and clarifies its purpose: >> >> - The name 'TestTooManyEntries' does not clearly convey the purpose of the test. What is tested is the validation that the total CEN size fits in a Java byte array. Suggested rename: CenSizeTooLarge >> - The test creates DEFLATED entries which incurs zlib costs and File Data / Data Descriptors for no additional benefit. We can use STORED instead. >> - By creating a single LocalDateTime and setting it with `ZipEntry.setTimeLocal`, we can avoid repeated time zone calculations. >> - The name of entries is generated by calling UUID.randomUUID, we could use simple counter instead. >> - The produced file is unnecessarily large. We know how large a CEN entry is, let's take advantage of that to create a file with the minimal size. >> - By adding a maximally large extra field to the CEN entries, we get away with fewer CEN records and save memory >> - The summary and comments of the test can be improved to help explain the purpose of the test and how we reach the limit being tested. >> - By writing sparse 'holes' until the last CEN entry, we can reduce required disk space. >> >> These speedups reduced the runtime from 4 min 17 sec to 3 seconds on my Macbook Pro. The produced ZIP size was reduced from 5.7 GB to ~4K. Memory consumption is down from 8GB to something like 12MB. > > Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision: > > Replace the 'afterLastCEN' boolean with a 'sparse' state variable Latest Mach5 run looks fine ------------- Marked as reviewed by lancea (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/12991#pullrequestreview-1722319085 From lancea at openjdk.org Thu Nov 9 11:31:04 2023 From: lancea at openjdk.org (Lance Andersen) Date: Thu, 9 Nov 2023 11:31:04 GMT Subject: RFR: 8303920: Avoid calling out to python in DataDescriptorSignatureMissing test [v9] In-Reply-To: References: Message-ID: <-Bf3AWzsrn3uzHzQ1NRzeLdR5175yTPO5-wPUYRi8Zc=.78ae1dd3-afff-43d7-ab5a-0e9f39bae21f@github.com> On Mon, 30 Oct 2023 17:48:48 GMT, Eirik Bjorsnos wrote: >> Please review this PR which brings the DataDescriptorSignatureMissing test back to life. >> >> This test currently calls out to Python to create a test vector ZIP with a Data Descriptor without the recommended but optional signature. The Python dependency has turned out to be very brittle, so the test is currently marked with `@ignore` >> >> The PR replaces Python callouts with directly creating the test vector ZIP in the test itself. We can then remove the `@ignore`tag and run this useful test automatically. > > Eirik Bjorsnos has updated the pull request incrementally with three additional commits since the last revision: > > - Describe the structure of Data Descriptors using an example > - Extend the comment of `makeZipWithSignaturelessDescriptor` with some background info on (signature-less) data descriptors, for the benefit of future maintainers. > - Convert test from testng to junit Latest Mach 5 run looks fine ------------- Marked as reviewed by lancea (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/12959#pullrequestreview-1722323767 From lancea at openjdk.org Thu Nov 9 11:32:57 2023 From: lancea at openjdk.org (Lance Andersen) Date: Thu, 9 Nov 2023 11:32:57 GMT Subject: RFR: 8296250" Update ICU4J to Version 74.1 In-Reply-To: References: Message-ID: On Wed, 1 Nov 2023 17:40:09 GMT, Naoto Sato wrote: > Updating the ICU4J components to v74.1 (https://icu.unicode.org/download/74). This change completes the Unicode 15.1 upgrade. The change is merely replacing binary data files used for the Normalization and BiDi support Marked as reviewed by lancea (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/16458#pullrequestreview-1722327026 From dfuchs at openjdk.org Thu Nov 9 11:51:11 2023 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Thu, 9 Nov 2023 11:51:11 GMT Subject: RFR: JDK-8319123 : Implementation of JEP-461: Stream Gatherers (Preview) [v2] In-Reply-To: References: Message-ID: On Thu, 9 Nov 2023 09:34:26 GMT, Viktor Klang wrote: >> I think it's still better to specify this for every method. Many developers read the documentation only for the specific method they are going to call, using IDE features like quick documentation. > > Yeah, I agree with @amaembo, I think it is important to keep the contract close to the caller. I don't mind either way - just wanted to note that the notion of blanket statements for `NullPointerException` is used in several areas ([java.util.logging](https://docs.oracle.com/en/java/javase/21/docs/api/java.logging/java/util/logging/package-summary.html), [java.net.http](https://docs.oracle.com/en/java/javase/21/docs/api/java.net.http/java/net/http/package-summary.html) ...). So there is an established precedent if you were inclined to go this route. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1387889210 From redestad at openjdk.org Thu Nov 9 12:00:15 2023 From: redestad at openjdk.org (Claes Redestad) Date: Thu, 9 Nov 2023 12:00:15 GMT Subject: RFR: 8319423: Improve Year.isLeap by checking divisibility by 16 In-Reply-To: References: Message-ID: On Wed, 8 Nov 2023 16:51:48 GMT, Lothar Kimmeringer wrote: > return (year & 3) == 0 && (year & 15 == 0 || year % 100 != 0); I tried this and many other variants but the one in this PR came out on top - and it even seemed the additional redundancy helped the JIT. This might be due a deficiency in how C2 handles conditional moves, so I stuck to the one that generated the seemingly best code layout with a plan to re-evaluate (and hopefully simplify) this once https://bugs.openjdk.org/browse/JDK-8319451 is resolved. There's already a PR out #16524 so hopefully we can re-visit this soon. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16491#issuecomment-1803695864 From pminborg at openjdk.org Thu Nov 9 12:31:16 2023 From: pminborg at openjdk.org (Per Minborg) Date: Thu, 9 Nov 2023 12:31:16 GMT Subject: RFR: 8319324: FFM: Reformat javadocs [v11] In-Reply-To: <-CK9Ln5FZQ2oX4RZ04Ltx1mzgxdt8qDnaY_Wte_B6CQ=.588bdde5-55c2-476e-8024-8c6b34c72f82@github.com> References: <-CK9Ln5FZQ2oX4RZ04Ltx1mzgxdt8qDnaY_Wte_B6CQ=.588bdde5-55c2-476e-8024-8c6b34c72f82@github.com> Message-ID: > This PR proposes to reformat all the JavaDocs for the FFM API. This would bring the FFM API docs more in line with the existing Java documentation (see below). Occasional drive-by fixes are also included in this PR (such as spelling and capitalization). > > I am aware this PR will (if approved) make a significant mark in the change logs which is regrettable. > > Background: > > Older classes like `Object` and `List` have a maximum line length of 80 characters whereas newer classes like `ScopedValue` have a maximum line length of 90 characters. > > The FFM API currently has javadoc lines that exceed 135 characters per line. It is also customary to use double spaces when starting a new sentence. Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits: - Merge branch 'master' into javadoc-reformat - Merge master - Update after additional reviews - Remove additional redundant full stops - Merge master and update Linker formatting - Harmonize the use of full stops in tags - Remove double spaces after full stops - Review classes not in the foreign package - Update after review - Merge master - ... and 4 more: https://git.openjdk.org/jdk/compare/dd9eab15...b3c4293b ------------- Changes: https://git.openjdk.org/jdk/pull/16518/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16518&range=10 Stats: 3026 lines in 16 files changed: 852 ins; 17 del; 2157 mod Patch: https://git.openjdk.org/jdk/pull/16518.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16518/head:pull/16518 PR: https://git.openjdk.org/jdk/pull/16518 From pminborg at openjdk.org Thu Nov 9 12:31:18 2023 From: pminborg at openjdk.org (Per Minborg) Date: Thu, 9 Nov 2023 12:31:18 GMT Subject: RFR: 8319324: FFM: Reformat javadocs [v10] In-Reply-To: References: <-CK9Ln5FZQ2oX4RZ04Ltx1mzgxdt8qDnaY_Wte_B6CQ=.588bdde5-55c2-476e-8024-8c6b34c72f82@github.com> Message-ID: <6NJG-HGET7esjK6SYd8VfQd2zT9soZeSQsjqd3RkwBg=.98ee6e2c-9fd3-4322-803d-a173a2aeb26b@github.com> On Wed, 8 Nov 2023 09:03:12 GMT, Per Minborg wrote: >> This PR proposes to reformat all the JavaDocs for the FFM API. This would bring the FFM API docs more in line with the existing Java documentation (see below). Occasional drive-by fixes are also included in this PR (such as spelling and capitalization). >> >> I am aware this PR will (if approved) make a significant mark in the change logs which is regrettable. >> >> Background: >> >> Older classes like `Object` and `List` have a maximum line length of 80 characters whereas newer classes like `ScopedValue` have a maximum line length of 90 characters. >> >> The FFM API currently has javadoc lines that exceed 135 characters per line. It is also customary to use double spaces when starting a new sentence. > > Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits: > > - Merge master > - Update after additional reviews > - Remove additional redundant full stops > - Merge master and update Linker formatting > - Harmonize the use of full stops in tags > - Remove double spaces after full stops > - Review classes not in the foreign package > - Update after review > - Merge master > - Reformat javadocs > - ... and 3 more: https://git.openjdk.org/jdk/compare/8555e0f6...b91beb2a A specdiff is available here https://cr.openjdk.org/~pminborg/panama/22/specdiff-panamajavadocrework/package-summary.html The specdiff is from this PR's latest commit (at the time of writing this message) and compares with ee57e731d03 which is a commit just before we started integrating a number of spec updates. This means the diff will include updates from other PRs including @JornVernee 's Linker improvements. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16518#issuecomment-1803737256 From pminborg at openjdk.org Thu Nov 9 12:41:10 2023 From: pminborg at openjdk.org (Per Minborg) Date: Thu, 9 Nov 2023 12:41:10 GMT Subject: RFR: JDK-8319123 : Implementation of JEP-461: Stream Gatherers (Preview) [v2] In-Reply-To: References: Message-ID: On Thu, 9 Nov 2023 09:33:54 GMT, Viktor Klang wrote: >> src/java.base/share/classes/java/util/stream/Gatherer.java line 261: >> >>> 259: /** >>> 260: * Returns an initializer which is the default initializer of a Gatherer. >>> 261: * The returned initializer identifies that the owner Gatherer is stateless. >> >> I know the text is logically correct but is there a way to be more intuitively correct? I mean, there are other initializers that could also mean the Gather is stateless. > > @minborg Not really, from an evaluation-perspective only this specific initializer indicates true statelessness (other instances will signal that it is stateful even if it happens to use `null` as its state). True statelessness means that the initializer doesn't need to be invoked, and that any state does not need to be tracked. Then it should read something that "if, and only if" >> src/java.base/share/classes/java/util/stream/Gatherer.java line 419: >> >>> 417: * @return the new {@code Gatherer} >>> 418: */ >>> 419: static Gatherer of( >> >> Nit: In `Collector` the parameters are formatted in a different way. Should we be consistent with that existing formatting? > > Which parameters? The type parameters or the method parameters? Here is an example: static Collector of(Supplier supplier, BiConsumer accumulator, BinaryOperator combiner, Function finisher, Characteristics... characteristics) { ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1387941646 PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1387942446 From pminborg at openjdk.org Thu Nov 9 12:41:12 2023 From: pminborg at openjdk.org (Per Minborg) Date: Thu, 9 Nov 2023 12:41:12 GMT Subject: RFR: JDK-8319123 : Implementation of JEP-461: Stream Gatherers (Preview) [v2] In-Reply-To: References: Message-ID: On Thu, 9 Nov 2023 11:46:55 GMT, Daniel Fuchs wrote: >> Yeah, I agree with @amaembo, I think it is important to keep the contract close to the caller. > > I don't mind either way - just wanted to note that the notion of blanket statements for `NullPointerException` is used in several areas ([java.util.logging](https://docs.oracle.com/en/java/javase/21/docs/api/java.logging/java/util/logging/package-summary.html), [java.net.http](https://docs.oracle.com/en/java/javase/21/docs/api/java.net.http/java/net/http/package-summary.html) ...). So there is an established precedent if you were inclined to go this route. It is different in `java.util.stream.Stream` and `Collector` and because `Gatherer` is more similar to `Collector` it might in fact be more consistent having the @throws NPE here. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1387940567 From pminborg at openjdk.org Thu Nov 9 12:47:12 2023 From: pminborg at openjdk.org (Per Minborg) Date: Thu, 9 Nov 2023 12:47:12 GMT Subject: RFR: JDK-8319123 : Implementation of JEP-461: Stream Gatherers (Preview) [v2] In-Reply-To: References: Message-ID: On Thu, 9 Nov 2023 09:39:16 GMT, Viktor Klang wrote: >> src/java.base/share/classes/java/util/stream/Gatherer.java line 535: >> >>> 533: */ >>> 534: @ForceInline >>> 535: static Integrator of(Integrator integrator) { >> >> While this idiom is very convenient, there are some trap doors in combinations with method references and compatibility which is why we backed out of https://github.com/openjdk/jdk/pull/16213 >> >> It is good that the text mentions "lambda" but maybe we should explicitly mention that method references might introduce said problems? > > This idiom is safer than casts since the casts are blind and need unchecked-annotations. I'm willing to take this approach for an evaluation during the Preview phase. I like the concept but we could document how to safely use it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1387949245 From mcimadamore at openjdk.org Thu Nov 9 12:50:02 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Thu, 9 Nov 2023 12:50:02 GMT Subject: RFR: 8319324: FFM: Reformat javadocs [v11] In-Reply-To: References: <-CK9Ln5FZQ2oX4RZ04Ltx1mzgxdt8qDnaY_Wte_B6CQ=.588bdde5-55c2-476e-8024-8c6b34c72f82@github.com> Message-ID: On Thu, 9 Nov 2023 12:31:16 GMT, Per Minborg wrote: >> This PR proposes to reformat all the JavaDocs for the FFM API. This would bring the FFM API docs more in line with the existing Java documentation (see below). Occasional drive-by fixes are also included in this PR (such as spelling and capitalization). >> >> I am aware this PR will (if approved) make a significant mark in the change logs which is regrettable. >> >> Background: >> >> Older classes like `Object` and `List` have a maximum line length of 80 characters whereas newer classes like `ScopedValue` have a maximum line length of 90 characters. >> >> The FFM API currently has javadoc lines that exceed 135 characters per line. It is also customary to use double spaces when starting a new sentence. > > Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits: > > - Merge branch 'master' into javadoc-reformat > - Merge master > - Update after additional reviews > - Remove additional redundant full stops > - Merge master and update Linker formatting > - Harmonize the use of full stops in tags > - Remove double spaces after full stops > - Review classes not in the foreign package > - Update after review > - Merge master > - ... and 4 more: https://git.openjdk.org/jdk/compare/dd9eab15...b3c4293b src/java.base/share/classes/java/lang/foreign/Arena.java line 35: > 33: /** > 34: * An arena controls the lifecycle of native memory segments, providing both flexible > 35: * allocation and timely de-allocation. Please revert all uses of "de-allocation". I don't think that's incorrect - seems more of a pedantic check from the tool. src/java.base/share/classes/java/lang/foreign/Linker.java line 878: > 876: /** > 877: * {@return a struct layout that represents the layout of the capture state > 878: * segment that is passedto a downcall handle linked with there's a mistake `passedto` w/o spaces src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 491: > 489: * so that the size of the segment is the same as the size of the target layout . In other > 490: * words, the returned segment is no longer a zero-length memory segment, and the pointer > 491: * it represents can be de-referenced directly: Please revert "de-referenced" ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16518#discussion_r1387948515 PR Review Comment: https://git.openjdk.org/jdk/pull/16518#discussion_r1387949177 PR Review Comment: https://git.openjdk.org/jdk/pull/16518#discussion_r1387952260 From mcimadamore at openjdk.org Thu Nov 9 12:55:00 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Thu, 9 Nov 2023 12:55:00 GMT Subject: RFR: 8319324: FFM: Reformat javadocs [v11] In-Reply-To: References: <-CK9Ln5FZQ2oX4RZ04Ltx1mzgxdt8qDnaY_Wte_B6CQ=.588bdde5-55c2-476e-8024-8c6b34c72f82@github.com> Message-ID: On Thu, 9 Nov 2023 12:31:16 GMT, Per Minborg wrote: >> This PR proposes to reformat all the JavaDocs for the FFM API. This would bring the FFM API docs more in line with the existing Java documentation (see below). Occasional drive-by fixes are also included in this PR (such as spelling and capitalization). >> >> I am aware this PR will (if approved) make a significant mark in the change logs which is regrettable. >> >> Background: >> >> Older classes like `Object` and `List` have a maximum line length of 80 characters whereas newer classes like `ScopedValue` have a maximum line length of 90 characters. >> >> The FFM API currently has javadoc lines that exceed 135 characters per line. It is also customary to use double spaces when starting a new sentence. > > Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits: > > - Merge branch 'master' into javadoc-reformat > - Merge master > - Update after additional reviews > - Remove additional redundant full stops > - Merge master and update Linker formatting > - Harmonize the use of full stops in tags > - Remove double spaces after full stops > - Review classes not in the foreign package > - Update after review > - Merge master > - ... and 4 more: https://git.openjdk.org/jdk/compare/dd9eab15...b3c4293b src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 1956: > 1954: * > 1955: * @param layout the layout of the region of memory to be read > 1956: * @param index a logical index, the offset in bytes (relative to this I think the new text for `index` is not good (here and elsewhere). I suggest: a logical index _denoting_ the offset in bytes... ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16518#discussion_r1387957764 From pminborg at openjdk.org Thu Nov 9 13:07:24 2023 From: pminborg at openjdk.org (Per Minborg) Date: Thu, 9 Nov 2023 13:07:24 GMT Subject: RFR: 8319324: FFM: Reformat javadocs [v12] In-Reply-To: <-CK9Ln5FZQ2oX4RZ04Ltx1mzgxdt8qDnaY_Wte_B6CQ=.588bdde5-55c2-476e-8024-8c6b34c72f82@github.com> References: <-CK9Ln5FZQ2oX4RZ04Ltx1mzgxdt8qDnaY_Wte_B6CQ=.588bdde5-55c2-476e-8024-8c6b34c72f82@github.com> Message-ID: > This PR proposes to reformat all the JavaDocs for the FFM API. This would bring the FFM API docs more in line with the existing Java documentation (see below). Occasional drive-by fixes are also included in this PR (such as spelling and capitalization). > > I am aware this PR will (if approved) make a significant mark in the change logs which is regrettable. > > Background: > > Older classes like `Object` and `List` have a maximum line length of 80 characters whereas newer classes like `ScopedValue` have a maximum line length of 90 characters. > > The FFM API currently has javadoc lines that exceed 135 characters per line. It is also customary to use double spaces when starting a new sentence. Per Minborg has updated the pull request incrementally with two additional commits since the last revision: - Fix issues from comments - Revert de-allocation changes to deallocation ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16518/files - new: https://git.openjdk.org/jdk/pull/16518/files/b3c4293b..39a525c7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16518&range=11 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16518&range=10-11 Stats: 25 lines in 3 files changed: 0 ins; 0 del; 25 mod Patch: https://git.openjdk.org/jdk/pull/16518.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16518/head:pull/16518 PR: https://git.openjdk.org/jdk/pull/16518 From mcimadamore at openjdk.org Thu Nov 9 14:17:45 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Thu, 9 Nov 2023 14:17:45 GMT Subject: RFR: 8319324: FFM: Reformat javadocs [v12] In-Reply-To: References: <-CK9Ln5FZQ2oX4RZ04Ltx1mzgxdt8qDnaY_Wte_B6CQ=.588bdde5-55c2-476e-8024-8c6b34c72f82@github.com> Message-ID: On Thu, 9 Nov 2023 13:07:24 GMT, Per Minborg wrote: >> This PR proposes to reformat all the JavaDocs for the FFM API. This would bring the FFM API docs more in line with the existing Java documentation (see below). Occasional drive-by fixes are also included in this PR (such as spelling and capitalization). >> >> I am aware this PR will (if approved) make a significant mark in the change logs which is regrettable. >> >> Background: >> >> Older classes like `Object` and `List` have a maximum line length of 80 characters whereas newer classes like `ScopedValue` have a maximum line length of 90 characters. >> >> The FFM API currently has javadoc lines that exceed 135 characters per line. It is also customary to use double spaces when starting a new sentence. > > Per Minborg has updated the pull request incrementally with two additional commits since the last revision: > > - Fix issues from comments > - Revert de-allocation changes to deallocation src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 1934: > 1932: * > 1933: * @param layout the layout of the region of memory to be read > 1934: * @param index a logical index denoting the offset in bytes (relative to this apologies for sending you the wrong way. As a single sentence this doesn't make sense. I suggest the original text (e.g. before this PR) is restored. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16518#discussion_r1388067580 From pminborg at openjdk.org Thu Nov 9 14:21:57 2023 From: pminborg at openjdk.org (Per Minborg) Date: Thu, 9 Nov 2023 14:21:57 GMT Subject: RFR: 8319324: FFM: Reformat javadocs [v13] In-Reply-To: <-CK9Ln5FZQ2oX4RZ04Ltx1mzgxdt8qDnaY_Wte_B6CQ=.588bdde5-55c2-476e-8024-8c6b34c72f82@github.com> References: <-CK9Ln5FZQ2oX4RZ04Ltx1mzgxdt8qDnaY_Wte_B6CQ=.588bdde5-55c2-476e-8024-8c6b34c72f82@github.com> Message-ID: > This PR proposes to reformat all the JavaDocs for the FFM API. This would bring the FFM API docs more in line with the existing Java documentation (see below). Occasional drive-by fixes are also included in this PR (such as spelling and capitalization). > > I am aware this PR will (if approved) make a significant mark in the change logs which is regrettable. > > Background: > > Older classes like `Object` and `List` have a maximum line length of 80 characters whereas newer classes like `ScopedValue` have a maximum line length of 90 characters. > > The FFM API currently has javadoc lines that exceed 135 characters per line. It is also customary to use double spaces when starting a new sentence. Per Minborg has updated the pull request incrementally with one additional commit since the last revision: Change text for logical index ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16518/files - new: https://git.openjdk.org/jdk/pull/16518/files/39a525c7..323ab12b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16518&range=12 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16518&range=11-12 Stats: 35 lines in 1 file changed: 0 ins; 0 del; 35 mod Patch: https://git.openjdk.org/jdk/pull/16518.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16518/head:pull/16518 PR: https://git.openjdk.org/jdk/pull/16518 From jvernee at openjdk.org Thu Nov 9 14:36:01 2023 From: jvernee at openjdk.org (Jorn Vernee) Date: Thu, 9 Nov 2023 14:36:01 GMT Subject: RFR: JDK-8317799 : AIX PPC64: FFI symbol lookup doesn't find symbols In-Reply-To: References: Message-ID: On Mon, 30 Oct 2023 10:54:48 GMT, suchismith1993 wrote: > 1. Adding required compiler flags. > 2. Adding required symbols. > > JBS-ISSUE : [JDK-8317799](https://bugs.openjdk.org/browse/JDK-8317799) For some context: `java.lang.foreign.Linker.nativeLinker().defaultLookup()` returns a `SymbolLookup` that can be used to find symbols from the standard library. We use a shim library that re-exports symbols from the standard library in order to make them accessible through `dlsym`, since on e.g. Linux the standard library .so files might actually be linker scripts which we don't want to mess with. On Windows we use ucrtbase.dll + an auxiliary library that contains the expansions of several 'inline' functions such as `printf`. I'm not surprised to see that another platform like AIX requires more to make this work as well. That said, I think we should limit the exported symbols to only those found in the standard C library header files: https://en.cppreference.com/w/c/header ------------- PR Comment: https://git.openjdk.org/jdk/pull/16414#issuecomment-1803944836 From alanb at openjdk.org Thu Nov 9 14:44:12 2023 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 9 Nov 2023 14:44:12 GMT Subject: RFR: JDK-8319123 : Implementation of JEP-461: Stream Gatherers (Preview) [v2] In-Reply-To: References: Message-ID: On Thu, 9 Nov 2023 09:42:41 GMT, Viktor Klang wrote: >> src/java.base/share/classes/java/util/stream/Gatherers.java line 326: >> >>> 324: >>> 325: /** >>> 326: * Gathers elements into fixed-size windows. The last window may contain >> >> Returns a ... > > You mean "Returns a Gatherer which gathers elements into ..." ? Is "window" defined anywhere? If you are doing another pass over the docs then the windowXXX methods could be expanded a bit to explain this grouping concept. Also it could say that the last windows (if it exists, the empty stream is the corner case) has at least one element. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1388076803 From alanb at openjdk.org Thu Nov 9 14:44:18 2023 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 9 Nov 2023 14:44:18 GMT Subject: RFR: JDK-8319123 : Implementation of JEP-461: Stream Gatherers (Preview) [v2] In-Reply-To: References: Message-ID: On Wed, 8 Nov 2023 21:08:03 GMT, Viktor Klang wrote: >> This Pull-Request implements [JEP-461](https://openjdk.org/jeps/461) > > Viktor Klang has updated the pull request incrementally with two additional commits since the last revision: > > - Addressing review feedback > - Make Gatherer.andThen take a wildcard for the rhs Gatherer state type src/java.base/share/classes/java/util/stream/Gatherers.java line 543: > 541: * @throws NullPointerException if any of the parameters are null > 542: */ > 543: public static Gatherer scan( The examples (as code snippets) in the windowXXX and fold methods are great. It might help to add one to scan too as some readers might not know what prefix scan is, or they wonder if this is scan left or right. src/java.base/share/classes/java/util/stream/Gatherers.java line 562: > 560: /** > 561: * An operation which executes operations concurrently > 562: * with a fixed window of max concurrency, using VirtualThreads. Of the 5, this is the one that I'm not sure about so will be interesting to see if there is feedback from real world usage. "VirtualThreads" isn't a class so maybe replace it with "virtual Threads", linked to Thread.html#virtual-threads. src/java.base/share/classes/java/util/stream/Gatherers.java line 615: > 613: assert wasAddedToWindow; > 614: > 615: Thread.startVirtualThread(task); At some point it might be worth seeing this should should use Executors.newVirtualThreadPerTaskExecutor(), that would at last simplify the cleanup as it would be executor.shutdownNow. The serviceability benefit would be that an observe on a far hill taking a thread dump would have the virtual threads grouped for each mapConcurrent gatherer. src/java.base/share/classes/java/util/stream/Stream.java line 1093: > 1091: * > 1092: * @implNote Implementations of this interface should provide their own > 1093: * implementation of this method. I think the sentence goes in the implSpec as it tells implementers that they must override this method. The `@see Gatherer` it probably not needed as the method already links to Gatherer. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1388083700 PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1388104543 PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1388101381 PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1388038457 From mcimadamore at openjdk.org Thu Nov 9 15:00:06 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Thu, 9 Nov 2023 15:00:06 GMT Subject: RFR: 8319324: FFM: Reformat javadocs [v13] In-Reply-To: References: <-CK9Ln5FZQ2oX4RZ04Ltx1mzgxdt8qDnaY_Wte_B6CQ=.588bdde5-55c2-476e-8024-8c6b34c72f82@github.com> Message-ID: <26Deb1ha2AzhrRI0t6cD_6TlRkr1kNwYGChXUwKORfU=.f770bb77-1b07-40bf-b245-ef6ea2e82bb6@github.com> On Thu, 9 Nov 2023 14:21:57 GMT, Per Minborg wrote: >> This PR proposes to reformat all the JavaDocs for the FFM API. This would bring the FFM API docs more in line with the existing Java documentation (see below). Occasional drive-by fixes are also included in this PR (such as spelling and capitalization). >> >> I am aware this PR will (if approved) make a significant mark in the change logs which is regrettable. >> >> Background: >> >> Older classes like `Object` and `List` have a maximum line length of 80 characters whereas newer classes like `ScopedValue` have a maximum line length of 90 characters. >> >> The FFM API currently has javadoc lines that exceed 135 characters per line. It is also customary to use double spaces when starting a new sentence. > > Per Minborg has updated the pull request incrementally with one additional commit since the last revision: > > Change text for logical index Marked as reviewed by mcimadamore (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/16518#pullrequestreview-1722745325 From rriggs at openjdk.org Thu Nov 9 15:15:59 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 9 Nov 2023 15:15:59 GMT Subject: RFR: 8311906: Improve robustness of String constructors with mutable array inputs [v2] In-Reply-To: <38KXJbU5VUW3iZk8YUdffRCQM2i7IyzHfk0q8hdYY5E=.b11199b9-7da1-4dde-bf81-ecc5cb4cd42b@github.com> References: <6SKlGLh5MmxoEx07wHCCUc8KWbbhcspLJmcc1uxQ_FI=.ca33bfb4-fa5c-45f0-b49f-ee6c5c6b68b4@github.com> <6Z8gWGyohCB0dp1gfe7-K-HDFpYHtn7jjwTsNt0XujY=.d756475b-6a44-44fc-854c-a5bd5290eb1c@github.com> <38KXJbU5VUW3iZk8YUdffRCQM2i7IyzHfk0q8hdYY5E=.b11199b9-7da1-4dde-bf81-ecc5cb4cd42b@github.com> Message-ID: <0iHPN-yDHDQHS0CS9mGVH-Vn2gQIWWEi07Hgsy1UjGE=.1f33d7bb-f0cd-4016-b337-6aeb3fec2131@github.com> On Thu, 9 Nov 2023 09:07:31 GMT, Chen Liang wrote: > Just curious, how does benchmark StringConstructor.newStringFromCharsMixedBegin change before and after this patch? If we can see how much of an impact this has on CJK strings it would be appreciated. You may have better insights from doing your own runs on your own systems. Here's a sample from a recent run. Mostly small improvements and a few small negatives. Benchmark Linux aarch64 | Linux x64 | MacOSX aarch64 | MacOSX x64 newStringFromCharsMixedBegin-size:64 | 1.22% | 0.91% | -0.81% | 1.08% newStringFromCharsMixedBegin-size:7 | 4.40% | 0.26% | -1.88% | 4.60% ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16425#discussion_r1388152228 From pminborg at openjdk.org Thu Nov 9 15:22:11 2023 From: pminborg at openjdk.org (Per Minborg) Date: Thu, 9 Nov 2023 15:22:11 GMT Subject: Integrated: 8319324: FFM: Reformat javadocs In-Reply-To: <-CK9Ln5FZQ2oX4RZ04Ltx1mzgxdt8qDnaY_Wte_B6CQ=.588bdde5-55c2-476e-8024-8c6b34c72f82@github.com> References: <-CK9Ln5FZQ2oX4RZ04Ltx1mzgxdt8qDnaY_Wte_B6CQ=.588bdde5-55c2-476e-8024-8c6b34c72f82@github.com> Message-ID: <7HttwHSOdJ-mh2c3ETgKp4YbaprvX5h3kkdEVlMOnZc=.2c70704a-a888-4b50-a69e-c34b96550f57@github.com> On Mon, 6 Nov 2023 07:41:46 GMT, Per Minborg wrote: > This PR proposes to reformat all the JavaDocs for the FFM API. This would bring the FFM API docs more in line with the existing Java documentation (see below). Occasional drive-by fixes are also included in this PR (such as spelling and capitalization). > > I am aware this PR will (if approved) make a significant mark in the change logs which is regrettable. > > Background: > > Older classes like `Object` and `List` have a maximum line length of 80 characters whereas newer classes like `ScopedValue` have a maximum line length of 90 characters. > > The FFM API currently has javadoc lines that exceed 135 characters per line. It is also customary to use double spaces when starting a new sentence. This pull request has now been integrated. Changeset: f9395421 Author: Per Minborg URL: https://git.openjdk.org/jdk/commit/f9395421047b505b37941acc258114a99df4e11c Stats: 3025 lines in 16 files changed: 852 ins; 17 del; 2156 mod 8319324: FFM: Reformat javadocs Reviewed-by: mcimadamore ------------- PR: https://git.openjdk.org/jdk/pull/16518 From jvernee at openjdk.org Thu Nov 9 15:38:11 2023 From: jvernee at openjdk.org (Jorn Vernee) Date: Thu, 9 Nov 2023 15:38:11 GMT Subject: RFR: 8254693: Add Panama feature to pass heap segments to native code [v12] In-Reply-To: References: Message-ID: On Thu, 9 Nov 2023 00:27:46 GMT, Vladimir Ivanov wrote: > Even though it's straightforward to support on-heap accesses during critical function calls, object pinning would support that for non-critical function calls as well, but proposed API doesn't cover it and new API will be required. What's the plan here? The issue is that most GCs don't support object pinning. I don't think we want an API that only works for some GCs. But, if we do, there's a better API that we can have for just pinning support, which is a `MemorySegment::pin(Arena)` method that returns a MemorySegment wrapping the pinned array. That would allow doing multiple native calls with just a single pin operation, and also allows embedding pointers to pinned segments in other data structures. For the current approach where we make the array accessible for the duration of the native call: without pinning support, other GCs would have to use GCLocker. That means that the native call also has to be relatively short-lived, at which point I figured we might as well drop the thread state transition, since that has the same requirement. I.e. we detect that the call is short-lived, and do the optimization ourselves without the hint from the user (`critical`). This coincidentally also greatly simplifies the implementation. In a prior iteration I did have a separate `allowHeap` `Option` that implied `critical`. But it was suggested to just merge the two together in that case. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16201#discussion_r1388181983 From jvernee at openjdk.org Thu Nov 9 15:43:08 2023 From: jvernee at openjdk.org (Jorn Vernee) Date: Thu, 9 Nov 2023 15:43:08 GMT Subject: RFR: 8254693: Add Panama feature to pass heap segments to native code [v12] In-Reply-To: References: Message-ID: On Wed, 8 Nov 2023 19:52:00 GMT, Vladimir Ivanov wrote: >> Jorn Vernee has updated the pull request incrementally with two additional commits since the last revision: >> >> - a -> an >> - add note to downcallHandle about passing heap segments by-reference > > src/hotspot/cpu/aarch64/downcallLinker_aarch64.cpp line 182: > >> 180: ArgumentShuffle arg_shuffle(filtered_java_regs, out_regs, shuffle_reg); >> 181: >> 182: #ifndef PRODUCT > > Any particular reason to exclude the logging in product builds? `ArgumentShuffle::print_on()` is unconditionally available there. This is partly historical. The log output is only intended for debugging, not for end-user eyes. So, I think I originally excluded it as a way of trimming fat from the product build. Either way, `ArgumentShuffle::print_on` should probably be excluded/included on the same basis. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16201#discussion_r1388189136 From rriggs at openjdk.org Thu Nov 9 15:44:02 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 9 Nov 2023 15:44:02 GMT Subject: RFR: 8317742: ISO Standard Date Format implementation consistency on DateTimeFormatter and String.format [v6] In-Reply-To: References: Message-ID: On Wed, 8 Nov 2023 00:52:36 GMT, Shaojin Wen wrote: >> j.u.Formatter now prints "%tF" (iso standard date) and the result is incorrect when processing year < 0 or year > 9999 > > Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: > > Use minus sign from cached DecimalFormatSymbols and improved testcase Thanks for the updates. ------------- Marked as reviewed by rriggs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16033#pullrequestreview-1722846831 From jvernee at openjdk.org Thu Nov 9 16:04:28 2023 From: jvernee at openjdk.org (Jorn Vernee) Date: Thu, 9 Nov 2023 16:04:28 GMT Subject: RFR: 8254693: Add Panama feature to pass heap segments to native code [v13] In-Reply-To: References: Message-ID: > Add the ability to pass heap segments to native code. This requires using `Linker.Option.critical(true)` as a linker option. It has the same limitations as normal critical calls, namely: upcalls into Java are not allowed, and the native function should return relatively quickly. Heap segments are exposed to native code through temporary native addresses that are valid for the duration of the native call. > > The motivation for this is supporting existing Java array-based APIs that might have to pass multi-megabyte size arrays to native code, and are current relying on Get-/ReleasePrimitiveArrayCritical from JNI. Where making a copy of the array would be overly prohibitive. > > Components of this patch: > > - New binding operator `SegmentBase`, which gets the base object of a `MemorySegment`. > - Rename `UnboxAddress` to `SegmentOffset`. Add flag to specify whether processing heap segments should be allowed. > - `CallArranger` impls use new binding operators when `Linker.Option.critical(/* allowHeap= */ true)` is specified. > - `NativeMethodHandle`/`NativeEntryPoint` allow `Object` in their signatures. > - The object/oop + offset is exposed as temporary address to native code. > - Since we stay in the `_thread_in_Java` state, we can safely expose the oops passed to the downcall stub to native code, without needing GCLocker. These oops are valid until we poll for safepoint, which we never do (invoking pure native code). > - Only x64 and AArch64 for now. > - I've refactored `ArgumentShuffle` in the C++ code to no longer rely on callbacks to get the set of source and destination registers (using `CallingConventionClosure`), but instead just rely on 2 equal size arrays with source and destination registers. This allows filtering the input java registers before passing them to `ArgumentShuffle`, which is required to filter out registers holding segment offsets. Replacing placeholder registers is also done as a separate pre-processing step now. See changes in: https://github.com/openjdk/jdk/pull/16201/commits/d2b40f1117d63cc6d74e377bf88cdcf6d15ff866 > - I've factored out `DowncallStubGenerator` in the x64 and AArch64 code to use a common `DowncallLinker::StubGenerator`. > - Fallback linker is also supported using JNI's `GetPrimitiveArrayCritical`/`ReleasePrimitiveArrayCritical` > > Aside: fixed existing issue with `DowncallLinker` not properly acquiring segments in interpreted mode. > > Numbers for the included benchmark on my machine are: > > > Benchmark (size) Mode Cnt ... Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 51 commits: - fix type and reformat doc in Linker - Merge branch 'master' into AllowHeapNoLock - tweak whitespace - a -> an - add note to downcallHandle about passing heap segments by-reference - Merge branch 'master' into AllowHeapNoLock - bump up argument counts in TestLargeStub to their maximum - s390 updates - add stub size stress test for allowHeap - RISC-V impl - ... and 41 more: https://git.openjdk.org/jdk/compare/f9395421...914f4882 ------------- Changes: https://git.openjdk.org/jdk/pull/16201/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16201&range=12 Stats: 2711 lines in 74 files changed: 1722 ins; 692 del; 297 mod Patch: https://git.openjdk.org/jdk/pull/16201.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16201/head:pull/16201 PR: https://git.openjdk.org/jdk/pull/16201 From vromero at openjdk.org Thu Nov 9 16:05:06 2023 From: vromero at openjdk.org (Vicente Romero) Date: Thu, 9 Nov 2023 16:05:06 GMT Subject: RFR: JDK-8315457 Implementation of String Templates (Second Preview) [v6] In-Reply-To: <3NHJ2yDj2dW6Y4qPF8FmBkqkXcG7l-BzQ3EKWYArZMI=.28885188-9e99-46e8-81bd-6234023c1b1f@github.com> References: <3NHJ2yDj2dW6Y4qPF8FmBkqkXcG7l-BzQ3EKWYArZMI=.28885188-9e99-46e8-81bd-6234023c1b1f@github.com> Message-ID: <0K0xamwKYF8WAEot9UxNl8ncxWFkonJiSDgCVqs8b7A=.755020db-142d-4572-9a59-e1e31a741945@github.com> On Tue, 7 Nov 2023 12:29:54 GMT, Jim Laskey wrote: >> Update String Templates for a second preview. With the addition of >> >> - Expression type and throws are determined from the `process` method of the processor type and not the processor type. >> >> - Qualified `STR` and `RAW` are treated the same as unqualified `STR` and `RAW` . >> >> - Raw (generic) process types are no longer an error. > > Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision: > > - Merge remote-tracking branch 'upstream/master' into 8315457 > - Remove preview from JavaLangAccess > - Merge remote-tracking branch 'upstream/master' into 8315457 > - Cache process method type in JCStringTemplate > - Revert source > - Revert @since 22 > - Accept qualified STR and RAW > - String Templates (second preview) lgtm ------------- Marked as reviewed by vromero (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16202#pullrequestreview-1722905748 From rriggs at openjdk.org Thu Nov 9 16:05:59 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 9 Nov 2023 16:05:59 GMT Subject: RFR: 8296250" Update ICU4J to Version 74.1 In-Reply-To: References: Message-ID: <7L1uSdeCYhYJZEwsjqWRVI2uVjxbp87DA-JGiV6neSM=.0e318dd7-a577-4493-b4d4-f579d69b8ca0@github.com> On Wed, 1 Nov 2023 17:40:09 GMT, Naoto Sato wrote: > Updating the ICU4J components to v74.1 (https://icu.unicode.org/download/74). This change completes the Unicode 15.1 upgrade. The change is merely replacing binary data files used for the Normalization and BiDi support Marked as reviewed by rriggs (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/16458#pullrequestreview-1722908995 From lancea at openjdk.org Thu Nov 9 16:20:59 2023 From: lancea at openjdk.org (Lance Andersen) Date: Thu, 9 Nov 2023 16:20:59 GMT Subject: RFR: 8306116: Update CLDR to Version 44.0 In-Reply-To: References: Message-ID: <0DDdC9CF-OhIVtmCFum1POY7ZTgWhEi-7kDZO5QZq5Q=.4f0c1ddb-1527-45c1-963f-8fc6a5ac89e7@github.com> On Tue, 31 Oct 2023 21:06:13 GMT, Naoto Sato wrote: > Upgrading CLDR to v44 (https://cldr.unicode.org/index/downloads/cldr-44). Besides the data upgrade, regression tests are modified to accommodate the following CLDR fixes: > > CLDR-16534: Suggestion to rename the Islamic Calendar to Hijri Calendar (https://unicode-org.atlassian.net/browse/CLDR-16534) > CLDR-17042: Use exception list for new languages (https://unicode-org.atlassian.net/browse/CLDR-17042) > CLDR-16586: en_ID shows IDR rather than Rp for currency (https://unicode-org.atlassian.net/browse/CLDR-16586) > CLDR-16358: Mexico and Latin America countries should be using 12 hours time format (https://unicode-org.atlassian.net/browse/CLDR-16358) > CLDR-16974: en_GB and en_AU: request to remove comma from MMMEEEEd format (https://unicode-org.atlassian.net/browse/CLDR-16974) > CLDR-16857: Need updated translations for new Sierra Leone currency - SLL became SLE (https://unicode-org.atlassian.net/browse/CLDR-16857) Marked as reviewed by lancea (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/16439#pullrequestreview-1722957033 From rriggs at openjdk.org Thu Nov 9 16:25:12 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 9 Nov 2023 16:25:12 GMT Subject: Integrated: 8319574: Exec/process tests should be marked as flagless In-Reply-To: References: Message-ID: On Wed, 8 Nov 2023 21:04:49 GMT, Roger Riggs wrote: > Tests that directly use ProcessBuilder to spawn processes and do not pass the standard test command line arguments should be marked as `vm.flagless` to indicate to the testing infrastructure that they do not accept them and should not be run with extra test command line options `test.vm.opts` and `test.java.opts`. > > Add @requires vm.flagless to tests This pull request has now been integrated. Changeset: 68110b7a Author: Roger Riggs URL: https://git.openjdk.org/jdk/commit/68110b7a82ae82e2485aec23aba5406d2a5c0327 Stats: 22 lines in 14 files changed: 13 ins; 0 del; 9 mod 8319574: Exec/process tests should be marked as flagless Reviewed-by: bpb, naoto, jpai ------------- PR: https://git.openjdk.org/jdk/pull/16572 From duke at openjdk.org Thu Nov 9 16:54:08 2023 From: duke at openjdk.org (Gaurav Chaudhari) Date: Thu, 9 Nov 2023 16:54:08 GMT Subject: RFR: 8319668: Fixup of jar filename typo in BadFactoryTest.sh Message-ID: The file test/jdk/javax/script/JDK_8196959/BadFactoryTest.sh contains a typo. When running without security manager, the test references 'badfactoty.jar' instead of 'badfactory.jar'. This change addresses this by correcting the jar name. ------------- Commit messages: - 8319668: Fixup of jar filename typo in BadFactoryTest.sh Changes: https://git.openjdk.org/jdk/pull/16585/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16585&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8319668 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/16585.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16585/head:pull/16585 PR: https://git.openjdk.org/jdk/pull/16585 From naoto at openjdk.org Thu Nov 9 17:18:03 2023 From: naoto at openjdk.org (Naoto Sato) Date: Thu, 9 Nov 2023 17:18:03 GMT Subject: RFR: 8317742: ISO Standard Date Format implementation consistency on DateTimeFormatter and String.format [v6] In-Reply-To: References: Message-ID: On Wed, 8 Nov 2023 00:52:36 GMT, Shaojin Wen wrote: >> j.u.Formatter now prints "%tF" (iso standard date) and the result is incorrect when processing year < 0 or year > 9999 > > Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: > > Use minus sign from cached DecimalFormatSymbols and improved testcase Looks like your fix causes a regression test failure in test/jdk/java/time/test/java/util/TestFormatter.java ----------System.out:(1097/72894)---------- test test.java.util.TestFormatter.test("en_US"): success test test.java.util.TestFormatter.test("th_TH"): success ChronoZonedDateTimeImpl(Japanese) actual: D:[04/19/05] F:[2023-04-19] FAILED; expected: D:[04/19/05] F:[0005-04-19] java.lang.RuntimeException at test.java.util.TestFormatter.test(TestFormatter.java:198) at test.java.util.TestFormatter.testDate(TestFormatter.java:216) at test.java.util.TestFormatter.test(TestFormatter.java:114) at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103) at java.base/java.lang.reflect.Method.invoke(Method.java:580) at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:132) at org.testng.internal.TestInvoker.invokeMethod(TestInvoker.java:599) at org.testng.internal.TestInvoker.invokeTestMethod(TestInvoker.java:174) at org.testng.internal.MethodRunner.runInSequence(MethodRunner.java:46) at org.testng.internal.TestInvoker$MethodInvocationAgent.invoke(TestInvoker.java:822) at org.testng.internal.TestInvoker.invokeTestMethods(TestInvoker.java:147) at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:146) at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:128) at java.base/java.util.ArrayList.forEach(ArrayList.java:1597) at org.testng.TestRunner.privateRun(TestRunner.java:764) at org.testng.TestRunner.run(TestRunner.java:585) at org.testng.SuiteRunner.runTest(SuiteRunner.java:384) at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:378) at org.testng.SuiteRunner.privateRun(SuiteRunner.java:337) at org.testng.SuiteRunner.run(SuiteRunner.java:286) at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:53) at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:96) at org.testng.TestNG.runSuitesSequentially(TestNG.java:1218) at org.testng.TestNG.runSuitesLocally(TestNG.java:1140) at org.testng.TestNG.runSuites(TestNG.java:1069) at org.testng.TestNG.run(TestNG.java:1037) at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:102) at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:58) at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103) at java.base/java.lang.reflect.Method.invoke(Method.java:580) at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138) at java.base/java.lang.Thread.run(Thread.java:1570) Please make sure all the related regression tests pass. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16033#issuecomment-1804237006 From lancea at openjdk.org Thu Nov 9 17:24:58 2023 From: lancea at openjdk.org (Lance Andersen) Date: Thu, 9 Nov 2023 17:24:58 GMT Subject: RFR: 8316141: Improve CEN header validation checking In-Reply-To: References: Message-ID: On Wed, 8 Nov 2023 19:59:34 GMT, Lance Andersen wrote: > Please review this PR which enhances the existing CEN header validation checking to ensure that the > size of the CEN Header + name length + comment length + extra length do not exceed 65,535 bytes per the PKWare APP.NOTE 4.4.10, 4.4.11, & 4.4.12. Also check that current CEN header will not exceed the length of the CEN array. > > Mach 5 tiers 1-3 are clean with this change. Thank you for the comments. See my replies below. Regarding you comment about checking whether or not to check if the combined length of the CEN header + name length + comment length + extra length > 65K bytes, I chose to add this given the strong wording given this a really old spec. That being said, I do not object to removing the validation if that is the overall preference. zerror("invalid CEN header (bad header size)"); } ------------- PR Review: https://git.openjdk.org/jdk/pull/16570#pullrequestreview-1723102540 From lancea at openjdk.org Thu Nov 9 17:25:02 2023 From: lancea at openjdk.org (Lance Andersen) Date: Thu, 9 Nov 2023 17:25:02 GMT Subject: RFR: 8316141: Improve CEN header validation checking In-Reply-To: References: Message-ID: On Wed, 8 Nov 2023 20:26:32 GMT, Eirik Bjorsnos wrote: >> Please review this PR which enhances the existing CEN header validation checking to ensure that the >> size of the CEN Header + name length + comment length + extra length do not exceed 65,535 bytes per the PKWare APP.NOTE 4.4.10, 4.4.11, & 4.4.12. Also check that current CEN header will not exceed the length of the CEN array. >> >> Mach 5 tiers 1-3 are clean with this change. > > src/java.base/share/classes/java/util/zip/ZipFile.java line 1225: > >> 1223: int elen = CENEXT(cen, pos); >> 1224: int clen = CENCOM(cen, pos); >> 1225: long headerSize = (long)CENHDR + nlen + clen + elen; > > Since CENHDR is 46 and nlen, clen, elen are all unsigned shorts, this sum cannot possibly overflow an int. Is the long conversion necessary? > > The specification uses the term "combined length", would it be better to name the local variable `combinedLength` instead? I can remove the cast as that was a holdover. I chose to make this a long knowing that it would not overflow but an overflow while unlikely could occur depending on the value of `pos` in the statement below if (headerSize > 0xFFFF || pos + headerSize > cen.length - ENDHDR) { zerror("invalid CEN header (bad header size)"); } I could keep headerSize an int and then move the cast to the if statement: if (headerSize > 0xFFFF || (long)pos + headerSize > cen.length - ENDHDR) { zerror("invalid CEN header (bad header size)"); } I decided making headerSize a long might be clearer but do not have a strong preference and will go with the consensus As far as the name, I don't have a strong preference, but not sure combinedLength is any better > src/java.base/share/classes/java/util/zip/ZipFile.java line 1235: > >> 1233: >> 1234: if (elen > 0 && !DISABLE_ZIP64_EXTRA_VALIDATION) { >> 1235: checkExtraFields(pos, entryPos + nlen, elen); > > The naming of `entryPos` confused me here. The name indicates it is the position where the CEN header starts, but we already have `pos` for that. (It actually contains the position where the encoded name starts) > > So perhaps it should be renamed to `namePos` or `npos` to make future maintenance less confusing? > > Also, I actually liked the `extraStartingOffset` local variable, having a name makes the code easier to follow than just `entryPos + nlen`. But perhaps `extraPos` is shorter and more consistent with other uses of `pos`? > > So perhaps: `long extraPos = pos + CENHDR + nlen` ? `entryPos` was the name of the field from a previous PR so I did not see a need to change it and decided there was no need to keep extraStartingOffset given the change in validation above. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16570#discussion_r1388318963 PR Review Comment: https://git.openjdk.org/jdk/pull/16570#discussion_r1388313503 From rriggs at openjdk.org Thu Nov 9 17:27:00 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 9 Nov 2023 17:27:00 GMT Subject: RFR: 8317742: ISO Standard Date Format implementation consistency on DateTimeFormatter and String.format [v6] In-Reply-To: References: Message-ID: <-GfViWiwQmceGNowaIERufq7gJn3DF3dA6oLo03BR04=.63199bff-9265-4d36-8bf3-0375800c1e6f@github.com> On Wed, 8 Nov 2023 00:52:36 GMT, Shaojin Wen wrote: >> j.u.Formatter now prints "%tF" (iso standard date) and the result is incorrect when processing year < 0 or year > 9999 > > Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: > > Use minus sign from cached DecimalFormatSymbols and improved testcase Without the change localization of the dates, the CSR is not needed ------------- PR Comment: https://git.openjdk.org/jdk/pull/16033#issuecomment-1804251322 From erikj at openjdk.org Thu Nov 9 17:49:00 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Thu, 9 Nov 2023 17:49:00 GMT Subject: RFR: JDK-8317799 : AIX PPC64: FFI symbol lookup doesn't find symbols In-Reply-To: References: Message-ID: On Mon, 30 Oct 2023 10:54:48 GMT, suchismith1993 wrote: > 1. Adding required compiler flags. > 2. Adding required symbols. > > JBS-ISSUE : [JDK-8317799](https://bugs.openjdk.org/browse/JDK-8317799) > Problem: There is syslookup file which expects the required symbols to be exported using the compiler flags, that are mentioned in the Lib.gmk file. The math library in AIX specifically, is a static archive. Doing a -lm wont suffice, because when the symbols are looked up using dlsym or accessing native code through Java, it will lead to failures. Hence we had to come up with a list of symbols to allow math library symbols to be accesible. Also, there are parts of libc library that are static too, and hence those symbols also are present in this list. Without this change, the StdLibTest and multiple other tests which make native function calls using FFI, fail with NoSuchElementException. > For some context: `java.lang.foreign.Linker.nativeLinker().defaultLookup()` returns a `SymbolLookup` that can be used to find symbols from the standard library. > > We use a shim library that re-exports symbols from the standard library in order to make them accessible through `dlsym`, since on e.g. Linux the standard library .so files might actually be linker scripts which we don't want to mess with. On Windows we use ucrtbase.dll + an auxiliary library that contains the expansions of several 'inline' functions such as `printf`. I'm not surprised to see that another platform like AIX requires more to make this work as well. > > That said, I think we should limit the exported symbols to only those found in the standard C library header files: https://en.cppreference.com/w/c/header Could the list of symbols be dynamically extracted at build time in some way or is the set stable enough to basically never change? ------------- PR Comment: https://git.openjdk.org/jdk/pull/16414#issuecomment-1804283653 From naoto at openjdk.org Thu Nov 9 17:56:10 2023 From: naoto at openjdk.org (Naoto Sato) Date: Thu, 9 Nov 2023 17:56:10 GMT Subject: RFR: 8319640: ClassicFormat::parseObject (from DateTimeFormatter) does not conform to the javadoc and may leak DateTimeException Message-ID: Fixing the `Format::parseObject(String, ParsePosition)` implementation in `DateTimeFormatter` class, to not throw `DateTimeException` but to return null. ------------- Commit messages: - initial commit Changes: https://git.openjdk.org/jdk/pull/16586/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16586&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8319640 Stats: 39 lines in 2 files changed: 24 ins; 8 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/16586.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16586/head:pull/16586 PR: https://git.openjdk.org/jdk/pull/16586 From ihse at openjdk.org Thu Nov 9 18:00:57 2023 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Thu, 9 Nov 2023 18:00:57 GMT Subject: RFR: 8319761: Simplify fields of Array VarHandles In-Reply-To: References: Message-ID: <9pwg5eUxgydLmPtYG6Y2Fs7X2zRwZWJIYM9S3f2DOBk=.3e2ef2ba-583c-4713-b88d-5e9618996078@github.com> On Sun, 24 Sep 2023 13:17:05 GMT, Chen Liang wrote: > 1. Primitive array VHs are now singletons and no longer need to record their array base and offset in their object themselves. > 2. Moved Unsafe offset calculation to a utility method, like `index` in VarHandleByteArrayView. Build changes look good. ------------- Marked as reviewed by ihse (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15894#pullrequestreview-1723191512 From duke at openjdk.org Thu Nov 9 18:15:07 2023 From: duke at openjdk.org (Srinivas Vamsi Parasa) Date: Thu, 9 Nov 2023 18:15:07 GMT Subject: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort) [v9] In-Reply-To: <5SwozIlMyFDx9yzlGOWnjNgYp2Jciix5B3ViuA68fjY=.1f7e374f-8321-4641-a566-59c4bd378274@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> <5SwozIlMyFDx9yzlGOWnjNgYp2Jciix5B3ViuA68fjY=.1f7e374f-8321-4641-a566-59c4bd378274@github.com> Message-ID: On Fri, 27 Oct 2023 13:26:33 GMT, Vladimir Yaroslavskiy wrote: >>> Hi Paul (@PaulSandoz), Alan (@AlanBateman), Any update? Do you agree with Radix sort in parallel case only? >> >> I think its definitely a better fit, but another aspect of my previous comment was wondering if we need a radix sort if the vectorized quicksort implementation is fast enough. IMO we need to compare performance results with the vectorized quick sort, and be aware of future enhancements to that. > > Hello @PaulSandoz and @AlanBateman ! > > Did you have time to look at the latest benchmarking? Hello Vladimir (@iaroslavski) Will provide the performance data using AVX512 sort as baseline by early next week. (Friday is a holiday for us due to Veterans Day) Thanks, Vamsi ------------- PR Comment: https://git.openjdk.org/jdk/pull/13568#issuecomment-1804319922 From mcimadamore at openjdk.org Thu Nov 9 18:20:11 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Thu, 9 Nov 2023 18:20:11 GMT Subject: RFR: 8254693: Add Panama feature to pass heap segments to native code [v12] In-Reply-To: References: Message-ID: On Thu, 9 Nov 2023 15:34:38 GMT, Jorn Vernee wrote: >> src/java.base/share/classes/java/lang/foreign/Linker.java line 792: >> >>> 790: * @param allowHeapAccess whether the linked function should allow access to the Java heap. >>> 791: */ >>> 792: static Option critical(boolean allowHeapAccess) { >> >> Speaking of public API, I'm surprised to see critical function property conflated with ability to perform on-heap accesses. These aspects look orthogonal to me. Any particular reason not to represent them as 2 separate `Option`s? >> >> Even though it's straightforward to support on-heap accesses during critical function calls, object pinning would support that for non-critical function calls as well, but proposed API doesn't cover it and new API will be required. What's the plan here? > >> Even though it's straightforward to support on-heap accesses during critical function calls, object pinning would support that for non-critical function calls as well, but proposed API doesn't cover it and new API will be required. What's the plan here? > > The issue is that most GCs don't support object pinning. I don't think we want an API that only works for some GCs. But, if we do, there's a better API that we can have for just pinning support, which is a `MemorySegment::pin(Arena)` method that returns a MemorySegment wrapping the pinned array. That would allow doing multiple native calls with just a single pin operation, and also allows embedding pointers to pinned segments in other data structures. > > For the current approach where we make the array accessible for the duration of the native call: without pinning support, other GCs would have to use GCLocker. That means that the native call also has to be relatively short-lived, at which point I figured we might as well drop the thread state transition, since that has the same requirement. I.e. we detect that the call is short-lived, and do the optimization ourselves without the hint from the user (`critical`). This coincidentally also greatly simplifies the implementation. In a prior iteration I did have a separate `allowHeap` `Option` that implied `critical`. But it was suggested to just merge the two together in that case. I stand by the current design: a GCLocker-based mechanism (as the current implementation is) needs to have similar restrictions both on-heap access and also removal of state transitions. It's true that a more general notion of pinning is possible, which doesn't necessarily require special support from the linker (because we can turn an heap segment into a native segment by pinning it and _then_ pass that to the linker). But at this point in this support for region-based pinning is not mature enough to justify such an API (and, if we'll ever get to that point, that would not invalidate the critical linker options). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16201#discussion_r1388411265 From rriggs at openjdk.org Thu Nov 9 18:21:00 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 9 Nov 2023 18:21:00 GMT Subject: RFR: 8319753: Duration javadoc has "period" instead of "duration" in several places In-Reply-To: References: Message-ID: On Wed, 8 Nov 2023 21:58:47 GMT, Eamonn McManus wrote: > This change simply replaces "period" with "duration", or in one case replaces "period unit" with just "unit". The changes look ok. A CSR will be needed so the TCK can be advised and stay in sync. ------------- PR Review: https://git.openjdk.org/jdk/pull/16573#pullrequestreview-1723229033 From duke at openjdk.org Thu Nov 9 18:31:05 2023 From: duke at openjdk.org (Vladimir Yaroslavskiy) Date: Thu, 9 Nov 2023 18:31:05 GMT Subject: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort) [v9] In-Reply-To: <5SwozIlMyFDx9yzlGOWnjNgYp2Jciix5B3ViuA68fjY=.1f7e374f-8321-4641-a566-59c4bd378274@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> <5SwozIlMyFDx9yzlGOWnjNgYp2Jciix5B3ViuA68fjY=.1f7e374f-8321-4641-a566-59c4bd378274@github.com> Message-ID: <_Cq1CAvZbEuSBSoPvxe_rVqufzu9KK_OvsqBBNZhFqs=.62c7ec92-7042-4171-9304-1c294bab100b@github.com> On Fri, 27 Oct 2023 13:26:33 GMT, Vladimir Yaroslavskiy wrote: >>> Hi Paul (@PaulSandoz), Alan (@AlanBateman), Any update? Do you agree with Radix sort in parallel case only? >> >> I think its definitely a better fit, but another aspect of my previous comment was wondering if we need a radix sort if the vectorized quicksort implementation is fast enough. IMO we need to compare performance results with the vectorized quick sort, and be aware of future enhancements to that. > > Hello @PaulSandoz and @AlanBateman ! > > Did you have time to look at the latest benchmarking? > Hello Vladimir (@iaroslavski) > > Will provide the performance data using AVX512 sort as baseline by early next week. (Friday is a holiday for us due to Veterans Day) > > Thanks, Vamsi Nice, Vamsi! Classes for benchmarking: https://github.com/iaroslavski/sorting/blob/master/radixsort/ArraysSort.java https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_RadixForParallel.java https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_RadixForAll.java ------------- PR Comment: https://git.openjdk.org/jdk/pull/13568#issuecomment-1804341408 From rriggs at openjdk.org Thu Nov 9 18:38:56 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 9 Nov 2023 18:38:56 GMT Subject: RFR: 8319640: ClassicFormat::parseObject (from DateTimeFormatter) does not conform to the javadoc and may leak DateTimeException In-Reply-To: References: Message-ID: On Thu, 9 Nov 2023 17:44:44 GMT, Naoto Sato wrote: > Fixing the `Format::parseObject(String, ParsePosition)` implementation in `DateTimeFormatter` class, to not throw `DateTimeException` but to return null. Looks good. ------------- Marked as reviewed by rriggs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16586#pullrequestreview-1723260458 From jbhateja at openjdk.org Thu Nov 9 18:56:19 2023 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Thu, 9 Nov 2023 18:56:19 GMT Subject: RFR: 8318650: Optimized subword gather for x86 targets. [v5] In-Reply-To: References: Message-ID: <7ekeGE9WoNdcaJESiuV-hApOZVN6whi7EEGRjlEISdA=.5e31e7a5-dd58-4668-8db6-f39acf8d893c@github.com> > Hi All, > > This patch optimizes sub-word gather operation for x86 targets with AVX2 and AVX512 features. > > Following is the summary of changes:- > > 1) Intrinsify sub-word gather with high performance backend implementation based on hybrid algorithm which initially partially unrolls scalar loop to accumulates values from gather indices into a quadword(64bit) slice followed by vector permutation to place the slice into appropriate vector lanes, it prevents code bloating and generates compact > JIT sequence. This coupled with savings from expansive array allocation in existing java implementation translates into significant performance of 1.3-5x gains with included micro. > > > ![image](https://github.com/openjdk/jdk/assets/59989778/e25ba4ad-6a61-42fa-9566-452f741a9c6d) > > > 2) Patch was also compared against modified java fallback implementation by replacing temporary array allocation with zero initialized vector and a scalar loops which inserts gathered values into vector. But, vector insert operation in higher vector lanes is a three step process which first extracts the upper vector 128 bit lane, updates it with gather subword value and then inserts the lane back to its original position. This makes inserts into higher order lanes costly w.r.t to proposed solution. In addition generated JIT code for modified fallback implementation was very bulky. This may impact in-lining decisions into caller contexts. > > 3) Some minor adjustments in existing gather instruction pattens for double/quad words. > > > Kindly review and share your feedback. > > > Best Regards, > Jatin Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: Review comments resolutions. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16354/files - new: https://git.openjdk.org/jdk/pull/16354/files/67a60cd8..c58a5283 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16354&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16354&range=03-04 Stats: 16 lines in 3 files changed: 4 ins; 11 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/16354.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16354/head:pull/16354 PR: https://git.openjdk.org/jdk/pull/16354 From iris at openjdk.org Thu Nov 9 18:57:01 2023 From: iris at openjdk.org (Iris Clark) Date: Thu, 9 Nov 2023 18:57:01 GMT Subject: RFR: 8319640: ClassicFormat::parseObject (from DateTimeFormatter) does not conform to the javadoc and may leak DateTimeException In-Reply-To: References: Message-ID: On Thu, 9 Nov 2023 17:44:44 GMT, Naoto Sato wrote: > Fixing the `Format::parseObject(String, ParsePosition)` implementation in `DateTimeFormatter` class, to not throw `DateTimeException` but to return null. Marked as reviewed by iris (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/16586#pullrequestreview-1723287749 From kdriver at openjdk.org Thu Nov 9 20:47:02 2023 From: kdriver at openjdk.org (Kevin Driver) Date: Thu, 9 Nov 2023 20:47:02 GMT Subject: RFR: JDK-8319122: Improve documentation of various Zip-file related APIs In-Reply-To: <8vEqyECjMkTfesVmL3X0dN4Yu8JShPiUdsKpmEz1WV0=.1b541f77-a05f-490b-aaf1-f6b7456c6d77@github.com> References: <8vEqyECjMkTfesVmL3X0dN4Yu8JShPiUdsKpmEz1WV0=.1b541f77-a05f-490b-aaf1-f6b7456c6d77@github.com> Message-ID: On Mon, 30 Oct 2023 17:26:53 GMT, Yakov Shafranovich wrote: > The various Zip/Jar-file related Java APIs have some long-standing differences or peculiarities with respect to the ZIP-file specification or compared to other implementations which should be documented in the API-doc. This documents the following: > - Cache of JAR files in JarURLConnection class > - Cache of JAR/ZIP files in JarFile and ZipFile classes > - Unexpected behavior when parsing ZIP files with duplicate entries in JarFile and ZipFile classes, as well as the zipfs provider > - Directories and filenames with the same name considered to be the same in ZipFile class > - Possible issues when local and central headers conflict in ZipInputStream class > > Related JBS report: > https://bugs.openjdk.org/browse/JDK-8319122 Marked as reviewed by kdriver (Committer). src/java.base/share/classes/java/net/JarURLConnection.java line 129: > 127: * JAR files retrieved by this class might get cached for performance reasons which can result > 128: * in unexpected behavior if the JAR files are modified while being read using this class. > 129: * If such behavior is undesirable, please use the {@link URLConnection#setUseCaches(boolean)} method to disable caching. consider a manual line wrap here, or is this ~80 chars? src/java.base/share/classes/java/util/zip/ZipFile.java line 104: > 102: * being returned due to internal caching. > 103: * > 104: * Additionally, for compatibility with earlier versions of the JDK, files and directories with the same name (such as "foobar" and "foobar/") consider a manual line wrap in these as well, or is this ~80 chars? src/jdk.zipfs/share/classes/module-info.java line 303: > 301: * may occur such as metadata or content from the later entry being returned due to internal caching. > 302: * > 303: * Additionally, for compatibility with earlier versions of the JDK, files and directories with the same name (such as "foobar" and "foobar/") consider a manual line wrap in these as well, or is this ~80 chars? ------------- PR Review: https://git.openjdk.org/jdk/pull/16424#pullrequestreview-1723465685 PR Review Comment: https://git.openjdk.org/jdk/pull/16424#discussion_r1388560373 PR Review Comment: https://git.openjdk.org/jdk/pull/16424#discussion_r1388561727 PR Review Comment: https://git.openjdk.org/jdk/pull/16424#discussion_r1388562238 From vklang at openjdk.org Thu Nov 9 21:08:10 2023 From: vklang at openjdk.org (Viktor Klang) Date: Thu, 9 Nov 2023 21:08:10 GMT Subject: RFR: JDK-8319123 : Implementation of JEP-461: Stream Gatherers (Preview) [v2] In-Reply-To: References: Message-ID: On Thu, 9 Nov 2023 14:26:40 GMT, Alan Bateman wrote: >> Viktor Klang has updated the pull request incrementally with two additional commits since the last revision: >> >> - Addressing review feedback >> - Make Gatherer.andThen take a wildcard for the rhs Gatherer state type > > src/java.base/share/classes/java/util/stream/Gatherers.java line 543: > >> 541: * @throws NullPointerException if any of the parameters are null >> 542: */ >> 543: public static Gatherer scan( > > The examples (as code snippets) in the windowXXX and fold methods are great. It might help to add one to scan too as some readers might not know what prefix scan is, or they wonder if this is scan left or right. Yeah, that's fair. I'll see if I can add something palatable. ? > src/java.base/share/classes/java/util/stream/Stream.java line 1093: > >> 1091: * >> 1092: * @implNote Implementations of this interface should provide their own >> 1093: * implementation of this method. > > I think the sentence goes in the implSpec as it tells implementers that they must override this method. > > The `@see Gatherer` it probably not needed as the method already links to Gatherer. Ok, will make that change! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1388581857 PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1388582664 From vklang at openjdk.org Thu Nov 9 21:18:12 2023 From: vklang at openjdk.org (Viktor Klang) Date: Thu, 9 Nov 2023 21:18:12 GMT Subject: RFR: JDK-8319123 : Implementation of JEP-461: Stream Gatherers (Preview) [v2] In-Reply-To: References: Message-ID: On Thu, 9 Nov 2023 07:57:27 GMT, Per Minborg wrote: >> src/java.base/share/classes/java/util/stream/Gatherer.java line 216: >> >>> 214: >>> 215: /** >>> 216: * A function which accepts two intermediate states and combines them into >> >> We could use a {@return ..} here. There might be other places too where we could do that. > > Nit: I suggest using "A function that" rather than "A function which". One peculiarity with the English language is the distinction between "that" (to be used in a restrictive clause) and "which" (to be used in a non-restrictive clause). Here is a reference: https://preply.com/en/blog/when-to-use-which-or-that-the-most-common-cases > > This comment also applies to documentation elsewhere. Sounds like it is something which ought to be done wholesale rather than on a point-basis. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1388589158 From vklang at openjdk.org Thu Nov 9 21:18:16 2023 From: vklang at openjdk.org (Viktor Klang) Date: Thu, 9 Nov 2023 21:18:16 GMT Subject: RFR: JDK-8319123 : Implementation of JEP-461: Stream Gatherers (Preview) [v2] In-Reply-To: References: Message-ID: On Thu, 9 Nov 2023 08:01:28 GMT, Per Minborg wrote: >> Viktor Klang has updated the pull request incrementally with two additional commits since the last revision: >> >> - Addressing review feedback >> - Make Gatherer.andThen take a wildcard for the rhs Gatherer state type > > src/java.base/share/classes/java/util/stream/Gatherer.java line 245: > >> 243: >> 244: /** >> 245: * Returns a composed Gatherer which connects the output of this Gatherer > > Generally, it would if we could harmonize and consolidate return clauses using {@return ...} Yeah, not in this PR tho :) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1388588485 From vklang at openjdk.org Thu Nov 9 21:18:16 2023 From: vklang at openjdk.org (Viktor Klang) Date: Thu, 9 Nov 2023 21:18:16 GMT Subject: RFR: JDK-8319123 : Implementation of JEP-461: Stream Gatherers (Preview) [v2] In-Reply-To: References: Message-ID: On Thu, 9 Nov 2023 12:37:30 GMT, Per Minborg wrote: >> Which parameters? The type parameters or the method parameters? > > Here is an example: > > > static Collector of(Supplier supplier, > BiConsumer accumulator, > BinaryOperator combiner, > Function finisher, > Characteristics... characteristics) { I'd love to, but if I want to keep horizontal space manageable I'll have to break somewhere.. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1388588129 From vklang at openjdk.org Thu Nov 9 21:18:20 2023 From: vklang at openjdk.org (Viktor Klang) Date: Thu, 9 Nov 2023 21:18:20 GMT Subject: RFR: JDK-8319123 : Implementation of JEP-461: Stream Gatherers (Preview) [v2] In-Reply-To: References: Message-ID: On Wed, 8 Nov 2023 17:36:42 GMT, R?mi Forax wrote: >> Viktor Klang has updated the pull request incrementally with two additional commits since the last revision: >> >> - Addressing review feedback >> - Make Gatherer.andThen take a wildcard for the rhs Gatherer state type > > src/java.base/share/classes/java/util/stream/GathererOp.java line 99: > >> 97: >> 98: public NodeBuilder join(NodeBuilder that) { >> 99: if (isEmpty()) > > Please add curly braces around if and if/else That's not the code style in most of the reference implementation of Stream, so I tried to keep it as harmonized with the rest as possible when not warranted by performance. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1388590401 From vklang at openjdk.org Thu Nov 9 21:18:21 2023 From: vklang at openjdk.org (Viktor Klang) Date: Thu, 9 Nov 2023 21:18:21 GMT Subject: RFR: JDK-8319123 : Implementation of JEP-461: Stream Gatherers (Preview) [v2] In-Reply-To: References: Message-ID: On Thu, 9 Nov 2023 14:21:55 GMT, Alan Bateman wrote: >> You mean "Returns a Gatherer which gathers elements into ..." ? > > Is "window" defined anywhere? If you are doing another pass over the docs then the windowXXX methods could be expanded a bit to explain this grouping concept. Also it could say that the last windows (if it exists, the empty stream is the corner case) has at least one element. @AlanBateman Good point. I may have assumed too much. Perhaps something along the lines of: "Returns a Gatherer which gathers elements into windows -- encounter-ordered groups of elements -- ?" ? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1388586922 From vklang at openjdk.org Thu Nov 9 21:18:24 2023 From: vklang at openjdk.org (Viktor Klang) Date: Thu, 9 Nov 2023 21:18:24 GMT Subject: RFR: JDK-8319123 : Implementation of JEP-461: Stream Gatherers (Preview) [v2] In-Reply-To: References: Message-ID: On Thu, 9 Nov 2023 14:41:10 GMT, Alan Bateman wrote: >> Viktor Klang has updated the pull request incrementally with two additional commits since the last revision: >> >> - Addressing review feedback >> - Make Gatherer.andThen take a wildcard for the rhs Gatherer state type > > src/java.base/share/classes/java/util/stream/Gatherers.java line 562: > >> 560: /** >> 561: * An operation which executes operations concurrently >> 562: * with a fixed window of max concurrency, using VirtualThreads. > > Of the 5, this is the one that I'm not sure about so will be interesting to see if there is feedback from real world usage. > > "VirtualThreads" isn't a class so maybe replace it with "virtual Threads", linked to Thread.html#virtual-threads. Sounds good. Wilco > src/java.base/share/classes/java/util/stream/Gatherers.java line 615: > >> 613: assert wasAddedToWindow; >> 614: >> 615: Thread.startVirtualThread(task); > > At some point it might be worth seeing this should should use Executors.newVirtualThreadPerTaskExecutor(), that would at least simplify the cleanup as it would be executor.shutdownNow. The serviceability benefit would be that an observer on a far hill taking a thread dump would have the virtual threads grouped for each mapConcurrent gatherer. Yeah, that's a good point. I'll try that after this PR. ? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1388591370 PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1388591204 From jlu at openjdk.org Thu Nov 9 22:05:15 2023 From: jlu at openjdk.org (Justin Lu) Date: Thu, 9 Nov 2023 22:05:15 GMT Subject: RFR: JDK-8318189: ChoiceFormat::format throws undocumented AIOOBE Message-ID: Please review this PR which makes an `ArrayIndexOutOfBoundsException` apparent in ChoiceFormat::format. An _incomplete_ ChoiceFormat can be created, which is not revealed until format is invoked. ------------- Commit messages: - init Changes: https://git.openjdk.org/jdk/pull/16587/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16587&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8318189 Stats: 13 lines in 1 file changed: 11 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/16587.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16587/head:pull/16587 PR: https://git.openjdk.org/jdk/pull/16587 From sviswanathan at openjdk.org Thu Nov 9 22:26:04 2023 From: sviswanathan at openjdk.org (Sandhya Viswanathan) Date: Thu, 9 Nov 2023 22:26:04 GMT Subject: RFR: 8319572: Test jdk/incubator/vector/LoadJsvmlTest.java ignores VM flags Message-ID: Test jdk/incubator/vector/LoadJsvmlTest.java ignores VM flags and thus marked as flagless through @requires vm.flagless per [JDK-8319566](https://bugs.openjdk.org/browse/JDK-8319566). ------------- Commit messages: - Mark LoadJsvmlTest.java test as flagless Changes: https://git.openjdk.org/jdk/pull/16589/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16589&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8319572 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/16589.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16589/head:pull/16589 PR: https://git.openjdk.org/jdk/pull/16589 From rriggs at openjdk.org Thu Nov 9 22:28:58 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 9 Nov 2023 22:28:58 GMT Subject: RFR: 8311906: Improve robustness of String constructors with mutable array inputs [v2] In-Reply-To: References: <6SKlGLh5MmxoEx07wHCCUc8KWbbhcspLJmcc1uxQ_FI=.ca33bfb4-fa5c-45f0-b49f-ee6c5c6b68b4@github.com> Message-ID: On Thu, 9 Nov 2023 04:16:25 GMT, Roger Riggs wrote: >> Strings, after construction, are immutable but may be constructed from mutable arrays of bytes, characters, or integers. >> The string constructors should guard against the effects of mutating the arrays during construction that might invalidate internal invariants for the correct behavior of operations on the resulting strings. In particular, a number of operations have optimizations for operations on pairs of latin1 strings and pairs of non-latin1 strings, while operations between latin1 and non-latin1 strings use a more general implementation. >> >> The changes include: >> >> - Adding a warning to each constructor with an array as an argument to indicate that the results are indeterminate >> if the input array is modified before the constructor returns. >> The resulting string may contain any combination of characters sampled from the input array. >> >> - Ensure that strings that are represented as non-latin1 contain at least one non-latin1 character. >> For latin1 inputs, whether the arrays contain ASCII, ISO-8859-1, UTF8, or another encoding decoded to latin1 the scanning and compression is unchanged. >> If a non-latin1 character is found, the string is represented as non-latin1 with the added verification that a non-latin1 character is present at the same index. >> If that character is found to be latin1, then the input array has been modified and the result of the scan may be incorrect. >> Though a ConcurrentModificationException could be thrown, the risk to an existing application of an unexpected exception should be avoided. >> Instead, the non-latin1 copy of the input is re-scanned and compressed; that scan determines whether the latin1 or the non-latin1 representation is returned. >> >> - The methods that scan for non-latin1 characters and their intrinsic implementations are updated to return the index of the non-latin1 character. >> >> - String construction from StringBuilder and CharSequence must also be guarded as their contents may be modified during construction. > > Roger Riggs has updated the pull request incrementally with three additional commits since the last revision: > > - Refactored extractCodePoints to avoid multiple resizes if the array was modified > - Replaced isLatin1 implementation with `getChar(buf, ndx) <= 0xff` > It performs better than the single byte array access by avoiding the bounds check. > - Misc updates for review comments, javadoc cleanup > Extra checking on maximum string lengths when calling toBytes(). Claes Redestad contributed performance improvements ------------- PR Comment: https://git.openjdk.org/jdk/pull/16425#issuecomment-1804780787 From jlu at openjdk.org Thu Nov 9 22:54:56 2023 From: jlu at openjdk.org (Justin Lu) Date: Thu, 9 Nov 2023 22:54:56 GMT Subject: RFR: 8319640: ClassicFormat::parseObject (from DateTimeFormatter) does not conform to the javadoc and may leak DateTimeException In-Reply-To: References: Message-ID: On Thu, 9 Nov 2023 17:44:44 GMT, Naoto Sato wrote: > Fixing the `Format::parseObject(String, ParsePosition)` implementation in `DateTimeFormatter` class, to not throw `DateTimeException` but to return null. LGTM ------------- Marked as reviewed by jlu (Committer). PR Review: https://git.openjdk.org/jdk/pull/16586#pullrequestreview-1723639587 From stuart.marks at oracle.com Fri Nov 10 00:02:56 2023 From: stuart.marks at oracle.com (Stuart Marks) Date: Thu, 9 Nov 2023 16:02:56 -0800 Subject: Provide thread-safe and concurrent sequenced collections with insertion order? In-Reply-To: References: Message-ID: <99886935-1446-967d-8382-1793470ce88b@oracle.com> Hi Sebastian, Regarding the lack of "synchronized" wrappers for Sequenced Collections: the main issue is that they provide only a limited sense of "thread safety" and as such don't add much actual value. Specifically, the synchronized wrappers hold a lock only around invocations of individual methods. This omits a large class of common, compound operations on collections, such as check-then-act operations and bulk operations that involve iteration or streaming. These operations aren't thread-safe with synchronized wrappers. To perform these operations safely from multiple threads, the client needs to do its own locking around the compound operation. This mostly defeats the purpose of the synchronized wrappers. If you need to use something like LinkedHashMap/LinkedHashSet from multiple threads, my recommendation is to write your own class that exposes exactly the set of operations you need and that does proper locking for those operations. It can then delegate the appropriate operations to an internal collection. Regarding concurrent collections: these are mainly intended for operations to proceed concurrently on different parts of the collection, such as updating different mappings in a ConcurrentHashMap simultaneously, or having producers/consumers operating on different ends of a Queue. I note that historically, the concurrent collections haven't included concurrent versions of LinkedHashSet/Map or general-purpose List implementations. (There is CopyOnWriteArrayList/Set, but they're highly specialized and can be prohibitively expensive for use cases that involve a lot of updates.) While it looks like things are missing from the concurrent collections, I'd have to ask what use cases would be satisfied by adding something like a "concurrent sequenced set" (or map) that wouldn't be fulfilled with a customized wrapper around LinkedHashSet/Map. s'marks On 11/2/23 4:56 AM, Sebastian Fischer wrote: > Hello. > > I am new to this list so might have missed previous discussion about this but > could not find what I was looking for in the archives. > > The Sequenced collections JEP adds the following static methods to > java.util.Collections. > > - unmodifiableSequencedCollection > - unmodifiableSequencedSet > - unmodifiableSequencedMap > > However, the set of static methods returning thread-safe versions of their > arguments (like synchronizedCollection, synchronizedSet, and synchronizedMap) has > not been extended. > > As a consequence, I don't see a straightforward way to create thread-safe > sequenced sets or maps where encounter-order corresponds to insertion order (like > LinkedHashSet or LinkedHashMap) and access them as SequencedSet or SequencedMap. > > When using the available methods mentioned above, the result is not a sequenced type. > > For predefined sets and maps where encounter order corresponds to natural order, > there are the following methods in java.util.Collections. > > - synchronizedNavigableSet > - synchronizedNavigableMap > - synchronizedSortedSet > - synchronizedSortedMap > > However, these methods cannot be used with LinkedHashSet or LinkedHashMap. > > The following methods would be useful in order to create thread-safe sequenced > collections where encounter order is insertion order, but they are currently not > provided. > > - synchronizedSequencedCollection > - synchronizedSequencedSet > - synchronizedSequencedMap > > What are the reasons for or against adding these methods? > > There are also no implementations of concurrent sequenced sets and maps where > encounter order is insertion order in java.util.concurrent. All of the provided > concurrent sequenced sets and maps are based on natural order, and consequently do > not support addFirst, and so on. > > Are there plans to add concurrent sequenced collections that support the whole > interface of sequenced collections? > > Kind regards, > Sebastian From naoto at openjdk.org Fri Nov 10 00:08:57 2023 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 10 Nov 2023 00:08:57 GMT Subject: RFR: JDK-8318189: ChoiceFormat::format throws undocumented AIOOBE In-Reply-To: References: Message-ID: On Thu, 9 Nov 2023 21:58:12 GMT, Justin Lu wrote: > Please review this PR which makes an `ArrayIndexOutOfBoundsException` apparent in ChoiceFormat::format. > > An _incomplete_ ChoiceFormat can be created, which is not revealed until format is invoked. Marked as reviewed by naoto (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/16587#pullrequestreview-1723711743 From duke at openjdk.org Fri Nov 10 00:40:28 2023 From: duke at openjdk.org (Steve Dohrmann) Date: Fri, 10 Nov 2023 00:40:28 GMT Subject: RFR: 8310159: Bulk copy with Unsafe::arrayCopy is slower compared to memcpy Message-ID: Below is baseline data collected using a modified version of the java.lang.foreign.xor micro benchmark referenced by @mcimadamore in the bug report. I collected data on an Ubuntu 22.04 laptop with a Tigerlake i7-1185G7, which does support AVX512. Baseline data Benchmark (arrayKind) (sizeKind) Mode Cnt Score Error Units -------------------------------------------------------------------------------------- XorTest.copy ELEMENTS SMALL avgt 30 584737355.767 ? 60414308.540 ns/op XorTest.copy ELEMENTS MEDIUM avgt 30 272248995.683 ? 2924954.498 ns/op XorTest.copy ELEMENTS LARGE avgt 30 1019200210.900 ? 28334453.652 ns/op XorTest.copy REGION SMALL avgt 30 7399944.164 ? 216821.819 ns/op XorTest.copy REGION MEDIUM avgt 30 20591454.558 ? 147398.572 ns/op XorTest.copy REGION LARGE avgt 30 21649266.051 ? 179263.875 ns/op XorTest.copy CRITICAL SMALL avgt 30 51079.357 ? 542.482 ns/op XorTest.copy CRITICAL MEDIUM avgt 30 2496.961 ? 11.375 ns/op XorTest.copy CRITICAL LARGE avgt 30 515.454 ? 5.831 ns/op XorTest.copy FOREIGN SMALL avgt 30 7558432.075 ? 79489.276 ns/op XorTest.copy FOREIGN MEDIUM avgt 30 19730666.341 ? 500505.099 ns/op XorTest.copy FOREIGN LARGE avgt 30 34616758.085 ? 340300.726 ns/op XorTest.xor ELEMENTS SMALL avgt 30 219832692.489 ? 2329417.319 ns/op XorTest.xor ELEMENTS MEDIUM avgt 30 505138197.167 ? 3818334.424 ns/op XorTest.xor ELEMENTS LARGE avgt 30 1189608474.667 ? 5877981.900 ns/op XorTest.xor REGION SMALL avgt 30 64093872.804 ? 599704.491 ns/op XorTest.xor REGION MEDIUM avgt 30 81544576.454 ? 1406342.118 ns/op XorTest.xor REGION LARGE avgt 30 90091424.883 ? 775577.613 ns/op XorTest.xor CRITICAL SMALL avgt 30 57231375.744 ? 438223.342 ns/op XorTest.xor CRITICAL MEDIUM avgt 30 58583884.930 ? 375355.215 ns/op XorTest.xor CRITICAL LARGE avgt 30 60644832.949 ? 588120.738 ns/op XorTest.xor FOREIGN SMALL avgt 30 73868679.405 ? 819965.524 ns/op XorTest.xor FOREIGN MEDIUM avgt 30 88156275.944 ? 1051257.152 ns/op XorTest.xor FOREIGN LARGE avgt 30 123115513.182 ? 1287935.621 ns/op The 'copy' benchmark was added to measure the memory copy components of the 'xor' benchmark, separate from the memory allocation and xor data update components. Profile data for the baseline REGION LARGE case, shows two hotspots covering about 90% of cycles: Baseline REGION LARGE (r231) Function CPU Time Clockticks Instructions Retired CPI Rate -------------------------------------------------------------------------------------------- xor_op 63.7% 18,189,000,000 52,464,000,000 0.347 __memcpy_evex_unaligned_erms 28.5% 7,608,000,000 3,459,000,000 2.199 ``` The baseline FOREIGN LARGE case shows 3 hotspots covering about 90% : Baseline FOREIGN LARGE (r226) Function CPU Time Clockticks Instructions Retired CPI Rate -------------------------------------------------------------------------------------------- xor_op 46.4% 18,345,000,000 52,476,000,000 0.350 jlong_disjoint_arraycopy_avx3 29.3% 11,124,000,000 1,404,000,000 7.923 Copy::fill_to_memory_atomic 15.3% 5,016,000,000 8,010,000,000 0.626 This PR optimizes the jlong_disjoint_arraycopy_avx3 code. The The Copy::fill_to memory_atomic hotspot (which I believe is associated with the benchmark's per-op off-heap buffer allocation) is not optimized here. The av3 array copy code is optimized by increasing the loop granularity from 192 to 256 bytes, adding source address prefetches, and using non-temporal writes with a store fence. The optimized code in only used with copies of greater that a set threshold number of bytes, currently 2.5MB. This is the size at which the optimized code was observed to be faster than the original code. The profile data with optimization is: Optimized FOREIGN LARGE (r277) Function CPU Time Clockticks Instructions Retired CPI Rate -------------------------------------------------------------------------------------------- xor_op 51.2% 18,153,000,000 52,404,000,000 0.346 jlong_disjoint_arraycopy_avx3 22.4% 7,581,000,000 2,364,000,000 3.207 Copy::fill_to_memory_atomic 16.3% 5,316,000,000 7,917,000,000 0.671 The optimization brings the cycles for the mem copy work roughly to parity with the REGION LARGE case. Benchmark data for the optimized case: Optimized data Benchmark (arrayKind) (sizeKind) Mode Cnt Score Error Units XorTest.copy ELEMENTS SMALL avgt 30 551072938.467 ? 4287149.108 ns/op XorTest.copy ELEMENTS MEDIUM avgt 30 272304419.633 ? 2993793.130 ns/op XorTest.copy ELEMENTS LARGE avgt 30 1013925081.233 ? 8590245.238 ns/op XorTest.copy REGION SMALL avgt 30 7472329.003 ? 77394.114 ns/op XorTest.copy REGION MEDIUM avgt 30 19882540.205 ? 349544.602 ns/op XorTest.copy REGION LARGE avgt 30 21185593.636 ? 404369.655 ns/op XorTest.copy CRITICAL SMALL avgt 30 52358.715 ? 1382.355 ns/op XorTest.copy CRITICAL MEDIUM avgt 30 2525.108 ? 22.396 ns/op XorTest.copy CRITICAL LARGE avgt 30 528.865 ? 11.747 ns/op XorTest.copy FOREIGN SMALL avgt 30 7748587.890 ? 67352.844 ns/op XorTest.copy FOREIGN MEDIUM avgt 30 19401977.378 ? 256247.071 ns/op XorTest.copy FOREIGN LARGE avgt 30 21519594.325 ? 124712.980 ns/op XorTest.xor ELEMENTS SMALL avgt 30 221049328.389 ? 2629557.148 ns/op XorTest.xor ELEMENTS MEDIUM avgt 30 503362446.150 ? 3759664.343 ns/op XorTest.xor ELEMENTS LARGE avgt 30 1186563496.067 ? 5135607.671 ns/op XorTest.xor REGION SMALL avgt 30 88402928.083 ? 790941.309 ns/op XorTest.xor REGION MEDIUM avgt 30 80041519.052 ? 597221.491 ns/op XorTest.xor REGION LARGE avgt 30 87706448.917 ? 751350.609 ns/op XorTest.xor CRITICAL SMALL avgt 30 56869387.315 ? 408618.338 ns/op XorTest.xor CRITICAL MEDIUM avgt 30 59041245.745 ? 820141.039 ns/op XorTest.xor CRITICAL LARGE avgt 30 60433672.443 ? 500954.831 ns/op XorTest.xor FOREIGN SMALL avgt 30 72838421.976 ? 410147.170 ns/op XorTest.xor FOREIGN MEDIUM avgt 30 87970109.478 ? 1058857.783 ns/op XorTest.xor FOREIGN LARGE avgt 30 103970690.407 ? 1033001.637 ns/op I am very much looking forward to contributing to OpenJDK! Please review this PR and let me know how it can be improved. ------------- Commit messages: - - fix whitespace issues - - initial commit -- optimize large array cases in StubGenerator::generate_disjoint_copy_avx3_masked Changes: https://git.openjdk.org/jdk/pull/16575/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16575&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8310159 Stats: 597 lines in 11 files changed: 596 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/16575.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16575/head:pull/16575 PR: https://git.openjdk.org/jdk/pull/16575 From duke at openjdk.org Fri Nov 10 00:40:28 2023 From: duke at openjdk.org (Steve Dohrmann) Date: Fri, 10 Nov 2023 00:40:28 GMT Subject: RFR: 8310159: Bulk copy with Unsafe::arrayCopy is slower compared to memcpy In-Reply-To: References: Message-ID: <4zrrORFKPBiswahAH3YnSLSuBKQz_wnTB7VD6yIZL9o=.7a7b643a-5bbf-415a-9039-87c68f87bd6b@github.com> On Wed, 8 Nov 2023 23:23:48 GMT, Steve Dohrmann wrote: > Below is baseline data collected using a modified version of the java.lang.foreign.xor micro benchmark referenced by @mcimadamore in the bug report. I collected data on an Ubuntu 22.04 laptop with a Tigerlake i7-1185G7, which does support AVX512. > > Baseline data > Benchmark (arrayKind) (sizeKind) Mode Cnt Score Error Units > -------------------------------------------------------------------------------------- > XorTest.copy ELEMENTS SMALL avgt 30 584737355.767 ? 60414308.540 ns/op > XorTest.copy ELEMENTS MEDIUM avgt 30 272248995.683 ? 2924954.498 ns/op > XorTest.copy ELEMENTS LARGE avgt 30 1019200210.900 ? 28334453.652 ns/op > XorTest.copy REGION SMALL avgt 30 7399944.164 ? 216821.819 ns/op > XorTest.copy REGION MEDIUM avgt 30 20591454.558 ? 147398.572 ns/op > XorTest.copy REGION LARGE avgt 30 21649266.051 ? 179263.875 ns/op > XorTest.copy CRITICAL SMALL avgt 30 51079.357 ? 542.482 ns/op > XorTest.copy CRITICAL MEDIUM avgt 30 2496.961 ? 11.375 ns/op > XorTest.copy CRITICAL LARGE avgt 30 515.454 ? 5.831 ns/op > XorTest.copy FOREIGN SMALL avgt 30 7558432.075 ? 79489.276 ns/op > XorTest.copy FOREIGN MEDIUM avgt 30 19730666.341 ? 500505.099 ns/op > XorTest.copy FOREIGN LARGE avgt 30 34616758.085 ? 340300.726 ns/op > XorTest.xor ELEMENTS SMALL avgt 30 219832692.489 ? 2329417.319 ns/op > XorTest.xor ELEMENTS MEDIUM avgt 30 505138197.167 ? 3818334.424 ns/op > XorTest.xor ELEMENTS LARGE avgt 30 1189608474.667 ? 5877981.900 ns/op > XorTest.xor REGION SMALL avgt 30 64093872.804 ? 599704.491 ns/op > XorTest.xor REGION MEDIUM avgt 30 81544576.454 ? 1406342.118 ns/op > XorTest.xor REGION LARGE avgt 30 90091424.883 ? 775577.613 ns/op > XorTest.xor CRITICAL SMALL avgt 30 57231375.744 ? 438223.342 ns/op > XorTest.xor CRITICAL MEDIUM avgt 30 58583884.930 ? 375355.215 ns/op > XorTest.xor CRITICAL LARGE avgt 30 60644832.949 ? 588120.738 ns/op > XorTest.xor FOREIGN SMALL avgt 30 73868679.405 ? 819965.524 ns/op > XorTest.xor FOREIGN MEDIUM avgt 30 88156275.944 ? 1051257.152 ns/op > XorTest.xor FOREIGN LARGE avgt 30 123115513... I'm part of the Intel Java team ------------- PR Comment: https://git.openjdk.org/jdk/pull/16575#issuecomment-1802923064 From joehw at openjdk.org Fri Nov 10 01:22:57 2023 From: joehw at openjdk.org (Joe Wang) Date: Fri, 10 Nov 2023 01:22:57 GMT Subject: RFR: 8319640: ClassicFormat::parseObject (from DateTimeFormatter) does not conform to the javadoc and may leak DateTimeException In-Reply-To: References: Message-ID: On Thu, 9 Nov 2023 17:44:44 GMT, Naoto Sato wrote: > Fixing the `Format::parseObject(String, ParsePosition)` implementation in `DateTimeFormatter` class, to not throw `DateTimeException` but to return null. test/jdk/java/time/test/java/time/format/TestDateTimeParsing.java line 260: > 258: .toFormatter(Locale.ROOT) > 259: .toFormat(); > 260: assertEquals(f.parseObject("17-30", new ParsePosition(0)), null); I might have missed it, but this test doesn't seem to exercise the situation where IOOBE would happen. Though the result would be the same as it catches RuntimeException always, I wonder whether an additional test case would be helpful to verify the IOOBE situation, e.g. set the position to be greater than the length. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16586#discussion_r1388762259 From sviswanathan at openjdk.org Fri Nov 10 01:34:01 2023 From: sviswanathan at openjdk.org (Sandhya Viswanathan) Date: Fri, 10 Nov 2023 01:34:01 GMT Subject: RFR: 8318650: Optimized subword gather for x86 targets. [v5] In-Reply-To: <7ekeGE9WoNdcaJESiuV-hApOZVN6whi7EEGRjlEISdA=.5e31e7a5-dd58-4668-8db6-f39acf8d893c@github.com> References: <7ekeGE9WoNdcaJESiuV-hApOZVN6whi7EEGRjlEISdA=.5e31e7a5-dd58-4668-8db6-f39acf8d893c@github.com> Message-ID: On Thu, 9 Nov 2023 18:56:19 GMT, Jatin Bhateja wrote: >> Hi All, >> >> This patch optimizes sub-word gather operation for x86 targets with AVX2 and AVX512 features. >> >> Following is the summary of changes:- >> >> 1) Intrinsify sub-word gather with high performance backend implementation based on hybrid algorithm which initially partially unrolls scalar loop to accumulates values from gather indices into a quadword(64bit) slice followed by vector permutation to place the slice into appropriate vector lanes, it prevents code bloating and generates compact >> JIT sequence. This coupled with savings from expansive array allocation in existing java implementation translates into significant performance of 1.3-5x gains with included micro. >> >> >> ![image](https://github.com/openjdk/jdk/assets/59989778/e25ba4ad-6a61-42fa-9566-452f741a9c6d) >> >> >> 2) Patch was also compared against modified java fallback implementation by replacing temporary array allocation with zero initialized vector and a scalar loops which inserts gathered values into vector. But, vector insert operation in higher vector lanes is a three step process which first extracts the upper vector 128 bit lane, updates it with gather subword value and then inserts the lane back to its original position. This makes inserts into higher order lanes costly w.r.t to proposed solution. In addition generated JIT code for modified fallback implementation was very bulky. This may impact in-lining decisions into caller contexts. >> >> 3) Some minor adjustments in existing gather instruction pattens for double/quad words. >> >> >> Kindly review and share your feedback. >> >> >> Best Regards, >> Jatin > > Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: > > Review comments resolutions. Thanks for considering other review comments. I am still struggling with the review of vgather_subword() method. src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 1621: > 1619: void C2_MacroAssembler::vgather_subword(BasicType elem_ty, XMMRegister dst, Register base, Register idx_base, > 1620: Register offset, Register mask, XMMRegister xtmp1, XMMRegister xtmp2, XMMRegister xtmp3, > 1621: Register rtmp, Register midx, Register length, int vector_len, int vlen_enc) { This function needs stepwise comments for easier review and mainatenance. src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 1629: > 1627: vallones(xtmp2, vlen_enc); > 1628: vpsubd(xtmp2, xtmp1, xtmp2 ,vlen_enc); > 1629: vpslld(xtmp2, xtmp2, 1, vlen_enc); We are basically loading "2" in each int element of xtmp2 here? src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 1648: > 1646: vpermd(xtmp3, xtmp1, xtmp3, vlen_enc == Assembler::AVX_512bit ? vlen_enc : Assembler::AVX_256bit); > 1647: vpsubd(xtmp1, xtmp1, xtmp2, vlen_enc); > 1648: vpor(dst, dst, xtmp3, vlen_enc); xtmp1 starts out as 0, 1,... so vpermd will place the lower 64 bit from xtmp3 to lower 64 bit of dst why vpsubd and not vpaddd? It looks to me that vpaddd is more intutive to understand. if vpadd, xtmp1 will become 2,3 in next iteration so vpermd will place the lower 64 bit from xtmp3 to 127:64 of dst and so on so forth Another point, for avx512 it looks to me that vpermd and vpor could be merged into one single instruction vpermd having dst as destination and merge bit set to true. ------------- PR Review: https://git.openjdk.org/jdk/pull/16354#pullrequestreview-1723774317 PR Review Comment: https://git.openjdk.org/jdk/pull/16354#discussion_r1388760152 PR Review Comment: https://git.openjdk.org/jdk/pull/16354#discussion_r1388760419 PR Review Comment: https://git.openjdk.org/jdk/pull/16354#discussion_r1388766170 From lmesnik at openjdk.org Fri Nov 10 01:49:17 2023 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Fri, 10 Nov 2023 01:49:17 GMT Subject: RFR: 8319200: Don't use test thread factory in ProcessTools.createLimitedTestJavaProcessBuilder() [v5] In-Reply-To: <3damdMQpRBrkUN2S32tBD0Tmrl2tmSqA31NniV8FzHU=.d3a36aa7-d5f4-4a63-b2ff-8b9b616a9637@github.com> References: <3damdMQpRBrkUN2S32tBD0Tmrl2tmSqA31NniV8FzHU=.d3a36aa7-d5f4-4a63-b2ff-8b9b616a9637@github.com> Message-ID: > Test thread factory is a mode similar to VM flags and should not be used in ProcessTools.createLimitedTestJavaProcessBuilder(). Only createTestJavaProcessBuilder() should use it like jtreg VM options. > > Adding the test thread factory requires the injection of arguments in the middle of the list. I don't think it makes sense to modify arguments in several places so I replaced it with the flag isLimited and moved all modifications in createJavaProcessBuilder(). > > Testing tier1-5. Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: variable was renamed. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16442/files - new: https://git.openjdk.org/jdk/pull/16442/files/aa93f71a..bc165dd6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16442&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16442&range=03-04 Stats: 10 lines in 1 file changed: 0 ins; 0 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/16442.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16442/head:pull/16442 PR: https://git.openjdk.org/jdk/pull/16442 From lmesnik at openjdk.org Fri Nov 10 02:19:56 2023 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Fri, 10 Nov 2023 02:19:56 GMT Subject: RFR: 8319200: Don't use test thread factory in ProcessTools.createLimitedTestJavaProcessBuilder() [v5] In-Reply-To: References: <3damdMQpRBrkUN2S32tBD0Tmrl2tmSqA31NniV8FzHU=.d3a36aa7-d5f4-4a63-b2ff-8b9b616a9637@github.com> Message-ID: <2AAk5mCkSkklvI_8dSY85b9Cpik2v_HQsaAuJ-QBrtA=.ad327557-c0f8-41ca-bb71-bb2ea42cd78a@github.com> On Fri, 10 Nov 2023 01:49:17 GMT, Leonid Mesnik wrote: >> Test thread factory is a mode similar to VM flags and should not be used in ProcessTools.createLimitedTestJavaProcessBuilder(). Only createTestJavaProcessBuilder() should use it like jtreg VM options. >> >> Adding the test thread factory requires the injection of arguments in the middle of the list. I don't think it makes sense to modify arguments in several places so I replaced it with the flag isLimited and moved all modifications in createJavaProcessBuilder(). >> >> Testing tier1-5. > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > variable was renamed. The createLimitedTestJavaProcessBuilder is used in 410 tests (hotspot and jdk). 233 of them are flagless and not supposed to be executed with any additional VM flags. (They should be reviewed by it is a separate issue). 177 are not marked as flagless and should be updated to be flagless or use createTestJavaProcessBuilder. The 'createLimitedTestJavaProcessBuilder' method should be used only when the process not accept any flags and it is logical to assume that thread factory shouldn't be used either. I think it just makes consistent the createLimitedTestJavaProcessBuilder and createTestJavaProcessBuilder methods. It was not my original goal to add test thread factory part of createLimitedTestJavaProcessBuilder, I just missed that original createJavaProcessBuilder is applied to all processes. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16442#issuecomment-1804972301 From duke at openjdk.org Fri Nov 10 03:14:22 2023 From: duke at openjdk.org (Shaojin Wen) Date: Fri, 10 Nov 2023 03:14:22 GMT Subject: RFR: 8317742: ISO Standard Date Format implementation consistency on DateTimeFormatter and String.format [v7] In-Reply-To: References: Message-ID: > j.u.Formatter now prints "%tF" (iso standard date) and the result is incorrect when processing year < 0 or year > 9999 Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: fix format 'ja-JP-u-ca-japanese' ChronoLocalDate ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16033/files - new: https://git.openjdk.org/jdk/pull/16033/files/47fc35f1..902ab4ca Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16033&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16033&range=05-06 Stats: 25 lines in 2 files changed: 24 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/16033.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16033/head:pull/16033 PR: https://git.openjdk.org/jdk/pull/16033 From duke at openjdk.org Fri Nov 10 03:31:26 2023 From: duke at openjdk.org (Shaojin Wen) Date: Fri, 10 Nov 2023 03:31:26 GMT Subject: RFR: 8317742: ISO Standard Date Format implementation consistency on DateTimeFormatter and String.format [v8] In-Reply-To: References: Message-ID: > j.u.Formatter now prints "%tF" (iso standard date) and the result is incorrect when processing year < 0 or year > 9999 Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: fix format 'ja-JP-u-ca-japanese' ChronoLocalDate ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16033/files - new: https://git.openjdk.org/jdk/pull/16033/files/902ab4ca..4e518b39 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16033&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16033&range=06-07 Stats: 17 lines in 2 files changed: 15 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/16033.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16033/head:pull/16033 PR: https://git.openjdk.org/jdk/pull/16033 From sviswanathan at openjdk.org Fri Nov 10 03:36:59 2023 From: sviswanathan at openjdk.org (Sandhya Viswanathan) Date: Fri, 10 Nov 2023 03:36:59 GMT Subject: RFR: 8318650: Optimized subword gather for x86 targets. [v5] In-Reply-To: References: <7ekeGE9WoNdcaJESiuV-hApOZVN6whi7EEGRjlEISdA=.5e31e7a5-dd58-4668-8db6-f39acf8d893c@github.com> Message-ID: On Fri, 10 Nov 2023 01:25:49 GMT, Sandhya Viswanathan wrote: >> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: >> >> Review comments resolutions. > > src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 1648: > >> 1646: vpermd(xtmp3, xtmp1, xtmp3, vlen_enc == Assembler::AVX_512bit ? vlen_enc : Assembler::AVX_256bit); >> 1647: vpsubd(xtmp1, xtmp1, xtmp2, vlen_enc); >> 1648: vpor(dst, dst, xtmp3, vlen_enc); > > xtmp1 starts out as 0, 1,... > so vpermd will place the lower 64 bit from xtmp3 to lower 64 bit of dst > why vpsubd and not vpaddd? It looks to me that vpaddd is more intutive to understand. > if vpadd, xtmp1 will become 2,3 in next iteration > so vpermd will place the lower 64 bit from xtmp3 to 127:64 of dst > and so on so forth > > Another point, for avx512 it looks to me that vpermd and vpor could be merged into one single instruction vpermd having dst as destination and merge bit set to true. Please ignore the last bit about avx512 vpermd merge as we are not using mask registers here. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16354#discussion_r1388837311 From gcao at openjdk.org Fri Nov 10 04:23:58 2023 From: gcao at openjdk.org (Gui Cao) Date: Fri, 10 Nov 2023 04:23:58 GMT Subject: RFR: 8311906: Improve robustness of String constructors with mutable array inputs [v2] In-Reply-To: References: <6SKlGLh5MmxoEx07wHCCUc8KWbbhcspLJmcc1uxQ_FI=.ca33bfb4-fa5c-45f0-b49f-ee6c5c6b68b4@github.com> Message-ID: <1qOoa9SlbVqiyZNIhT4L3gq3R9YIjrxXpDsFYz8LoUw=.3a72fff6-6216-456f-a999-6fe01c71d179@github.com> On Thu, 9 Nov 2023 04:16:25 GMT, Roger Riggs wrote: >> Strings, after construction, are immutable but may be constructed from mutable arrays of bytes, characters, or integers. >> The string constructors should guard against the effects of mutating the arrays during construction that might invalidate internal invariants for the correct behavior of operations on the resulting strings. In particular, a number of operations have optimizations for operations on pairs of latin1 strings and pairs of non-latin1 strings, while operations between latin1 and non-latin1 strings use a more general implementation. >> >> The changes include: >> >> - Adding a warning to each constructor with an array as an argument to indicate that the results are indeterminate >> if the input array is modified before the constructor returns. >> The resulting string may contain any combination of characters sampled from the input array. >> >> - Ensure that strings that are represented as non-latin1 contain at least one non-latin1 character. >> For latin1 inputs, whether the arrays contain ASCII, ISO-8859-1, UTF8, or another encoding decoded to latin1 the scanning and compression is unchanged. >> If a non-latin1 character is found, the string is represented as non-latin1 with the added verification that a non-latin1 character is present at the same index. >> If that character is found to be latin1, then the input array has been modified and the result of the scan may be incorrect. >> Though a ConcurrentModificationException could be thrown, the risk to an existing application of an unexpected exception should be avoided. >> Instead, the non-latin1 copy of the input is re-scanned and compressed; that scan determines whether the latin1 or the non-latin1 representation is returned. >> >> - The methods that scan for non-latin1 characters and their intrinsic implementations are updated to return the index of the non-latin1 character. >> >> - String construction from StringBuilder and CharSequence must also be guarded as their contents may be modified during construction. > > Roger Riggs has updated the pull request incrementally with three additional commits since the last revision: > > - Refactored extractCodePoints to avoid multiple resizes if the array was modified > - Replaced isLatin1 implementation with `getChar(buf, ndx) <= 0xff` > It performs better than the single byte array access by avoiding the bounds check. > - Misc updates for review comments, javadoc cleanup > Extra checking on maximum string lengths when calling toBytes(). Hi, I have performed tier1-3 test on linux-riscv64 using QEMU with -XX:+UseRVV. Result looks good. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16425#issuecomment-1805063605 From dholmes at openjdk.org Fri Nov 10 04:32:59 2023 From: dholmes at openjdk.org (David Holmes) Date: Fri, 10 Nov 2023 04:32:59 GMT Subject: RFR: 8319200: Don't use test thread factory in ProcessTools.createLimitedTestJavaProcessBuilder() [v5] In-Reply-To: References: <3damdMQpRBrkUN2S32tBD0Tmrl2tmSqA31NniV8FzHU=.d3a36aa7-d5f4-4a63-b2ff-8b9b616a9637@github.com> Message-ID: On Fri, 10 Nov 2023 01:49:17 GMT, Leonid Mesnik wrote: >> Test thread factory is a mode similar to VM flags and should not be used in ProcessTools.createLimitedTestJavaProcessBuilder(). Only createTestJavaProcessBuilder() should use it like jtreg VM options. >> >> Adding the test thread factory requires the injection of arguments in the middle of the list. I don't think it makes sense to modify arguments in several places so I replaced it with the flag isLimited and moved all modifications in createJavaProcessBuilder(). >> >> Testing tier1-5. > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > variable was renamed. Okay, sorry, I've misunderstood the nature of this issue. This change has no affect on whether jtreg runs a specific test (or set of tests) using the virtual thread wrapper to launch the test. This only affects code that uses ProcessTools and where the launched JVM would examine the `test.thread.factory` property. How many tests actually look at this property directly in code that is run via ProcessTools? The only tests that appear to look at this property are JDB and JDI tests, where we have a test framework that selects use of virtual threads based on this property. I couldn't find any test that would actually be affected by this. Sorry for the noise. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16442#issuecomment-1805069620 From dholmes at openjdk.org Fri Nov 10 04:44:57 2023 From: dholmes at openjdk.org (David Holmes) Date: Fri, 10 Nov 2023 04:44:57 GMT Subject: RFR: 8319200: Don't use test thread factory in ProcessTools.createLimitedTestJavaProcessBuilder() [v5] In-Reply-To: References: <3damdMQpRBrkUN2S32tBD0Tmrl2tmSqA31NniV8FzHU=.d3a36aa7-d5f4-4a63-b2ff-8b9b616a9637@github.com> Message-ID: <8wapJbtnZDHwUMUTGHUeF8nR51Jbi_fjofhDowyVIU4=.8d911151-87e0-41cc-98e7-73343716c881@github.com> On Fri, 10 Nov 2023 01:49:17 GMT, Leonid Mesnik wrote: >> Test thread factory is a mode similar to VM flags and should not be used in ProcessTools.createLimitedTestJavaProcessBuilder(). Only createTestJavaProcessBuilder() should use it like jtreg VM options. >> >> Adding the test thread factory requires the injection of arguments in the middle of the list. I don't think it makes sense to modify arguments in several places so I replaced it with the flag isLimited and moved all modifications in createJavaProcessBuilder(). >> >> Testing tier1-5. > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > variable was renamed. Uggghhh no I've still misunderstood what this is doing. `addTestThreadFactoryArgs` will create a wrapper to run the specified main class in a virtual thread. So if the test using `createLimitedTestJavaProcessBuilder` was being run in a virtual thread, then the exec'd "app" would be too. Plus it would have the property set. So this is potentially reducing virtual thread test coverage. That said I'm bowing out of this discussion. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16442#issuecomment-1805077951 From jbhateja at openjdk.org Fri Nov 10 04:57:58 2023 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Fri, 10 Nov 2023 04:57:58 GMT Subject: RFR: 8318650: Optimized subword gather for x86 targets. [v5] In-Reply-To: References: <7ekeGE9WoNdcaJESiuV-hApOZVN6whi7EEGRjlEISdA=.5e31e7a5-dd58-4668-8db6-f39acf8d893c@github.com> Message-ID: On Fri, 10 Nov 2023 03:33:51 GMT, Sandhya Viswanathan wrote: >> src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 1648: >> >>> 1646: vpermd(xtmp3, xtmp1, xtmp3, vlen_enc == Assembler::AVX_512bit ? vlen_enc : Assembler::AVX_256bit); >>> 1647: vpsubd(xtmp1, xtmp1, xtmp2, vlen_enc); >>> 1648: vpor(dst, dst, xtmp3, vlen_enc); >> >> xtmp1 starts out as 0, 1,... >> so vpermd will place the lower 64 bit from xtmp3 to lower 64 bit of dst >> why vpsubd and not vpaddd? It looks to me that vpaddd is more intutive to understand. >> if vpadd, xtmp1 will become 2,3 in next iteration >> so vpermd will place the lower 64 bit from xtmp3 to 127:64 of dst >> and so on so forth >> >> Another point, for avx512 it looks to me that vpermd and vpor could be merged into one single instruction vpermd having dst as destination and merge bit set to true. > > Please ignore the last bit about avx512 vpermd merge as we are not using mask registers here. > xtmp1 starts out as 0, 1,... so vpermd will place the lower 64 bit from xtmp3 to lower 64 bit of dst why vpsubd and not vpaddd? It looks to me that vpaddd is more intutive to understand. if vpadd, xtmp1 will become 2,3 in next iteration so vpermd will place the lower 64 bit from xtmp3 to 127:64 of dst and so on so forth > I have taken a different approach here based on progressive subtraction to get permute indices for each iteration. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16354#discussion_r1388901259 From darcy at openjdk.org Fri Nov 10 06:04:01 2023 From: darcy at openjdk.org (Joe Darcy) Date: Fri, 10 Nov 2023 06:04:01 GMT Subject: RFR: 8319174: Enhance robustness of some j.m.BigInteger constructors [v5] In-Reply-To: <8sscQFpSGhptxc9OJVvOAJHkV8U8j-_RmIMg-ZxZz-E=.9b651b5f-a894-45c9-9a59-16332c1cb69c@github.com> References: <0iccBwbAhAmIPGxnz1bhry2Sj_Kz2xngZmb2lPFCUpU=.c2b7c8ef-4e77-4c8f-a7ec-7c5c0980e59e@github.com> <8sscQFpSGhptxc9OJVvOAJHkV8U8j-_RmIMg-ZxZz-E=.9b651b5f-a894-45c9-9a59-16332c1cb69c@github.com> Message-ID: On Fri, 3 Nov 2023 19:14:18 GMT, Raffaello Giulietti wrote: >> Enhance `java.math.BigInteger` constructors taking a `byte[]` argument by improving guarantees of internal invariants. > > Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: > > Changed behavior on len == 0. Looks fine. May want to add some assert to verify the stated pre-conditions hold. ------------- Marked as reviewed by darcy (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16449#pullrequestreview-1724068755 From duke at openjdk.org Fri Nov 10 06:26:14 2023 From: duke at openjdk.org (Shaojin Wen) Date: Fri, 10 Nov 2023 06:26:14 GMT Subject: RFR: 8315585: Optimization for decimal to string [v12] In-Reply-To: <5R25xg0wYYxP2Z-RlM6Fp91A4YPmWjR-b8Fg1bl0sgg=.b3079752-f499-4e4e-af96-7d0d62b3def7@github.com> References: <5R25xg0wYYxP2Z-RlM6Fp91A4YPmWjR-b8Fg1bl0sgg=.b3079752-f499-4e4e-af96-7d0d62b3def7@github.com> Message-ID: > I submitted PR #15555 before, and there were too many changes. I split it into multiple PRs with small changes. This one is one of them. > > this PR removed the duplicate code for getChars in BigDecimal#StringBuilderHelper, i also make performance faster. > Please review and don't hesitate to critique my approach and patch. Shaojin Wen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits: - merge from master - Merge remote-tracking branch 'upstream/master' into optim_decimal_to_string_x1 # Conflicts: # src/java.base/share/classes/java/math/BigDecimal.java - use JLA - update copyright info & comments - reduce duplicate code & code format & refactor benchmark case - Merge remote-tracking branch 'upstream/master' into optim_decimal_to_string_x1 - remove JLA - recipe ("\1.\1\1") - Use StringConcatFactory.makeConcatWithConstants - use % calculate lowInt - ... and 5 more: https://git.openjdk.org/jdk/compare/4e8c0364...2074a0da ------------- Changes: https://git.openjdk.org/jdk/pull/16006/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16006&range=11 Stats: 526 lines in 6 files changed: 271 ins; 163 del; 92 mod Patch: https://git.openjdk.org/jdk/pull/16006.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16006/head:pull/16006 PR: https://git.openjdk.org/jdk/pull/16006 From darcy at openjdk.org Fri Nov 10 06:39:01 2023 From: darcy at openjdk.org (Joe Darcy) Date: Fri, 10 Nov 2023 06:39:01 GMT Subject: RFR: 8180892: Correct handling of annotations on parameters [v2] In-Reply-To: References: Message-ID: On Sun, 8 Oct 2023 17:01:37 GMT, Joe Darcy wrote: >> @liach , thank you for working on this fix. I've given the changes an initial skim, but will need to do a more thorough review before approving or offering suggestions for changes. My top priority for the next few weeks will be JDK 21 CSRs so it may take a while for me to circle back to this PR. > >> @jddarcy Joe, can you take a look at this patch where annotation handling on parameters now uses available `MethodParameters` attribute to match from explicit formal parameter indices to implicit formal parameter indices? > > @liach sorry for the delays. > > I'll be attending to some other matters in the immediate future; please ping me again in a few weeks if I don't reply first. > Hello Joe @jddarcy, is there anything that I need to do to move this patch forward? Should I file a CSR for the behavior change to `getAnnotatedParameterTypes()` and `getParameters()[i].getAnnotatedType()` due to this bugfix, as it now annotates correctly? Hi @liach , sorry for the continued delays. I'm currently working through reviewing a backlog of CSRs for JDK 22. This is (still) on my list to get to. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13664#issuecomment-1805182300 From duke at openjdk.org Fri Nov 10 06:51:17 2023 From: duke at openjdk.org (Shaojin Wen) Date: Fri, 10 Nov 2023 06:51:17 GMT Subject: RFR: 8315585: Optimization for decimal to string [v13] In-Reply-To: <5R25xg0wYYxP2Z-RlM6Fp91A4YPmWjR-b8Fg1bl0sgg=.b3079752-f499-4e4e-af96-7d0d62b3def7@github.com> References: <5R25xg0wYYxP2Z-RlM6Fp91A4YPmWjR-b8Fg1bl0sgg=.b3079752-f499-4e4e-af96-7d0d62b3def7@github.com> Message-ID: > I submitted PR #15555 before, and there were too many changes. I split it into multiple PRs with small changes. This one is one of them. > > this PR removed the duplicate code for getChars in BigDecimal#StringBuilderHelper, i also make performance faster. > Please review and don't hesitate to critique my approach and patch. Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: revert use JLA ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16006/files - new: https://git.openjdk.org/jdk/pull/16006/files/2074a0da..19f5c7a7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16006&range=12 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16006&range=11-12 Stats: 131 lines in 4 files changed: 47 ins; 79 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/16006.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16006/head:pull/16006 PR: https://git.openjdk.org/jdk/pull/16006 From pminborg at openjdk.org Fri Nov 10 07:26:12 2023 From: pminborg at openjdk.org (Per Minborg) Date: Fri, 10 Nov 2023 07:26:12 GMT Subject: RFR: 8319820: Use unnamed variables in the FFM implementation Message-ID: <19Ft-0cMiWPWUp3lbG-7gcU_zZAoDlTyJwPLigo5AOE=.5c2d3380-40d3-46c2-b213-715c56f948ee@github.com> This PR proposes to use unnamed variables now that they have become available in Java. There is also a cosmetic cleanup making a switch rake smaller and where variables are pre-calculated rather than spreading expressions around. ------------- Commit messages: - Use unnamed variables Changes: https://git.openjdk.org/jdk/pull/16594/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16594&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8319820 Stats: 35 lines in 4 files changed: 2 ins; 11 del; 22 mod Patch: https://git.openjdk.org/jdk/pull/16594.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16594/head:pull/16594 PR: https://git.openjdk.org/jdk/pull/16594 From jlahoda at openjdk.org Fri Nov 10 07:31:01 2023 From: jlahoda at openjdk.org (Jan Lahoda) Date: Fri, 10 Nov 2023 07:31:01 GMT Subject: RFR: 8304446: javap --system flag doesn't override system APIs [v2] In-Reply-To: References: Message-ID: <9mCI1X7vryzmoq2UUS2tDc0BxeI1F3wCmpKb5q_2V38=.3b5c1f73-8bcb-456b-823d-250592abe1c9@github.com> On Fri, 3 Nov 2023 08:21:15 GMT, Adam Sotona wrote: >> Javap ignores --system option when searching for JDK classes. >> This patch prepends search over JDK system modules. >> >> Please review. >> >> Thanks, >> Adam > > Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: > > Skip search over JDK modules for classes in unnamed package (mainly to skip JDK module-infos) To me, looks reasonable. Is there a chance for a jtreg test? Two other minor comments inline. src/jdk.jdeps/share/classes/com/sun/tools/javap/JavapTask.java line 28: > 26: package com.sun.tools.javap; > 27: > 28: import com.sun.tools.javac.file.Locations; Nit: seems unused. src/jdk.jdeps/share/classes/com/sun/tools/javap/JavapTask.java line 864: > 862: fo = fileManager.getJavaFileForInput(moduleLocation, className, JavaFileObject.Kind.CLASS); > 863: } else { > 864: if (className.indexOf('.') > 0) try { I would put the try into a block - it is slightly longer, but much clear, I think. ------------- PR Review: https://git.openjdk.org/jdk/pull/16476#pullrequestreview-1724173952 PR Review Comment: https://git.openjdk.org/jdk/pull/16476#discussion_r1389013585 PR Review Comment: https://git.openjdk.org/jdk/pull/16476#discussion_r1389014202 From duke at openjdk.org Fri Nov 10 07:59:59 2023 From: duke at openjdk.org (suchismith1993) Date: Fri, 10 Nov 2023 07:59:59 GMT Subject: RFR: JDK-8317799 : AIX PPC64: FFI symbol lookup doesn't find symbols In-Reply-To: <0YcwDWnMl1fH5HGhHDEl_eE_5sfyBnzesOc5WmJ-eII=.105c0c2a-09c4-4538-9d85-b7d987352d3f@github.com> References: <0YcwDWnMl1fH5HGhHDEl_eE_5sfyBnzesOc5WmJ-eII=.105c0c2a-09c4-4538-9d85-b7d987352d3f@github.com> Message-ID: On Wed, 8 Nov 2023 21:11:32 GMT, Magnus Ihse Bursie wrote: > First and foremost, the `make/data/hotspot-symbols` directory is, as the name says, for hotspot symbols. These are not hotspot symbols. If you really do need the file, then it needs to reside in a proper location. > > Secondly: do you really need this file? It looks just like an enumeration of (a subset of?) standard library functions. This looks like a completely incorrect solution to the problem. How did you arrive at this list? What if in the future new functions are added to the standard library? Which directory do you suggest to put the exports list in ? Do we create a new directory or use any existing directory. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16414#issuecomment-1805254422 From duke at openjdk.org Fri Nov 10 08:00:00 2023 From: duke at openjdk.org (suchismith1993) Date: Fri, 10 Nov 2023 08:00:00 GMT Subject: RFR: JDK-8317799 : AIX PPC64: FFI symbol lookup doesn't find symbols In-Reply-To: References: Message-ID: <4IdhKbmi7IHLT5m3OufNTva-1e817Lx3dtGV8aQVsqw=.54172da9-f1c8-4fa7-8cd4-d10d577283e8@github.com> On Thu, 9 Nov 2023 17:46:20 GMT, Erik Joelsson wrote: > For some context: `java.lang.foreign.Linker.nativeLinker().defaultLookup()` returns a `SymbolLookup` that can be used to find symbols from the standard library. > > We use a shim library that re-exports symbols from the standard library in order to make them accessible through `dlsym`, since on e.g. Linux the standard library .so files might actually be linker scripts which we don't want to mess with. On Windows we use ucrtbase.dll + an auxiliary library that contains the expansions of several 'inline' functions such as `printf`. I'm not surprised to see that another platform like AIX requires more to make this work as well. > > That said, I think we should limit the exported symbols to only those found in the standard C library header files: https://en.cppreference.com/w/c/header Currently the symbols are restricted to some parts of libc and the entire math library libm. Are you suggesting we restrict the list to common math functions such as https://en.cppreference.com/w/c/numeric/math ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/16414#issuecomment-1805256603 From pminborg at openjdk.org Fri Nov 10 08:17:22 2023 From: pminborg at openjdk.org (Per Minborg) Date: Fri, 10 Nov 2023 08:17:22 GMT Subject: RFR: 8316493: Remove the caching fields in AbstractMap [v11] In-Reply-To: References: Message-ID: <4tW3v7m0W_M4bmmLcywMRC5Gm26VhCt6pb16Bg7idTA=.c85a1df3-2208-439a-ac82-e9d16c537196@github.com> > This PR outlines a solution for making immutable maps `@ValueBased` by removing cacheing of certain values in `AbstractMap`. > > By removing these caching fields in `AbstractMap`, we can make the immutable maps `@ValueBased` and at the same time, performance is likely improved because the JVM is probably able to optimize away object creation anyway via escape analysis. Also, all maps will occupy less space as we get rid of a number of objects and references stored for each map. > > We need to benchmark this solution to better understand its implications. Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits: - Merge branch 'master' into vb-map2 - Fix formatting - Remove caching in TreeMap - Remove caching from CHM and CSLM - Move back clone to original position - Reintroduce AbstractMap::clone - Add 'fresh' to implSpec - Remove AbstractMap::clone - Merge master - Merge branch 'master' into vb-map2 - ... and 4 more: https://git.openjdk.org/jdk/compare/9cce9fe0...b1bfcd17 ------------- Changes: https://git.openjdk.org/jdk/pull/15614/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15614&range=10 Stats: 295 lines in 11 files changed: 92 ins; 165 del; 38 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 asotona at openjdk.org Fri Nov 10 08:38:09 2023 From: asotona at openjdk.org (Adam Sotona) Date: Fri, 10 Nov 2023 08:38:09 GMT Subject: RFR: 8304446: javap --system flag doesn't override system APIs [v3] In-Reply-To: References: Message-ID: > Javap ignores --system option when searching for JDK classes. > This patch prepends search over JDK system modules. > > Please review. > > Thanks, > Adam Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: applied suggested changes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16476/files - new: https://git.openjdk.org/jdk/pull/16476/files/78dc9840..1141201d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16476&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16476&range=01-02 Stats: 12 lines in 1 file changed: 4 ins; 3 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/16476.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16476/head:pull/16476 PR: https://git.openjdk.org/jdk/pull/16476 From asotona at openjdk.org Fri Nov 10 08:38:12 2023 From: asotona at openjdk.org (Adam Sotona) Date: Fri, 10 Nov 2023 08:38:12 GMT Subject: RFR: 8304446: javap --system flag doesn't override system APIs [v2] In-Reply-To: <9mCI1X7vryzmoq2UUS2tDc0BxeI1F3wCmpKb5q_2V38=.3b5c1f73-8bcb-456b-823d-250592abe1c9@github.com> References: <9mCI1X7vryzmoq2UUS2tDc0BxeI1F3wCmpKb5q_2V38=.3b5c1f73-8bcb-456b-823d-250592abe1c9@github.com> Message-ID: On Fri, 10 Nov 2023 07:25:45 GMT, Jan Lahoda wrote: >> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: >> >> Skip search over JDK modules for classes in unnamed package (mainly to skip JDK module-infos) > > src/jdk.jdeps/share/classes/com/sun/tools/javap/JavapTask.java line 28: > >> 26: package com.sun.tools.javap; >> 27: >> 28: import com.sun.tools.javac.file.Locations; > > Nit: seems unused. Removed, thanks. > src/jdk.jdeps/share/classes/com/sun/tools/javap/JavapTask.java line 864: > >> 862: fo = fileManager.getJavaFileForInput(moduleLocation, className, JavaFileObject.Kind.CLASS); >> 863: } else { >> 864: if (className.indexOf('.') > 0) try { > > I would put the try into a block - it is slightly longer, but much clear, I think. Fixed, thanks. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16476#discussion_r1389076255 PR Review Comment: https://git.openjdk.org/jdk/pull/16476#discussion_r1389076418 From asotona at openjdk.org Fri Nov 10 08:41:58 2023 From: asotona at openjdk.org (Adam Sotona) Date: Fri, 10 Nov 2023 08:41:58 GMT Subject: RFR: 8304446: javap --system flag doesn't override system APIs [v2] In-Reply-To: <9mCI1X7vryzmoq2UUS2tDc0BxeI1F3wCmpKb5q_2V38=.3b5c1f73-8bcb-456b-823d-250592abe1c9@github.com> References: <9mCI1X7vryzmoq2UUS2tDc0BxeI1F3wCmpKb5q_2V38=.3b5c1f73-8bcb-456b-823d-250592abe1c9@github.com> Message-ID: On Fri, 10 Nov 2023 07:28:30 GMT, Jan Lahoda wrote: > Is there a chance for a jtreg test? Unfortunately I haven't found a simple way to include a different JDK as `--system` for the test. Any suggestions are welcome. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16476#issuecomment-1805312908 From vklang at openjdk.org Fri Nov 10 09:32:17 2023 From: vklang at openjdk.org (Viktor Klang) Date: Fri, 10 Nov 2023 09:32:17 GMT Subject: RFR: JDK-8319123 : Implementation of JEP-461: Stream Gatherers (Preview) [v3] In-Reply-To: References: Message-ID: > This Pull-Request implements [JEP-461](https://openjdk.org/jeps/461) Viktor Klang has updated the pull request incrementally with two additional commits since the last revision: - Multiple improvements to Gatherer and Gatherers javadoc and restructuring of Gatherers.java to put public at the top of the file. - Augmenting Gatherer tests to include default implementation in Stream ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16420/files - new: https://git.openjdk.org/jdk/pull/16420/files/6c05d682..74936cdd Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16420&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16420&range=01-02 Stats: 1036 lines in 6 files changed: 464 ins; 372 del; 200 mod Patch: https://git.openjdk.org/jdk/pull/16420.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16420/head:pull/16420 PR: https://git.openjdk.org/jdk/pull/16420 From pminborg at openjdk.org Fri Nov 10 09:37:15 2023 From: pminborg at openjdk.org (Per Minborg) Date: Fri, 10 Nov 2023 09:37:15 GMT Subject: RFR: 8319882: SequenceLayout::toString throws ArithmeticException Message-ID: This PR proposes to fix a problem where a sequence layout contains an element of `byteSize()` zero. ------------- Commit messages: - Fix toString problem Changes: https://git.openjdk.org/jdk/pull/16599/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16599&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8319882 Stats: 16 lines in 2 files changed: 15 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/16599.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16599/head:pull/16599 PR: https://git.openjdk.org/jdk/pull/16599 From tvaleev at openjdk.org Fri Nov 10 09:42:12 2023 From: tvaleev at openjdk.org (Tagir F. Valeev) Date: Fri, 10 Nov 2023 09:42:12 GMT Subject: RFR: JDK-8319123 : Implementation of JEP-461: Stream Gatherers (Preview) [v2] In-Reply-To: References: Message-ID: On Wed, 8 Nov 2023 21:08:03 GMT, Viktor Klang wrote: >> This Pull-Request implements [JEP-461](https://openjdk.org/jeps/461) > > Viktor Klang has updated the pull request incrementally with two additional commits since the last revision: > > - Addressing review feedback > - Make Gatherer.andThen take a wildcard for the rhs Gatherer state type src/java.base/share/classes/java/util/stream/GathererOp.java line 301: > 299: * the output. This is highly beneficial in the parallel case as stateful > 300: * operations cannot be pipelined in the ReferencePipeline implementation. > 301: * Overriding collect-operations overcomes this limitation. Does this mean that .parallel().gather(myGatherer).map(smth).collect(..) will be slower than .parallel().gather(myGatherer.andThen(mappingGatherer(smth))).collect(..)? Also, what about other terminals (e.g. reduce())? Will they require processing all the upstream before reduction? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1389147792 From rgiulietti at openjdk.org Fri Nov 10 10:09:11 2023 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Fri, 10 Nov 2023 10:09:11 GMT Subject: Integrated: 8319174: Enhance robustness of some j.m.BigInteger constructors In-Reply-To: <0iccBwbAhAmIPGxnz1bhry2Sj_Kz2xngZmb2lPFCUpU=.c2b7c8ef-4e77-4c8f-a7ec-7c5c0980e59e@github.com> References: <0iccBwbAhAmIPGxnz1bhry2Sj_Kz2xngZmb2lPFCUpU=.c2b7c8ef-4e77-4c8f-a7ec-7c5c0980e59e@github.com> Message-ID: On Wed, 1 Nov 2023 12:32:24 GMT, Raffaello Giulietti wrote: > Enhance `java.math.BigInteger` constructors taking a `byte[]` argument by improving guarantees of internal invariants. This pull request has now been integrated. Changeset: a64fc48e Author: Raffaello Giulietti URL: https://git.openjdk.org/jdk/commit/a64fc48e2dbc650b31869dd79b1ba1012376fc51 Stats: 323 lines in 3 files changed: 253 ins; 7 del; 63 mod 8319174: Enhance robustness of some j.m.BigInteger constructors Reviewed-by: rriggs, darcy ------------- PR: https://git.openjdk.org/jdk/pull/16449 From vklang at openjdk.org Fri Nov 10 10:30:11 2023 From: vklang at openjdk.org (Viktor Klang) Date: Fri, 10 Nov 2023 10:30:11 GMT Subject: RFR: JDK-8319123 : Implementation of JEP-461: Stream Gatherers (Preview) [v2] In-Reply-To: References: Message-ID: On Fri, 10 Nov 2023 09:38:51 GMT, Tagir F. Valeev wrote: >> Viktor Klang has updated the pull request incrementally with two additional commits since the last revision: >> >> - Addressing review feedback >> - Make Gatherer.andThen take a wildcard for the rhs Gatherer state type > > src/java.base/share/classes/java/util/stream/GathererOp.java line 301: > >> 299: * the output. This is highly beneficial in the parallel case as stateful >> 300: * operations cannot be pipelined in the ReferencePipeline implementation. >> 301: * Overriding collect-operations overcomes this limitation. > > Does this mean that .parallel().gather(myGatherer).map(smth).collect(..) will be slower than .parallel().gather(myGatherer.andThen(mappingGatherer(smth))).collect(..)? Also, what about other terminals (e.g. reduce())? Will they require processing all the upstream before reduction? That will completely depend on many different factors, including the implementation of Stream (parallel is advisory only), the nature of the source Spliterator, the implementation of `map` and the implementation of `collect` (besides environmental factors such as availability of memory, CPU, etc). Currently, in this PR, GathererOP is a "stateful" operation (in the reference implementation parlance), although consecutive `gather()`- operations are fused, and a `collect` after a `gather` is fused. There is a combination of characteristics of Gatherers where they could be encoded as Spliterators, and in that case it could be conceived that they could be considered stateless. This is something which can be explored during the Preview. There are multiple microbenchmarks in this PR for those who are curious about current performance. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1389216765 From mcimadamore at openjdk.org Fri Nov 10 11:08:58 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Fri, 10 Nov 2023 11:08:58 GMT Subject: RFR: 8319882: SequenceLayout::toString throws ArithmeticException In-Reply-To: References: Message-ID: On Fri, 10 Nov 2023 09:31:29 GMT, Per Minborg wrote: > This PR proposes to fix a problem where a sequence layout contains an element of `byteSize()` zero. Marked as reviewed by mcimadamore (Reviewer). src/java.base/share/classes/jdk/internal/foreign/layout/SequenceLayoutImpl.java line 182: > 180: @Override > 181: public String toString() { > 182: boolean max = (Long.MAX_VALUE / Math.max(1, elementLayout.byteSize())) == elemCount; Looks good - now if you have a sequence layout whose count is Long.MAX_VALUE, but whose element layout has size 0, you also get the `*` in the toString, which I guess makes sense (as you can't have a bigger sequence layout than that). ------------- PR Review: https://git.openjdk.org/jdk/pull/16599#pullrequestreview-1724554448 PR Review Comment: https://git.openjdk.org/jdk/pull/16599#discussion_r1389257693 From mail at sebfisch.de Fri Nov 10 11:26:15 2023 From: mail at sebfisch.de (Sebastian Fischer) Date: Fri, 10 Nov 2023 12:26:15 +0100 Subject: Provide thread-safe and concurrent sequenced collections with insertion order? In-Reply-To: <99886935-1446-967d-8382-1793470ce88b@oracle.com> References: <99886935-1446-967d-8382-1793470ce88b@oracle.com> Message-ID: Hi Stuart. Thanks, I understand now how the limited thread safety of "synchronized" wrappers has led to not adding new ones. My use case is an LRU-cache that is accessed by a large number of (virtual) threads. In my initial implementation I constructed a LinkedHashMap passing true for the accessOrder parameter, implemented removeEldestEntry appropriately and then wrapped it using Collections.sequencedMap. Thanks to this interface, I did not need a specialized wrapper supporting putLast or pollFirstEntry to manage the capacity myself. So, wrapping a LinkedHashMap seemed like a viable approach at first. But, the map is being used by many threads, and a synchronized wrapper is governed by a single exclusion lock. I improved throughput using a concurrent map supporting concurrent reads and (some) writes. Here is a simplified example using a sequenced collection instead of a map. public record RecentlyAccessed(int capacity, SequencedCollection elements) { public RecentlyAccessed(int capacity) { this(capacity, new ConcurrentLinkedDeque<>()); } public void add(T elem) { elements.addLast(elem); while (capacity < elements.size()) { elements.removeFirst(); } } } As the add method is not synchronized, the real capacity might deviate from the intended capacity. Additionally, ConcurrentLinkedDeque can contain duplicate elements. I could implement repositioning by removing all occurrences of elem before calling addLast but that would introduce an intermediate state where elem is not present (even if it was present before) due to the lack of synchronization. In my current implementation of the cache I use a ConcurrentHashMap with an additional ConcurrentLinkedDeque holding keys in access order telling me which entries to remove from the map. But this approach is not really thread-safe due to missing synchronization and incorrect due to duplicate keys in the deque. I was hoping to use a ConcurrentLinkedHashSet (or really ConcurrentLinkedHashMap, but both seem useful), where repositioning would presumably be implemented in a thread-safe way. Ideally, the option to override removeEldestEntry would allow it to also maintain the intended capacity in a thread-safe way. I'm not familiar enough with the implementation of concurrent collections to judge whether my hope is justified. But essentially, my use case would be an LRU-cache that does not use a single exclusion lock to improve concurrent access by a large number of (virtual) threads. Sebastian On Fri, Nov 10, 2023 at 1:03?AM Stuart Marks wrote: > Hi Sebastian, > > Regarding the lack of "synchronized" wrappers for Sequenced Collections: > the main > issue is that they provide only a limited sense of "thread safety" and as > such don't > add much actual value. Specifically, the synchronized wrappers hold a lock > only > around invocations of individual methods. This omits a large class of > common, > compound operations on collections, such as check-then-act operations and > bulk > operations that involve iteration or streaming. These operations aren't > thread-safe > with synchronized wrappers. To perform these operations safely from > multiple > threads, the client needs to do its own locking around the compound > operation. This > mostly defeats the purpose of the synchronized wrappers. > > If you need to use something like LinkedHashMap/LinkedHashSet from > multiple threads, > my recommendation is to write your own class that exposes exactly the set > of > operations you need and that does proper locking for those operations. It > can then > delegate the appropriate operations to an internal collection. > > Regarding concurrent collections: these are mainly intended for operations > to > proceed concurrently on different parts of the collection, such as > updating > different mappings in a ConcurrentHashMap simultaneously, or having > producers/consumers operating on different ends of a Queue. I note that > historically, the concurrent collections haven't included concurrent > versions of > LinkedHashSet/Map or general-purpose List implementations. (There is > CopyOnWriteArrayList/Set, but they're highly specialized and can be > prohibitively > expensive for use cases that involve a lot of updates.) > > While it looks like things are missing from the concurrent collections, > I'd have to > ask what use cases would be satisfied by adding something like a > "concurrent > sequenced set" (or map) that wouldn't be fulfilled with a customized > wrapper around > LinkedHashSet/Map. > > s'marks > > > On 11/2/23 4:56 AM, Sebastian Fischer wrote: > > Hello. > > > > I am new to this list so might have missed previous discussion about > this but > > could not find what I was looking for in the archives. > > > > The Sequenced collections JEP adds the following static methods to > > java.util.Collections. > > > > - unmodifiableSequencedCollection > > - unmodifiableSequencedSet > > - unmodifiableSequencedMap > > > > However, the set of static methods returning thread-safe versions of > their > > arguments (like synchronizedCollection, synchronizedSet, and > synchronizedMap) has > > not been extended. > > > > As a consequence, I don't see a straightforward way to create > thread-safe > > sequenced sets or maps where encounter-order corresponds to insertion > order (like > > LinkedHashSet or LinkedHashMap) and access them as SequencedSet or > SequencedMap. > > > > When using the available methods mentioned above, the result is not a > sequenced type. > > > > For predefined sets and maps where encounter order corresponds to > natural order, > > there are the following methods in java.util.Collections. > > > > - synchronizedNavigableSet > > - synchronizedNavigableMap > > - synchronizedSortedSet > > - synchronizedSortedMap > > > > However, these methods cannot be used with LinkedHashSet or > LinkedHashMap. > > > > The following methods would be useful in order to create thread-safe > sequenced > > collections where encounter order is insertion order, but they are > currently not > > provided. > > > > - synchronizedSequencedCollection > > - synchronizedSequencedSet > > - synchronizedSequencedMap > > > > What are the reasons for or against adding these methods? > > > > There are also no implementations of concurrent sequenced sets and maps > where > > encounter order is insertion order in java.util.concurrent. All of the > provided > > concurrent sequenced sets and maps are based on natural order, and > consequently do > > not support addFirst, and so on. > > > > Are there plans to add concurrent sequenced collections that support the > whole > > interface of sequenced collections? > > > > Kind regards, > > Sebastian > -------------- next part -------------- An HTML attachment was scrubbed... URL: From JanecekPetr at seznam.cz Fri Nov 10 12:14:07 2023 From: JanecekPetr at seznam.cz (=?utf-8?q?Petr_Jane=C4=8Dek?=) Date: Fri, 10 Nov 2023 13:14:07 +0100 (CET) Subject: =?utf-8?q?JDK-8249280=3A_Calling_toLocalDateTime=28=29_on_an_inva?= =?utf-8?q?lid_java=2Esql=2ETimestamp_throws?= Message-ID: <8tl.1Gbp.3D6PWSZqz8S.1bJXwF@seznam.cz> Hello! This is meant as a comment on JDK-8249280 (Date and Timestamp valueOf wrong for BCE years) and/or JDK-8272194 (java.sql.Date::toLocalDate() broken for dates before 1 A.D.) as I can't comment directly. The direct consequence of the bug is that using big negative timestamps it's possible to construct invalid java.sql.Date or java.sql.Timestamp instances that throw when toLocalDate() or toLocalDateTime() is called on them. The following code: ``` var millis = -9223371997689600000L; var timestamp = new Timestamp(millis); var localDateTime = timestamp.toLocalDateTime(); // throws ``` throws ``` Exception in thread "main" java.time.DateTimeException: Invalid date 'February 29' as '292269053' is not a leap year at java.base/java.time.LocalDate.create(LocalDate.java:459) at java.base/java.time.LocalDate.of(LocalDate.java:273) at java.base/java.time.LocalDateTime.of(LocalDateTime.java:363) at java.sql/java.sql.Timestamp.toLocalDateTime(Timestamp.java:519) at [...] ``` Obviously `new java.sql.Date(millis).toLocalDate()` fails the same way, and this happens for all timestamps for a day every 4 years, so fairly often. This makes the bug much worse than implied by their descriptions as it's unintuitive to assume that `new Timestamp(any).toLocalDateTime()` could ever throw. All the values are naively valid and possible. Is it a good time to reevaluate the bugs' priority? Returning a bad value is one thing, throwing is another. The workaround is clear - just use Instant instead: ``` var instant = Instant.ofEpochMilli(millis); var localDateTime = LocalDateTime.ofInstant(instant, utcOrDefaultZone); ``` I'm sure this never happens, but perhaps the old-timey Date/Timestamp should be reimplemented using the new java.time types? Thank you, Petr Jane?ek From pminborg at openjdk.org Fri Nov 10 14:27:08 2023 From: pminborg at openjdk.org (Per Minborg) Date: Fri, 10 Nov 2023 14:27:08 GMT Subject: Integrated: 8319882: SequenceLayout::toString throws ArithmeticException In-Reply-To: References: Message-ID: On Fri, 10 Nov 2023 09:31:29 GMT, Per Minborg wrote: > This PR proposes to fix a problem where a sequence layout contains an element of `byteSize()` zero. This pull request has now been integrated. Changeset: c9657cad Author: Per Minborg URL: https://git.openjdk.org/jdk/commit/c9657cad124d2be10b8d6006d0ca9a038b1c5945 Stats: 16 lines in 2 files changed: 15 ins; 0 del; 1 mod 8319882: SequenceLayout::toString throws ArithmeticException Reviewed-by: mcimadamore ------------- PR: https://git.openjdk.org/jdk/pull/16599 From rgiulietti at openjdk.org Fri Nov 10 15:06:01 2023 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Fri, 10 Nov 2023 15:06:01 GMT Subject: RFR: 8311906: Improve robustness of String constructors with mutable array inputs [v2] In-Reply-To: References: <6SKlGLh5MmxoEx07wHCCUc8KWbbhcspLJmcc1uxQ_FI=.ca33bfb4-fa5c-45f0-b49f-ee6c5c6b68b4@github.com> Message-ID: On Thu, 9 Nov 2023 04:16:25 GMT, Roger Riggs wrote: >> Strings, after construction, are immutable but may be constructed from mutable arrays of bytes, characters, or integers. >> The string constructors should guard against the effects of mutating the arrays during construction that might invalidate internal invariants for the correct behavior of operations on the resulting strings. In particular, a number of operations have optimizations for operations on pairs of latin1 strings and pairs of non-latin1 strings, while operations between latin1 and non-latin1 strings use a more general implementation. >> >> The changes include: >> >> - Adding a warning to each constructor with an array as an argument to indicate that the results are indeterminate >> if the input array is modified before the constructor returns. >> The resulting string may contain any combination of characters sampled from the input array. >> >> - Ensure that strings that are represented as non-latin1 contain at least one non-latin1 character. >> For latin1 inputs, whether the arrays contain ASCII, ISO-8859-1, UTF8, or another encoding decoded to latin1 the scanning and compression is unchanged. >> If a non-latin1 character is found, the string is represented as non-latin1 with the added verification that a non-latin1 character is present at the same index. >> If that character is found to be latin1, then the input array has been modified and the result of the scan may be incorrect. >> Though a ConcurrentModificationException could be thrown, the risk to an existing application of an unexpected exception should be avoided. >> Instead, the non-latin1 copy of the input is re-scanned and compressed; that scan determines whether the latin1 or the non-latin1 representation is returned. >> >> - The methods that scan for non-latin1 characters and their intrinsic implementations are updated to return the index of the non-latin1 character. >> >> - String construction from StringBuilder and CharSequence must also be guarded as their contents may be modified during construction. > > Roger Riggs has updated the pull request incrementally with three additional commits since the last revision: > > - Refactored extractCodePoints to avoid multiple resizes if the array was modified > - Replaced isLatin1 implementation with `getChar(buf, ndx) <= 0xff` > It performs better than the single byte array access by avoiding the bounds check. > - Misc updates for review comments, javadoc cleanup > Extra checking on maximum string lengths when calling toBytes(). src/java.base/share/classes/java/lang/StringUTF16.java line 279: > 277: } else { > 278: // Pass 1: Compute precise size of char[]; see extractCodePoints for caveat > 279: int estSize = ndx + computeCodePointSize(val, off, end); To avoid reallocations in `extractCodepoints()`, a way is to profit from the presence of `latin1[]`, putting `latin1[i] = (byte) (cp >>> 16)`, starting from `ndx`, while scanning the `val[]` in `computeCodePointSize()` to preserve information about the upper bits of the codepoint. Later, while copying the `val[]` codepoints to `utf16[]`, the info in `latin1[]` is included in the `cp` just read from `val[]`, for example as in `cp = (cp & 0xffff) | ((latin1[i] & 0xff) << 16)`. The resulting codepoint would be BMP or supplementary as when it was scanned during `computeCodePointSize()`, even in presence of later modifications, and preserving the original value if it wasn't modified in the meantime. Since the info about a codepoint needing 1 or 2 chars in `utf16[]` is preserved in `latin1[]`, there should be no need for reallocations. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16425#discussion_r1389509263 From duke at openjdk.org Fri Nov 10 15:32:00 2023 From: duke at openjdk.org (Yakov Shafranovich) Date: Fri, 10 Nov 2023 15:32:00 GMT Subject: RFR: JDK-8319122: Improve documentation of various Zip-file related APIs In-Reply-To: References: <8vEqyECjMkTfesVmL3X0dN4Yu8JShPiUdsKpmEz1WV0=.1b541f77-a05f-490b-aaf1-f6b7456c6d77@github.com> Message-ID: On Thu, 9 Nov 2023 20:41:22 GMT, Kevin Driver wrote: >> The various Zip/Jar-file related Java APIs have some long-standing differences or peculiarities with respect to the ZIP-file specification or compared to other implementations which should be documented in the API-doc. This documents the following: >> - Cache of JAR files in JarURLConnection class >> - Cache of JAR/ZIP files in JarFile and ZipFile classes >> - Unexpected behavior when parsing ZIP files with duplicate entries in JarFile and ZipFile classes, as well as the zipfs provider >> - Directories and filenames with the same name considered to be the same in ZipFile class >> - Possible issues when local and central headers conflict in ZipInputStream class >> >> Related JBS report: >> https://bugs.openjdk.org/browse/JDK-8319122 > > src/java.base/share/classes/java/net/JarURLConnection.java line 129: > >> 127: * JAR files retrieved by this class might get cached for performance reasons which can result >> 128: * in unexpected behavior if the JAR files are modified while being read using this class. >> 129: * If such behavior is undesirable, please use the {@link URLConnection#setUseCaches(boolean)} method to disable caching. > > consider a manual line wrap here, or is this ~80 chars? will fix ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16424#discussion_r1389545818 From duke at openjdk.org Fri Nov 10 15:36:02 2023 From: duke at openjdk.org (Yakov Shafranovich) Date: Fri, 10 Nov 2023 15:36:02 GMT Subject: RFR: JDK-8319122: Improve documentation of various Zip-file related APIs In-Reply-To: References: <8vEqyECjMkTfesVmL3X0dN4Yu8JShPiUdsKpmEz1WV0=.1b541f77-a05f-490b-aaf1-f6b7456c6d77@github.com> Message-ID: On Thu, 9 Nov 2023 20:42:52 GMT, Kevin Driver wrote: >> The various Zip/Jar-file related Java APIs have some long-standing differences or peculiarities with respect to the ZIP-file specification or compared to other implementations which should be documented in the API-doc. This documents the following: >> - Cache of JAR files in JarURLConnection class >> - Cache of JAR/ZIP files in JarFile and ZipFile classes >> - Unexpected behavior when parsing ZIP files with duplicate entries in JarFile and ZipFile classes, as well as the zipfs provider >> - Directories and filenames with the same name considered to be the same in ZipFile class >> - Possible issues when local and central headers conflict in ZipInputStream class >> >> Related JBS report: >> https://bugs.openjdk.org/browse/JDK-8319122 > > src/java.base/share/classes/java/util/zip/ZipFile.java line 104: > >> 102: * being returned due to internal caching. >> 103: * >> 104: * Additionally, for compatibility with earlier versions of the JDK, files and directories with the same name (such as "foobar" and "foobar/") > > consider a manual line wrap in these as well, or is this ~80 chars? will fix ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16424#discussion_r1389551613 From duke at openjdk.org Fri Nov 10 15:44:19 2023 From: duke at openjdk.org (Yakov Shafranovich) Date: Fri, 10 Nov 2023 15:44:19 GMT Subject: RFR: JDK-8319122: Improve documentation of various Zip-file related APIs [v2] In-Reply-To: <8vEqyECjMkTfesVmL3X0dN4Yu8JShPiUdsKpmEz1WV0=.1b541f77-a05f-490b-aaf1-f6b7456c6d77@github.com> References: <8vEqyECjMkTfesVmL3X0dN4Yu8JShPiUdsKpmEz1WV0=.1b541f77-a05f-490b-aaf1-f6b7456c6d77@github.com> Message-ID: > The various Zip/Jar-file related Java APIs have some long-standing differences or peculiarities with respect to the ZIP-file specification or compared to other implementations which should be documented in the API-doc. This documents the following: > - Cache of JAR files in JarURLConnection class > - Cache of JAR/ZIP files in JarFile and ZipFile classes > - Unexpected behavior when parsing ZIP files with duplicate entries in JarFile and ZipFile classes, as well as the zipfs provider > - Directories and filenames with the same name considered to be the same in ZipFile class > - Possible issues when local and central headers conflict in ZipInputStream class > > Related JBS report: > https://bugs.openjdk.org/browse/JDK-8319122 Yakov Shafranovich has updated the pull request incrementally with two additional commits since the last revision: - Fixed more line breaks - fixed line breaks ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16424/files - new: https://git.openjdk.org/jdk/pull/16424/files/8ee093c0..919666a0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16424&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16424&range=00-01 Stats: 46 lines in 5 files changed: 15 ins; 0 del; 31 mod Patch: https://git.openjdk.org/jdk/pull/16424.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16424/head:pull/16424 PR: https://git.openjdk.org/jdk/pull/16424 From duke at openjdk.org Fri Nov 10 15:44:20 2023 From: duke at openjdk.org (Yakov Shafranovich) Date: Fri, 10 Nov 2023 15:44:20 GMT Subject: RFR: JDK-8319122: Improve documentation of various Zip-file related APIs [v2] In-Reply-To: References: <8vEqyECjMkTfesVmL3X0dN4Yu8JShPiUdsKpmEz1WV0=.1b541f77-a05f-490b-aaf1-f6b7456c6d77@github.com> Message-ID: On Thu, 9 Nov 2023 20:43:25 GMT, Kevin Driver wrote: >> Yakov Shafranovich has updated the pull request incrementally with two additional commits since the last revision: >> >> - Fixed more line breaks >> - fixed line breaks > > src/jdk.zipfs/share/classes/module-info.java line 303: > >> 301: * may occur such as metadata or content from the later entry being returned due to internal caching. >> 302: * >> 303: * Additionally, for compatibility with earlier versions of the JDK, files and directories with the same name (such as "foobar" and "foobar/") > > consider a manual line wrap in these as well, or is this ~80 chars? will fix ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16424#discussion_r1389556168 From ihse at openjdk.org Fri Nov 10 15:52:02 2023 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 10 Nov 2023 15:52:02 GMT Subject: RFR: JDK-8317799 : AIX PPC64: FFI symbol lookup doesn't find symbols In-Reply-To: References: <0YcwDWnMl1fH5HGhHDEl_eE_5sfyBnzesOc5WmJ-eII=.105c0c2a-09c4-4538-9d85-b7d987352d3f@github.com> Message-ID: <9TvREErKy_SqMc5WY1R-9yEDNDKOCAqsi3br27-7MAg=.4cfe1eb5-58f6-46d5-be68-7eaae51f2671@github.com> On Fri, 10 Nov 2023 07:54:40 GMT, suchismith1993 wrote: > Which directory do you suggest to put the exports list in ? Do we create a new directory or use any existing directory. My initial thinking is like Erik's, that this list should be dynamically generated at build-time. I am pretty sure that anything but doing that will end up with hard-to-debug problems in the future. At build-time, you know exactly what symbols you are linking with. If this, for some reason, is infeasible, then we can discuss how to generate/update such a list, and where to put it. If the list needs to be manually generated ahead-of-time of the build, then this should ideally be done by a script that is checked in. If manual intervention/curation is needed, then this needs to be properly documented. Just pushing a list like this, with no explanation, is not going to cut it, regardless of where in the source code tree it is stored. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16414#issuecomment-1805972829 From mcimadamore at openjdk.org Fri Nov 10 16:18:58 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Fri, 10 Nov 2023 16:18:58 GMT Subject: RFR: 8319820: Use unnamed variables in the FFM implementation In-Reply-To: <19Ft-0cMiWPWUp3lbG-7gcU_zZAoDlTyJwPLigo5AOE=.5c2d3380-40d3-46c2-b213-715c56f948ee@github.com> References: <19Ft-0cMiWPWUp3lbG-7gcU_zZAoDlTyJwPLigo5AOE=.5c2d3380-40d3-46c2-b213-715c56f948ee@github.com> Message-ID: On Fri, 10 Nov 2023 07:19:42 GMT, Per Minborg wrote: > This PR proposes to use unnamed variables now that they have become available in Java. > > There is also a cosmetic cleanup making a switch rake smaller and where variables are pre-calculated rather than spreading expressions around. Marked as reviewed by mcimadamore (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/16594#pullrequestreview-1725130496 From duke at openjdk.org Fri Nov 10 16:32:59 2023 From: duke at openjdk.org (suchismith1993) Date: Fri, 10 Nov 2023 16:32:59 GMT Subject: RFR: JDK-8317799 : AIX PPC64: FFI symbol lookup doesn't find symbols In-Reply-To: <9TvREErKy_SqMc5WY1R-9yEDNDKOCAqsi3br27-7MAg=.4cfe1eb5-58f6-46d5-be68-7eaae51f2671@github.com> References: <0YcwDWnMl1fH5HGhHDEl_eE_5sfyBnzesOc5WmJ-eII=.105c0c2a-09c4-4538-9d85-b7d987352d3f@github.com> <9TvREErKy_SqMc5WY1R-9yEDNDKOCAqsi3br27-7MAg=.4cfe1eb5-58f6-46d5-be68-7eaae51f2671@github.com> Message-ID: On Fri, 10 Nov 2023 15:48:59 GMT, Magnus Ihse Bursie wrote: > > Which directory do you suggest to put the exports list in ? Do we create a new directory or use any existing directory. > > My initial thinking is like Erik's, that this list should be dynamically generated at build-time. I am pretty sure that anything but doing that will end up with hard-to-debug problems in the future. At build-time, you know exactly what symbols you are linking with. > > If this, for some reason, is infeasible, then we can discuss how to generate/update such a list, and where to put it. If the list needs to be manually generated ahead-of-time of the build, then this should ideally be done by a script that is checked in. If manual intervention/curation is needed, then this needs to be properly documented. > > Just pushing a list like this, with no explanation, is not going to cut it, regardless of where in the source code tree it is stored. There is not generic way of generating this. It needs a manual intervention and symbols are to be added on a need basis in future. Looks like a list to be maintained. I had tried adding comments to explain the list, but that causes build failures. Can you point on any guidelines and todos to document this ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/16414#issuecomment-1806047128 From mcimadamore at openjdk.org Fri Nov 10 16:38:06 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Fri, 10 Nov 2023 16:38:06 GMT Subject: RFR: 8319928: Exceptions thrown by cleanup actions passed to reinterpreted segments should be ignored Message-ID: This simplePR tweaks the factory which wraps custom cleanup actions passed to `MemorySegment::reinterpret`, so that any exception thrown by the custom cleanup is swallowed when the arena is closed. This aligns the behavior of confined/shared session with that of implicit session (as implicit sessions are backed by a `Cleaner`, there is no way for cleanup exception to bubble up). ------------- Commit messages: - Initial push Changes: https://git.openjdk.org/jdk/pull/16619/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16619&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8319928 Stats: 20 lines in 3 files changed: 17 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/16619.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16619/head:pull/16619 PR: https://git.openjdk.org/jdk/pull/16619 From rriggs at openjdk.org Fri Nov 10 16:44:00 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 10 Nov 2023 16:44:00 GMT Subject: RFR: 8311906: Improve robustness of String constructors with mutable array inputs [v2] In-Reply-To: References: <6SKlGLh5MmxoEx07wHCCUc8KWbbhcspLJmcc1uxQ_FI=.ca33bfb4-fa5c-45f0-b49f-ee6c5c6b68b4@github.com> Message-ID: <6VulrG9chGhju3-nh8ibToI87bQQe2J0SMpnQSMzB6s=.a1fc7c4d-fcee-49db-a0ec-264a8528dce6@github.com> On Fri, 10 Nov 2023 14:59:57 GMT, Raffaello Giulietti wrote: >> Roger Riggs has updated the pull request incrementally with three additional commits since the last revision: >> >> - Refactored extractCodePoints to avoid multiple resizes if the array was modified >> - Replaced isLatin1 implementation with `getChar(buf, ndx) <= 0xff` >> It performs better than the single byte array access by avoiding the bounds check. >> - Misc updates for review comments, javadoc cleanup >> Extra checking on maximum string lengths when calling toBytes(). > > src/java.base/share/classes/java/lang/StringUTF16.java line 279: > >> 277: } else { >> 278: // Pass 1: Compute precise size of char[]; see extractCodePoints for caveat >> 279: int estSize = ndx + computeCodePointSize(val, off, end); > > To avoid reallocations in `extractCodepoints()`, a way is to profit from the presence of `latin1[]`, putting `latin1[i] = (byte) (cp >>> 16)`, starting from `ndx`, while scanning the `val[]` in `computeCodePointSize()` to preserve information about the upper bits of the codepoint. > > Later, while copying the `val[]` codepoints to `utf16[]`, the info in `latin1[]` is included in the `cp` just read from `val[]`, for example as in `cp = (cp & 0xffff) | ((latin1[i] & 0xff) << 16)`. > > The resulting codepoint would be BMP or supplementary as when it was scanned during `computeCodePointSize()`, even in presence of later modifications, and preserving the original value if it wasn't modified in the meantime. Since the info about a codepoint needing 1 or 2 chars in `utf16[]` is preserved in `latin1[]`, there should be no need for reallocations. Interesting idea, but it might mean that if the codepoint val[i] was modified it could result in a cp that did not (ever) exist in the input; creating a value out of thin air. The high bits would be from the first read of val[i] and the low bits from the 2nd read. The code in extractCodepoints could be simpler and computeCodePointSize just a little more comples. Creating values out of thin air is usually bad and could have (different) unexpected results in the app. The additional writes to the latin1 array would also slow down the normal case of computing the size whether or not the input was modified. On that basis, I'd keep the current approach to resizing only if needed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16425#discussion_r1389637034 From prappo at openjdk.org Fri Nov 10 16:49:05 2023 From: prappo at openjdk.org (Pavel Rappo) Date: Fri, 10 Nov 2023 16:49:05 GMT Subject: RFR: 8310813: Simplify and modernize equals, hashCode, and compareTo for BigInteger [v8] In-Reply-To: References: <-bypZB03AZE1K1vsfn_qFZ98tuqrll8smbCBMaXnNLs=.ea39341c-df39-4278-956c-ce9bbe0f6611@github.com> Message-ID: On Tue, 7 Nov 2023 07:58:40 GMT, Pavel Rappo wrote: >> Please review this PR to use modern APIs and language features to simplify equals, hashCode, and compareTo for BigInteger. If you have any performance concerns, please raise them. >> >> This PR is cherry-picked from a bigger, not-yet-published PR, to test the waters. That latter PR will be published soon. > > Pavel Rappo has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 15 additional commits since the last revision: > > - Merge branch 'master' into 8310813 > - 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 > - ... and 5 more: https://git.openjdk.org/jdk/compare/8ac67427...155fedba Here's a benchmark which was performed after the most recent merge (155fedb) with openjdk/jdk master. Factor it in your review. In addition to the new benchmarks, I included some benchmarks from the security area, which might be affected by this PR. If security-dev (cc'ed earlier) thinks I should benchmark anything else, please let me know. To reduce horizontal scrolling and make the table easier on the eyes, leading `openjdk.bench.java.` was removed from the name of each benchmark; then leading `math` and `security` were replaced with `m` and `s` respectively. |Benchmark | Linux aarch64| Linux x64| MacOSX aarch64| MacOSX x64| Windows x64| |:------------------------------------------------------------------------------------------|--------------:|----------:|---------------:|-----------:|------------:| |m.BigIntegerCompareTo.testCompareTo-group:L | 25.59%| 41.63%| 31.77%| 29.87%| 41.60%| |m.BigIntegerCompareTo.testCompareTo-group:M | 1.67%| -2.14%| 11.55%| -8.86%| -2.08%| |m.BigIntegerCompareTo.testCompareTo-group:S | -9.48%| 1.85%| -7.39%| -1.13%| 2.47%| |m.BigIntegerEquals.testEquals-group:L | 8.41%| 15.42%| 17.44%| -6.24%| 4.32%| |m.BigIntegerEquals.testEquals-group:M | -0.59%| -17.27%| 3.43%| -25.37%| -30.70%| |m.BigIntegerEquals.testEquals-group:S | 5.62%| -36.56%| 11.45%| -29.62%| -26.71%| |m.BigIntegerHashCode.testHashCode-group:L | 0.01%| 78.80%| 0.01%| 70.25%| 78.70%| |m.BigIntegerHashCode.testHashCode-group:M | 0.00%| 30.25%| -0.03%| 20.46%| 27.40%| |m.BigIntegerHashCode.testHashCode-group:S | 1.18%| 38.16%| 1.80%| 24.49%| 38.92%| |m.BigIntegerParallelMultiply.multiply-n:1000000 | -1.74%| 0.89%| 2.76%| 0.16%| 0.55%| |m.BigIntegerParallelMultiply.multiply-n:10000000 | 0.22%| -0.13%| 0.85%| -1.90%| -0.47%| |m.BigIntegerParallelMultiply.multiply-n:100000000 | -0.01%| -2.28%| 0.31%| 2.51%| -0.71%| |m.BigIntegerParallelMultiply.parallelMultiply-n:1000000 | -6.10%| 0.32%| 0.83%| 2.58%| 2.27%| |m.BigIntegerParallelMultiply.parallelMultiply-n:10000000 | -4.23%| -2.49%| 1.54%| 0.94%| -1.53%| |m.BigIntegerParallelMultiply.parallelMultiply-n:100000000 | 0.07%| -0.80%| 0.53%| 0.86%| 0.41%| |m.BigIntegers.SmallShifts.testLeftShift-maxNumbits:128 | 2.83%| -1.87%| -0.49%| -0.81%| -0.13%| |m.BigIntegers.SmallShifts.testLeftShift-maxNumbits:256 | -1.38%| -0.32%| -0.48%| 0.07%| 0.25%| |m.BigIntegers.SmallShifts.testLeftShift-maxNumbits:32 | 0.14%| 0.01%| 2.77%| 0.30%| -0.81%| |m.BigIntegers.SmallShifts.testRightShift-maxNumbits:128 | -2.91%| 0.20%| -2.99%| -0.72%| 0.46%| |m.BigIntegers.SmallShifts.testRightShift-maxNumbits:256 | -2.35%| 0.02%| 1.56%| 0.54%| 3.65%| |m.BigIntegers.SmallShifts.testRightShift-maxNumbits:32 | -0.12%| -0.70%| -2.96%| 0.22%| -0.89%| |m.BigIntegers.testAdd | -0.05%| 1.36%| -1.20%| 0.15%| 1.58%| |m.BigIntegers.testGcd | -0.08%| 0.44%| 0.05%| -0.08%| 0.12%| |m.BigIntegers.testHugeToString | -0.30%| -0.58%| -0.10%| -0.47%| 1.25%| |m.BigIntegers.testLargeToString | -2.30%| -0.36%| 0.01%| -0.06%| 1.98%| |m.BigIntegers.testLeftShift | 0.53%| 0.94%| -0.12%| 12.72%| 0.09%| |m.BigIntegers.testMultiply | -0.03%| 0.01%| -0.37%| 0.19%| -0.07%| |m.BigIntegers.testRightShift | 0.45%| 0.17%| 0.13%| 0.06%| 0.62%| |m.BigIntegers.testSmallToString | -0.22%| -3.08%| 10.58%| -0.11%| -0.14%| |s.AlgorithmConstraintsPermits.permits-algorithm:DES | 0.09%| -0.03%| 0.00%| -0.05%| 0.00%| |s.AlgorithmConstraintsPermits.permits-algorithm:NULL | 3.46%| -0.00%| -0.09%| -0.25%| 0.05%| |s.AlgorithmConstraintsPermits.permits-algorithm:SSLv3 | 0.18%| 0.00%| -0.07%| 0.05%| -0.78%| |s.AlgorithmConstraintsPermits.permits-algorithm:TLS1_3 | -3.55%| 0.01%| 0.19%| -0.06%| 0.28%| |s.CacheBench.get-size:20480-timeout:0 | -0.75%| 2.24%| 0.37%| -0.06%| -1.10%| |s.CacheBench.get-size:20480-timeout:86400 | -0.28%| 0.11%| -0.18%| 1.03%| 0.99%| |s.CacheBench.get-size:204800-timeout:0 | -0.62%| -1.72%| -2.97%| -0.50%| -0.43%| |s.CacheBench.get-size:204800-timeout:86400 | 1.42%| -0.73%| 0.17%| -0.29%| 0.08%| |s.CacheBench.get-size:5120000-timeout:0 | 3.95%| 4.65%| 1.70%| -1.18%| 3.32%| |s.CacheBench.get-size:5120000-timeout:86400 | -0.62%| 1.36%| -0.12%| 0.78%| -3.43%| |s.CacheBench.put-size:20480-timeout:0 | -0.24%| 2.44%| -0.55%| -1.15%| 2.81%| |s.CacheBench.put-size:20480-timeout:86400 | -0.25%| 1.56%| -0.13%| -0.21%| -0.19%| |s.CacheBench.put-size:204800-timeout:0 | -0.71%| -1.07%| 0.19%| 0.12%| 0.42%| |s.CacheBench.put-size:204800-timeout:86400 | -0.16%| 1.15%| 0.08%| -0.17%| 0.85%| |s.CacheBench.put-size:5120000-timeout:0 | 0.67%| 2.10%| 2.44%| 1.80%| -2.10%| |s.CacheBench.put-size:5120000-timeout:86400 | 0.35%| 0.56%| -1.37%| 0.17%| 1.14%| |s.CacheBench.remove-size:20480-timeout:0 | 3.87%| 0.52%| 0.92%| 0.35%| -0.74%| |s.CacheBench.remove-size:20480-timeout:86400 | 1.00%| 0.61%| 0.08%| 0.32%| -1.49%| |s.CacheBench.remove-size:204800-timeout:0 | 3.90%| 0.86%| 1.37%| -1.25%| -0.62%| |s.CacheBench.remove-size:204800-timeout:86400 | -3.40%| 0.73%| -0.11%| 0.10%| -2.99%| |s.CacheBench.remove-size:5120000-timeout:0 | -2.43%| -3.88%| -0.51%| 0.46%| 0.12%| |s.CacheBench.remove-size:5120000-timeout:86400 | 3.82%| -0.07%| -0.36%| -2.73%| -1.58%| |s.CipherSuiteBench.benchmarkCipherSuite-cipherSuite:TLS_AES_256_GCM_SHA384 | -0.19%| -1.17%| 0.33%| -5.94%| 2.67%| |s.CipherSuiteBench.benchmarkCipherSuite-cipherSuite:TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 | -2.48%| 2.27%| 0.50%| -1.16%| -0.61%| |s.CipherSuiteBench.benchmarkCipherSuite-cipherSuite:TLS_DHE_RSA_WITH_AES_256_CBC_SHA | -0.21%| -1.97%| -0.47%| -0.20%| 0.00%| |s.CipherSuiteBench.benchmarkCipherSuite-cipherSuite:TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384| 1.30%| 1.64%| -0.12%| -3.01%| -3.36%| |s.DoPrivileged.test | 0.34%| 0.02%| -0.11%| 0.07%| -4.00%| |s.DoPrivileged.testInline | -0.34%| -0.01%| -0.04%| 14.05%| -9.02%| |s.GetContext.Deep.testNonPrivRecurse-depth:2 | -0.19%| -1.48%| -1.63%| -0.35%| 0.66%| |s.GetContext.Deep.testNonPrivRecurse-depth:50 | 5.26%| -0.67%| -1.27%| 1.48%| -0.64%| |s.GetContext.Deep.testPrivInline-depth:2 | -5.64%| 1.09%| 0.36%| -0.14%| -0.43%| |s.GetContext.Deep.testPrivInline-depth:50 | 1.33%| -2.29%| -0.44%| 0.76%| -1.06%| |s.GetContext.Top.testNonPriv | 1.80%| 1.45%| -0.85%| 0.44%| -0.07%| |s.GetContext.Top.testPriv | -4.01%| 1.43%| 0.38%| -1.05%| -0.31%| |s.GetMessageDigest.cloneInstance-digesterName:SHA_1 | 2.12%| 0.49%| -0.28%| -0.07%| -3.90%| |s.GetMessageDigest.cloneInstance-digesterName:SHA_256 | 0.73%| -0.40%| 0.25%| 0.73%| -0.89%| |s.GetMessageDigest.cloneInstance-digesterName:md5 | 0.53%| -1.36%| 0.13%| -0.13%| -2.36%| |s.GetMessageDigest.getInstance-digesterName:SHA_1 | -2.08%| 1.18%| -0.24%| -2.59%| 0.30%| |s.GetMessageDigest.getInstance-digesterName:SHA_256 | 1.58%| 0.86%| 0.18%| 0.56%| 3.53%| |s.GetMessageDigest.getInstance-digesterName:md5 | -1.74%| -3.66%| -0.20%| 0.01%| 7.36%| |s.GetMessageDigest.getInstanceWithProvider-digesterName:SHA_1 | 0.83%| -0.51%| 0.11%| -0.32%| 0.12%| |s.GetMessageDigest.getInstanceWithProvider-digesterName:SHA_256 | 0.90%| 1.06%| 0.14%| 2.48%| -1.64%| |s.GetMessageDigest.getInstanceWithProvider-digesterName:md5 | -0.05%| 1.61%| -0.11%| -0.13%| -0.06%| |s.HSS.test01.verify-test:RFC 8554 1 | 1.00%| 0.45%| -1.15%| -0.03%| 0.57%| |s.HSS.test02.verify-test:RFC 8554 2 | -0.18%| 0.33%| 0.76%| -0.26%| 0.45%| |s.HSS.test03.verify-test: h15_w8 | -0.09%| -0.00%| -0.23%| -0.10%| -0.73%| |s.HSS.test04.verify-test: h20_w8 | -0.83%| -0.02%| -0.49%| 0.23%| 0.17%| |s.HSS.test05.verify-test: h15_w4 | 0.15%| 0.25%| 0.54%| 0.05%| -0.21%| |s.HSS.test06.verify-test: h20_w4 | 0.00%| 0.33%| 2.65%| -0.47%| 1.04%| |s.HSS.test07.verify-test:h15_w4_h10_w4 | 0.14%| 0.19%| 0.17%| -0.48%| -0.04%| |s.HSS.test08.verify-test:h15_w4_h15_w4 | 0.10%| 0.51%| -0.38%| 0.12%| 0.59%| |s.HSS.test09.verify-test:h20_w4_h10_w4 | -0.01%| 0.82%| -0.12%| 0.37%| -0.79%| |s.HSS.test10.verify-test:h20_w4_h15_w4 | -0.12%| -1.20%| -0.09%| 0.04%| 1.02%| |s.HSS.verify-test:noop | -1.78%| -4.47%| -3.98%| -1.69%| -5.32%| |s.MessageDigests.digest-digesterName:SHA3_256-length:16384-provider:DEFAULT | 0.00%| 0.02%| 0.02%| 0.04%| 0.36%| |s.MessageDigests.digest-digesterName:SHA3_256-length:64-provider:DEFAULT | 0.08%| -0.10%| 0.03%| -0.37%| -0.52%| |s.MessageDigests.digest-digesterName:SHA3_512-length:16384-provider:DEFAULT | 0.02%| 0.01%| 0.02%| 0.11%| 0.03%| |s.MessageDigests.digest-digesterName:SHA3_512-length:64-provider:DEFAULT | -0.22%| 0.03%| 0.03%| -0.04%| 0.17%| |s.MessageDigests.digest-digesterName:SHA_1-length:16384-provider:DEFAULT | -0.01%| -0.02%| 0.05%| 0.19%| -0.03%| |s.MessageDigests.digest-digesterName:SHA_1-length:64-provider:DEFAULT | 0.55%| -0.70%| -5.04%| -0.02%| -0.44%| |s.MessageDigests.digest-digesterName:SHA_224-length:16384-provider:DEFAULT | 0.00%| -0.01%| 0.08%| -0.13%| 0.02%| |s.MessageDigests.digest-digesterName:SHA_224-length:64-provider:DEFAULT | 1.11%| 0.06%| 0.97%| -0.24%| 1.81%| |s.MessageDigests.digest-digesterName:SHA_256-length:16384-provider:DEFAULT | 0.00%| -0.01%| 0.03%| -0.10%| 0.05%| |s.MessageDigests.digest-digesterName:SHA_256-length:64-provider:DEFAULT | 0.31%| 0.05%| -0.96%| -0.60%| -0.39%| |s.MessageDigests.digest-digesterName:SHA_384-length:16384-provider:DEFAULT | -0.01%| -0.03%| 0.01%| -0.08%| 0.08%| |s.MessageDigests.digest-digesterName:SHA_384-length:64-provider:DEFAULT | 0.09%| -0.46%| 2.90%| -0.18%| -0.27%| |s.MessageDigests.digest-digesterName:SHA_512-length:16384-provider:DEFAULT | -0.00%| -0.02%| -0.00%| 0.01%| 0.03%| |s.MessageDigests.digest-digesterName:SHA_512-length:64-provider:DEFAULT | -0.05%| -0.76%| -1.10%| 0.18%| 0.42%| |s.MessageDigests.digest-digesterName:md5-length:16384-provider:DEFAULT | -0.00%| -0.01%| -0.00%| 0.11%| -0.00%| |s.MessageDigests.digest-digesterName:md5-length:64-provider:DEFAULT | -0.02%| 0.03%| 2.25%| -1.43%| -0.21%| |s.MessageDigests.getAndDigest-digesterName:SHA3_256-length:16384-provider:DEFAULT | 0.01%| 0.14%| 0.01%| 0.42%| -0.13%| |s.MessageDigests.getAndDigest-digesterName:SHA3_256-length:64-provider:DEFAULT | 0.13%| 0.09%| 0.10%| -0.00%| -0.33%| |s.MessageDigests.getAndDigest-digesterName:SHA3_512-length:16384-provider:DEFAULT | -0.04%| -0.07%| -0.05%| -0.04%| 0.30%| |s.MessageDigests.getAndDigest-digesterName:SHA3_512-length:64-provider:DEFAULT | -0.10%| -0.15%| -0.01%| -0.59%| 0.27%| |s.MessageDigests.getAndDigest-digesterName:SHA_1-length:16384-provider:DEFAULT | -0.02%| 0.02%| -0.09%| -0.01%| 0.06%| |s.MessageDigests.getAndDigest-digesterName:SHA_1-length:64-provider:DEFAULT | -0.05%| 1.05%| 2.55%| 0.02%| -0.01%| |s.MessageDigests.getAndDigest-digesterName:SHA_224-length:16384-provider:DEFAULT | -0.15%| -0.09%| -0.14%| -0.20%| 0.07%| |s.MessageDigests.getAndDigest-digesterName:SHA_224-length:64-provider:DEFAULT | 0.12%| 0.29%| 5.47%| -0.02%| -0.06%| |s.MessageDigests.getAndDigest-digesterName:SHA_256-length:16384-provider:DEFAULT | 0.00%| 0.00%| -0.00%| 0.12%| -0.14%| |s.MessageDigests.getAndDigest-digesterName:SHA_256-length:64-provider:DEFAULT | -0.60%| -0.10%| 0.60%| 0.21%| 0.24%| |s.MessageDigests.getAndDigest-digesterName:SHA_384-length:16384-provider:DEFAULT | -0.01%| -0.03%| 0.00%| 0.13%| 0.09%| |s.MessageDigests.getAndDigest-digesterName:SHA_384-length:64-provider:DEFAULT | -0.74%| -0.42%| 0.23%| -0.63%| -0.38%| |s.MessageDigests.getAndDigest-digesterName:SHA_512-length:16384-provider:DEFAULT | -0.01%| 0.03%| -0.06%| 0.11%| 0.15%| |s.MessageDigests.getAndDigest-digesterName:SHA_512-length:64-provider:DEFAULT | -0.78%| 0.48%| -0.16%| 0.58%| -0.75%| |s.MessageDigests.getAndDigest-digesterName:md5-length:16384-provider:DEFAULT | -0.04%| -0.01%| -0.01%| 0.00%| -0.00%| |s.MessageDigests.getAndDigest-digesterName:md5-length:64-provider:DEFAULT | 0.17%| 0.23%| 1.53%| -0.56%| 0.37%| |s.PKCS12KeyStores.instrong10000_New | 1.49%| -1.52%| 0.01%| 1.80%| 0.79%| |s.PKCS12KeyStores.instrong2048 | 0.34%| -1.44%| -1.84%| 1.20%| -0.02%| |s.PKCS12KeyStores.instrong50000 | -1.35%| -0.10%| -6.56%| 0.66%| -0.01%| |s.PKCS12KeyStores.inweak2048 | 1.48%| -0.08%| -1.12%| 0.49%| -0.55%| |s.PKCS12KeyStores.inweak50000_Old | 0.75%| 0.32%| -0.38%| -0.86%| 0.48%| |s.PKCS12KeyStores.outstrong10000_New | 0.03%| 2.20%| -0.33%| -0.52%| 2.87%| |s.PKCS12KeyStores.outstrong2048 | 0.09%| -1.31%| -2.58%| 0.58%| -1.58%| |s.PKCS12KeyStores.outstrong50000 | 0.12%| -3.98%| -1.03%| -1.77%| 0.15%| |s.PKCS12KeyStores.outweak2048 | 0.10%| 0.82%| -0.18%| 2.40%| -2.75%| |s.PKCS12KeyStores.outweak50000_Old | 0.47%| 0.01%| -0.52%| -0.54%| -3.71%| |s.PermissionsImplies.withPermission | -0.18%| 0.00%| 0.01%| -0.01%| -0.71%| |s.PermissionsImplies.withUnresolvedPermission | -4.60%| -0.08%| 0.01%| 0.03%| 3.59%| |s.PermissionsImplies.withoutPermission | 0.01%| -1.29%| -0.23%| 0.25%| 0.07%| |s.ProtectionDomainBench.noSecurityManager-numberOfClasses:100-numberOfCodeSources:10 | -0.01%| 1.10%| 0.27%| 0.55%| -0.39%| |s.ProtectionDomainBench.withSecurityManager-numberOfClasses:100-numberOfCodeSources:10 | -1.70%| -1.36%| -0.36%| -2.10%| 1.59%| |s.SSLHandshake.doHandshake-resume:false-tlsVersion:TLS | -0.35%| 0.51%| 0.00%| -0.08%| -0.36%| |s.SSLHandshake.doHandshake-resume:false-tlsVersion:TLSv1_2 | -0.12%| 0.37%| -0.09%| 0.32%| -0.10%| |s.SSLHandshake.doHandshake-resume:true-tlsVersion:TLS | 0.27%| 0.35%| 0.24%| -0.17%| -0.78%| |s.SSLHandshake.doHandshake-resume:true-tlsVersion:TLSv1_2 | -1.20%| -0.36%| -0.06%| -1.43%| 0.29%| |s.Signatures.DSA.sign-algorithm:SHA256withDSA-messageLength:16384 | 0.03%| -0.03%| 0.01%| 0.16%| -0.03%| |s.Signatures.DSA.sign-algorithm:SHA256withDSA-messageLength:2048 | -0.02%| -0.01%| -0.00%| 0.19%| 0.06%| |s.Signatures.DSA.sign-algorithm:SHA256withDSA-messageLength:512 | -0.03%| -0.06%| 0.01%| 0.28%| -0.14%| |s.Signatures.DSA.sign-algorithm:SHA256withDSA-messageLength:64 | -0.05%| -0.04%| 0.01%| 0.13%| 0.04%| |s.Signatures.DSA.sign-algorithm:SHA384withDSA-messageLength:16384 | -0.02%| 0.05%| -0.02%| -0.12%| -0.42%| |s.Signatures.DSA.sign-algorithm:SHA384withDSA-messageLength:2048 | 0.01%| 0.01%| -0.00%| -0.31%| -0.01%| |s.Signatures.DSA.sign-algorithm:SHA384withDSA-messageLength:512 | -0.02%| -0.04%| -0.01%| 0.60%| -0.02%| |s.Signatures.DSA.sign-algorithm:SHA384withDSA-messageLength:64 | -0.03%| -0.04%| -0.06%| -0.09%| -0.06%| |s.Signatures.DSA.sign-algorithm:SHA512withDSA-messageLength:16384 | 0.01%| -0.03%| 0.02%| 0.13%| -0.03%| |s.Signatures.DSA.sign-algorithm:SHA512withDSA-messageLength:2048 | -0.00%| 0.03%| 0.04%| 0.07%| -0.05%| |s.Signatures.DSA.sign-algorithm:SHA512withDSA-messageLength:512 | -0.00%| 0.02%| -0.01%| -0.13%| 0.02%| |s.Signatures.DSA.sign-algorithm:SHA512withDSA-messageLength:64 | -0.04%| -0.06%| -0.03%| -0.37%| -0.03%| |s.Signatures.EdDSA.sign-algorithm:Ed25519-messageLength:16384 | -0.03%| -0.84%| -0.05%| 0.07%| 0.18%| |s.Signatures.EdDSA.sign-algorithm:Ed25519-messageLength:2048 | -0.02%| 0.11%| 0.03%| -0.06%| -0.62%| |s.Signatures.EdDSA.sign-algorithm:Ed25519-messageLength:512 | -0.06%| 1.11%| 0.09%| 0.62%| -1.25%| |s.Signatures.EdDSA.sign-algorithm:Ed25519-messageLength:64 | -0.01%| -1.12%| -0.00%| -0.43%| -0.31%| |s.Signatures.EdDSA.sign-algorithm:Ed448-messageLength:16384 | -0.03%| 1.01%| -0.03%| 0.01%| 0.58%| |s.Signatures.EdDSA.sign-algorithm:Ed448-messageLength:2048 | 0.05%| 0.27%| -0.04%| -0.18%| 1.90%| |s.Signatures.EdDSA.sign-algorithm:Ed448-messageLength:512 | -0.08%| 0.42%| -0.19%| -0.12%| 0.01%| |s.Signatures.EdDSA.sign-algorithm:Ed448-messageLength:64 | 0.03%| -0.62%| 0.12%| -0.43%| 3.17%| |s.Signatures.RSA.sign-algorithm:SHA256withRSA-messageLength:16384 | 0.02%| -0.37%| 0.32%| -0.11%| -0.09%| |s.Signatures.RSA.sign-algorithm:SHA256withRSA-messageLength:2048 | 0.03%| -0.23%| -0.06%| 0.02%| 0.21%| |s.Signatures.RSA.sign-algorithm:SHA256withRSA-messageLength:512 | -0.10%| 0.07%| 0.34%| -0.01%| -0.29%| |s.Signatures.RSA.sign-algorithm:SHA256withRSA-messageLength:64 | 0.19%| 0.28%| -0.25%| 0.07%| 0.07%| |s.Signatures.RSA.sign-algorithm:SHA384withRSA-messageLength:16384 | 0.04%| -0.10%| -0.14%| 0.42%| 0.36%| |s.Signatures.RSA.sign-algorithm:SHA384withRSA-messageLength:2048 | 0.04%| -0.00%| -0.20%| 0.00%| 0.82%| |s.Signatures.RSA.sign-algorithm:SHA384withRSA-messageLength:512 | -0.03%| -0.23%| 0.04%| 0.09%| -0.11%| |s.Signatures.RSA.sign-algorithm:SHA384withRSA-messageLength:64 | -0.13%| -0.11%| 0.08%| 0.70%| 0.24%| |s.Signatures.RSA.sign-algorithm:SHA512withRSA-messageLength:16384 | 0.11%| 0.04%| 0.04%| 0.11%| 0.05%| |s.Signatures.RSA.sign-algorithm:SHA512withRSA-messageLength:2048 | -0.05%| 0.21%| 0.04%| 0.20%| 0.27%| |s.Signatures.RSA.sign-algorithm:SHA512withRSA-messageLength:512 | -0.00%| 0.01%| -0.04%| 0.11%| -0.03%| |s.Signatures.RSA.sign-algorithm:SHA512withRSA-messageLength:64 | 0.01%| -0.48%| 0.11%| 0.22%| 0.02%| |s.Signatures.RSASSAPSS.sign-algorithm:SHA256-messageLength:16384 | 0.15%| 0.07%| -0.19%| -0.26%| -0.02%| |s.Signatures.RSASSAPSS.sign-algorithm:SHA256-messageLength:2048 | 0.17%| -0.01%| -0.22%| -0.63%| -0.19%| |s.Signatures.RSASSAPSS.sign-algorithm:SHA256-messageLength:512 | -0.32%| -0.15%| -0.06%| -0.01%| 0.22%| |s.Signatures.RSASSAPSS.sign-algorithm:SHA256-messageLength:64 | 0.00%| -0.05%| 0.08%| 0.06%| 0.01%| |s.Signatures.RSASSAPSS.sign-algorithm:SHA384-messageLength:16384 | -0.03%| 0.05%| -0.06%| 0.68%| 0.21%| |s.Signatures.RSASSAPSS.sign-algorithm:SHA384-messageLength:2048 | 0.01%| -0.10%| 0.04%| 0.10%| 0.15%| |s.Signatures.RSASSAPSS.sign-algorithm:SHA384-messageLength:512 | -0.01%| -0.06%| 0.02%| -0.49%| 0.58%| |s.Signatures.RSASSAPSS.sign-algorithm:SHA384-messageLength:64 | 0.11%| -0.24%| -0.07%| 0.24%| -0.13%| |s.Signatures.RSASSAPSS.sign-algorithm:SHA512-messageLength:16384 | -0.02%| -0.17%| 0.05%| 0.06%| 0.07%| |s.Signatures.RSASSAPSS.sign-algorithm:SHA512-messageLength:2048 | -0.08%| -0.06%| 0.15%| 0.09%| -0.10%| |s.Signatures.RSASSAPSS.sign-algorithm:SHA512-messageLength:512 | -0.04%| 0.00%| 0.24%| 0.08%| 0.03%| |s.Signatures.RSASSAPSS.sign-algorithm:SHA512-messageLength:64 | 0.05%| 0.07%| -0.16%| 0.21%| 0.09%| |s.Signatures.sign-algorithm:secp256r1-messageLength:16384 | 0.11%| 0.25%| -0.83%| -0.35%| 0.68%| |s.Signatures.sign-algorithm:secp256r1-messageLength:2048 | 0.07%| 1.17%| 0.50%| -0.14%| -0.38%| |s.Signatures.sign-algorithm:secp256r1-messageLength:512 | -0.01%| 3.95%| -0.22%| -0.37%| -0.45%| |s.Signatures.sign-algorithm:secp256r1-messageLength:64 | 0.00%| 3.77%| -0.19%| -0.21%| -0.38%| |s.Signatures.sign-algorithm:secp384r1-messageLength:16384 | -0.03%| 0.44%| 0.09%| -0.22%| 0.21%| |s.Signatures.sign-algorithm:secp384r1-messageLength:2048 | -0.05%| 0.88%| -0.53%| -0.09%| 0.53%| |s.Signatures.sign-algorithm:secp384r1-messageLength:512 | -0.00%| 0.36%| 0.03%| -0.23%| 0.27%| |s.Signatures.sign-algorithm:secp384r1-messageLength:64 | -0.00%| -0.36%| 0.31%| 0.31%| 0.12%| |s.Signatures.sign-algorithm:secp521r1-messageLength:16384 | -0.01%| 0.51%| -0.01%| -0.03%| 0.58%| |s.Signatures.sign-algorithm:secp521r1-messageLength:2048 | -0.01%| 0.07%| 0.04%| -0.17%| 0.51%| |s.Signatures.sign-algorithm:secp521r1-messageLength:512 | 0.00%| -0.14%| -0.05%| -0.18%| -1.12%| |s.Signatures.sign-algorithm:secp521r1-messageLength:64 | -0.01%| -0.27%| 0.03%| -0.24%| 0.62%| ------------- PR Comment: https://git.openjdk.org/jdk/pull/14630#issuecomment-1806069239 From alanb at openjdk.org Fri Nov 10 16:59:15 2023 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 10 Nov 2023 16:59:15 GMT Subject: RFR: JDK-8319123 : Implementation of JEP-461: Stream Gatherers (Preview) [v3] In-Reply-To: References: Message-ID: On Fri, 10 Nov 2023 09:32:17 GMT, Viktor Klang wrote: >> This Pull-Request implements [JEP-461](https://openjdk.org/jeps/461) > > Viktor Klang has updated the pull request incrementally with two additional commits since the last revision: > > - Multiple improvements to Gatherer and Gatherers javadoc and restructuring of Gatherers.java to put public at the top of the file. > - Augmenting Gatherer tests to include default implementation in Stream I did another pass over the API/docs with the latest changes and it looks very good, this is a really nice API. src/java.base/share/classes/java/util/stream/Gatherer.java line 91: > 89: * > 90: *

    In addition to the predefined implementations in {@link Gatherers}, the > 91: * static factory methods {@code of(...)} and {@code ofSequential(...)} I assume both of these could be links. src/java.base/share/classes/java/util/stream/Gatherer.java line 479: > 477: * > 478: *

    If this method returns {@code false} then the next stage does > 479: * not accept any more elements. So once push returns false then any further attempts to push to this downstream will also return false. src/java.base/share/classes/java/util/stream/Gatherer.java line 494: > 492: * never return false again for the same instance. > 493: * > 494: *

    By default this method returns {@code false}. The text that specifies the default implementation can be in implSpec rather than the apiNote. I agree that false is the only sane default here. src/java.base/share/classes/java/util/stream/Gatherer.java line 528: > 526: * {@code false} if not > 527: */ > 528: boolean integrate(A state, T element, Downstream downstream); Integrator is silent on nulls and whether NPE is thrown. ------------- PR Review: https://git.openjdk.org/jdk/pull/16420#pullrequestreview-1725141944 PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1389643747 PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1389620446 PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1389617514 PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1389625114 From alanb at openjdk.org Fri Nov 10 17:01:57 2023 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 10 Nov 2023 17:01:57 GMT Subject: RFR: 8319928: Exceptions thrown by cleanup actions passed to reinterpreted segments should be ignored In-Reply-To: References: Message-ID: <_LYagooqKKD-wN7nHMeMojx5Y8iV8SUwz82-0NYOfqQ=.7b1a3a41-f4bc-4817-a5d9-0a250bc5dabd@github.com> On Fri, 10 Nov 2023 16:34:11 GMT, Maurizio Cimadamore wrote: > This simplePR tweaks the factory which wraps custom cleanup actions passed to `MemorySegment::reinterpret`, so that any exception thrown by the custom cleanup is swallowed when the arena is closed. > > This aligns the behavior of confined/shared session with that of implicit session (as implicit sessions are backed by a `Cleaner`, there is no way for cleanup exception to bubble up). src/java.base/share/classes/jdk/internal/foreign/MemorySessionImpl.java line 283: > 281: cleanupAction.run(); > 282: } catch (Throwable ex) { > 283: // swallow @tprinzing This may be an area that you want to look at sometime to see if a JFR event might make sense. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16619#discussion_r1389654209 From mcimadamore at openjdk.org Fri Nov 10 17:08:57 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Fri, 10 Nov 2023 17:08:57 GMT Subject: RFR: 8319928: Exceptions thrown by cleanup actions passed to reinterpreted segments should be ignored In-Reply-To: <_LYagooqKKD-wN7nHMeMojx5Y8iV8SUwz82-0NYOfqQ=.7b1a3a41-f4bc-4817-a5d9-0a250bc5dabd@github.com> References: <_LYagooqKKD-wN7nHMeMojx5Y8iV8SUwz82-0NYOfqQ=.7b1a3a41-f4bc-4817-a5d9-0a250bc5dabd@github.com> Message-ID: <-LCzebaOVE9AUvDZEgFu-gTJ_ZGgP-qA9H20ZUQU4_M=.93655544-09ed-46f7-a016-ff1ed519c9d0@github.com> On Fri, 10 Nov 2023 16:59:09 GMT, Alan Bateman wrote: > @tprinzing This may be an area that you want to look at sometime to see if a JFR event might make sense. Might make sense - I suggest that should be done also for Cleaner - as that's using same mechanism (and no JFR events) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16619#discussion_r1389663264 From ihse at openjdk.org Fri Nov 10 17:18:59 2023 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 10 Nov 2023 17:18:59 GMT Subject: RFR: JDK-8317799 : AIX PPC64: FFI symbol lookup doesn't find symbols In-Reply-To: References: Message-ID: On Mon, 30 Oct 2023 10:54:48 GMT, suchismith1993 wrote: > 1. Adding required compiler flags. > 2. Adding required symbols. > > JBS-ISSUE : [JDK-8317799](https://bugs.openjdk.org/browse/JDK-8317799) Not even using `nm` on the libraries in question? The file seem to be consumed by the compiler, presumably it does not like any additional content such as comments. In that case, you need to put the documentation outside the file, perhaps where it is used. Or, if it is too complex to describe in the make source code, just add a link to the wiki or similar place where the procedure is described. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16414#issuecomment-1806115517 From dfuchs at openjdk.org Fri Nov 10 17:54:27 2023 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Fri, 10 Nov 2023 17:54:27 GMT Subject: RFR: JDK-8319123 : Implementation of JEP-461: Stream Gatherers (Preview) [v3] In-Reply-To: References: Message-ID: On Fri, 10 Nov 2023 09:32:17 GMT, Viktor Klang wrote: >> This Pull-Request implements [JEP-461](https://openjdk.org/jeps/461) > > Viktor Klang has updated the pull request incrementally with two additional commits since the last revision: > > - Multiple improvements to Gatherer and Gatherers javadoc and restructuring of Gatherers.java to put public at the top of the file. > - Augmenting Gatherer tests to include default implementation in Stream Very nice API. Some minor suggestions and comments (and one fix for one of the examples). I only looked at the API. src/java.base/share/classes/java/util/stream/Gatherer.java line 45: > 43: * or be parallelized -- if a combiner function is supplied. > 44: * > 45: *

    Examples of gathering operations include, but is not limited to: > Examples of ... but _are_ not limited to src/java.base/share/classes/java/util/stream/Gatherer.java line 115: > 113: * Gatherer toString = map(i -> i.toString()); > 114: * > 115: * Gatherer incrementThenToString = plusOne.andThen(intToString); Suggestion: * Gatherer incrementThenToString = increment.andThen(intToString); src/java.base/share/classes/java/util/stream/Gatherer.java line 138: > 136: * ); > 137: * } > 138: * } I would have appreciated a usage example here - with a stream of input elements and what such a gatherer would produce as output. src/java.base/share/classes/java/util/stream/Gatherer.java line 250: > 248: * @param that the other gatherer > 249: * @param The type of output of that Gatherer > 250: * @throws NullPointerException if the argument is null Suggestion: * @throws NullPointerException if the argument is {@code null} src/java.base/share/classes/java/util/stream/Gatherer.java line 312: > 310: * @param the type of input elements for the new gatherer > 311: * @param the type of results for the new gatherer > 312: * @throws NullPointerException if the argument is null Suggestion: * @throws NullPointerException if the argument is {@code null} src/java.base/share/classes/java/util/stream/Gatherer.java line 333: > 331: * @param the type of input elements for the new gatherer > 332: * @param the type of results for the new gatherer > 333: * @throws NullPointerException if any argument is null Suggestion: * @throws NullPointerException if any argument is {@code null} src/java.base/share/classes/java/util/stream/Gatherer.java line 356: > 354: * @param the type of initializer for the new gatherer > 355: * @param the type of results for the new gatherer > 356: * @throws NullPointerException if any argument is null Suggestion: * @throws NullPointerException if any argument is {@code null} src/java.base/share/classes/java/util/stream/Gatherer.java line 402: > 400: * @param the type of input elements for the new gatherer > 401: * @param the type of results for the new gatherer > 402: * @throws NullPointerException if any argument is null Suggestion: * @throws NullPointerException if any argument is {@code null} src/java.base/share/classes/java/util/stream/Gatherer.java line 422: > 420: * @param the type of input elements for the new gatherer > 421: * @param the type of results for the new gatherer > 422: * @throws NullPointerException if any argument is null Suggestion: * @throws NullPointerException if any argument is {@code null} src/java.base/share/classes/java/util/stream/Gatherer.java line 448: > 446: * @param the type of initializer for the new gatherer > 447: * @param the type of results for the new gatherer > 448: * @throws NullPointerException if any argument is null Suggestion: * @throws NullPointerException if any argument is {@code null} src/java.base/share/classes/java/util/stream/Gatherer.java line 492: > 490: * > 491: * @apiNote This is best-effort only, once this returns true it should > 492: * never return false again for the same instance. Suggestion: * @apiNote This is best-effort only, once this returns {@code true} it should * never return {@code false} again for the same instance. src/java.base/share/classes/java/util/stream/Gatherer.java line 577: > 575: interface Greedy extends Integrator { } > 576: } > 577: } Looks like there is no newline at the end of this file. Though newline at end of file is not mandatory it avoids getting warning in some tools (such as IDE etc...) Suggestion: } src/java.base/share/classes/java/util/stream/Gatherers.java line 80: > 78: * and the contents of the windows it produces > 79: * @return a new gatherer which groups elements into fixed-size windows > 80: * @throws IllegalArgumentException when windowSize is less than 1 Suggestion: * @throws IllegalArgumentException when {@code windowSize} is less than 1 src/java.base/share/classes/java/util/stream/Gatherers.java line 164: > 162: * and the contents of the windows it produces > 163: * @return a new gatherer which groups elements into sliding windows > 164: * @throws IllegalArgumentException when windowSize is less than 1 Suggestion: * @throws IllegalArgumentException when {@code windowSize} is less than 1 src/java.base/share/classes/java/util/stream/Gatherers.java line 235: > 233: *

    Example: > 234: * {@snippet lang = java: > 235: * // will contain: Optional[123456789] Suggestion: * // will contain: Optional["123456789"] src/java.base/share/classes/java/util/stream/Gatherers.java line 251: > 249: * @param the type of elements the returned gatherer produces > 250: * @return a new Gatherer > 251: * @throws NullPointerException if any of the parameters are null Suggestion: * @throws NullPointerException if any of the parameters are {@code null} src/java.base/share/classes/java/util/stream/Gatherers.java line 284: > 282: *

    Example: > 283: * {@snippet lang = java: > 284: * // will contain: [1, 12, 123, 1234, 12345, 123456, 1234567, 12345678, 123456789] Suggestion: * // will contain: ["1", "12", "123", "1234", "12345", "123456", "1234567", "12345678", "123456789"] src/java.base/share/classes/java/util/stream/Gatherers.java line 298: > 296: * @param the type of element which this gatherer produces > 297: * @return a new Gatherer which performs a prefix scan > 298: * @throws NullPointerException if any of the parameters are null Suggestion: * @throws NullPointerException if any of the parameters are {@code null} src/java.base/share/classes/java/util/stream/Gatherers.java line 320: > 318: * An operation which executes operations concurrently > 319: * with a fixed window of max concurrency, using > 320: * virtual threads. Suggestion: * {@linkplain Thread##virtual-threads virtual threads}. src/java.base/share/classes/java/util/stream/Gatherers.java line 337: > 335: * @return a new Gatherer > 336: * @throws IllegalArgumentException if maxConcurrency is less than 1 > 337: * @throws NullPointerException if mapper is null Suggestion: * @throws IllegalArgumentException if {@code maxConcurrency} is less than 1 * @throws NullPointerException if mapper is {@code null} ------------- PR Review: https://git.openjdk.org/jdk/pull/16420#pullrequestreview-1725219596 PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1389667892 PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1389673357 PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1389677998 PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1389682609 PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1389685672 PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1389687482 PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1389687891 PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1389688993 PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1389689868 PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1389690634 PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1389691810 PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1389693254 PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1389696394 PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1389698730 PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1389700158 PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1389700567 PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1389701449 PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1389701795 PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1389702802 PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1389703538 From rgiulietti at openjdk.org Fri Nov 10 19:34:59 2023 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Fri, 10 Nov 2023 19:34:59 GMT Subject: RFR: 8311906: Improve robustness of String constructors with mutable array inputs [v2] In-Reply-To: References: <6SKlGLh5MmxoEx07wHCCUc8KWbbhcspLJmcc1uxQ_FI=.ca33bfb4-fa5c-45f0-b49f-ee6c5c6b68b4@github.com> Message-ID: On Thu, 9 Nov 2023 04:16:25 GMT, Roger Riggs wrote: >> Strings, after construction, are immutable but may be constructed from mutable arrays of bytes, characters, or integers. >> The string constructors should guard against the effects of mutating the arrays during construction that might invalidate internal invariants for the correct behavior of operations on the resulting strings. In particular, a number of operations have optimizations for operations on pairs of latin1 strings and pairs of non-latin1 strings, while operations between latin1 and non-latin1 strings use a more general implementation. >> >> The changes include: >> >> - Adding a warning to each constructor with an array as an argument to indicate that the results are indeterminate >> if the input array is modified before the constructor returns. >> The resulting string may contain any combination of characters sampled from the input array. >> >> - Ensure that strings that are represented as non-latin1 contain at least one non-latin1 character. >> For latin1 inputs, whether the arrays contain ASCII, ISO-8859-1, UTF8, or another encoding decoded to latin1 the scanning and compression is unchanged. >> If a non-latin1 character is found, the string is represented as non-latin1 with the added verification that a non-latin1 character is present at the same index. >> If that character is found to be latin1, then the input array has been modified and the result of the scan may be incorrect. >> Though a ConcurrentModificationException could be thrown, the risk to an existing application of an unexpected exception should be avoided. >> Instead, the non-latin1 copy of the input is re-scanned and compressed; that scan determines whether the latin1 or the non-latin1 representation is returned. >> >> - The methods that scan for non-latin1 characters and their intrinsic implementations are updated to return the index of the non-latin1 character. >> >> - String construction from StringBuilder and CharSequence must also be guarded as their contents may be modified during construction. > > Roger Riggs has updated the pull request incrementally with three additional commits since the last revision: > > - Refactored extractCodePoints to avoid multiple resizes if the array was modified > - Replaced isLatin1 implementation with `getChar(buf, ndx) <= 0xff` > It performs better than the single byte array access by avoiding the bounds check. > - Misc updates for review comments, javadoc cleanup > Extra checking on maximum string lengths when calling toBytes(). Second take: Java code in src/ looks good Next take will be about code in test/ ------------- PR Comment: https://git.openjdk.org/jdk/pull/16425#issuecomment-1806325709 From jlaskey at openjdk.org Fri Nov 10 20:00:28 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Fri, 10 Nov 2023 20:00:28 GMT Subject: RFR: JDK-8315458 JEP 463: Implementation of Implicitly Declared Classes and Instance Main Method (Second Preview) [v16] In-Reply-To: References: Message-ID: > Address changes from JEP 445 to JEP 463. > > - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. > > - Don't mark class on read. > > - Remove reflection and annotation processing related to unnamed classes. > > - Simplify main method search. Jim Laskey has updated the pull request incrementally with five additional commits since the last revision: - Simplified and compatible main method finding - Update LauncherHelper.java - Update tests - Misspelling - Clean up exception checks ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16461/files - new: https://git.openjdk.org/jdk/pull/16461/files/d3581d89..1bf935f4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16461&range=15 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16461&range=14-15 Stats: 232 lines in 8 files changed: 99 ins; 102 del; 31 mod Patch: https://git.openjdk.org/jdk/pull/16461.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16461/head:pull/16461 PR: https://git.openjdk.org/jdk/pull/16461 From jlaskey at openjdk.org Fri Nov 10 20:48:12 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Fri, 10 Nov 2023 20:48:12 GMT Subject: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v16] In-Reply-To: References: Message-ID: On Fri, 10 Nov 2023 20:00:28 GMT, Jim Laskey wrote: >> Address changes from JEP 445 to JEP 463. >> >> - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. >> >> - Don't mark class on read. >> >> - Remove reflection and annotation processing related to unnamed classes. >> >> - Simplify main method search. > > Jim Laskey has updated the pull request incrementally with five additional commits since the last revision: > > - Simplified and compatible main method finding > - Update LauncherHelper.java > - Update tests > - Misspelling > - Clean up exception checks Hold off reviewing until I get things cleaned up - I accidentally pushed some experimental code. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16461#issuecomment-1806408880 From vklang at openjdk.org Fri Nov 10 21:55:12 2023 From: vklang at openjdk.org (Viktor Klang) Date: Fri, 10 Nov 2023 21:55:12 GMT Subject: RFR: JDK-8319123 : Implementation of JEP-461: Stream Gatherers (Preview) [v3] In-Reply-To: References: Message-ID: On Fri, 10 Nov 2023 16:48:34 GMT, Alan Bateman wrote: >> Viktor Klang has updated the pull request incrementally with two additional commits since the last revision: >> >> - Multiple improvements to Gatherer and Gatherers javadoc and restructuring of Gatherers.java to put public at the top of the file. >> - Augmenting Gatherer tests to include default implementation in Stream > > src/java.base/share/classes/java/util/stream/Gatherer.java line 91: > >> 89: * >> 90: *

    In addition to the predefined implementations in {@link Gatherers}, the >> 91: * static factory methods {@code of(...)} and {@code ofSequential(...)} > > I assume both of these could be links. Unfortunately they can't, since they are both overloaded and here we're talking about them "generically". > src/java.base/share/classes/java/util/stream/Gatherer.java line 494: > >> 492: * never return false again for the same instance. >> 493: * >> 494: *

    By default this method returns {@code false}. > > The text that specifies the default implementation can be in implSpec rather than the apiNote. I agree that false is the only sane default here. Yeah, should likely be implSpec. Will change. > src/java.base/share/classes/java/util/stream/Gatherer.java line 528: > >> 526: * {@code false} if not >> 527: */ >> 528: boolean integrate(A state, T element, Downstream downstream); > > Integrator is silent on nulls and whether NPE is thrown. No sure what it should say regarding nulls. The `initializer` might return `null` in which case `state` would be `null`. `element` can be `null` if the stream contains `null`s. `Downstream` should never be null. Should the Javadoc say something about how RuntimeExceptions thrown must be interpreted by the caller? ? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1389957565 PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1389956115 PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1389957272 From vklang at openjdk.org Fri Nov 10 22:01:12 2023 From: vklang at openjdk.org (Viktor Klang) Date: Fri, 10 Nov 2023 22:01:12 GMT Subject: RFR: JDK-8319123 : Implementation of JEP-461: Stream Gatherers (Preview) [v3] In-Reply-To: References: Message-ID: On Fri, 10 Nov 2023 17:10:56 GMT, Daniel Fuchs wrote: >> Viktor Klang has updated the pull request incrementally with two additional commits since the last revision: >> >> - Multiple improvements to Gatherer and Gatherers javadoc and restructuring of Gatherers.java to put public at the top of the file. >> - Augmenting Gatherer tests to include default implementation in Stream > > src/java.base/share/classes/java/util/stream/Gatherer.java line 45: > >> 43: * or be parallelized -- if a combiner function is supplied. >> 44: * >> 45: *

    Examples of gathering operations include, but is not limited to: > >> Examples of ... but _are_ not limited to Will go with a different wording. > src/java.base/share/classes/java/util/stream/Gatherer.java line 115: > >> 113: * Gatherer toString = map(i -> i.toString()); >> 114: * >> 115: * Gatherer incrementThenToString = plusOne.andThen(intToString); > > Suggestion: > > * Gatherer incrementThenToString = increment.andThen(intToString); Will fix, thanks! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1389959973 PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1389960616 From vklang at openjdk.org Fri Nov 10 22:10:12 2023 From: vklang at openjdk.org (Viktor Klang) Date: Fri, 10 Nov 2023 22:10:12 GMT Subject: RFR: JDK-8319123 : Implementation of JEP-461: Stream Gatherers (Preview) [v3] In-Reply-To: References: Message-ID: On Fri, 10 Nov 2023 17:21:23 GMT, Daniel Fuchs wrote: >> Viktor Klang has updated the pull request incrementally with two additional commits since the last revision: >> >> - Multiple improvements to Gatherer and Gatherers javadoc and restructuring of Gatherers.java to put public at the top of the file. >> - Augmenting Gatherer tests to include default implementation in Stream > > src/java.base/share/classes/java/util/stream/Gatherer.java line 138: > >> 136: * ); >> 137: * } >> 138: * } > > I would have appreciated a usage example here - with a stream of input elements and what such a gatherer would produce as output. Wilco! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1389966709 From vklang at openjdk.org Fri Nov 10 22:10:14 2023 From: vklang at openjdk.org (Viktor Klang) Date: Fri, 10 Nov 2023 22:10:14 GMT Subject: RFR: JDK-8319123 : Implementation of JEP-461: Stream Gatherers (Preview) [v3] In-Reply-To: References: <3z8IYhG73DKYCv_643Jtb-nDyNRlaLPyvqoPTDeI6SM=.b336d2d0-29ea-4ee2-98e9-3d89f4f85a7d@github.com> <8U_gZrZdfBEfUJm394moAzoPXayVE6Sdh5rxWXVdcDc=.7731cb78-927f-4661-881e-c1b539bb6590@github.com> Message-ID: On Wed, 8 Nov 2023 17:15:11 GMT, R?mi Forax wrote: >> @amaembo In this case, given that it is intended as Preview, I think it makes sense to receive some user feedback on this. Note that Collector has been without PECS for Collector.of since 1.8: [of](https://docs.oracle.com/javase/8/docs/api/java/util/stream/Collector.html#of-java.util.function.Supplier-java.util.function.BiConsumer-java.util.function.BinaryOperator-java.util.function.Function-java.util.stream.Collector.Characteristics...-) >> >> Right now I don't want to deviate from the Collector-heritage until there's more usage feedback, and I'm definitely not ruling out that PECS:ing the factories might be worth it. > > I don't see the point of waiting here. Usually requests for PECSing signatures always comes two or three years after the API is realing when people starts to use the API in anger so the preview time is likely not enough. Postponing such a change as candidate for a potential second preview. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1389967686 From vklang at openjdk.org Fri Nov 10 22:10:15 2023 From: vklang at openjdk.org (Viktor Klang) Date: Fri, 10 Nov 2023 22:10:15 GMT Subject: RFR: JDK-8319123 : Implementation of JEP-461: Stream Gatherers (Preview) [v3] In-Reply-To: References: Message-ID: On Fri, 10 Nov 2023 09:32:17 GMT, Viktor Klang wrote: >> This Pull-Request implements [JEP-461](https://openjdk.org/jeps/461) > > Viktor Klang has updated the pull request incrementally with two additional commits since the last revision: > > - Multiple improvements to Gatherer and Gatherers javadoc and restructuring of Gatherers.java to put public at the top of the file. > - Augmenting Gatherer tests to include default implementation in Stream src/java.base/share/classes/java/util/stream/Gatherer.java line 380: > 378: * @param the type of initializer for the new gatherer > 379: * @param the type of results for the new gatherer > 380: * @throws NullPointerException if any argument is null Not here @dfuch ? :) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1389967961 From vklang at openjdk.org Fri Nov 10 22:10:18 2023 From: vklang at openjdk.org (Viktor Klang) Date: Fri, 10 Nov 2023 22:10:18 GMT Subject: RFR: JDK-8319123 : Implementation of JEP-461: Stream Gatherers (Preview) [v3] In-Reply-To: References: Message-ID: On Fri, 10 Nov 2023 16:25:44 GMT, Alan Bateman wrote: >> Viktor Klang has updated the pull request incrementally with two additional commits since the last revision: >> >> - Multiple improvements to Gatherer and Gatherers javadoc and restructuring of Gatherers.java to put public at the top of the file. >> - Augmenting Gatherer tests to include default implementation in Stream > > src/java.base/share/classes/java/util/stream/Gatherer.java line 479: > >> 477: * >> 478: *

    If this method returns {@code false} then the next stage does >> 479: * not accept any more elements. > > So once push returns false then any further attempts to push to this downstream will also return false. Yeah, perhaps should read something like: `If this method returns {@code false} then no further elements need to be pushed, and subsequent pushes will also return {@code false}.` ? (And make it an implSpec?) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1389969005 From vklang at openjdk.org Fri Nov 10 22:17:10 2023 From: vklang at openjdk.org (Viktor Klang) Date: Fri, 10 Nov 2023 22:17:10 GMT Subject: RFR: JDK-8319123 : Implementation of JEP-461: Stream Gatherers (Preview) [v3] In-Reply-To: References: Message-ID: <5na6chnuf908XKvaBS2VVxzRTFK0b1zvCpGG0hsaRWs=.273d0631-b05f-4d92-b747-2e6b81587dbe@github.com> On Fri, 10 Nov 2023 17:34:48 GMT, Daniel Fuchs wrote: >> Viktor Klang has updated the pull request incrementally with two additional commits since the last revision: >> >> - Multiple improvements to Gatherer and Gatherers javadoc and restructuring of Gatherers.java to put public at the top of the file. >> - Augmenting Gatherer tests to include default implementation in Stream > > src/java.base/share/classes/java/util/stream/Gatherer.java line 492: > >> 490: * >> 491: * @apiNote This is best-effort only, once this returns true it should >> 492: * never return false again for the same instance. > > Suggestion: > > * @apiNote This is best-effort only, once this returns {@code true} it should > * never return {@code false} again for the same instance. Will fix all of these :) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1389975495 From mdoerr at openjdk.org Fri Nov 10 22:42:00 2023 From: mdoerr at openjdk.org (Martin Doerr) Date: Fri, 10 Nov 2023 22:42:00 GMT Subject: RFR: 8311906: Improve robustness of String constructors with mutable array inputs [v2] In-Reply-To: References: <6SKlGLh5MmxoEx07wHCCUc8KWbbhcspLJmcc1uxQ_FI=.ca33bfb4-fa5c-45f0-b49f-ee6c5c6b68b4@github.com> Message-ID: On Thu, 9 Nov 2023 04:16:25 GMT, Roger Riggs wrote: >> Strings, after construction, are immutable but may be constructed from mutable arrays of bytes, characters, or integers. >> The string constructors should guard against the effects of mutating the arrays during construction that might invalidate internal invariants for the correct behavior of operations on the resulting strings. In particular, a number of operations have optimizations for operations on pairs of latin1 strings and pairs of non-latin1 strings, while operations between latin1 and non-latin1 strings use a more general implementation. >> >> The changes include: >> >> - Adding a warning to each constructor with an array as an argument to indicate that the results are indeterminate >> if the input array is modified before the constructor returns. >> The resulting string may contain any combination of characters sampled from the input array. >> >> - Ensure that strings that are represented as non-latin1 contain at least one non-latin1 character. >> For latin1 inputs, whether the arrays contain ASCII, ISO-8859-1, UTF8, or another encoding decoded to latin1 the scanning and compression is unchanged. >> If a non-latin1 character is found, the string is represented as non-latin1 with the added verification that a non-latin1 character is present at the same index. >> If that character is found to be latin1, then the input array has been modified and the result of the scan may be incorrect. >> Though a ConcurrentModificationException could be thrown, the risk to an existing application of an unexpected exception should be avoided. >> Instead, the non-latin1 copy of the input is re-scanned and compressed; that scan determines whether the latin1 or the non-latin1 representation is returned. >> >> - The methods that scan for non-latin1 characters and their intrinsic implementations are updated to return the index of the non-latin1 character. >> >> - String construction from StringBuilder and CharSequence must also be guarded as their contents may be modified during construction. > > Roger Riggs has updated the pull request incrementally with three additional commits since the last revision: > > - Refactored extractCodePoints to avoid multiple resizes if the array was modified > - Replaced isLatin1 implementation with `getChar(buf, ndx) <= 0xff` > It performs better than the single byte array access by avoiding the bounds check. > - Misc updates for review comments, javadoc cleanup > Extra checking on maximum string lengths when calling toBytes(). Can you include PPC64, please? diff --git a/src/hotspot/cpu/ppc/ppc.ad b/src/hotspot/cpu/ppc/ppc.ad index 89ce51e997e..102701e4969 100644 --- a/src/hotspot/cpu/ppc/ppc.ad +++ b/src/hotspot/cpu/ppc/ppc.ad @@ -12727,16 +12727,8 @@ instruct string_compress(rarg1RegP src, rarg2RegP dst, iRegIsrc len, iRegIdst re ins_cost(300); format %{ "String Compress $src,$dst,$len -> $result \t// KILL $tmp1, $tmp2, $tmp3, $tmp4, $tmp5" %} ins_encode %{ - Label Lskip, Ldone; - __ li($result$$Register, 0); - __ string_compress_16($src$$Register, $dst$$Register, $len$$Register, $tmp1$$Register, - $tmp2$$Register, $tmp3$$Register, $tmp4$$Register, $tmp5$$Register, Ldone); - __ rldicl_($tmp1$$Register, $len$$Register, 0, 64-3); // Remaining characters. - __ beq(CCR0, Lskip); - __ string_compress($src$$Register, $dst$$Register, $tmp1$$Register, $tmp2$$Register, Ldone); - __ bind(Lskip); - __ mr($result$$Register, $len$$Register); - __ bind(Ldone); + __ encode_iso_array($src$$Register, $dst$$Register, $len$$Register, $tmp1$$Register, $tmp2$$Register, + $tmp3$$Register, $tmp4$$Register, $tmp5$$Register, $result$$Register, false); %} ins_pipe(pipe_class_default); %} @offamitkumar: I guess s390 also needs an adaptation. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16425#issuecomment-1806526012 From alanb at openjdk.org Sat Nov 11 11:22:01 2023 From: alanb at openjdk.org (Alan Bateman) Date: Sat, 11 Nov 2023 11:22:01 GMT Subject: RFR: 8287843: File::getCanonicalFile doesn't work for \\?\C:\ style paths DOS device paths [v7] In-Reply-To: <26zgN9543IcbQEum-nEsgfSv4v8412UkkJ412GszuXw=.44fa0b44-fc17-40d0-99a6-87d6d8be58a1@github.com> References: <26zgN9543IcbQEum-nEsgfSv4v8412UkkJ412GszuXw=.44fa0b44-fc17-40d0-99a6-87d6d8be58a1@github.com> Message-ID: On Wed, 4 Oct 2023 20:35:25 GMT, Brian Burkhalter wrote: >> In the Windows implementation of java.io.File.getCanonicalPath, strip any long path or UNC prefix before canonicalizing the remainder of the pathname. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8287843: Remove unused constant and method from WindowsPrefixes test Implementation change looks fine. I see CSR is approved. We'll need to RN this change too. test/jdk/java/io/File/GetAbsolutePath.java line 76: > 74: public void windows(String path, String absolute) throws IOException { > 75: assertEquals(absolute.toLowerCase(), > 76: new File(path).getAbsolutePath().toLowerCase()); WinNTFileSystem.compareTo uses compareToIgnoreCase so this test should probably do the same. test/jdk/java/io/File/WindowsPrefixes.java line 27: > 25: * @bug 8287843 > 26: * @summary Basic test for Windows path prefixes > 27: * @requires (os.family == "windows") Given the `@requires` then I assume `@EnabledOnOs(OS.WINDOWS)` can be dropped from the test methods. test/jdk/java/io/File/WindowsPrefixes.java line 54: > 52: Arguments.of("C:\\foo"), > 53: Arguments.of("C:foo"), > 54: Arguments.of("C:\\foo\\bar")); I suppose this should include `\foo` in the list too. ------------- PR Review: https://git.openjdk.org/jdk/pull/15603#pullrequestreview-1726039058 PR Review Comment: https://git.openjdk.org/jdk/pull/15603#discussion_r1390204239 PR Review Comment: https://git.openjdk.org/jdk/pull/15603#discussion_r1390203019 PR Review Comment: https://git.openjdk.org/jdk/pull/15603#discussion_r1390203853 From alanb at openjdk.org Sat Nov 11 14:06:58 2023 From: alanb at openjdk.org (Alan Bateman) Date: Sat, 11 Nov 2023 14:06:58 GMT Subject: RFR: JDK-8319122: Improve documentation of various Zip-file related APIs [v2] In-Reply-To: References: <8vEqyECjMkTfesVmL3X0dN4Yu8JShPiUdsKpmEz1WV0=.1b541f77-a05f-490b-aaf1-f6b7456c6d77@github.com> Message-ID: <2g3In8YpJfWbDWoF886uO7x2XHFq6mTTKhuG3IVgLh4=.1c26f50d-7926-4ebe-b735-31ae734e3264@github.com> On Fri, 10 Nov 2023 15:44:19 GMT, Yakov Shafranovich wrote: >> The various Zip/Jar-file related Java APIs have some long-standing differences or peculiarities with respect to the ZIP-file specification or compared to other implementations which should be documented in the API-doc. This documents the following: >> - Cache of JAR files in JarURLConnection class >> - Cache of JAR/ZIP files in JarFile and ZipFile classes >> - Unexpected behavior when parsing ZIP files with duplicate entries in JarFile and ZipFile classes, as well as the zipfs provider >> - Directories and filenames with the same name considered to be the same in ZipFile class >> - Possible issues when local and central headers conflict in ZipInputStream class >> >> Related JBS report: >> https://bugs.openjdk.org/browse/JDK-8319122 > > Yakov Shafranovich has updated the pull request incrementally with two additional commits since the last revision: > > - Fixed more line breaks > - fixed line breaks src/jdk.zipfs/share/classes/module-info.java line 310: > 308: * considered duplicates, which can result in unexpected behavior such as wrong > 309: * metadata or content being returned when parsing archives containing > 310: * duplicate names. The jdk.zipfs module is the JDK's ZIP file system provider, it allows the contents of a ZIP or JAR file be treated as a file system. I think what is missing from this module description is the mapping of file system concepts to ZIP files. If we added a section to the documentation for that then it would be a place to document the file separator, normalization, how directories and file tree are synthesized, and the limitation that a file system cannot be constructed when it leads to have several entries in a directory having equal names. There's a lot more that could be added but hopefully you can see that an implNote and warnings just doesn't work as a way to present the mapping. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16424#discussion_r1390232094 From jlaskey at openjdk.org Sat Nov 11 15:53:41 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Sat, 11 Nov 2023 15:53:41 GMT Subject: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v17] In-Reply-To: References: Message-ID: <0LKNN6Pviv2PzMqRC_6ue3l989oNTOUQpPk3O-Ue9oM=.f07734f7-b94f-4dbf-baa5-b8b96d4e8c57@github.com> > Address changes from JEP 445 to JEP 463. > > - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. > > - Don't mark class on read. > > - Remove reflection and annotation processing related to unnamed classes. > > - Simplify main method search. Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: Clean up previous commit ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16461/files - new: https://git.openjdk.org/jdk/pull/16461/files/1bf935f4..abf48816 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16461&range=16 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16461&range=15-16 Stats: 5 lines in 2 files changed: 2 ins; 1 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/16461.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16461/head:pull/16461 PR: https://git.openjdk.org/jdk/pull/16461 From jlaskey at openjdk.org Sat Nov 11 16:00:37 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Sat, 11 Nov 2023 16:00:37 GMT Subject: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v18] In-Reply-To: References: Message-ID: > Address changes from JEP 445 to JEP 463. > > - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. > > - Don't mark class on read. > > - Remove reflection and annotation processing related to unnamed classes. > > - Simplify main method search. Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: Reinstate test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16461/files - new: https://git.openjdk.org/jdk/pull/16461/files/abf48816..dd6703e7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16461&range=17 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16461&range=16-17 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/16461.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16461/head:pull/16461 PR: https://git.openjdk.org/jdk/pull/16461 From jlaskey at openjdk.org Sat Nov 11 16:00:37 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Sat, 11 Nov 2023 16:00:37 GMT Subject: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v17] In-Reply-To: <0LKNN6Pviv2PzMqRC_6ue3l989oNTOUQpPk3O-Ue9oM=.f07734f7-b94f-4dbf-baa5-b8b96d4e8c57@github.com> References: <0LKNN6Pviv2PzMqRC_6ue3l989oNTOUQpPk3O-Ue9oM=.f07734f7-b94f-4dbf-baa5-b8b96d4e8c57@github.com> Message-ID: On Sat, 11 Nov 2023 15:53:41 GMT, Jim Laskey wrote: >> Address changes from JEP 445 to JEP 463. >> >> - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. >> >> - Don't mark class on read. >> >> - Remove reflection and annotation processing related to unnamed classes. >> >> - Simplify main method search. > > Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: > > Clean up previous commit Things should be fine now. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16461#issuecomment-1806851245 From duke at openjdk.org Sun Nov 12 03:07:13 2023 From: duke at openjdk.org (duke) Date: Sun, 12 Nov 2023 03:07:13 GMT Subject: Withdrawn: 8316235: Optimization for DateTimeFormatter::format In-Reply-To: References: Message-ID: On Wed, 13 Sep 2023 14:56:15 GMT, Shaojin Wen 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 This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/15722 From aturbanov at openjdk.org Sun Nov 12 09:18:04 2023 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Sun, 12 Nov 2023 09:18:04 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`. Can I get a review? ------------- PR Comment: https://git.openjdk.org/jdk/pull/15736#issuecomment-1807066050 From alanb at openjdk.org Sun Nov 12 11:39:57 2023 From: alanb at openjdk.org (Alan Bateman) Date: Sun, 12 Nov 2023 11:39:57 GMT Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged modules being present [v6] In-Reply-To: References: Message-ID: <3KNTIkHPE-MFJBMEbo52nz4qwDAUCkiaNRGJngG41xE=.1a6b9d6f-6736-4801-9c5b-5287999d1fa9@github.com> On Wed, 18 Oct 2023 17:37:30 GMT, Severin Gehwolf wrote: >> Please review this patch which adds a "jmodless" jlink mode to the JDK. Fundamentally this patch adds an option to use `jlink` even though your JDK install might not come with the packaged modules (directory `jmods`). This is particularly useful to further reduce the size of a jlinked runtime. After the removal of the concept of a JRE, a common distribution mechanism is still the full JDK with all modules and packaged modules. However, packaged modules can incur an additional size tax. For example in a container scenario it could be useful to have a base JDK container including all modules, but without also delivering the packaged modules. This comes at a size advantage of `~25%`. Such a base JDK container could then be used to `jlink` application specific runtimes, further reducing the size of the application runtime image (App + JDK runtime; as a single image *or* separate bundles, depending on the app being modularized). >> >> The basic design of this approach is to add a jlink plugin for tracking non-class and non-resource files of a JDK install. I.e. files which aren't present in the jimage (`lib/modules`). This enables producing a `JmodLessArchive` class which has all the info of what constitutes the final jlinked runtime. >> >> Basic usage example: >> >> $ diff -u <(./bin/java --list-modules --limit-modules java.se) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules java.se) >> $ diff -u <(./bin/java --list-modules --limit-modules java.se) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules jdk.jlink) >> $ ls ../linux-x86_64-server-release/images/jdk/jmods >> java.base.jmod java.net.http.jmod java.sql.rowset.jmod jdk.crypto.ec.jmod jdk.internal.opt.jmod jdk.jdi.jmod jdk.management.agent.jmod jdk.security.auth.jmod >> java.compiler.jmod java.prefs.jmod java.transaction.xa.jmod jdk.dynalink.jmod jdk.internal.vm.ci.jmod jdk.jdwp.agent.jmod jdk.management.jfr.jmod jdk.security.jgss.jmod >> java.datatransfer.jmod java.rmi.jmod java.xml.crypto.jmod jdk.editpad.jmod jdk.internal.vm.compiler.jmod jdk.jfr.jmod jdk.management.jmod jdk.unsupported.desktop.jmod >> java.desktop.jmod java.scripting.jmod java.xml.jmod jdk.hotspot.agent.jmod jdk.internal.vm.compiler.management.jmod jdk.jlink.jmod jdk.naming.dns.j... > > Severin Gehwolf has updated the pull request incrementally with four additional commits since the last revision: > > - Add a message when a run-image based link is being performed > - Add hint to the modified file case > - AddJmodResourcesPlugin => AddRunImageResourcesPlugin rename > - --add-jmod-resources => --add-run-image-resources rename > > Also rename jmod_resources to runimage_resources I looked at the latest proposal and CSR. Overall I think the proposal is good and you've got the right default to fail if the run-time image has been modified. So I think we are down to a few lesser topics now. I'm wondering if the CLI option to override, meaning a first run-time image containing the jdk.jlink module generates a second run-time image, and the first run-time image has been modified, whether this is really needed. I'm wondering about this because this CLI option is hard to explain, will developers really understand it? If there is an CLI option then we'll need to find a better name, I don't think "--unlock-run-time" works as a name (the usage of options talk about "runtime image" for example, maybe "-ignore-signing-information" can provide inspiration as an override too). Can --add-run-image-resources be dropped? Exposing this in the interface feels like it's an attractive nuisance and now clear (to me anyway) what developers would do with this. A few very minor things that I jotted down while looking at the current proposal: - Adding a resource to serve as a marker that indicates it was created without the packaged modules is fine. I think the name should be looked as "runimage" is a bit consistent for this area. I'm also wondering if it would be better to hide in jdk/internal somewhere to avoid any tooling assuming it's a supported interface. - The error message exclaims "Please double check!", I think that error message will need to be tweaked once we get down to details like this. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14787#issuecomment-1807100511 From jlu at openjdk.org Sun Nov 12 21:43:08 2023 From: jlu at openjdk.org (Justin Lu) Date: Sun, 12 Nov 2023 21:43:08 GMT Subject: Integrated: JDK-8318189: ChoiceFormat::format throws undocumented AIOOBE In-Reply-To: References: Message-ID: <_7ErQkr_PSy1C9WH3F9l5AiVouA92CVKhLBSMuX768k=.d7cb535e-a601-457d-87e8-ab64606b709a@github.com> On Thu, 9 Nov 2023 21:58:12 GMT, Justin Lu wrote: > Please review this PR which makes an `ArrayIndexOutOfBoundsException` apparent in ChoiceFormat::format. > > An _incomplete_ ChoiceFormat can be created, which is not revealed until format is invoked. This pull request has now been integrated. Changeset: caf71810 Author: Justin Lu URL: https://git.openjdk.org/jdk/commit/caf71810f85ea55083ce7d1c76307a0c42d9be0e Stats: 13 lines in 1 file changed: 11 ins; 0 del; 2 mod 8318189: ChoiceFormat::format throws undocumented AIOOBE Reviewed-by: naoto ------------- PR: https://git.openjdk.org/jdk/pull/16587 From jlu at openjdk.org Sun Nov 12 21:45:10 2023 From: jlu at openjdk.org (Justin Lu) Date: Sun, 12 Nov 2023 21:45:10 GMT Subject: RFR: JDK-8319628: DateFormat does not mention IllegalArgumentException for invalid style args Message-ID: Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8319868) which makes IllegalArgumentExceptions apparent for the _j.text.DateFormat_ static factory methods that have the _style_ parameter. ------------- Commit messages: - init Changes: https://git.openjdk.org/jdk/pull/16624/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16624&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8319628 Stats: 6 lines in 1 file changed: 2 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/16624.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16624/head:pull/16624 PR: https://git.openjdk.org/jdk/pull/16624 From dholmes at openjdk.org Mon Nov 13 02:36:00 2023 From: dholmes at openjdk.org (David Holmes) Date: Mon, 13 Nov 2023 02:36:00 GMT Subject: RFR: JDK-8317799 : AIX PPC64: FFI symbol lookup doesn't find symbols In-Reply-To: References: Message-ID: <6QJlLvoxeGTLr-Wk406AlHdtw6yxkoMhSwYIviyeBO0=.573ab212-01fc-4b6e-a1d7-f2c7e6ed3f46@github.com> On Mon, 30 Oct 2023 10:54:48 GMT, suchismith1993 wrote: > 1. Adding required compiler flags. > 2. Adding required symbols. > > JBS-ISSUE : [JDK-8317799](https://bugs.openjdk.org/browse/JDK-8317799) I cannot decide if this is an AIX issue for not using dynamic libraries; a FFI issue for assuming dynamic libraries; or a test issue. Won't this be a general problem for any function you try to access via FFI that is statically linked? ------------- PR Comment: https://git.openjdk.org/jdk/pull/16414#issuecomment-1807386320 From dholmes at openjdk.org Mon Nov 13 04:44:09 2023 From: dholmes at openjdk.org (David Holmes) Date: Mon, 13 Nov 2023 04:44:09 GMT Subject: RFR: 8318776: Require supports_cx8 to always be true Message-ID: As discussed in JBS all platforms (some tweaks to Zero are in progress) actually do support `cx8` i.e. 64-bit compare-and-exchange, so we can strip out the locked-based alternatives to using it and just add a guarantee that it is true at runtime. And all platforms except some ARM variants set `SUPPORTS_NATIVE_CX8`, so we can greatly simplify things. Summary of changes: - `_supports_cx8` field is only needed when `SUPPORTS_NATIVE_CX8` is not defined - Assertions for `supports_cx8()` are removed - Access backend is greatly simplified without the need for lock-based alternative - `java.util.concurrent.AtomicLongFieldUpdater` is simplified without the need for a lock-based alternative I did consider moving all the ARM `kuser_helper` related code to be only defined when `SUPPORTS_NATIVE_CX8` is not defined, but there was a theoretical risk this could change the behaviour if ARMv7 binaries were run on other ARM CPU's. I added a note to that effect in vm_version_linux_arm32.cpp so the ARM port maintainers could clean this up further if desired. Testing: - All Oracle tiers 1-5 builds (which includes an ARMv7 build) - GHA builds/tests - Oracle tiers 1-3 sanity testing Zero changes coming in via [JDK-8319777](https://bugs.openjdk.org/browse/JDK-8319777) will be merged when they arrive. Thanks. ------------- Commit messages: - 8318776: Require supports_cx8 to always be true Changes: https://git.openjdk.org/jdk/pull/16625/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16625&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8318776 Stats: 386 lines in 35 files changed: 14 ins; 359 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/16625.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16625/head:pull/16625 PR: https://git.openjdk.org/jdk/pull/16625 From dholmes at openjdk.org Mon Nov 13 04:50:12 2023 From: dholmes at openjdk.org (David Holmes) Date: Mon, 13 Nov 2023 04:50:12 GMT Subject: RFR: 8318776: Require supports_cx8 to always be true [v2] In-Reply-To: References: Message-ID: > As discussed in JBS all platforms (some tweaks to Zero are in progress) actually do support `cx8` i.e. 64-bit compare-and-exchange, so we can strip out the locked-based alternatives to using it and just add a guarantee that it is true at runtime. And all platforms except some ARM variants set `SUPPORTS_NATIVE_CX8`, so we can greatly simplify things. Summary of changes: > - `_supports_cx8` field is only needed when `SUPPORTS_NATIVE_CX8` is not defined > - Assertions for `supports_cx8()` are removed > - Compiler predicates requiring `supports_cx8()` are removed > - Access backend is greatly simplified without the need for lock-based alternative > - `java.util.concurrent.AtomicLongFieldUpdater` is simplified without the need for a lock-based alternative > > I did consider moving all the ARM `kuser_helper` related code to be only defined when `SUPPORTS_NATIVE_CX8` is not defined, but there was a theoretical risk this could change the behaviour if ARMv7 binaries were run on other ARM CPU's. I added a note to that effect in vm_version_linux_arm32.cpp so the ARM port maintainers could clean this up further if desired. > > Testing: > - All Oracle tiers 1-5 builds (which includes an ARMv7 build) > - GHA builds/tests > - Oracle tiers 1-3 sanity testing > > Zero changes coming in via [JDK-8319777](https://bugs.openjdk.org/browse/JDK-8319777) will be merged when they arrive. > > Thanks. David Holmes has updated the pull request incrementally with one additional commit since the last revision: Remove test for VMSupportsCX8 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16625/files - new: https://git.openjdk.org/jdk/pull/16625/files/3f2ec66f..b6dea4b6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16625&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16625&range=00-01 Stats: 53 lines in 1 file changed: 0 ins; 53 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/16625.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16625/head:pull/16625 PR: https://git.openjdk.org/jdk/pull/16625 From dholmes at openjdk.org Mon Nov 13 05:10:17 2023 From: dholmes at openjdk.org (David Holmes) Date: Mon, 13 Nov 2023 05:10:17 GMT Subject: RFR: 8318776: Require supports_cx8 to always be true [v3] In-Reply-To: References: Message-ID: > As discussed in JBS all platforms (some tweaks to Zero are in progress) actually do support `cx8` i.e. 64-bit compare-and-exchange, so we can strip out the locked-based alternatives to using it and just add a guarantee that it is true at runtime. And all platforms except some ARM variants set `SUPPORTS_NATIVE_CX8`, so we can greatly simplify things. Summary of changes: > - `_supports_cx8` field is only needed when `SUPPORTS_NATIVE_CX8` is not defined > - Assertions for `supports_cx8()` are removed > - Compiler predicates requiring `supports_cx8()` are removed > - Access backend is greatly simplified without the need for lock-based alternative > - `java.util.concurrent.AtomicLongFieldUpdater` is simplified without the need for a lock-based alternative > > I did consider moving all the ARM `kuser_helper` related code to be only defined when `SUPPORTS_NATIVE_CX8` is not defined, but there was a theoretical risk this could change the behaviour if ARMv7 binaries were run on other ARM CPU's. I added a note to that effect in vm_version_linux_arm32.cpp so the ARM port maintainers could clean this up further if desired. > > Testing: > - All Oracle tiers 1-5 builds (which includes an ARMv7 build) > - GHA builds/tests > - Oracle tiers 1-3 sanity testing > > Zero changes coming in via [JDK-8319777](https://bugs.openjdk.org/browse/JDK-8319777) will be merged when they arrive. > > Thanks. David Holmes has updated the pull request incrementally with two additional commits since the last revision: - Remove cx8 comment as no longer relevant (the spinlock is used regardless of cx8) - Remove suports_cx8() checks from gtest ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16625/files - new: https://git.openjdk.org/jdk/pull/16625/files/b6dea4b6..65871144 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16625&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16625&range=01-02 Stats: 14 lines in 2 files changed: 0 ins; 14 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/16625.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16625/head:pull/16625 PR: https://git.openjdk.org/jdk/pull/16625 From vklang at openjdk.org Mon Nov 13 07:24:24 2023 From: vklang at openjdk.org (Viktor Klang) Date: Mon, 13 Nov 2023 07:24:24 GMT Subject: RFR: JDK-8319123 : Implementation of JEP-461: Stream Gatherers (Preview) [v4] In-Reply-To: References: Message-ID: > This Pull-Request implements [JEP-461](https://openjdk.org/jeps/461) Viktor Klang has updated the pull request incrementally with one additional commit since the last revision: Addressing further review feedback ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16420/files - new: https://git.openjdk.org/jdk/pull/16420/files/74936cdd..a4745ccf Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16420&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16420&range=02-03 Stats: 123 lines in 4 files changed: 49 ins; 3 del; 71 mod Patch: https://git.openjdk.org/jdk/pull/16420.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16420/head:pull/16420 PR: https://git.openjdk.org/jdk/pull/16420 From jvernee at openjdk.org Mon Nov 13 07:35:57 2023 From: jvernee at openjdk.org (Jorn Vernee) Date: Mon, 13 Nov 2023 07:35:57 GMT Subject: RFR: JDK-8317799 : AIX PPC64: FFI symbol lookup doesn't find symbols In-Reply-To: <6QJlLvoxeGTLr-Wk406AlHdtw6yxkoMhSwYIviyeBO0=.573ab212-01fc-4b6e-a1d7-f2c7e6ed3f46@github.com> References: <6QJlLvoxeGTLr-Wk406AlHdtw6yxkoMhSwYIviyeBO0=.573ab212-01fc-4b6e-a1d7-f2c7e6ed3f46@github.com> Message-ID: On Mon, 13 Nov 2023 02:32:48 GMT, David Holmes wrote: > I cannot decide if this is an AIX issue for not using dynamic libraries; a FFI issue for assuming dynamic libraries; or a test issue. Won't this be a general problem for any function you try to access via FFI that is statically linked? Not sure what FFI is expected to do differently here. It is not possible to load a static library at runtime and look up functions inside of it, as far as I know. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16414#issuecomment-1807600121 From alanb at openjdk.org Mon Nov 13 07:43:57 2023 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 13 Nov 2023 07:43:57 GMT Subject: RFR: JDK-8317799 : AIX PPC64: FFI symbol lookup doesn't find symbols In-Reply-To: References: <0YcwDWnMl1fH5HGhHDEl_eE_5sfyBnzesOc5WmJ-eII=.105c0c2a-09c4-4538-9d85-b7d987352d3f@github.com> <9TvREErKy_SqMc5WY1R-9yEDNDKOCAqsi3br27-7MAg=.4cfe1eb5-58f6-46d5-be68-7eaae51f2671@github.com> Message-ID: <8F79NCdCWFanNH_WTgdJMsbtkqgp6Ab5Fe9ZxtrR02Q=.57663b23-7f89-4725-91eb-9e9d13629ef8@github.com> On Fri, 10 Nov 2023 16:30:35 GMT, suchismith1993 wrote: > There is not generic way of generating this. It needs a manual intervention and symbols are to be added on a need basis in future. Looks like a list to be maintained. I had tried adding comments to explain the list, but that causes build failures. Would it be possible to paste the summary of the "instructions" to generate this? My initial reaction when seeing this PR is to wonder why it can't be generated at build time but from the discussion, it seems like it's a subset of the symbols but it is really just the functions used by libjvm or is it all the native libraries? ------------- PR Comment: https://git.openjdk.org/jdk/pull/16414#issuecomment-1807608795 From jvernee at openjdk.org Mon Nov 13 07:48:58 2023 From: jvernee at openjdk.org (Jorn Vernee) Date: Mon, 13 Nov 2023 07:48:58 GMT Subject: RFR: JDK-8317799 : AIX PPC64: FFI symbol lookup doesn't find symbols In-Reply-To: <4IdhKbmi7IHLT5m3OufNTva-1e817Lx3dtGV8aQVsqw=.54172da9-f1c8-4fa7-8cd4-d10d577283e8@github.com> References: <4IdhKbmi7IHLT5m3OufNTva-1e817Lx3dtGV8aQVsqw=.54172da9-f1c8-4fa7-8cd4-d10d577283e8@github.com> Message-ID: On Fri, 10 Nov 2023 07:56:46 GMT, suchismith1993 wrote: > > That said, I think we should limit the exported symbols to only those found in the standard C library header files: https://en.cppreference.com/w/c/header > > Currently the symbols are restricted to some parts of libc and the entire math library libm. Are you suggesting we restrict the list to common math functions such as https://en.cppreference.com/w/c/numeric/math ? I'm suggesting to include things that are defined by the C standard, plus some platform specific extensions. i.e. limit this to what is considered part of the public/supported API of the standard library on AIX. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16414#issuecomment-1807614260 From aturbanov at openjdk.org Mon Nov 13 08:08:58 2023 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Mon, 13 Nov 2023 08:08:58 GMT Subject: RFR: 8319820: Use unnamed variables in the FFM implementation In-Reply-To: <19Ft-0cMiWPWUp3lbG-7gcU_zZAoDlTyJwPLigo5AOE=.5c2d3380-40d3-46c2-b213-715c56f948ee@github.com> References: <19Ft-0cMiWPWUp3lbG-7gcU_zZAoDlTyJwPLigo5AOE=.5c2d3380-40d3-46c2-b213-715c56f948ee@github.com> Message-ID: On Fri, 10 Nov 2023 07:19:42 GMT, Per Minborg wrote: > This PR proposes to use unnamed variables now that they have become available in Java. > > There is also a cosmetic cleanup making a switch rake smaller and where variables are pre-calculated rather than spreading expressions around. src/java.base/share/classes/jdk/internal/foreign/AbstractMemorySegmentImpl.java line 570: > 568: case int[] _ -> new HeapMemorySegmentImpl.OfInt(off, base, len, readOnly, bufferScope); > 569: case float[] _ -> new HeapMemorySegmentImpl.OfFloat(off, base, len, readOnly, bufferScope); > 570: case long[] _ -> new HeapMemorySegmentImpl.OfLong(off, base, len, readOnly, bufferScope); Suggestion: case long[] _ -> new HeapMemorySegmentImpl.OfLong(off, base, len, readOnly, bufferScope); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16594#discussion_r1390729188 From jvernee at openjdk.org Mon Nov 13 08:37:56 2023 From: jvernee at openjdk.org (Jorn Vernee) Date: Mon, 13 Nov 2023 08:37:56 GMT Subject: RFR: 8319928: Exceptions thrown by cleanup actions passed to reinterpreted segments should be ignored In-Reply-To: References: Message-ID: On Fri, 10 Nov 2023 16:34:11 GMT, Maurizio Cimadamore wrote: > This simplePR tweaks the factory which wraps custom cleanup actions passed to `MemorySegment::reinterpret`, so that any exception thrown by the custom cleanup is swallowed when the arena is closed. > > This aligns the behavior of confined/shared session with that of implicit session (as implicit sessions are backed by a `Cleaner`, there is no way for cleanup exception to bubble up). Not sure whether always swallowing the exceptions is the right move... it seems like an advantage that explicit arenas _can_ report exceptions thrown by cleanup actions. Silently ignoring exceptions seems bad, but something that is forced when using a Cleaner. I don't think we should extend that bad behavior to all arenas. I do think it is problematic that we bail out of the cleanup loop on the first exception, but I suggest solving this by catching the exceptions/Throwables thrown by individual cleanup actions, and then only propagating them at the end of the cleanup loop. (where, if there are multiple exceptions we can use `addSuppressed`). ------------- PR Comment: https://git.openjdk.org/jdk/pull/16619#issuecomment-1807677201 From thartmann at openjdk.org Mon Nov 13 08:39:02 2023 From: thartmann at openjdk.org (Tobias Hartmann) Date: Mon, 13 Nov 2023 08:39:02 GMT Subject: RFR: 8310159: Bulk copy with Unsafe::arrayCopy is slower compared to memcpy In-Reply-To: References: Message-ID: On Wed, 8 Nov 2023 23:23:48 GMT, Steve Dohrmann wrote: > Below is baseline data collected using a modified version of the java.lang.foreign.xor micro benchmark referenced by @mcimadamore in the bug report. I collected data on an Ubuntu 22.04 laptop with a Tigerlake i7-1185G7, which does support AVX512. > > Baseline data > Benchmark (arrayKind) (sizeKind) Mode Cnt Score Error Units > -------------------------------------------------------------------------------------- > XorTest.copy ELEMENTS SMALL avgt 30 584737355.767 ? 60414308.540 ns/op > XorTest.copy ELEMENTS MEDIUM avgt 30 272248995.683 ? 2924954.498 ns/op > XorTest.copy ELEMENTS LARGE avgt 30 1019200210.900 ? 28334453.652 ns/op > XorTest.copy REGION SMALL avgt 30 7399944.164 ? 216821.819 ns/op > XorTest.copy REGION MEDIUM avgt 30 20591454.558 ? 147398.572 ns/op > XorTest.copy REGION LARGE avgt 30 21649266.051 ? 179263.875 ns/op > XorTest.copy CRITICAL SMALL avgt 30 51079.357 ? 542.482 ns/op > XorTest.copy CRITICAL MEDIUM avgt 30 2496.961 ? 11.375 ns/op > XorTest.copy CRITICAL LARGE avgt 30 515.454 ? 5.831 ns/op > XorTest.copy FOREIGN SMALL avgt 30 7558432.075 ? 79489.276 ns/op > XorTest.copy FOREIGN MEDIUM avgt 30 19730666.341 ? 500505.099 ns/op > XorTest.copy FOREIGN LARGE avgt 30 34616758.085 ? 340300.726 ns/op > XorTest.xor ELEMENTS SMALL avgt 30 219832692.489 ? 2329417.319 ns/op > XorTest.xor ELEMENTS MEDIUM avgt 30 505138197.167 ? 3818334.424 ns/op > XorTest.xor ELEMENTS LARGE avgt 30 1189608474.667 ? 5877981.900 ns/op > XorTest.xor REGION SMALL avgt 30 64093872.804 ? 599704.491 ns/op > XorTest.xor REGION MEDIUM avgt 30 81544576.454 ? 1406342.118 ns/op > XorTest.xor REGION LARGE avgt 30 90091424.883 ? 775577.613 ns/op > XorTest.xor CRITICAL SMALL avgt 30 57231375.744 ? 438223.342 ns/op > XorTest.xor CRITICAL MEDIUM avgt 30 58583884.930 ? 375355.215 ns/op > XorTest.xor CRITICAL LARGE avgt 30 60644832.949 ? 588120.738 ns/op > XorTest.xor FOREIGN SMALL avgt 30 73868679.405 ? 819965.524 ns/op > XorTest.xor FOREIGN MEDIUM avgt 30 88156275.944 ? 1051257.152 ns/op > XorTest.xor FOREIGN LARGE avgt 30 123115513... I submitted some quick testing and I'm seeing the following failure with multiple tests: # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (/workspace/open/src/hotspot/cpu/x86/stubGenerator_x86_64_arraycopy.cpp:1201), pid=24136, tid=24139 # assert(MaxVectorSize == 64) failed: vector length != 64 # # JRE version: (22.0) (fastdebug build ) # Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 22-internal-2023-11-13-0750559.tobias.hartmann.jdk2, mixed mode, sharing, compressed oops, compressed class ptrs, g1 gc, linux-amd64) # Problematic frame: # V [libjvm.so+0x16c00e6] StubGenerator::copy64_masked_avx(Register, Register, XMMRegister, KRegister, Register, Register, Register, int, int, bool)+0x366 Stack: [0x00007f0b5e919000,0x00007f0b5ea1a000], sp=0x00007f0b5ea17150, free space=1016k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0x16c00e6] StubGenerator::copy64_masked_avx(Register, Register, XMMRegister, KRegister, Register, Register, Register, int, int, bool)+0x366 (stubGenerator_x86_64_arraycopy.cpp:1201) V [libjvm.so+0x16c0ecd] StubGenerator::arraycopy_avx3_special_cases_256(XMMRegister, KRegister, Register, Register, Register, int, Register, Register, Label&, Label&)+0x19d (stubGenerator_x86_64_arraycopy.cpp:1055) V [libjvm.so+0x16c16c1] StubGenerator::arraycopy_avx3_large(Register, Register, Register, Register, Register, Register, Register, XMMRegister, XMMRegister, XMMRegister, XMMRegister, int)+0x3f1 (stubGenerator_x86_64_arraycopy.cpp:790) V [libjvm.so+0x16c22f0] StubGenerator::generate_disjoint_copy_avx3_masked(unsigned char**, char const*, int, bool, bool, bool)+0xa90 (stubGenerator_x86_64_arraycopy.cpp:728) V [libjvm.so+0x16c4b85] StubGenerator::generate_disjoint_byte_copy(bool, unsigned char**, char const*)+0x965 (stubGenerator_x86_64_arraycopy.cpp:1277) V [libjvm.so+0x16cb309] StubGenerator::generate_arraycopy_stubs()+0x29 (stubGenerator_x86_64_arraycopy.cpp:88) V [libjvm.so+0x16a1089] StubGenerator::generate_final_stubs()+0xb9 (stubGenerator_x86_64.cpp:4051) V [libjvm.so+0x16a22a5] StubGenerator_generate(CodeBuffer*, StubCodeGenerator::StubsKind)+0x105 (stubGenerator_x86_64.cpp:4296) V [libjvm.so+0x16f349e] initialize_stubs(StubCodeGenerator::StubsKind, int, int, char const*, char const*, char const*)+0x13e (stubRoutines.cpp:241) V [libjvm.so+0x16f500d] final_stubs_init()+0x3d (stubRoutines.cpp:288) V [libjvm.so+0xe30c59] init_globals2()+0x69 (init.cpp:180) V [libjvm.so+0x17b9151] Threads::create_vm(JavaVMInitArgs*, bool*)+0x311 (threads.cpp:569) V [libjvm.so+0xf937e4] JNI_CreateJavaVM+0x54 (jni.cpp:3576) C [libjli.so+0x419f] JavaMain+0x8f (java.c:1522) C [libjli.so+0x7c39] ThreadJavaMain+0x9 (java_md.c:650) For example, with `compiler/arraycopy/TestArrayCopyConjoint.java` and `-XX:-UseTLAB`. ------------- Changes requested by thartmann (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16575#pullrequestreview-1726765770 From aturbanov at openjdk.org Mon Nov 13 08:46:04 2023 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Mon, 13 Nov 2023 08:46:04 GMT Subject: RFR: 8311906: Improve robustness of String constructors with mutable array inputs [v2] In-Reply-To: References: <6SKlGLh5MmxoEx07wHCCUc8KWbbhcspLJmcc1uxQ_FI=.ca33bfb4-fa5c-45f0-b49f-ee6c5c6b68b4@github.com> Message-ID: On Thu, 9 Nov 2023 04:16:25 GMT, Roger Riggs wrote: >> Strings, after construction, are immutable but may be constructed from mutable arrays of bytes, characters, or integers. >> The string constructors should guard against the effects of mutating the arrays during construction that might invalidate internal invariants for the correct behavior of operations on the resulting strings. In particular, a number of operations have optimizations for operations on pairs of latin1 strings and pairs of non-latin1 strings, while operations between latin1 and non-latin1 strings use a more general implementation. >> >> The changes include: >> >> - Adding a warning to each constructor with an array as an argument to indicate that the results are indeterminate >> if the input array is modified before the constructor returns. >> The resulting string may contain any combination of characters sampled from the input array. >> >> - Ensure that strings that are represented as non-latin1 contain at least one non-latin1 character. >> For latin1 inputs, whether the arrays contain ASCII, ISO-8859-1, UTF8, or another encoding decoded to latin1 the scanning and compression is unchanged. >> If a non-latin1 character is found, the string is represented as non-latin1 with the added verification that a non-latin1 character is present at the same index. >> If that character is found to be latin1, then the input array has been modified and the result of the scan may be incorrect. >> Though a ConcurrentModificationException could be thrown, the risk to an existing application of an unexpected exception should be avoided. >> Instead, the non-latin1 copy of the input is re-scanned and compressed; that scan determines whether the latin1 or the non-latin1 representation is returned. >> >> - The methods that scan for non-latin1 characters and their intrinsic implementations are updated to return the index of the non-latin1 character. >> >> - String construction from StringBuilder and CharSequence must also be guarded as their contents may be modified during construction. > > Roger Riggs has updated the pull request incrementally with three additional commits since the last revision: > > - Refactored extractCodePoints to avoid multiple resizes if the array was modified > - Replaced isLatin1 implementation with `getChar(buf, ndx) <= 0xff` > It performs better than the single byte array access by avoiding the bounds check. > - Misc updates for review comments, javadoc cleanup > Extra checking on maximum string lengths when calling toBytes(). test/jdk/java/lang/String/StringRacyConstructor.java line 283: > 281: if ((s.charAt(0) < 256 && !original.equals(s)) || i > 1_000_000) { > 282: thread.interrupt(); > 283: try { Suggestion: try { test/jdk/java/lang/String/StringRacyConstructor.java line 329: > 327: if ((s.charAt(0) < 256 && !original.equals(s)) || i > 1_000_000) { > 328: thread.interrupt(); > 329: try { Suggestion: try { test/jdk/java/lang/String/StringRacyConstructor.java line 376: > 374: if ((s.length() != original.length()) || i > 1_000_000) { > 375: thread.interrupt(); > 376: try { Suggestion: try { ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16425#discussion_r1390767265 PR Review Comment: https://git.openjdk.org/jdk/pull/16425#discussion_r1390767406 PR Review Comment: https://git.openjdk.org/jdk/pull/16425#discussion_r1390767564 From aturbanov at openjdk.org Mon Nov 13 09:03:19 2023 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Mon, 13 Nov 2023 09:03:19 GMT Subject: RFR: JDK-8319123 : Implementation of JEP-461: Stream Gatherers (Preview) [v4] In-Reply-To: References: Message-ID: On Mon, 13 Nov 2023 07:24:24 GMT, Viktor Klang wrote: >> This Pull-Request implements [JEP-461](https://openjdk.org/jeps/461) > > Viktor Klang has updated the pull request incrementally with one additional commit since the last revision: > > Addressing further review feedback src/java.base/share/classes/java/util/stream/GathererOp.java line 86: > 84: final static class NodeBuilder implements Consumer { > 85: private final static int LINEAR_APPEND_MAX = 8; // TODO revisit > 86: final static class Builder extends SpinedBuffer implements Node { Let's use blessed modifiers order: Suggestion: static final class NodeBuilder implements Consumer { private static final int LINEAR_APPEND_MAX = 8; // TODO revisit static final class Builder extends SpinedBuffer implements Node { src/java.base/share/classes/java/util/stream/GathererOp.java line 139: > 137: } > 138: > 139: final static class GatherSink implements Sink, Gatherer.Downstream { Let's use blessed modifiers order: Suggestion: static final class GatherSink implements Sink, Gatherer.Downstream { src/java.base/share/classes/java/util/stream/GathererOp.java line 221: > 219: DEFAULT_FLAGS | StreamOpFlag.IS_SHORT_CIRCUIT; > 220: > 221: private final static int GREEDY_FLAGS = Let's use blessed modifiers order: Suggestion: private static final int DEFAULT_FLAGS = StreamOpFlag.NOT_SORTED | StreamOpFlag.NOT_DISTINCT | StreamOpFlag.NOT_SIZED; private static final int SHORT_CIRCUIT_FLAGS = DEFAULT_FLAGS | StreamOpFlag.IS_SHORT_CIRCUIT; private static final int GREEDY_FLAGS = test/jdk/java/util/stream/GatherersTest.java line 248: > 246: > 247: // Test cancellation after exception during processing > 248: if(config.streamSize > 2) { // We need streams of a minimum size to test this Suggestion: if (config.streamSize > 2) { // We need streams of a minimum size to test this test/jdk/java/util/stream/GatherersTest.java line 257: > 255: .gather( > 256: Gatherers.mapConcurrent(config.streamSize(), i -> { > 257: switch(i) { Suggestion: switch (i) { test/jdk/java/util/stream/GatherersTest.java line 285: > 283: .toList(); > 284: fail("This should not be reached"); > 285: } catch(Throwable e) { Suggestion: } catch (Throwable e) { test/jdk/java/util/stream/GatherersTest.java line 286: > 284: fail("This should not be reached"); > 285: } catch(Throwable e) { > 286: while(e.getCause() != null) Suggestion: while (e.getCause() != null) test/jdk/java/util/stream/GatherersTest.java line 298: > 296: > 297: // Test cancellation during short-circuiting > 298: if(config.streamSize > 2) { Suggestion: if (config.streamSize > 2) { ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1390783396 PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1390783885 PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1390784768 PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1390785381 PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1390786469 PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1390785634 PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1390785784 PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1390785930 From aturbanov at openjdk.org Mon Nov 13 09:11:17 2023 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Mon, 13 Nov 2023 09:11:17 GMT Subject: RFR: JDK-8319123 : Implementation of JEP-461: Stream Gatherers (Preview) [v4] In-Reply-To: References: Message-ID: On Mon, 13 Nov 2023 07:24:24 GMT, Viktor Klang wrote: >> This Pull-Request implements [JEP-461](https://openjdk.org/jeps/461) > > Viktor Klang has updated the pull request incrementally with one additional commit since the last revision: > > Addressing further review feedback test/jdk/java/util/stream/GatherersTest.java line 307: > 305: .gather( > 306: Gatherers.mapConcurrent(config.streamSize(), i -> { > 307: switch(i) { nit Suggestion: switch (i) { ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1390798915 From vklang at openjdk.org Mon Nov 13 09:22:13 2023 From: vklang at openjdk.org (Viktor Klang) Date: Mon, 13 Nov 2023 09:22:13 GMT Subject: RFR: JDK-8319123 : Implementation of JEP-461: Stream Gatherers (Preview) [v5] In-Reply-To: References: Message-ID: <8VQk_eX35V8wo8YSfdTGCi0XxZklabPegtiBU-lg_8M=.3c560f0e-9df3-4d21-a03a-0554c1451a90@github.com> > This Pull-Request implements [JEP-461](https://openjdk.org/jeps/461) Viktor Klang has updated the pull request incrementally with one additional commit since the last revision: Minor improvements to Gatherer Javadoc ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16420/files - new: https://git.openjdk.org/jdk/pull/16420/files/a4745ccf..b1540ca5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16420&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16420&range=03-04 Stats: 6 lines in 1 file changed: 0 ins; 1 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/16420.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16420/head:pull/16420 PR: https://git.openjdk.org/jdk/pull/16420 From aturbanov at openjdk.org Mon Nov 13 09:22:19 2023 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Mon, 13 Nov 2023 09:22:19 GMT Subject: RFR: JDK-8319123 : Implementation of JEP-461: Stream Gatherers (Preview) [v4] In-Reply-To: References: Message-ID: On Mon, 13 Nov 2023 07:24:24 GMT, Viktor Klang wrote: >> This Pull-Request implements [JEP-461](https://openjdk.org/jeps/461) > > Viktor Klang has updated the pull request incrementally with one additional commit since the last revision: > > Addressing further review feedback src/java.base/share/classes/java/util/stream/Gatherers.java line 117: > 115: > 116: void finish(Downstream> downstream) { > 117: if(at > 0 && !downstream.isRejecting()) { Suggestion: if (at > 0 && !downstream.isRejecting()) { src/java.base/share/classes/java/util/stream/Gatherers.java line 211: > 209: > 210: void finish(Downstream> downstream) { > 211: if(firstWindow && at > 0 && !downstream.isRejecting()) { Suggestion: if (firstWindow && at > 0 && !downstream.isRejecting()) { src/java.base/share/classes/java/util/stream/Gatherers.java line 392: > 390: try { > 391: Future current; > 392: while(proceed Suggestion: while (proceed src/java.base/share/classes/java/util/stream/Gatherers.java line 410: > 408: if (!proceed) { > 409: Future next; > 410: while((next = window.pollFirst()) != null) { Suggestion: while ((next = window.pollFirst()) != null) { src/java.base/share/classes/java/util/stream/Gatherers.java line 495: > 493: } > 494: > 495: final static class Composite implements Gatherer { Suggestion: static final class Composite implements Gatherer { test/micro/org/openjdk/bench/java/util/stream/ops/ref/BenchmarkGathererImpls.java line 91: > 89: > 90: @Override public boolean integrate(Void state, T element, Gatherer.Downstream downstream) { > 91: try(Stream s = mapper.apply(element)) { Suggestion: try (Stream s = mapper.apply(element)) { test/micro/org/openjdk/bench/java/util/stream/ops/ref/BenchmarkGathererImpls.java line 98: > 96: } > 97: return true; > 98: } catch(RuntimeException e) { Suggestion: } catch (RuntimeException e) { ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1390809499 PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1390809768 PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1390810017 PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1390810201 PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1390810531 PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1390808681 PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1390809068 From tvaleev at openjdk.org Mon Nov 13 10:11:18 2023 From: tvaleev at openjdk.org (Tagir F. Valeev) Date: Mon, 13 Nov 2023 10:11:18 GMT Subject: RFR: JDK-8319123 : Implementation of JEP-461: Stream Gatherers (Preview) [v5] In-Reply-To: <8VQk_eX35V8wo8YSfdTGCi0XxZklabPegtiBU-lg_8M=.3c560f0e-9df3-4d21-a03a-0554c1451a90@github.com> References: <8VQk_eX35V8wo8YSfdTGCi0XxZklabPegtiBU-lg_8M=.3c560f0e-9df3-4d21-a03a-0554c1451a90@github.com> Message-ID: On Mon, 13 Nov 2023 09:22:13 GMT, Viktor Klang wrote: >> This Pull-Request implements [JEP-461](https://openjdk.org/jeps/461) > > Viktor Klang has updated the pull request incrementally with one additional commit since the last revision: > > Minor improvements to Gatherer Javadoc Marked as reviewed by tvaleev (Committer). ------------- PR Review: https://git.openjdk.org/jdk/pull/16420#pullrequestreview-1726970871 From pminborg at openjdk.org Mon Nov 13 10:55:39 2023 From: pminborg at openjdk.org (Per Minborg) Date: Mon, 13 Nov 2023 10:55:39 GMT Subject: RFR: 8319820: Use unnamed variables in the FFM implementation [v2] In-Reply-To: <19Ft-0cMiWPWUp3lbG-7gcU_zZAoDlTyJwPLigo5AOE=.5c2d3380-40d3-46c2-b213-715c56f948ee@github.com> References: <19Ft-0cMiWPWUp3lbG-7gcU_zZAoDlTyJwPLigo5AOE=.5c2d3380-40d3-46c2-b213-715c56f948ee@github.com> Message-ID: > This PR proposes to use unnamed variables now that they have become available in Java. > > There is also a cosmetic cleanup making a switch rake smaller and where variables are pre-calculated rather than spreading expressions around. Per Minborg has updated the pull request incrementally with one additional commit since the last revision: Reformat slightly ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16594/files - new: https://git.openjdk.org/jdk/pull/16594/files/c2a94d36..2475b8eb Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16594&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16594&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/16594.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16594/head:pull/16594 PR: https://git.openjdk.org/jdk/pull/16594 From pminborg at openjdk.org Mon Nov 13 10:55:39 2023 From: pminborg at openjdk.org (Per Minborg) Date: Mon, 13 Nov 2023 10:55:39 GMT Subject: Integrated: 8319820: Use unnamed variables in the FFM implementation In-Reply-To: <19Ft-0cMiWPWUp3lbG-7gcU_zZAoDlTyJwPLigo5AOE=.5c2d3380-40d3-46c2-b213-715c56f948ee@github.com> References: <19Ft-0cMiWPWUp3lbG-7gcU_zZAoDlTyJwPLigo5AOE=.5c2d3380-40d3-46c2-b213-715c56f948ee@github.com> Message-ID: On Fri, 10 Nov 2023 07:19:42 GMT, Per Minborg wrote: > This PR proposes to use unnamed variables now that they have become available in Java. > > There is also a cosmetic cleanup making a switch rake smaller and where variables are pre-calculated rather than spreading expressions around. This pull request has now been integrated. Changeset: b41b00a4 Author: Per Minborg URL: https://git.openjdk.org/jdk/commit/b41b00a41c443f8a6c0c7023aab6b95745c57c23 Stats: 36 lines in 4 files changed: 2 ins; 11 del; 23 mod 8319820: Use unnamed variables in the FFM implementation Reviewed-by: mcimadamore ------------- PR: https://git.openjdk.org/jdk/pull/16594 From mcimadamore at openjdk.org Mon Nov 13 11:10:57 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 13 Nov 2023 11:10:57 GMT Subject: RFR: 8319928: Exceptions thrown by cleanup actions passed to reinterpreted segments should be ignored In-Reply-To: References: Message-ID: On Mon, 13 Nov 2023 08:35:21 GMT, Jorn Vernee wrote: > Not sure whether always swallowing the exceptions is the right move... it seems like an advantage that explicit arenas _can_ report exceptions thrown by cleanup actions. Silently ignoring exceptions seems bad, but something that is forced when using a Cleaner. I don't think we should extend that bad behavior to all arenas. > > I do think it is problematic that we bail out of the cleanup loop on the first exception, but I suggest solving this by catching the exceptions/Throwables thrown by individual cleanup actions, and then only propagating them at the end of the cleanup loop. (where, if there are multiple exceptions we can use `addSuppressed`). The problem with this approach is that if we do this we would need either: * `close` to throw `Throwable`, since *anything goes* * `close` to throw some runtime exception wrapper (either existing, or a new type defined by us) which wraps whatever exception is thrown by the cleanup action IMHO, neither approach is too compelling, given that neither would work with implicit arenas. While swallowing exceptions is never ideal, I think having uniform behavior across all arena kinds is important, and, let's also not forget that attaching custom cleanup actions is a rather advanced operation, so asking developers to use that with caution seems an ok move (even if not a perfect one, but no perfect move exists here). ------------- PR Comment: https://git.openjdk.org/jdk/pull/16619#issuecomment-1807950255 From amitkumar at openjdk.org Mon Nov 13 11:25:02 2023 From: amitkumar at openjdk.org (Amit Kumar) Date: Mon, 13 Nov 2023 11:25:02 GMT Subject: RFR: 8311906: Improve robustness of String constructors with mutable array inputs [v2] In-Reply-To: References: <6SKlGLh5MmxoEx07wHCCUc8KWbbhcspLJmcc1uxQ_FI=.ca33bfb4-fa5c-45f0-b49f-ee6c5c6b68b4@github.com> Message-ID: On Thu, 9 Nov 2023 04:16:25 GMT, Roger Riggs wrote: >> Strings, after construction, are immutable but may be constructed from mutable arrays of bytes, characters, or integers. >> The string constructors should guard against the effects of mutating the arrays during construction that might invalidate internal invariants for the correct behavior of operations on the resulting strings. In particular, a number of operations have optimizations for operations on pairs of latin1 strings and pairs of non-latin1 strings, while operations between latin1 and non-latin1 strings use a more general implementation. >> >> The changes include: >> >> - Adding a warning to each constructor with an array as an argument to indicate that the results are indeterminate >> if the input array is modified before the constructor returns. >> The resulting string may contain any combination of characters sampled from the input array. >> >> - Ensure that strings that are represented as non-latin1 contain at least one non-latin1 character. >> For latin1 inputs, whether the arrays contain ASCII, ISO-8859-1, UTF8, or another encoding decoded to latin1 the scanning and compression is unchanged. >> If a non-latin1 character is found, the string is represented as non-latin1 with the added verification that a non-latin1 character is present at the same index. >> If that character is found to be latin1, then the input array has been modified and the result of the scan may be incorrect. >> Though a ConcurrentModificationException could be thrown, the risk to an existing application of an unexpected exception should be avoided. >> Instead, the non-latin1 copy of the input is re-scanned and compressed; that scan determines whether the latin1 or the non-latin1 representation is returned. >> >> - The methods that scan for non-latin1 characters and their intrinsic implementations are updated to return the index of the non-latin1 character. >> >> - String construction from StringBuilder and CharSequence must also be guarded as their contents may be modified during construction. > > Roger Riggs has updated the pull request incrementally with three additional commits since the last revision: > > - Refactored extractCodePoints to avoid multiple resizes if the array was modified > - Replaced isLatin1 implementation with `getChar(buf, ndx) <= 0xff` > It performs better than the single byte array access by avoiding the bounds check. > - Misc updates for review comments, javadoc cleanup > Extra checking on maximum string lengths when calling toBytes(). Please add s390 port: diff --git a/src/hotspot/cpu/s390/s390.ad b/src/hotspot/cpu/s390/s390.ad index ffac6b70a58..61b6a6a5906 100644 --- a/src/hotspot/cpu/s390/s390.ad +++ b/src/hotspot/cpu/s390/s390.ad @@ -10190,7 +10190,7 @@ instruct string_compress(iRegP src, iRegP dst, iRegI result, iRegI len, iRegI tm format %{ "String Compress $src->$dst($len) -> $result" %} ins_encode %{ __ string_compress($result$$Register, $src$$Register, $dst$$Register, $len$$Register, - $tmp$$Register, false, false); + $tmp$$Register, true, false); %} ins_pipe(pipe_class_dummy); %} ------------- PR Comment: https://git.openjdk.org/jdk/pull/16425#issuecomment-1807971207 From pminborg at openjdk.org Mon Nov 13 11:45:06 2023 From: pminborg at openjdk.org (Per Minborg) Date: Mon, 13 Nov 2023 11:45: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/cldr/CLDRCalendarDataProviderImpl.java line 48: > 46: public class CLDRCalendarDataProviderImpl extends CalendarDataProviderImpl { > 47: > 48: private static final Map firstDay = new ConcurrentHashMap<>(); We might rename these fields to FIRST_DAY etc. src/java.base/share/classes/sun/util/cldr/CLDRLocaleProviderAdapter.java line 63: > 61: > 62: // parent locales map > 63: private static final Map parentLocalesMap; Rename to PARENT_LOCALES_MAP? src/java.base/share/classes/sun/util/locale/LocaleObjectCache.java line 102: > 100: } > 101: > 102: private static class CacheEntry extends SoftReference { The class itself might be `final` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15736#discussion_r1391002631 PR Review Comment: https://git.openjdk.org/jdk/pull/15736#discussion_r1391004183 PR Review Comment: https://git.openjdk.org/jdk/pull/15736#discussion_r1391005224 From duke at openjdk.org Mon Nov 13 11:51:01 2023 From: duke at openjdk.org (suchismith1993) Date: Mon, 13 Nov 2023 11:51:01 GMT Subject: RFR: JDK-8317799 : AIX PPC64: FFI symbol lookup doesn't find symbols In-Reply-To: <8F79NCdCWFanNH_WTgdJMsbtkqgp6Ab5Fe9ZxtrR02Q=.57663b23-7f89-4725-91eb-9e9d13629ef8@github.com> References: <0YcwDWnMl1fH5HGhHDEl_eE_5sfyBnzesOc5WmJ-eII=.105c0c2a-09c4-4538-9d85-b7d987352d3f@github.com> <9TvREErKy_SqMc5WY1R-9yEDNDKOCAqsi3br27-7MAg=.4cfe1eb5-58f6-46d5-be68-7eaae51f2671@github.com> <8F79NCdCWFanNH_WTgdJMsbtkqgp6Ab5Fe9ZxtrR02Q=.57663b23-7f89-4725-91eb-9e9d13629ef8@github.com> Message-ID: <6NvReFfoN8ywugSu6Ii-h-EL58N7gzynT2dpam5MsmM=.d8c15778-8bb1-4126-aa83-4966230b96cb@github.com> On Mon, 13 Nov 2023 07:41:11 GMT, Alan Bateman wrote: > > There is not generic way of generating this. It needs a manual intervention and symbols are to be added on a need basis in future. Looks like a list to be maintained. I had tried adding comments to explain the list, but that causes build failures. > > Would it be possible to paste the summary of the "instructions" to generate this? My initial reaction when seeing this PR is to wonder why it can't be generated at build time but from the discussion, it seems like it's a subset symbols, just the functions used by libjvm or is it all the native libraries? I just did a nm command and did a grep of " T " . That way i got all the symbols for math libraries. There were additional parsing instructions to remove the first column and remove periods at beginning. Then we had to remove certain symbols that are dependent on DFP symbols and xlc17 doesn't support them yet, So we had to trim down the list further, which is why it now becomes a list to be maintained. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16414#issuecomment-1808009070 From pminborg at openjdk.org Mon Nov 13 11:51:00 2023 From: pminborg at openjdk.org (Per Minborg) Date: Mon, 13 Nov 2023 11:51:00 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`. LGTM. See comments though. src/java.base/share/classes/sun/util/locale/StringTokenIterator.java line 33: > 31: package sun.util.locale; > 32: > 33: public class StringTokenIterator { The class may be `final` ------------- Marked as reviewed by pminborg (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15736#pullrequestreview-1727154051 PR Review Comment: https://git.openjdk.org/jdk/pull/15736#discussion_r1391008427 From jvernee at openjdk.org Mon Nov 13 12:51:36 2023 From: jvernee at openjdk.org (Jorn Vernee) Date: Mon, 13 Nov 2023 12:51:36 GMT Subject: RFR: 8254693: Add Panama feature to pass heap segments to native code [v14] In-Reply-To: References: Message-ID: > Add the ability to pass heap segments to native code. This requires using `Linker.Option.critical(true)` as a linker option. It has the same limitations as normal critical calls, namely: upcalls into Java are not allowed, and the native function should return relatively quickly. Heap segments are exposed to native code through temporary native addresses that are valid for the duration of the native call. > > The motivation for this is supporting existing Java array-based APIs that might have to pass multi-megabyte size arrays to native code, and are current relying on Get-/ReleasePrimitiveArrayCritical from JNI. Where making a copy of the array would be overly prohibitive. > > Components of this patch: > > - New binding operator `SegmentBase`, which gets the base object of a `MemorySegment`. > - Rename `UnboxAddress` to `SegmentOffset`. Add flag to specify whether processing heap segments should be allowed. > - `CallArranger` impls use new binding operators when `Linker.Option.critical(/* allowHeap= */ true)` is specified. > - `NativeMethodHandle`/`NativeEntryPoint` allow `Object` in their signatures. > - The object/oop + offset is exposed as temporary address to native code. > - Since we stay in the `_thread_in_Java` state, we can safely expose the oops passed to the downcall stub to native code, without needing GCLocker. These oops are valid until we poll for safepoint, which we never do (invoking pure native code). > - Only x64 and AArch64 for now. > - I've refactored `ArgumentShuffle` in the C++ code to no longer rely on callbacks to get the set of source and destination registers (using `CallingConventionClosure`), but instead just rely on 2 equal size arrays with source and destination registers. This allows filtering the input java registers before passing them to `ArgumentShuffle`, which is required to filter out registers holding segment offsets. Replacing placeholder registers is also done as a separate pre-processing step now. See changes in: https://github.com/openjdk/jdk/pull/16201/commits/d2b40f1117d63cc6d74e377bf88cdcf6d15ff866 > - I've factored out `DowncallStubGenerator` in the x64 and AArch64 code to use a common `DowncallLinker::StubGenerator`. > - Fallback linker is also supported using JNI's `GetPrimitiveArrayCritical`/`ReleasePrimitiveArrayCritical` > > Aside: fixed existing issue with `DowncallLinker` not properly acquiring segments in interpreted mode. > > Numbers for the included benchmark on my machine are: > > > Benchmark (size) Mode Cnt ... Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 52 commits: - Merge branch 'master' into AllowHeapNoLock - fix type and reformat doc in Linker - Merge branch 'master' into AllowHeapNoLock - tweak whitespace - a -> an - add note to downcallHandle about passing heap segments by-reference - Merge branch 'master' into AllowHeapNoLock - bump up argument counts in TestLargeStub to their maximum - s390 updates - add stub size stress test for allowHeap - ... and 42 more: https://git.openjdk.org/jdk/compare/03db8281...36da79d1 ------------- Changes: https://git.openjdk.org/jdk/pull/16201/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16201&range=13 Stats: 2711 lines in 74 files changed: 1722 ins; 692 del; 297 mod Patch: https://git.openjdk.org/jdk/pull/16201.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16201/head:pull/16201 PR: https://git.openjdk.org/jdk/pull/16201 From jvernee at openjdk.org Mon Nov 13 12:51:36 2023 From: jvernee at openjdk.org (Jorn Vernee) Date: Mon, 13 Nov 2023 12:51:36 GMT Subject: RFR: 8254693: Add Panama feature to pass heap segments to native code [v12] In-Reply-To: References: Message-ID: <6CiULyvr5njIHm6Pm7sU5ElUrXElHAmD3up0aYVutuU=.77f43912-543e-4505-a04c-181233939af4@github.com> On Thu, 9 Nov 2023 15:39:54 GMT, Jorn Vernee wrote: >> src/hotspot/cpu/aarch64/downcallLinker_aarch64.cpp line 182: >> >>> 180: ArgumentShuffle arg_shuffle(filtered_java_regs, out_regs, shuffle_reg); >>> 181: >>> 182: #ifndef PRODUCT >> >> Any particular reason to exclude the logging in product builds? `ArgumentShuffle::print_on()` is unconditionally available there. > > This is partly historical. The log output is only intended for debugging, not for end-user eyes. So, I think I originally excluded it as a way of trimming fat from the product build. > > Either way, `ArgumentShuffle::print_on` should probably be excluded/included on the same basis. Either way, this seems like something that should be addressed in a separate patch ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16201#discussion_r1391072872 From duke at openjdk.org Mon Nov 13 13:51:05 2023 From: duke at openjdk.org (Stewart X Addison) Date: Mon, 13 Nov 2023 13:51:05 GMT Subject: RFR: JDK-8319958: Fix ifdef to support WIN32 in libGetXSpace.c Message-ID: ~~I will force push to change ONLY the commit message once I get a bug created - I am not currently an author. In draft until I do that.~~ Done FYI @andrew-m-leonard (who I've discussed this with) and @GoeLin This fixes a build break which has shown up on 32-bit Windows (Deprecated but not removed in [JEP 449](https://openjdk.org/jeps/449)). Found initially in JDK21, but now also affecting JDK17 where Win32 is still fully supported. I intend to get this into 22 then request a backport to all affected versions. This will need to get in before the January CPU to avoid breaking this platform in the next JDK17 release. Introduced by https://github.com/openjdk/jdk/commit/3ef834fc6fc245accffc41da714358fc82f22657 under https://github.com/openjdk/jdk/pull/12397 in February In JDK21: https://github.com/openjdk/jdk21u/commit/3ef834fc6fc245accffc41da714358fc82f22657#diff-6a0b6da94fe13f6caf3b50072a6bef7d559c4b5fc92de7aa2e3c0079f33190d3 That change was backported to JDK17 three weeks ago in https://github.com/openjdk/jdk17u/commit/f85053f578125d1af7c3c762d966fee8283a6ce2 ------------- Commit messages: - JDK-8319958: Fix ifdef to support WIN32 in libGetXSpace.c Changes: https://git.openjdk.org/jdk/pull/16628/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16628&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8319958 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/16628.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16628/head:pull/16628 PR: https://git.openjdk.org/jdk/pull/16628 From duke at openjdk.org Mon Nov 13 14:04:22 2023 From: duke at openjdk.org (Stewart X Addison) Date: Mon, 13 Nov 2023 14:04:22 GMT Subject: RFR: 8319958: test/jdk/java/io/File/libGetXSpace.c does not compile on Windows 32-bit [v2] In-Reply-To: References: Message-ID: > ~~I will force push to change ONLY the commit message once I get a bug created - I am not currently an author. In draft until I do that.~~ Done > > FYI @andrew-m-leonard (who I've discussed this with) and @GoeLin > > This fixes a build break which has shown up on 32-bit Windows (Deprecated but not removed in [JEP 449](https://openjdk.org/jeps/449)). > Found initially in JDK21, but now also affecting JDK17 where Win32 is still fully supported. I intend to get this into 22 then request a backport to all affected versions. This will need to get in before the January CPU to avoid breaking this platform in the next JDK17 release. > > Introduced by https://github.com/openjdk/jdk/commit/3ef834fc6fc245accffc41da714358fc82f22657 under https://github.com/openjdk/jdk/pull/12397 in February > In JDK21: https://github.com/openjdk/jdk21u/commit/3ef834fc6fc245accffc41da714358fc82f22657#diff-6a0b6da94fe13f6caf3b50072a6bef7d559c4b5fc92de7aa2e3c0079f33190d3 > That change was backported to JDK17 three weeks ago in https://github.com/openjdk/jdk17u/commit/f85053f578125d1af7c3c762d966fee8283a6ce2 Stewart X Addison 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: 8319958: Fix ifdef to support WIN32 in libGetXSpace.c Signed-off-by: Stewart X Addison ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16628/files - new: https://git.openjdk.org/jdk/pull/16628/files/cfe8813d..702cea38 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16628&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16628&range=00-01 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/16628.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16628/head:pull/16628 PR: https://git.openjdk.org/jdk/pull/16628 From duke at openjdk.org Mon Nov 13 14:04:23 2023 From: duke at openjdk.org (Stewart X Addison) Date: Mon, 13 Nov 2023 14:04:23 GMT Subject: RFR: 8319958: test/jdk/java/io/File/libGetXSpace.c does not compile on Windows 32-bit In-Reply-To: References: Message-ID: On Mon, 13 Nov 2023 12:02:11 GMT, Stewart X Addison wrote: > ~~I will force push to change ONLY the commit message once I get a bug created - I am not currently an author. In draft until I do that.~~ Done > > FYI @andrew-m-leonard (who I've discussed this with) and @GoeLin > > This fixes a build break which has shown up on 32-bit Windows (Deprecated but not removed in [JEP 449](https://openjdk.org/jeps/449)). > Found initially in JDK21, but now also affecting JDK17 where Win32 is still fully supported. I intend to get this into 22 then request a backport to all affected versions. This will need to get in before the January CPU to avoid breaking this platform in the next JDK17 release. > > Introduced by https://github.com/openjdk/jdk/commit/3ef834fc6fc245accffc41da714358fc82f22657 under https://github.com/openjdk/jdk/pull/12397 in February > In JDK21: https://github.com/openjdk/jdk21u/commit/3ef834fc6fc245accffc41da714358fc82f22657#diff-6a0b6da94fe13f6caf3b50072a6bef7d559c4b5fc92de7aa2e3c0079f33190d3 > That change was backported to JDK17 three weeks ago in https://github.com/openjdk/jdk17u/commit/f85053f578125d1af7c3c762d966fee8283a6ce2 (Force pushing to remove `JDK-` prefix from the commit message - no other changes) ------------- PR Comment: https://git.openjdk.org/jdk/pull/16628#issuecomment-1808216033 From sgehwolf at openjdk.org Mon Nov 13 15:42:00 2023 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Mon, 13 Nov 2023 15:42:00 GMT Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged modules being present [v6] In-Reply-To: <3KNTIkHPE-MFJBMEbo52nz4qwDAUCkiaNRGJngG41xE=.1a6b9d6f-6736-4801-9c5b-5287999d1fa9@github.com> References: <3KNTIkHPE-MFJBMEbo52nz4qwDAUCkiaNRGJngG41xE=.1a6b9d6f-6736-4801-9c5b-5287999d1fa9@github.com> Message-ID: On Sun, 12 Nov 2023 11:37:31 GMT, Alan Bateman wrote: >> Severin Gehwolf has updated the pull request incrementally with four additional commits since the last revision: >> >> - Add a message when a run-image based link is being performed >> - Add hint to the modified file case >> - AddJmodResourcesPlugin => AddRunImageResourcesPlugin rename >> - --add-jmod-resources => --add-run-image-resources rename >> >> Also rename jmod_resources to runimage_resources > > I looked at the latest proposal and CSR. Overall I think the proposal is good and you've got the right default to fail if the run-time image has been modified. So I think we are down to a few lesser topics now. > > I'm wondering if the CLI option to override, meaning a first run-time image containing the jdk.jlink module generates a second run-time image, and the first run-time image has been modified, whether this is really needed. I'm wondering about this because this CLI option is hard to explain, will developers really understand it? If there is an CLI option then we'll need to find a better name, I don't think "--unlock-run-time" works as a name (the usage of options talk about "runtime image" for example, maybe "-ignore-signing-information" can provide inspiration as an override too). > > Can --add-run-image-resources be dropped? Exposing this in the interface feels like it's an attractive nuisance and not clear (to me anyway) what developers would do with this. > > A few very minor things that I jotted down while looking at the current proposal: > > - Adding a resource to serve as a marker that indicates it was created without the packaged modules is fine. I think the name should be looked as "runimage" is a bit consistent for this area. I'm also wondering if it would be better to hide in jdk/internal somewhere to avoid any tooling assuming it's a supported interface. > > - The error message exclaims "Please double check!", I think that error message will need to be tweaked once we get down to details like this. @AlanBateman Thanks for having taken another look! > I looked at the latest proposal and CSR. Overall I think the proposal is good and you've got the right default to fail if the run-time image has been modified. So I think we are down to a few lesser topics now. Glad to hear it. Hopefully we can still get this into JDK 22. > I'm wondering if the CLI option to override, meaning a first run-time image containing the jdk.jlink module generates a second run-time image, and the first run-time image has been modified, whether this is really needed. I'm wondering about this because this CLI option is hard to explain, will developers really understand it? If there is an CLI option then we'll need to find a better name, I don't think "--unlock-run-time" works as a name (the usage of options talk about "runtime image" for example, maybe "-ignore-signing-information" can provide inspiration as an override too). I think we need the option. Be it only for users wanting to validate links with and without packaged modules present (as one of the tests does). How about we call the option `--force-run-image-link`? Or maybe `--ignore-base-run-image-changes`. I'm not very good with coming up with names. > Can --add-run-image-resources be dropped? Exposing this in the interface feels like it's an attractive nuisance and not clear (to me anyway) what developers would do with this. It's not clear what you mean by that. Dropped from what? The CSR? Something else? The run-image based link needs the `--add-run-image-resources` plugin for it to work. > A few very minor things that I jotted down while looking at the current proposal: > > * Adding a resource to serve as a marker that indicates it was created without the packaged modules is fine. I think the name should be looked as "runimage" is a bit consistent for this area. I'm also wondering if it would be better to hide in jdk/internal somewhere to avoid any tooling assuming it's a supported interface. How does `jdk/internal/runimage` as a name sound? > * The error message exclaims "Please double check!", I think that error message will need to be tweaked once we get down to details like this. Sure. I can just drop that phrase. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14787#issuecomment-1808398661 From duke at openjdk.org Mon Nov 13 16:03:08 2023 From: duke at openjdk.org (Yakov Shafranovich) Date: Mon, 13 Nov 2023 16:03:08 GMT Subject: RFR: JDK-8319122: Improve documentation of various Zip-file related APIs [v2] In-Reply-To: <2g3In8YpJfWbDWoF886uO7x2XHFq6mTTKhuG3IVgLh4=.1c26f50d-7926-4ebe-b735-31ae734e3264@github.com> References: <8vEqyECjMkTfesVmL3X0dN4Yu8JShPiUdsKpmEz1WV0=.1b541f77-a05f-490b-aaf1-f6b7456c6d77@github.com> <2g3In8YpJfWbDWoF886uO7x2XHFq6mTTKhuG3IVgLh4=.1c26f50d-7926-4ebe-b735-31ae734e3264@github.com> Message-ID: On Sat, 11 Nov 2023 14:04:11 GMT, Alan Bateman wrote: >> Yakov Shafranovich has updated the pull request incrementally with two additional commits since the last revision: >> >> - Fixed more line breaks >> - fixed line breaks > > src/jdk.zipfs/share/classes/module-info.java line 310: > >> 308: * considered duplicates, which can result in unexpected behavior such as wrong >> 309: * metadata or content being returned when parsing archives containing >> 310: * duplicate names. > > The jdk.zipfs module is the JDK's ZIP file system provider, it allows the contents of a ZIP or JAR file be treated as a file system. I think what is missing from this module description is the mapping of file system concepts to ZIP files. If we added a section to the documentation for that then it would be a place to document the file separator, normalization, how directories and file tree are synthesized, and the limitation that a file system cannot be constructed when it leads to have several entries in a directory having equal names. There's a lot more that could be added but hopefully you can see that an implNote and warnings just doesn't work as a way to present the mapping. That would probably also involve taking existing documentation such as the note about not opening entries with "."/"..", and the POSIX permissions mappings? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16424#discussion_r1391317278 From mcimadamore at openjdk.org Mon Nov 13 16:09:10 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 13 Nov 2023 16:09:10 GMT Subject: RFR: 8319928: Exceptions thrown by cleanup actions passed to reinterpreted segments should be ignored [v2] In-Reply-To: References: Message-ID: <_nJfgVMZekYtS_S1hAkpdIoz5JcZohAsp5djmuxjbOU=.84b1ca53-5d4b-472b-b17b-77f27acd8437@github.com> > This simplePR tweaks the factory which wraps custom cleanup actions passed to `MemorySegment::reinterpret`, so that any exception thrown by the custom cleanup is swallowed when the arena is closed. > > This aligns the behavior of confined/shared session with that of implicit session (as implicit sessions are backed by a `Cleaner`, there is no way for cleanup exception to bubble up). Maurizio Cimadamore has updated the pull request incrementally with three additional commits since the last revision: - More javadoc tweaks - Tweak javadoc - Catch all cleanup failures in `CleanupException` ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16619/files - new: https://git.openjdk.org/jdk/pull/16619/files/6eb8998a..5f57ab3c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16619&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16619&range=00-01 Stats: 105 lines in 4 files changed: 91 ins; 4 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/16619.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16619/head:pull/16619 PR: https://git.openjdk.org/jdk/pull/16619 From mcimadamore at openjdk.org Mon Nov 13 16:09:12 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 13 Nov 2023 16:09:12 GMT Subject: RFR: 8319928: Exceptions thrown by cleanup actions passed to reinterpreted segments should be ignored In-Reply-To: References: Message-ID: On Fri, 10 Nov 2023 16:34:11 GMT, Maurizio Cimadamore wrote: > This simplePR tweaks the factory which wraps custom cleanup actions passed to `MemorySegment::reinterpret`, so that any exception thrown by the custom cleanup is swallowed when the arena is closed. > > This aligns the behavior of confined/shared session with that of implicit session (as implicit sessions are backed by a `Cleaner`, there is no way for cleanup exception to bubble up). After some offline discussions, I've decided to add a new exception (Arena.CleanupException) which is used to wrap custom cleanup action exceptions and rethrow them on close. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16619#issuecomment-1808461148 From rriggs at openjdk.org Mon Nov 13 16:44:59 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Mon, 13 Nov 2023 16:44:59 GMT Subject: RFR: 8319753: Duration javadoc has "period" instead of "duration" in several places In-Reply-To: References: Message-ID: On Wed, 8 Nov 2023 21:58:47 GMT, Eamonn McManus wrote: > This change simply replaces "period" with "duration", or in one case replaces "period unit" with just "unit". Looks good. I reviewed the CSR, it can be "Finalized" to get its review started. ------------- Marked as reviewed by rriggs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16573#pullrequestreview-1727732928 PR Comment: https://git.openjdk.org/jdk/pull/16573#issuecomment-1808529657 From mcimadamore at openjdk.org Mon Nov 13 16:44:57 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 13 Nov 2023 16:44:57 GMT Subject: RFR: 8319928: Exceptions thrown by cleanup actions should be handled correctly In-Reply-To: References: Message-ID: On Mon, 13 Nov 2023 16:05:08 GMT, Maurizio Cimadamore wrote: > After some offline discussions, I've decided to add a new exception (Arena.CleanupException) which is used to wrap custom cleanup action exceptions and rethrow them on close. To be clear, the reasons as to why the original proposal was amended are as follows: * it is a "bug" rather than a feature that exceptions are swallowed by a cleaner. Having those exceptions bubbling up when calling `Arena::close` provides meaningful diagnostic feedback; * the fact that an automatic arena doesn't report any exception from custom cleanup can be seen explained as: a `Cleaner` will call `Arena::close` implicitly, so exceptions (including the new `Arena.CleanupException`) will be swallowed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16619#issuecomment-1808531110 From naoto at openjdk.org Mon Nov 13 16:57:14 2023 From: naoto at openjdk.org (Naoto Sato) Date: Mon, 13 Nov 2023 16:57:14 GMT Subject: Integrated: 8296250" Update ICU4J to Version 74.1 In-Reply-To: References: Message-ID: On Wed, 1 Nov 2023 17:40:09 GMT, Naoto Sato wrote: > Updating the ICU4J components to v74.1 (https://icu.unicode.org/download/74). This change completes the Unicode 15.1 upgrade. The change is merely replacing binary data files used for the Normalization and BiDi support This pull request has now been integrated. Changeset: 88ccd646 Author: Naoto Sato URL: https://git.openjdk.org/jdk/commit/88ccd646a7778045d773099da0f743efb169169c Stats: 528 lines in 12 files changed: 80 ins; 426 del; 22 mod 8296250: Update ICU4J to Version 74.1 Reviewed-by: joehw, lancea, rriggs ------------- PR: https://git.openjdk.org/jdk/pull/16458 From naoto at openjdk.org Mon Nov 13 16:58:17 2023 From: naoto at openjdk.org (Naoto Sato) Date: Mon, 13 Nov 2023 16:58:17 GMT Subject: Integrated: 8306116: Update CLDR to Version 44.0 In-Reply-To: References: Message-ID: On Tue, 31 Oct 2023 21:06:13 GMT, Naoto Sato wrote: > Upgrading CLDR to v44 (https://cldr.unicode.org/index/downloads/cldr-44). Besides the data upgrade, regression tests are modified to accommodate the following CLDR fixes: > > CLDR-16534: Suggestion to rename the Islamic Calendar to Hijri Calendar (https://unicode-org.atlassian.net/browse/CLDR-16534) > CLDR-17042: Use exception list for new languages (https://unicode-org.atlassian.net/browse/CLDR-17042) > CLDR-16586: en_ID shows IDR rather than Rp for currency (https://unicode-org.atlassian.net/browse/CLDR-16586) > CLDR-16358: Mexico and Latin America countries should be using 12 hours time format (https://unicode-org.atlassian.net/browse/CLDR-16358) > CLDR-16974: en_GB and en_AU: request to remove comma from MMMEEEEd format (https://unicode-org.atlassian.net/browse/CLDR-16974) > CLDR-16857: Need updated translations for new Sierra Leone currency - SLL became SLE (https://unicode-org.atlassian.net/browse/CLDR-16857) This pull request has now been integrated. Changeset: 3684b4b5 Author: Naoto Sato URL: https://git.openjdk.org/jdk/commit/3684b4b5f24b413408b1b6d206917931b855844e Stats: 591898 lines in 499 files changed: 72642 ins; 463467 del; 55789 mod 8306116: Update CLDR to Version 44.0 Reviewed-by: srl, joehw, lancea ------------- PR: https://git.openjdk.org/jdk/pull/16439 From sgehwolf at openjdk.org Mon Nov 13 17:00:32 2023 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Mon, 13 Nov 2023 17:00:32 GMT Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged modules being present [v7] In-Reply-To: References: Message-ID: > Please review this patch which adds a "jmodless" jlink mode to the JDK. Fundamentally this patch adds an option to use `jlink` even though your JDK install might not come with the packaged modules (directory `jmods`). This is particularly useful to further reduce the size of a jlinked runtime. After the removal of the concept of a JRE, a common distribution mechanism is still the full JDK with all modules and packaged modules. However, packaged modules can incur an additional size tax. For example in a container scenario it could be useful to have a base JDK container including all modules, but without also delivering the packaged modules. This comes at a size advantage of `~25%`. Such a base JDK container could then be used to `jlink` application specific runtimes, further reducing the size of the application runtime image (App + JDK runtime; as a single image *or* separate bundles, depending on the app being modularized). > > The basic design of this approach is to add a jlink plugin for tracking non-class and non-resource files of a JDK install. I.e. files which aren't present in the jimage (`lib/modules`). This enables producing a `JmodLessArchive` class which has all the info of what constitutes the final jlinked runtime. > > Basic usage example: > > $ diff -u <(./bin/java --list-modules --limit-modules java.se) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules java.se) > $ diff -u <(./bin/java --list-modules --limit-modules java.se) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules jdk.jlink) > $ ls ../linux-x86_64-server-release/images/jdk/jmods > java.base.jmod java.net.http.jmod java.sql.rowset.jmod jdk.crypto.ec.jmod jdk.internal.opt.jmod jdk.jdi.jmod jdk.management.agent.jmod jdk.security.auth.jmod > java.compiler.jmod java.prefs.jmod java.transaction.xa.jmod jdk.dynalink.jmod jdk.internal.vm.ci.jmod jdk.jdwp.agent.jmod jdk.management.jfr.jmod jdk.security.jgss.jmod > java.datatransfer.jmod java.rmi.jmod java.xml.crypto.jmod jdk.editpad.jmod jdk.internal.vm.compiler.jmod jdk.jfr.jmod jdk.management.jmod jdk.unsupported.desktop.jmod > java.desktop.jmod java.scripting.jmod java.xml.jmod jdk.hotspot.agent.jmod jdk.internal.vm.compiler.management.jmod jdk.jlink.jmod jdk.naming.dns.jmod jdk.unsupported... Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 16 additional commits since the last revision: - Merge branch 'master' into jdk-8311302-jmodless-link - Add a message when a run-image based link is being performed - Add hint to the modified file case - AddJmodResourcesPlugin => AddRunImageResourcesPlugin rename - --add-jmod-resources => --add-run-image-resources rename Also rename jmod_resources to runimage_resources - Improve error message of run-image recursive link - Use a single option --unlock-run-image for single hop and warnings - JmodLessArchive => RunImageArchive rename - Merge branch 'master' into jdk-8311302-jmodless-link - Work-around JDK-8317609 (jdk.jcmd module doesn't verify) - ... and 6 more: https://git.openjdk.org/jdk/compare/a23907ec...fea34e3a ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14787/files - new: https://git.openjdk.org/jdk/pull/14787/files/b82efb08..fea34e3a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14787&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14787&range=05-06 Stats: 73397 lines in 2188 files changed: 36664 ins; 18945 del; 17788 mod Patch: https://git.openjdk.org/jdk/pull/14787.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14787/head:pull/14787 PR: https://git.openjdk.org/jdk/pull/14787 From alanb at openjdk.org Mon Nov 13 18:13:59 2023 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 13 Nov 2023 18:13:59 GMT Subject: RFR: JDK-8319122: Improve documentation of various Zip-file related APIs [v2] In-Reply-To: References: <8vEqyECjMkTfesVmL3X0dN4Yu8JShPiUdsKpmEz1WV0=.1b541f77-a05f-490b-aaf1-f6b7456c6d77@github.com> <2g3In8YpJfWbDWoF886uO7x2XHFq6mTTKhuG3IVgLh4=.1c26f50d-7926-4ebe-b735-31ae734e3264@github.com> Message-ID: <9O4rzgUxgatkIKu8aCng2w9ypg3Gpao185Osd6nzZws=.de9a68c6-577b-40fd-9e9e-32e12873f919@github.com> On Mon, 13 Nov 2023 16:00:05 GMT, Yakov Shafranovich wrote: > That would probably also involve taking existing documentation such as the note about not opening entries with "."/"..", and the POSIX permissions mappings? Would it make sense to split the rest of the changes in this PR from the zipfs changes since that's going to be a bigger undertaking? Yes, I think it should be separated, and it would be nice to drop the changes to jdk.zipfs from this PR. If/when this documentation is written then it describe the "/" character and the synthesized links that are "." and "..", which can lead to documentation that a zip file that contain contains with "." or ".." elements cannot be opened as a file system. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16424#discussion_r1391493510 From naoto at openjdk.org Mon Nov 13 18:37:42 2023 From: naoto at openjdk.org (Naoto Sato) Date: Mon, 13 Nov 2023 18:37:42 GMT Subject: RFR: 8319640: ClassicFormat::parseObject (from DateTimeFormatter) does not conform to the javadoc and may leak DateTimeException [v2] In-Reply-To: References: Message-ID: > Fixing the `Format::parseObject(String, ParsePosition)` implementation in `DateTimeFormatter` class, to not throw `DateTimeException` but to return null. 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 four additional commits since the last revision: - comment fix - Addresses review comments - Merge branch 'master' into JDK-8319640-ClassicFormat-parseObject - initial commit ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16586/files - new: https://git.openjdk.org/jdk/pull/16586/files/7a4b8ef2..2b03aa2d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16586&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16586&range=00-01 Stats: 611054 lines in 787 files changed: 78824 ins; 472476 del; 59754 mod Patch: https://git.openjdk.org/jdk/pull/16586.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16586/head:pull/16586 PR: https://git.openjdk.org/jdk/pull/16586 From naoto at openjdk.org Mon Nov 13 18:37:42 2023 From: naoto at openjdk.org (Naoto Sato) Date: Mon, 13 Nov 2023 18:37:42 GMT Subject: RFR: 8319640: ClassicFormat::parseObject (from DateTimeFormatter) does not conform to the javadoc and may leak DateTimeException [v2] In-Reply-To: References: Message-ID: On Fri, 10 Nov 2023 01:20:28 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 four additional commits since the last revision: >> >> - comment fix >> - Addresses review comments >> - Merge branch 'master' into JDK-8319640-ClassicFormat-parseObject >> - initial commit > > test/jdk/java/time/test/java/time/format/TestDateTimeParsing.java line 260: > >> 258: .toFormatter(Locale.ROOT) >> 259: .toFormat(); >> 260: assertEquals(f.parseObject("17-30", new ParsePosition(0)), null); > > I might have missed it, but this test doesn't seem to exercise the situation where IOOBE would happen. Though the result would be the same as it catches RuntimeException always, I wonder whether an additional test case would be helpful to verify the IOOBE situation, e.g. set the position to be greater than the length. Thanks, Joe. Added extra test for IOOBE. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16586#discussion_r1391518275 From naoto at openjdk.org Mon Nov 13 18:41:08 2023 From: naoto at openjdk.org (Naoto Sato) Date: Mon, 13 Nov 2023 18:41:08 GMT Subject: RFR: 8319640: ClassicFormat::parseObject (from DateTimeFormatter) does not conform to the javadoc and may leak DateTimeException [v3] In-Reply-To: References: Message-ID: <3kVo3Ekns0CGdqxh9XtcU3Nq3VfLjAN55kZ6qV7S2ck=.5401cdab-726f-4f71-96cd-50099e9cc81a@github.com> > Fixing the `Format::parseObject(String, ParsePosition)` implementation in `DateTimeFormatter` class, to not throw `DateTimeException` but to return null. Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: comment fix^2 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16586/files - new: https://git.openjdk.org/jdk/pull/16586/files/2b03aa2d..f43ae0f2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16586&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16586&range=01-02 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/16586.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16586/head:pull/16586 PR: https://git.openjdk.org/jdk/pull/16586 From vromero at openjdk.org Mon Nov 13 18:44:58 2023 From: vromero at openjdk.org (Vicente Romero) Date: Mon, 13 Nov 2023 18:44:58 GMT Subject: RFR: 8319220: Pattern matching switch with a lot of cases is unduly slow [v5] In-Reply-To: References: Message-ID: On Tue, 7 Nov 2023 14:18:41 GMT, Jan Lahoda wrote: >> Consider code like: >> >> void test(Object o) { >> switch (o) { >> case X1 -> {} >> case X2 -> {} >> ...(about 100 cases) >> ``` >> >> javac will compile the switch into a switch whose selector is an indy invocation to `SwitchBootstraps.typeSwitch`, with static arguments being the types in the cases. >> >> `SwitchBootstraps.typeSwitch` will then create a chain of `MethodHandle`s performing `instanceof` checks between the switch's selector and the given case type. The problem is that when the number of cases is high enough, (more than ~40-50), the chain gets too long, and the tests won't inline anymore. This then leads to a very bad performance, when compared to manually written if-instanceof-else-if-instanceof- chain. >> >> The proposal herein is to use bytecode (written using the ClassFile API/library) instead of the `MethodHandle`s chain. The overall performance of this seems to be similar to the manually written if-instanceof-else-if-instanceof- chain. >> >> Using the benchmark from the bug, and this patch, I am getting: >> >> MyBenchmark.testIfElse100 thrpt 5 521826.326 ? 7510.042 ops/s >> MyBenchmark.testSwitch100 thrpt 5 505440.170 ? 3757.178 ops/s >> >> >> The most tricky part of this new way to generate the tests is handling of non-type case labels, and in particular cases with enum constant labels. The resolution of enum constants is deferred as much as possible, by using an indirection through the `ResolvedEnumLabels`. >> >> Further improvements may be possible, esp. for some specific cases (like all cases having a type, and the type being a final class). > > Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits: > > - Merge branch 'master' into JDK-8319220 > - reflecting review comment: fixing letter case. > - Reflecting review feedback. > - Some more get->orElseThrow > - Reflecting review feedback. > - Avoiding generating dead code - review feedback. > - Cleanup. > - Attempting to speeding SwitchBootstraps. lgtm, very interesting! ------------- Marked as reviewed by vromero (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16489#pullrequestreview-1727980755 From naoto at openjdk.org Mon Nov 13 19:35:41 2023 From: naoto at openjdk.org (Naoto Sato) Date: Mon, 13 Nov 2023 19:35:41 GMT Subject: RFR: JDK-8319628: DateFormat does not mention IllegalArgumentException for invalid style args In-Reply-To: References: Message-ID: <745WFfokAyTnXxGiMr6ux80MxA85Y2PyQr322jllonI=.d5d53f5e-18bb-4fd1-bd3e-c70184ea4be8@github.com> On Sun, 12 Nov 2023 21:39:29 GMT, Justin Lu wrote: > Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8319868) which makes IllegalArgumentExceptions apparent for the _j.text.DateFormat_ static factory methods that have the _style_ parameter. src/java.base/share/classes/java/text/DateFormat.java line 68: > 66: * styles. The formatting styles include {@link #FULL}, {@link #LONG}, {@link #MEDIUM}, and {@link #SHORT}. > 67: * For any of the factory methods with the parameter style, an {@code > 68: * IllegalArgumentException} will be thrown if style is not equal to one I wonder if "not equal to *any* of the ..." may read better here. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16624#discussion_r1391596506 From darcy at openjdk.org Mon Nov 13 19:40:48 2023 From: darcy at openjdk.org (Joe Darcy) Date: Mon, 13 Nov 2023 19:40:48 GMT Subject: RFR: JDK-8295391: Add discussion of binary <-> decimal conversion issues [v5] In-Reply-To: References: Message-ID: <9SZ9cE9dbV4EDf_4zph2yfdDQesTEsg0AN5II0LpGnA=.9185a738-df52-4ae2-af92-ce4b8b489430@github.com> > Add discussion of some of the common pitfalls related to decimal <-> binary conversion. Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: - Merge branch 'master' into JDK-8295391 - Fix typo. - Switch to parseFloat from valueOf, add links. - Address issues found by reviewers. - Appease jcheck. - JDK-8295391: Add discussion of binary <-> decimal conversion issues ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16566/files - new: https://git.openjdk.org/jdk/pull/16566/files/d8d6c00b..7dd11da2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16566&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16566&range=03-04 Stats: 18043 lines in 283 files changed: 5486 ins; 8626 del; 3931 mod Patch: https://git.openjdk.org/jdk/pull/16566.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16566/head:pull/16566 PR: https://git.openjdk.org/jdk/pull/16566 From bpb at openjdk.org Mon Nov 13 19:41:48 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Mon, 13 Nov 2023 19:41:48 GMT Subject: RFR: 8287843: File::getCanonicalFile doesn't work for \\?\C:\ style paths DOS device paths [v8] In-Reply-To: References: Message-ID: <19bVaXUXu_WNtbJL2CCd0zfqG1Fq3YkhfC8msRn0G9Q=.00ef8eba-dce3-497c-bba6-d396f1d5759a@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 with a new target base 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: - 8287843: Change tests as suggested in review - Merge - 8287843: Remove unused constant and method from WindowsPrefixes test - 8287843: remove stripLongOrUNCPrefix() except in normalize() - 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 - 8287843: Move prefix stripping to separate method; add to isAbsolute - 8287843: Move \\?\ prefix stripping to resolve(File) - 8287843: Handle "\\?\UNC"; add bad paths to test - ... and 1 more: https://git.openjdk.org/jdk/compare/3ed19459...2f313185 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15603/files - new: https://git.openjdk.org/jdk/pull/15603/files/a43f7276..2f313185 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15603&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15603&range=06-07 Stats: 807994 lines in 5961 files changed: 173684 ins; 518195 del; 116115 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 Mon Nov 13 19:41:51 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Mon, 13 Nov 2023 19:41:51 GMT Subject: RFR: 8287843: File::getCanonicalFile doesn't work for \\?\C:\ style paths DOS device paths [v7] In-Reply-To: References: <26zgN9543IcbQEum-nEsgfSv4v8412UkkJ412GszuXw=.44fa0b44-fc17-40d0-99a6-87d6d8be58a1@github.com> Message-ID: On Sat, 11 Nov 2023 11:18:04 GMT, Alan Bateman wrote: >> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: >> >> 8287843: Remove unused constant and method from WindowsPrefixes test > > test/jdk/java/io/File/GetAbsolutePath.java line 76: > >> 74: public void windows(String path, String absolute) throws IOException { >> 75: assertEquals(absolute.toLowerCase(), >> 76: new File(path).getAbsolutePath().toLowerCase()); > > WinNTFileSystem.compareTo uses compareToIgnoreCase so this test should probably do the same. So changed in 2f31318530d7093dc69c07115c5d46b63612ff4b. > test/jdk/java/io/File/WindowsPrefixes.java line 27: > >> 25: * @bug 8287843 >> 26: * @summary Basic test for Windows path prefixes >> 27: * @requires (os.family == "windows") > > Given the `@requires` then I assume `@EnabledOnOs(OS.WINDOWS)` can be dropped from the test methods. Indeed the `@EnabledOnOs` are pointless here. Removed in 2f31318530d7093dc69c07115c5d46b63612ff4b. > test/jdk/java/io/File/WindowsPrefixes.java line 54: > >> 52: Arguments.of("C:\\foo"), >> 53: Arguments.of("C:foo"), >> 54: Arguments.of("C:\\foo\\bar")); > > I suppose this should include `\foo` in the list too. Included in 2f31318530d7093dc69c07115c5d46b63612ff4b. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15603#discussion_r1391604968 PR Review Comment: https://git.openjdk.org/jdk/pull/15603#discussion_r1391603346 PR Review Comment: https://git.openjdk.org/jdk/pull/15603#discussion_r1391604363 From rriggs at openjdk.org Mon Nov 13 19:52:10 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Mon, 13 Nov 2023 19:52:10 GMT Subject: RFR: 8319640: ClassicFormat::parseObject (from DateTimeFormatter) does not conform to the javadoc and may leak DateTimeException [v3] In-Reply-To: <3kVo3Ekns0CGdqxh9XtcU3Nq3VfLjAN55kZ6qV7S2ck=.5401cdab-726f-4f71-96cd-50099e9cc81a@github.com> References: <3kVo3Ekns0CGdqxh9XtcU3Nq3VfLjAN55kZ6qV7S2ck=.5401cdab-726f-4f71-96cd-50099e9cc81a@github.com> Message-ID: <93p7Rpn6iffeQPULlFiHv_hFJxd63GGz8Of6hJsN9vc=.f811574f-276c-41a4-a1d7-204b4b6df32b@github.com> On Mon, 13 Nov 2023 18:41:08 GMT, Naoto Sato wrote: >> Fixing the `Format::parseObject(String, ParsePosition)` implementation in `DateTimeFormatter` class, to not throw `DateTimeException` but to return null. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > comment fix^2 Marked as reviewed by rriggs (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/16586#pullrequestreview-1728140279 From alanb at openjdk.org Mon Nov 13 19:52:18 2023 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 13 Nov 2023 19:52:18 GMT Subject: RFR: 8287843: File::getCanonicalFile doesn't work for \\?\C:\ style paths DOS device paths [v8] In-Reply-To: <19bVaXUXu_WNtbJL2CCd0zfqG1Fq3YkhfC8msRn0G9Q=.00ef8eba-dce3-497c-bba6-d396f1d5759a@github.com> References: <19bVaXUXu_WNtbJL2CCd0zfqG1Fq3YkhfC8msRn0G9Q=.00ef8eba-dce3-497c-bba6-d396f1d5759a@github.com> Message-ID: On Mon, 13 Nov 2023 19:41:48 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 with a new target base 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: > > - 8287843: Change tests as suggested in review > - Merge > - 8287843: Remove unused constant and method from WindowsPrefixes test > - 8287843: remove stripLongOrUNCPrefix() except in normalize() > - 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 > - 8287843: Move prefix stripping to separate method; add to isAbsolute > - 8287843: Move \\?\ prefix stripping to resolve(File) > - 8287843: Handle "\\?\UNC"; add bad paths to test > - ... and 1 more: https://git.openjdk.org/jdk/compare/f6b98c0c...2f313185 I don't have any other comments on this. I assume you'll run the tests a number of times to make sure they are stable. ------------- Marked as reviewed by alanb (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15603#pullrequestreview-1728139348 From bpb at openjdk.org Mon Nov 13 20:10:08 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Mon, 13 Nov 2023 20:10:08 GMT Subject: RFR: 8287843: File::getCanonicalFile doesn't work for \\?\C:\ style paths DOS device paths [v8] In-Reply-To: References: <19bVaXUXu_WNtbJL2CCd0zfqG1Fq3YkhfC8msRn0G9Q=.00ef8eba-dce3-497c-bba6-d396f1d5759a@github.com> Message-ID: On Mon, 13 Nov 2023 19:49:17 GMT, Alan Bateman wrote: > I assume you'll run the tests a number of times to make sure they are stable. I always run tiers 1-3 before integrating, but will add also separate runs of these tests with repeats. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15603#issuecomment-1808970375 From rriggs at openjdk.org Mon Nov 13 20:25:29 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Mon, 13 Nov 2023 20:25:29 GMT Subject: RFR: 8311906: Improve robustness of String constructors with mutable array inputs [v2] In-Reply-To: References: <6SKlGLh5MmxoEx07wHCCUc8KWbbhcspLJmcc1uxQ_FI=.ca33bfb4-fa5c-45f0-b49f-ee6c5c6b68b4@github.com> Message-ID: On Thu, 9 Nov 2023 04:16:25 GMT, Roger Riggs wrote: >> Strings, after construction, are immutable but may be constructed from mutable arrays of bytes, characters, or integers. >> The string constructors should guard against the effects of mutating the arrays during construction that might invalidate internal invariants for the correct behavior of operations on the resulting strings. In particular, a number of operations have optimizations for operations on pairs of latin1 strings and pairs of non-latin1 strings, while operations between latin1 and non-latin1 strings use a more general implementation. >> >> The changes include: >> >> - Adding a warning to each constructor with an array as an argument to indicate that the results are indeterminate >> if the input array is modified before the constructor returns. >> The resulting string may contain any combination of characters sampled from the input array. >> >> - Ensure that strings that are represented as non-latin1 contain at least one non-latin1 character. >> For latin1 inputs, whether the arrays contain ASCII, ISO-8859-1, UTF8, or another encoding decoded to latin1 the scanning and compression is unchanged. >> If a non-latin1 character is found, the string is represented as non-latin1 with the added verification that a non-latin1 character is present at the same index. >> If that character is found to be latin1, then the input array has been modified and the result of the scan may be incorrect. >> Though a ConcurrentModificationException could be thrown, the risk to an existing application of an unexpected exception should be avoided. >> Instead, the non-latin1 copy of the input is re-scanned and compressed; that scan determines whether the latin1 or the non-latin1 representation is returned. >> >> - The methods that scan for non-latin1 characters and their intrinsic implementations are updated to return the index of the non-latin1 character. >> >> - String construction from StringBuilder and CharSequence must also be guarded as their contents may be modified during construction. > > Roger Riggs has updated the pull request incrementally with three additional commits since the last revision: > > - Refactored extractCodePoints to avoid multiple resizes if the array was modified > - Replaced isLatin1 implementation with `getChar(buf, ndx) <= 0xff` > It performs better than the single byte array access by avoiding the bounds check. > - Misc updates for review comments, javadoc cleanup > Extra checking on maximum string lengths when calling toBytes(). Contributed update to s390.ad. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16425#issuecomment-1809008222 From rriggs at openjdk.org Mon Nov 13 20:42:00 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Mon, 13 Nov 2023 20:42:00 GMT Subject: RFR: 8311906: Improve robustness of String constructors with mutable array inputs [v3] In-Reply-To: <6SKlGLh5MmxoEx07wHCCUc8KWbbhcspLJmcc1uxQ_FI=.ca33bfb4-fa5c-45f0-b49f-ee6c5c6b68b4@github.com> References: <6SKlGLh5MmxoEx07wHCCUc8KWbbhcspLJmcc1uxQ_FI=.ca33bfb4-fa5c-45f0-b49f-ee6c5c6b68b4@github.com> Message-ID: > Strings, after construction, are immutable but may be constructed from mutable arrays of bytes, characters, or integers. > The string constructors should guard against the effects of mutating the arrays during construction that might invalidate internal invariants for the correct behavior of operations on the resulting strings. In particular, a number of operations have optimizations for operations on pairs of latin1 strings and pairs of non-latin1 strings, while operations between latin1 and non-latin1 strings use a more general implementation. > > The changes include: > > - Adding a warning to each constructor with an array as an argument to indicate that the results are indeterminate > if the input array is modified before the constructor returns. > The resulting string may contain any combination of characters sampled from the input array. > > - Ensure that strings that are represented as non-latin1 contain at least one non-latin1 character. > For latin1 inputs, whether the arrays contain ASCII, ISO-8859-1, UTF8, or another encoding decoded to latin1 the scanning and compression is unchanged. > If a non-latin1 character is found, the string is represented as non-latin1 with the added verification that a non-latin1 character is present at the same index. > If that character is found to be latin1, then the input array has been modified and the result of the scan may be incorrect. > Though a ConcurrentModificationException could be thrown, the risk to an existing application of an unexpected exception should be avoided. > Instead, the non-latin1 copy of the input is re-scanned and compressed; that scan determines whether the latin1 or the non-latin1 representation is returned. > > - The methods that scan for non-latin1 characters and their intrinsic implementations are updated to return the index of the non-latin1 character. > > - String construction from StringBuilder and CharSequence must also be guarded as their contents may be modified during construction. Roger Riggs has updated the pull request incrementally with two additional commits since the last revision: - code and doc cleanup in StringRacyConstructor test - Update of string_compress for the s390 port to return the index of the non-latin1 char. Contributed by Amit Kumar. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16425/files - new: https://git.openjdk.org/jdk/pull/16425/files/ad73a2a6..f6080595 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16425&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16425&range=01-02 Stats: 11 lines in 2 files changed: 0 ins; 1 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/16425.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16425/head:pull/16425 PR: https://git.openjdk.org/jdk/pull/16425 From emcmanus at openjdk.org Mon Nov 13 20:59:44 2023 From: emcmanus at openjdk.org (Eamonn McManus) Date: Mon, 13 Nov 2023 20:59:44 GMT Subject: Integrated: 8319753: Duration javadoc has "period" instead of "duration" in several places In-Reply-To: References: Message-ID: On Wed, 8 Nov 2023 21:58:47 GMT, Eamonn McManus wrote: > This change simply replaces "period" with "duration", or in one case replaces "period unit" with just "unit". This pull request has now been integrated. Changeset: 965ae729 Author: Eamonn McManus URL: https://git.openjdk.org/jdk/commit/965ae7296459bb25ef8f0d1ba4955f1ed7260ab3 Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod 8319753: Duration javadoc has "period" instead of "duration" in several places Reviewed-by: rriggs ------------- PR: https://git.openjdk.org/jdk/pull/16573 From bpb at openjdk.org Mon Nov 13 21:21:29 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Mon, 13 Nov 2023 21:21:29 GMT Subject: RFR: 8319958: test/jdk/java/io/File/libGetXSpace.c does not compile on Windows 32-bit [v2] In-Reply-To: References: Message-ID: On Mon, 13 Nov 2023 14:04:22 GMT, Stewart X Addison wrote: >> ~~I will force push to change ONLY the commit message once I get a bug created - I am not currently an author. In draft until I do that.~~ Done >> >> FYI @andrew-m-leonard (who I've discussed this with) and @GoeLin >> >> This fixes a build break which has shown up on 32-bit Windows (Deprecated but not removed in [JEP 449](https://openjdk.org/jeps/449)). >> Found initially in JDK21, but now also affecting JDK17 where Win32 is still fully supported. I intend to get this into 22 then request a backport to all affected versions. This will need to get in before the January CPU to avoid breaking this platform in the next JDK17 release. >> >> Introduced by https://github.com/openjdk/jdk/commit/3ef834fc6fc245accffc41da714358fc82f22657 under https://github.com/openjdk/jdk/pull/12397 in February >> In JDK21: https://github.com/openjdk/jdk21u/commit/3ef834fc6fc245accffc41da714358fc82f22657#diff-6a0b6da94fe13f6caf3b50072a6bef7d559c4b5fc92de7aa2e3c0079f33190d3 >> That change was backported to JDK17 three weeks ago in https://github.com/openjdk/jdk17u/commit/f85053f578125d1af7c3c762d966fee8283a6ce2 > > Stewart X Addison 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: > > 8319958: Fix ifdef to support WIN32 in libGetXSpace.c > > Signed-off-by: Stewart X Addison Looks good. I verified that the test still builds and succeeds on Win64. ------------- Marked as reviewed by bpb (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16628#pullrequestreview-1728303108 From jlu at openjdk.org Mon Nov 13 21:38:11 2023 From: jlu at openjdk.org (Justin Lu) Date: Mon, 13 Nov 2023 21:38:11 GMT Subject: RFR: JDK-8319628: DateFormat does not mention IllegalArgumentException for invalid style args [v2] In-Reply-To: References: Message-ID: > Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8319868) which makes IllegalArgumentExceptions apparent for the _j.text.DateFormat_ static factory methods that have the _style_ parameter. Justin Lu has updated the pull request incrementally with one additional commit since the last revision: reflect review, one -> any ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16624/files - new: https://git.openjdk.org/jdk/pull/16624/files/f1a4b6c9..fa795543 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16624&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16624&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/16624.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16624/head:pull/16624 PR: https://git.openjdk.org/jdk/pull/16624 From jlu at openjdk.org Mon Nov 13 21:38:11 2023 From: jlu at openjdk.org (Justin Lu) Date: Mon, 13 Nov 2023 21:38:11 GMT Subject: RFR: JDK-8319628: DateFormat does not mention IllegalArgumentException for invalid style args [v2] In-Reply-To: <745WFfokAyTnXxGiMr6ux80MxA85Y2PyQr322jllonI=.d5d53f5e-18bb-4fd1-bd3e-c70184ea4be8@github.com> References: <745WFfokAyTnXxGiMr6ux80MxA85Y2PyQr322jllonI=.d5d53f5e-18bb-4fd1-bd3e-c70184ea4be8@github.com> Message-ID: On Mon, 13 Nov 2023 19:32:18 GMT, Naoto Sato wrote: >> Justin Lu has updated the pull request incrementally with one additional commit since the last revision: >> >> reflect review, one -> any > > src/java.base/share/classes/java/text/DateFormat.java line 68: > >> 66: * styles. The formatting styles include {@link #FULL}, {@link #LONG}, {@link #MEDIUM}, and {@link #SHORT}. >> 67: * For any of the factory methods with the parameter style, an {@code >> 68: * IllegalArgumentException} will be thrown if style is not equal to one > > I wonder if "not equal to *any* of the ..." may read better here. Agreed that sounds better. Changed in both the CSR and the PR, thanks. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16624#discussion_r1391730654 From jlu at openjdk.org Mon Nov 13 22:07:01 2023 From: jlu at openjdk.org (Justin Lu) Date: Mon, 13 Nov 2023 22:07:01 GMT Subject: RFR: JDK-8319626: Override toString() for ZipFile Message-ID: Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8319982) which overrides and provides an implementation of `toString()` in _java.util.zip.ZipFile_ (and by extension, _java.util.jar.JarFile_). This change is primarily to provide a more informative String representation of the two classes rather than the default hexadecimal representation of the hash code. ------------- Commit messages: - init Changes: https://git.openjdk.org/jdk/pull/16643/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16643&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8319626 Stats: 13 lines in 1 file changed: 13 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/16643.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16643/head:pull/16643 PR: https://git.openjdk.org/jdk/pull/16643 From joehw at openjdk.org Mon Nov 13 22:13:28 2023 From: joehw at openjdk.org (Joe Wang) Date: Mon, 13 Nov 2023 22:13:28 GMT Subject: RFR: 8319640: ClassicFormat::parseObject (from DateTimeFormatter) does not conform to the javadoc and may leak DateTimeException [v3] In-Reply-To: <3kVo3Ekns0CGdqxh9XtcU3Nq3VfLjAN55kZ6qV7S2ck=.5401cdab-726f-4f71-96cd-50099e9cc81a@github.com> References: <3kVo3Ekns0CGdqxh9XtcU3Nq3VfLjAN55kZ6qV7S2ck=.5401cdab-726f-4f71-96cd-50099e9cc81a@github.com> Message-ID: On Mon, 13 Nov 2023 18:41:08 GMT, Naoto Sato wrote: >> Fixing the `Format::parseObject(String, ParsePosition)` implementation in `DateTimeFormatter` class, to not throw `DateTimeException` but to return null. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > comment fix^2 Marked as reviewed by joehw (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/16586#pullrequestreview-1728370308 From joehw at openjdk.org Mon Nov 13 22:13:31 2023 From: joehw at openjdk.org (Joe Wang) Date: Mon, 13 Nov 2023 22:13:31 GMT Subject: RFR: 8319640: ClassicFormat::parseObject (from DateTimeFormatter) does not conform to the javadoc and may leak DateTimeException [v3] In-Reply-To: References: Message-ID: On Mon, 13 Nov 2023 18:33:55 GMT, Naoto Sato wrote: >> test/jdk/java/time/test/java/time/format/TestDateTimeParsing.java line 260: >> >>> 258: .toFormatter(Locale.ROOT) >>> 259: .toFormat(); >>> 260: assertEquals(f.parseObject("17-30", new ParsePosition(0)), null); >> >> I might have missed it, but this test doesn't seem to exercise the situation where IOOBE would happen. Though the result would be the same as it catches RuntimeException always, I wonder whether an additional test case would be helpful to verify the IOOBE situation, e.g. set the position to be greater than the length. > > Thanks, Joe. Added extra test for IOOBE. Thanks, Naoto. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16586#discussion_r1391759495 From jvernee at openjdk.org Mon Nov 13 22:20:28 2023 From: jvernee at openjdk.org (Jorn Vernee) Date: Mon, 13 Nov 2023 22:20:28 GMT Subject: RFR: 8319928: Exceptions thrown by cleanup actions should be handled correctly [v2] In-Reply-To: <_nJfgVMZekYtS_S1hAkpdIoz5JcZohAsp5djmuxjbOU=.84b1ca53-5d4b-472b-b17b-77f27acd8437@github.com> References: <_nJfgVMZekYtS_S1hAkpdIoz5JcZohAsp5djmuxjbOU=.84b1ca53-5d4b-472b-b17b-77f27acd8437@github.com> Message-ID: <73kueZulGb-e154xPx7WkZwjJwENsH1PM__bYof6jDI=.ddc2f322-bd09-4ef1-9b54-f18706e4becc@github.com> On Mon, 13 Nov 2023 16:09:10 GMT, Maurizio Cimadamore wrote: >> This simplePR tweaks the factory which wraps custom cleanup actions passed to `MemorySegment::reinterpret`, so that any exception thrown by the custom cleanup is swallowed when the arena is closed. >> >> This aligns the behavior of confined/shared session with that of implicit session (as implicit sessions are backed by a `Cleaner`, there is no way for cleanup exception to bubble up). > > Maurizio Cimadamore has updated the pull request incrementally with three additional commits since the last revision: > > - More javadoc tweaks > - Tweak javadoc > - Catch all cleanup failures in `CleanupException` Marked as reviewed by jvernee (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/16619#pullrequestreview-1728378083 From bchristi at openjdk.org Mon Nov 13 22:37:37 2023 From: bchristi at openjdk.org (Brent Christian) Date: Mon, 13 Nov 2023 22:37:37 GMT Subject: RFR: 8314480: Memory ordering spec updates in java.lang.ref Message-ID: Classes in the `java.lang.ref` package would benefit from an update to bring the spec in line with how the VM already behaves. The changes would focus on _happens-before_ edges at some key points during reference processing. A couple key things we want to be able to say are: - `Reference.reachabilityFence(x)` _happens-before_ reference processing occurs for 'x'. - `Cleaner.register()` _happens-before_ the Cleaner thread runs the registered cleaning action. This will bring Cleaner in line (or close) with the memory visibility guarantees made for finalizers in [JLS 17.4.5](https://docs.oracle.com/javase/specs/jls/se18/html/jls-17.html#jls-17.4.5): _"There is a happens-before edge from the end of a constructor of an object to the start of a finalizer (?12.6) for that object."_ ------------- Commit messages: - Merge - Update enqueue() docs, add warnings about still-reachable referent - small tweak to enqueue() - Updates to clear() and enqueue() - updates re: reference clearing - Per slack, 'on a queue' is inconsistent with existing wording - reworked - Update 'remains reachable', per Slack - tweak again - tweak - consistency tweaks - ... and 28 more: https://git.openjdk.org/jdk/compare/cc4b0d92...dfce0dd5 Changes: https://git.openjdk.org/jdk/pull/16644/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16644&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8314480 Stats: 108 lines in 4 files changed: 87 ins; 0 del; 21 mod Patch: https://git.openjdk.org/jdk/pull/16644.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16644/head:pull/16644 PR: https://git.openjdk.org/jdk/pull/16644 From naoto at openjdk.org Mon Nov 13 23:40:27 2023 From: naoto at openjdk.org (Naoto Sato) Date: Mon, 13 Nov 2023 23:40:27 GMT Subject: RFR: JDK-8319628: DateFormat does not mention IllegalArgumentException for invalid style args [v2] In-Reply-To: References: Message-ID: On Mon, 13 Nov 2023 21:38:11 GMT, Justin Lu wrote: >> Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8319868) which makes IllegalArgumentExceptions apparent for the _j.text.DateFormat_ static factory methods that have the _style_ parameter. > > Justin Lu has updated the pull request incrementally with one additional commit since the last revision: > > reflect review, one -> any LGTM. The CSR has also been reviewed. ------------- Marked as reviewed by naoto (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16624#pullrequestreview-1728451901 From naoto at openjdk.org Mon Nov 13 23:40:36 2023 From: naoto at openjdk.org (Naoto Sato) Date: Mon, 13 Nov 2023 23:40:36 GMT Subject: RFR: 8319986: Invalid/inconsistent description and example for DateFormat Message-ID: Correcting the explanation of the `DateFormat.SHORT` constant. ------------- Commit messages: - initial commit Changes: https://git.openjdk.org/jdk/pull/16645/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16645&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8319986 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/16645.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16645/head:pull/16645 PR: https://git.openjdk.org/jdk/pull/16645 From naoto at openjdk.org Mon Nov 13 23:45:37 2023 From: naoto at openjdk.org (Naoto Sato) Date: Mon, 13 Nov 2023 23:45:37 GMT Subject: Integrated: 8319640: ClassicFormat::parseObject (from DateTimeFormatter) does not conform to the javadoc and may leak DateTimeException In-Reply-To: References: Message-ID: On Thu, 9 Nov 2023 17:44:44 GMT, Naoto Sato wrote: > Fixing the `Format::parseObject(String, ParsePosition)` implementation in `DateTimeFormatter` class, to not throw `DateTimeException` but to return null. This pull request has now been integrated. Changeset: fe0ccdf5 Author: Naoto Sato URL: https://git.openjdk.org/jdk/commit/fe0ccdf5f8a5559a608d2e2cd2b6aecbe245c5ec Stats: 50 lines in 2 files changed: 34 ins; 8 del; 8 mod 8319640: ClassicFormat::parseObject (from DateTimeFormatter) does not conform to the javadoc and may leak DateTimeException Reviewed-by: rriggs, iris, jlu, joehw ------------- PR: https://git.openjdk.org/jdk/pull/16586 From duke at openjdk.org Tue Nov 14 00:17:40 2023 From: duke at openjdk.org (Shaojin Wen) Date: Tue, 14 Nov 2023 00:17:40 GMT Subject: Withdrawn: 8315585: Optimization for decimal to string In-Reply-To: References: Message-ID: On Mon, 4 Sep 2023 04:58:08 GMT, Shaojin Wen 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... This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/15555 From psandoz at openjdk.org Tue Nov 14 00:46:53 2023 From: psandoz at openjdk.org (Paul Sandoz) Date: Tue, 14 Nov 2023 00:46:53 GMT Subject: RFR: JDK-8319123 : Implementation of JEP-461: Stream Gatherers (Preview) [v5] In-Reply-To: <8VQk_eX35V8wo8YSfdTGCi0XxZklabPegtiBU-lg_8M=.3c560f0e-9df3-4d21-a03a-0554c1451a90@github.com> References: <8VQk_eX35V8wo8YSfdTGCi0XxZklabPegtiBU-lg_8M=.3c560f0e-9df3-4d21-a03a-0554c1451a90@github.com> Message-ID: On Mon, 13 Nov 2023 09:22:13 GMT, Viktor Klang wrote: >> This Pull-Request implements [JEP-461](https://openjdk.org/jeps/461) > > Viktor Klang has updated the pull request incrementally with one additional commit since the last revision: > > Minor improvements to Gatherer Javadoc src/java.base/share/classes/java/util/stream/Gatherer.java line 40: > 38: * stream of output elements, optionally applying a final action when the end of > 39: * the upstream is reached. The transformation may be stateless or stateful, > 40: * and a Gatherer may buffer arbitrarily much input before producing any output. Suggestion: * and may buffer input before producing any output. src/java.base/share/classes/java/util/stream/Gatherer.java line 63: > 61: * > 62: * > 63: *

    Each invocation to {@link #initializer()}, {@link #integrator()}, Suggestion: *

    Each invocation of {@link #initializer()}, {@link #integrator()}, src/java.base/share/classes/java/util/stream/Gatherer.java line 119: > 117: * > 118: *

    As an example, in order to create a gatherer to implement a sequential > 119: * Prefix Scan as a Gatherer, it could be done the following way: Suggestion: *

    As an example, a Gatherer implementing a sequential Prefix Scan * could be done the following way: src/java.base/share/classes/java/util/stream/Gatherer.java line 152: > 150: * } > 151: * > 152: * @implSpec Libraries that implement transformation based on {@code Gatherer}, Suggestion: * @implSpec Libraries that implement transformations based on {@code Gatherer}, src/java.base/share/classes/java/util/stream/Gatherer.java line 166: > 164: * arguments passed to the combiner function, and the argument passed to the > 165: * finisher function must be the result of a previous invocation of the > 166: * initializer, integrator, or combiner functions. the integrator returns a boolean, so is it just the result of a previous invocation of the initializer or combiner functions? (Similarly for the next clause.) src/java.base/share/classes/java/util/stream/Gatherer.java line 185: > 183: * partitions state using the combiner, and then invoking the finisher on > 184: * the joined state. Outputs and state later in the input sequence will > 185: * be discarded if processing an earlier segment short-circuits. Suggestion: * be discarded if processing an earlier partition short-circuits. src/java.base/share/classes/java/util/stream/Gatherer.java line 501: > 499: > 500: /** > 501: * Allows for checking whether the next stage is known to not want Suggestion: * Checks whether the next stage is known to not want src/java.base/share/classes/java/util/stream/Gatherer.java line 558: > 556: > 557: /** > 558: * Factory method for turning Integrator-shaped lambdas into Suggestion: * Targets Integrator-shaped lambdas to It's not a factory, as it does produce anything, it's an identity function that aids in the targeting of the lambda expression to the integrator when there would otherwise be ambiguity as to the target. src/java.base/share/classes/java/util/stream/Gatherers.java line 47: > 45: > 46: /** > 47: * Implementations of {@link Gatherer} that implement various useful intermediate Suggestion: * Implementations of {@link Gatherer} that provide useful intermediate src/java.base/share/classes/java/util/stream/Gatherers.java line 80: > 78: * and eagerly. This means that choosing large window sizes for > 79: * small streams may use excessive memory for the duration of > 80: * evaluation of this operation. Suggestion: * small streams may use excessive memory during * evaluation of this operation. (Same for other methods.) src/java.base/share/classes/java/util/stream/Gatherers.java line 329: > 327: > 328: /** > 329: * An operation which executes operations concurrently Suggestion: * An operation which executes a function concurrently src/java.base/share/classes/java/util/stream/Gatherers.java line 340: > 338: *

    If the mapper throws an exception during evaluation of this Gatherer, > 339: * and the result of that invocation is to be produced to the downstream, > 340: * then that exception will instead be rethrown as a {@link RuntimeException}. Suggestion: *

    If a result of the function is to be pushed downstream but instead the function completed * exceptionally then the corresponding exception will instead be rethrown by this method as an * instance of {@link RuntimeException}. After which any remaining tasks are canceled. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1391814346 PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1391815675 PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1391818520 PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1391818887 PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1391821170 PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1391822409 PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1391826169 PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1391829649 PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1391830903 PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1391832936 PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1391840780 PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1391849458 From duke at openjdk.org Tue Nov 14 01:23:34 2023 From: duke at openjdk.org (Steve Dohrmann) Date: Tue, 14 Nov 2023 01:23:34 GMT Subject: RFR: 8310159: Bulk copy with Unsafe::arrayCopy is slower compared to memcpy In-Reply-To: References: Message-ID: On Mon, 13 Nov 2023 08:36:44 GMT, Tobias Hartmann wrote: >> Below is baseline data collected using a modified version of the java.lang.foreign.xor micro benchmark referenced by @mcimadamore in the bug report. I collected data on an Ubuntu 22.04 laptop with a Tigerlake i7-1185G7, which does support AVX512. >> >> Baseline data >> Benchmark (arrayKind) (sizeKind) Mode Cnt Score Error Units >> -------------------------------------------------------------------------------------- >> XorTest.copy ELEMENTS SMALL avgt 30 584737355.767 ? 60414308.540 ns/op >> XorTest.copy ELEMENTS MEDIUM avgt 30 272248995.683 ? 2924954.498 ns/op >> XorTest.copy ELEMENTS LARGE avgt 30 1019200210.900 ? 28334453.652 ns/op >> XorTest.copy REGION SMALL avgt 30 7399944.164 ? 216821.819 ns/op >> XorTest.copy REGION MEDIUM avgt 30 20591454.558 ? 147398.572 ns/op >> XorTest.copy REGION LARGE avgt 30 21649266.051 ? 179263.875 ns/op >> XorTest.copy CRITICAL SMALL avgt 30 51079.357 ? 542.482 ns/op >> XorTest.copy CRITICAL MEDIUM avgt 30 2496.961 ? 11.375 ns/op >> XorTest.copy CRITICAL LARGE avgt 30 515.454 ? 5.831 ns/op >> XorTest.copy FOREIGN SMALL avgt 30 7558432.075 ? 79489.276 ns/op >> XorTest.copy FOREIGN MEDIUM avgt 30 19730666.341 ? 500505.099 ns/op >> XorTest.copy FOREIGN LARGE avgt 30 34616758.085 ? 340300.726 ns/op >> XorTest.xor ELEMENTS SMALL avgt 30 219832692.489 ? 2329417.319 ns/op >> XorTest.xor ELEMENTS MEDIUM avgt 30 505138197.167 ? 3818334.424 ns/op >> XorTest.xor ELEMENTS LARGE avgt 30 1189608474.667 ? 5877981.900 ns/op >> XorTest.xor REGION SMALL avgt 30 64093872.804 ? 599704.491 ns/op >> XorTest.xor REGION MEDIUM avgt 30 81544576.454 ? 1406342.118 ns/op >> XorTest.xor REGION LARGE avgt 30 90091424.883 ? 775577.613 ns/op >> XorTest.xor CRITICAL SMALL avgt 30 57231375.744 ? 438223.342 ns/op >> XorTest.xor CRITICAL MEDIUM avgt 30 58583884.930 ? 375355.215 ns/op >> XorTest.xor CRITICAL LARGE avgt 30 60644832.949 ? 588120.738 ns/op >> XorTest.xor FOREIGN SMALL avgt 30 73868679.405 ? 819965.524 ns/op >> XorTest.xor FOREIGN MEDIUM avgt 30 88156275.944 ? 1051257.152 ns/op >> Xo... > > I submitted some quick testing and I'm seeing the following failure with multiple tests: > > > # A fatal error has been detected by the Java Runtime Environment: > # > # Internal Error (/workspace/open/src/hotspot/cpu/x86/stubGenerator_x86_64_arraycopy.cpp:1201), pid=24136, tid=24139 > # assert(MaxVectorSize == 64) failed: vector length != 64 > # > # JRE version: (22.0) (fastdebug build ) > # Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 22-internal-2023-11-13-0750559.tobias.hartmann.jdk2, mixed mode, sharing, compressed oops, compressed class ptrs, g1 gc, linux-amd64) > # Problematic frame: > # V [libjvm.so+0x16c00e6] StubGenerator::copy64_masked_avx(Register, Register, XMMRegister, KRegister, Register, Register, Register, int, int, bool)+0x366 > > Stack: [0x00007f0b5e919000,0x00007f0b5ea1a000], sp=0x00007f0b5ea17150, free space=1016k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > V [libjvm.so+0x16c00e6] StubGenerator::copy64_masked_avx(Register, Register, XMMRegister, KRegister, Register, Register, Register, int, int, bool)+0x366 (stubGenerator_x86_64_arraycopy.cpp:1201) > V [libjvm.so+0x16c0ecd] StubGenerator::arraycopy_avx3_special_cases_256(XMMRegister, KRegister, Register, Register, Register, int, Register, Register, Label&, Label&)+0x19d (stubGenerator_x86_64_arraycopy.cpp:1055) > V [libjvm.so+0x16c16c1] StubGenerator::arraycopy_avx3_large(Register, Register, Register, Register, Register, Register, Register, XMMRegister, XMMRegister, XMMRegister, XMMRegister, int)+0x3f1 (stubGenerator_x86_64_arraycopy.cpp:790) > V [libjvm.so+0x16c22f0] StubGenerator::generate_disjoint_copy_avx3_masked(unsigned char**, char const*, int, bool, bool, bool)+0xa90 (stubGenerator_x86_64_arraycopy.cpp:728) > V [libjvm.so+0x16c4b85] StubGenerator::generate_disjoint_byte_copy(bool, unsigned char**, char const*)+0x965 (stubGenerator_x86_64_arraycopy.cpp:1277) > V [libjvm.so+0x16cb309] StubGenerator::generate_arraycopy_stubs()+0x29 (stubGenerator_x86_64_arraycopy.cpp:88) > V [libjvm.so+0x16a1089] StubGenerator::generate_final_stubs()+0xb9 (stubGenerator_x86_64.cpp:4051) > V [libjvm.so+0x16a22a5] StubGenerator_generate(CodeBuffer*, StubCodeGenerator::StubsKind)+0x105 (stubGenerator_x86_64.cpp:4296) > V [libjvm.so+0x16f349e] initialize_stubs(StubCodeGenerator::StubsKind, int, int, char const*, char const*, char const*)+0x13e (stubRoutines.cpp:241) > V [libjvm.so+0x16f500d] final_stubs_init()+0x3d (stubRoutines.cpp:288) > V [libjvm.so+0xe30c59]... Thank you @TobiHartmann for the feedback. I'm working on the issue. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16575#issuecomment-1809390162 From joehw at openjdk.org Tue Nov 14 01:45:26 2023 From: joehw at openjdk.org (Joe Wang) Date: Tue, 14 Nov 2023 01:45:26 GMT Subject: RFR: 8319986: Invalid/inconsistent description and example for DateFormat In-Reply-To: References: Message-ID: <8GdRmjvKIH0rjG6uP98UpaIGnl1qrYRKu74narYg0c4=.445ac7c3-fe57-41d4-9886-0e53c7e46bbb@github.com> On Mon, 13 Nov 2023 23:35:11 GMT, Naoto Sato wrote: > Correcting the explanation of the `DateFormat.SHORT` constant. src/java.base/share/classes/java/text/DateFormat.java line 120: > 118: * result; from {@link #SHORT} to {@link #MEDIUM} to {@link #LONG} to {@link #FULL}. The exact result depends > 119: * on the locale, but generally: > 120: *

    > 909: * > 910: * I went through a number of iterations with Joe on this implNote so happy with this version. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16719#discussion_r1398355355 PR Review Comment: https://git.openjdk.org/jdk/pull/16719#discussion_r1398355680 From alanb at openjdk.org Sun Nov 19 08:49:32 2023 From: alanb at openjdk.org (Alan Bateman) Date: Sun, 19 Nov 2023 08:49:32 GMT Subject: RFR: 8306055: Add a built-in Catalog to JDK XML module In-Reply-To: <2EwrTJpoiEvBJ9Ua7QoYKSS9gs7_3JThLczgv4rUXj8=.388eed17-79c7-436d-b280-f63d252ddc0f@github.com> References: <2EwrTJpoiEvBJ9Ua7QoYKSS9gs7_3JThLczgv4rUXj8=.388eed17-79c7-436d-b280-f63d252ddc0f@github.com> Message-ID: On Sun, 19 Nov 2023 08:44:01 GMT, Alan Bateman wrote: >> Implement the built-in Catalog. > > src/java.xml/share/classes/jdk/xml/internal/jdkcatalog/JDKCatalog.xml line 34: > >> 32: >> 33: >> 34: > > Would it be possible to provide a summary on how the relative uri in the "uri" attribute is handled? Asking as it's not clear to me how the decoding is handling, meaning this is a relative URI, not a relative file path. Can we move DTD in the JDK's catalog to a "Java" or "JavaSE" directory, only because "J2SE" feels a bit yesterday. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16719#discussion_r1398355546 From kasperni at gmail.com Sun Nov 19 09:38:05 2023 From: kasperni at gmail.com (Kasper Nielsen) Date: Sun, 19 Nov 2023 09:38:05 +0000 Subject: RFE: support safely wrapping restricted FFM calls In-Reply-To: <3e803df7-1d0d-4643-93c9-d8395dff664c@icemanx.nl> References: <0dcba352-dd99-4571-8b35-f0c38af6c42d@icemanx.nl> <64d189ed-10b0-44eb-bd74-9ce0c130bd5c@oracle.com> <3b9e09b7-1db4-49ed-9f8e-230fbc1f2e31@icemanx.nl> <2ed750a9-7107-4c85-b30a-4e3a96430bd7@oracle.com> <7b98a8c9-700d-441d-a809-8b37594ab3d5@icemanx.nl> <3e803df7-1d0d-4643-93c9-d8395dff664c@icemanx.nl> Message-ID: Hi Rob, In that case maybe just have an interface users of your library must implement with all the relevant caller sensitive methods? And then require the user to specify an instance whenever they call into your library? If you need to set up some static data structures this would probably not be ideal though. /Kasper /Kasper On Sat, 18 Nov 2023 at 15:00, Rob Spoor wrote: > > On 18/11/2023 06:46, Kasper Nielsen wrote: > > Hi Rob, > > > > Delegating caller sensitive methods can be tricky. > > > > Besides the obvious solutions with StackWalker and/or Lookup objects I've > > sometimes used an abstract class that must be extended by users of my library. > > This may be more trouble in your case than the other solutions though. > > > > In your situation it would be something like this. > > > > // Defined in your library and extendable by users of your library > > public abstract class NativeLoader { > > > > protected abstract MethodHandle downcallHandle(Linker linker, MemorySegment > > address, FunctionDescriptor function, Linker.Option... options); > > > > public final T load(Class interFace) { > > .. do stuff. > > call this.downcallHandle > > .. do more stuff > > } > > } > > > > // Usage by other library > > class UsageByOtherLibrary { > > private static final NativeLoader NL = new NativeLoader() { > > protected MethodHandle downcallHandle(Linker linker, MemorySegment > > address, FunctionDescriptor function, Option... options) { > > return linker.downcallHandle(address, function, options); > > } > > }; > > > > public void main() { > > SomeInterface si = NL.load(SomeInterface.class); > > } > > } > > > > The actual call to Linker.downcallHandle is now only performed by the user of > > your library. So depending on what you do, you might even be able to avoid > > requiring enabling native access for your library. Only the libraries that use > > your library would need it. > > > > /Kasper > > Hi Kasper, > > This would indeed be relatively easiy if Linker.downcallHandle was the > only native call, but I've already used AddressLayout.withTargetLayout, > and just had to add a call to MemorySegment.reinterpret for the > MemorySegment an AddressLayout was referring to (the result of a native > call like malloc). Such custom implementations would need to be passed > around several method calls of my module. Still, this is something to > consider, as it does take away restricted calls away from my module to > the caller. Thanks for the hint! > > Rob > > > > > > > > > > > > On Thu, 16 Nov 2023 at 19:21, Rob Spoor wrote: > >> > >> On 16/11/2023 18:15, Maurizio Cimadamore wrote: > >>> > >>> On 16/11/2023 16:54, Rob Spoor wrote: > >>>> Hi Maurizio, > >>>> > >>>> I don't think you understand what my module is doing. For instance, > >>>> it's not specifying the downcall method handles themselves, it's just > >>>> making it easy to define them. Maybe a small example would show what > >>>> I'm doing. > >>>> > >>>> Consider the following partial interface from JNA: > >>>> > >>>> public interface Kernel32 extends StdCallLibrary, WinNT, Wincon { > >>>> > >>>> /** The instance. */ > >>>> Kernel32 INSTANCE = Native.load("kernel32", Kernel32.class, > >>>> W32APIOptions.DEFAULT_OPTIONS); > >>>> > >>>> int GetLastError(); > >>>> } > >>>> > >>>> What JNA is doing is creating an implementation based on this > >>>> interface that delegates to the native kernel32 library. This is all > >>>> done through the Native.load method. > From jlaskey at openjdk.org Sun Nov 19 15:04:14 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Sun, 19 Nov 2023 15:04:14 GMT Subject: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v25] In-Reply-To: References: Message-ID: > Address changes from JEP 445 to JEP 463. > > - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. > > - Don't mark class on read. > > - Remove reflection and annotation processing related to unnamed classes. > > - Simplify main method search. Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: Add getMainMethod Test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16461/files - new: https://git.openjdk.org/jdk/pull/16461/files/90d4d1c5..8ef55fdf Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16461&range=24 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16461&range=23-24 Stats: 120 lines in 1 file changed: 120 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/16461.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16461/head:pull/16461 PR: https://git.openjdk.org/jdk/pull/16461 From dl at openjdk.org Sun Nov 19 17:40:49 2023 From: dl at openjdk.org (Doug Lea) Date: Sun, 19 Nov 2023 17:40:49 GMT Subject: RFR: JDK-8319662 ForkJoinPool trims worker threads too slowly Message-ID: This update cascades timeouts to trim subsequent workers after the first keepAlive inactive period. ------------- Commit messages: - Support cascading idle timeouts Changes: https://git.openjdk.org/jdk/pull/16725/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16725&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8319662 Stats: 63 lines in 1 file changed: 6 ins; 7 del; 50 mod Patch: https://git.openjdk.org/jdk/pull/16725.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16725/head:pull/16725 PR: https://git.openjdk.org/jdk/pull/16725 From info at birkeheeren.de Sun Nov 19 19:28:13 2023 From: info at birkeheeren.de (Birke Heeren) Date: Sun, 19 Nov 2023 20:28:13 +0100 (CET) Subject: irk character set (Birke Heeren) Message-ID: <553987137.2431434.1700422093445@webmail.strato.com> /* * when the character irk is detected, the language irk is present * */ public enum Irk { IRK, END_IRK, HASH, END_HASH, COLON, ARRAY, END_ARRAY, QUOTE, END_QUOTE, COMMA; public static String is_irk = " i**********irk0"; public static String is_end_irk = " i**********irk1"; public static String is_hash = " i**********irk2"; public static String is_end_hash = " i**********irk3"; public static String is_colon = " i**********irk4"; public static String is_array = " i**********irk5"; public static String is_end_array = " i**********irk6"; public static String is_quote = " i**********irk7"; public static String is_end_quote = " i**********irk8"; public static String is_comma = " i**********irk9"; public static String is_irk_pattern = " i**********irk0 i**********irk1"; public static String is_hash_pattern = " i**********irk2 i**********irk3"; public static String is_colon_pattern = " i**********irk4"; public static String is_array_pattern = " i**********irk5 i**********irk6"; public static String is_quote_pattern = " i**********irk7 i**********irk8"; public static String is_comma_pattern = " i**********irk9"; } From jlaskey at openjdk.org Sun Nov 19 20:14:10 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Sun, 19 Nov 2023 20:14:10 GMT Subject: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v26] In-Reply-To: References: Message-ID: > Address changes from JEP 445 to JEP 463. > > - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. > > - Don't mark class on read. > > - Remove reflection and annotation processing related to unnamed classes. > > - Simplify main method search. Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: Additional tests for getMainMethod ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16461/files - new: https://git.openjdk.org/jdk/pull/16461/files/8ef55fdf..27de4fec Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16461&range=25 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16461&range=24-25 Stats: 13 lines in 1 file changed: 11 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/16461.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16461/head:pull/16461 PR: https://git.openjdk.org/jdk/pull/16461 From duke at openjdk.org Sun Nov 19 23:05:51 2023 From: duke at openjdk.org (duke) Date: Sun, 19 Nov 2023 23:05:51 GMT Subject: Withdrawn: 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, Shaojin Wen 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 This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/15658 From joehw at openjdk.org Sun Nov 19 23:36:16 2023 From: joehw at openjdk.org (Joe Wang) Date: Sun, 19 Nov 2023 23:36:16 GMT Subject: RFR: 8306055: Add a built-in Catalog to JDK XML module [v2] In-Reply-To: References: Message-ID: <6Z_nwDH5HB8r4MDO8PvBiakQhl8XZZl2bs4i_V_3miI=.9e811013-6c90-42c7-b8e8-e555f63cb167@github.com> > Implement the built-in Catalog. Joe Wang has updated the pull request incrementally with one additional commit since the last revision: remove J2SE directory; add note explaining how DTDs are resolved ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16719/files - new: https://git.openjdk.org/jdk/pull/16719/files/f52f8ad6..c1059a84 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16719&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16719&range=00-01 Stats: 8 lines in 4 files changed: 5 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/16719.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16719/head:pull/16719 PR: https://git.openjdk.org/jdk/pull/16719 From joehw at openjdk.org Sun Nov 19 23:41:29 2023 From: joehw at openjdk.org (Joe Wang) Date: Sun, 19 Nov 2023 23:41:29 GMT Subject: RFR: 8306055: Add a built-in Catalog to JDK XML module [v2] In-Reply-To: References: <2EwrTJpoiEvBJ9Ua7QoYKSS9gs7_3JThLczgv4rUXj8=.388eed17-79c7-436d-b280-f63d252ddc0f@github.com> Message-ID: On Sun, 19 Nov 2023 08:45:29 GMT, Alan Bateman wrote: >> src/java.xml/share/classes/jdk/xml/internal/jdkcatalog/JDKCatalog.xml line 34: >> >>> 32: >>> 33: >>> 34: >> >> Would it be possible to provide a summary on how the relative uri in the "uri" attribute is handled? Asking as it's not clear to me how the decoding is handling, meaning this is a relative URI, not a relative file path. > > Can we move DTD in the JDK's catalog to a "Java" or "JavaSE" directory, only because "J2SE" feels a bit yesterday. Thanks Alan. Removed ?J2SE?. Added a note explaining how the DTDs are resolved. In early prototypes, the Catalog contained 7 sub-groups in the java/dtd group, including J2SE and J2EE, names came from their original places where these DTDs were defined. You're right, now that the built-in catalog contains only DTDs defined in the Java platform, it makes sense to keep just the java/dtd group. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16719#discussion_r1398519536 From joehw at openjdk.org Sun Nov 19 23:51:30 2023 From: joehw at openjdk.org (Joe Wang) Date: Sun, 19 Nov 2023 23:51:30 GMT Subject: RFR: 8306055: Add a built-in Catalog to JDK XML module [v2] In-Reply-To: <2EwrTJpoiEvBJ9Ua7QoYKSS9gs7_3JThLczgv4rUXj8=.388eed17-79c7-436d-b280-f63d252ddc0f@github.com> References: <2EwrTJpoiEvBJ9Ua7QoYKSS9gs7_3JThLczgv4rUXj8=.388eed17-79c7-436d-b280-f63d252ddc0f@github.com> Message-ID: On Sun, 19 Nov 2023 08:46:30 GMT, Alan Bateman wrote: >> Joe Wang has updated the pull request incrementally with one additional commit since the last revision: >> >> remove J2SE directory; add note explaining how DTDs are resolved > > src/java.xml/share/classes/module-info.java line 910: > >> 908: * >> 909: * >> 910: * > > I went through a number of iterations with Joe on this implNote so happy with this version. Thanks Alan! I really appreciate your allocating so much time to this project, esp. the APIs and CSRs. So this is the last piece to finally complete the project. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16719#discussion_r1398521238 From joehw at openjdk.org Mon Nov 20 00:00:29 2023 From: joehw at openjdk.org (Joe Wang) Date: Mon, 20 Nov 2023 00:00:29 GMT Subject: RFR: 8306055: Add a built-in Catalog to JDK XML module [v2] In-Reply-To: <6Z_nwDH5HB8r4MDO8PvBiakQhl8XZZl2bs4i_V_3miI=.9e811013-6c90-42c7-b8e8-e555f63cb167@github.com> References: <6Z_nwDH5HB8r4MDO8PvBiakQhl8XZZl2bs4i_V_3miI=.9e811013-6c90-42c7-b8e8-e555f63cb167@github.com> Message-ID: On Sun, 19 Nov 2023 23:36:16 GMT, Joe Wang wrote: >> Implement the built-in Catalog. > > Joe Wang has updated the pull request incrementally with one additional commit since the last revision: > > remove J2SE directory; add note explaining how DTDs are resolved Tests: Tier 1-3 and JCK passed. SPECjvm2008: no regression ------------- PR Comment: https://git.openjdk.org/jdk/pull/16719#issuecomment-1818021731 From xgong at openjdk.org Mon Nov 20 01:37:33 2023 From: xgong at openjdk.org (Xiaohong Gong) Date: Mon, 20 Nov 2023 01:37:33 GMT Subject: RFR: 8318650: Optimized subword gather for x86 targets. [v7] In-Reply-To: References: <6trfINWUmYQ7emAfsQAeLPzXSWZGRubI7v8s-wWcGn4=.91ef2dc5-dc4b-4fdd-aa0d-1e7f809cd060@github.com> Message-ID: <5IoBfWZuhhO06Sy3vjPv-kKXWuCuzX86fsbg5g6JXm4=.59f4fd89-e3fc-4e7e-ad3b-0a5d6e48f809@github.com> On Fri, 17 Nov 2023 06:06:16 GMT, Jatin Bhateja wrote: > > BTW, I have two questions: > > > > 1. An intrinsic which should accept the vector as index like non-subword gather is more benefical in real applications. See: [8287289: Gather/Scatter with Index Vector?panama-vector#201](https://github.com/openjdk/panama-vector/pull/201) please. > > 2. Do you have the plan for adding such optimization for subword scatter in future? > > > > Thanks, Xiaohong > > I agree, proposal looks reasonable to me, but given that x86 ISA does not have direct sub-word gather instruction hence we will always need to pass index array to inline expander. Existing interface provisions passing both index array and vector. So in the x86 backend implementation, are the indexs finally stored into a vector register? Per my understand, it looks that way. If so, maybe an alternative is 1) just making the intrinsics accept an index vector like non-subword types, and 2) calling several times such load-gather intrinsics in java implementation of the subword gather (e.g. 4 load-gather for byte gather with int indexes). That means we can move the complex operations to java side, and compiler should only cover a single load-gather operation. This may make the subword unify with non-subword gathers in compiler/intrinsics side. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16354#issuecomment-1818077141 From xgong at openjdk.org Mon Nov 20 01:55:39 2023 From: xgong at openjdk.org (Xiaohong Gong) Date: Mon, 20 Nov 2023 01:55:39 GMT Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations with SLEEF [v3] In-Reply-To: References: Message-ID: On Thu, 16 Nov 2023 13:00:03 GMT, Magnus Ihse Bursie wrote: >> Xiaohong Gong has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: >> >> - Add a bundled native lib in jdk as a bridge to libsleef >> - Merge 'jdk:master' into JDK-8312425 >> - Disable sleef by default >> - Merge 'jdk:master' into JDK-8312425 >> - 8312425: [vectorapi] AArch64: Optimize vector math operations with SLEEF > > doc/building.md line 552: > >> 550: >> 551: libsleef, the [SIMD Library for Evaluating Elementary Functions]( >> 552: https://sleef.org/) is required when building libvmath.so on Linux+AArch64 > > The conventional way we have refered to os/cpu combinations in the build documentation is like this: `Linux/aarch64`. > > I also think you need to expand a bit that this is optional, and if you do not provide libsleef, the build will succeed but without the vector performance enhancements provided by libvmath. Thanks for the review! This sounds good to me. I will add it. > make/autoconf/lib-vmath.m4 line 49: > >> 47: test -e ${with_libsleef}/include/sleef.h; then >> 48: LIBSLEEF_FOUND=yes >> 49: LIBVMATH_LIBS="-L${with_libsleef}/lib" > > This should be LIBSLEEF_LIBS and ...CFLAGS. Seems as above. The target library is `libvmath.so`, and the cflags/libs are used for building it instead of `libsleef.so`. > make/autoconf/lib-vmath.m4 line 92: > >> 90: [] >> 91: ) >> 92: AC_MSG_RESULT([${SVE_FEATURE_SUPPORT}]) > > What is this test even for? I can't see any usage of SVE_FEATURE_SUPPORT outside this function. This is just used to print the result of `AC_MSG_CEHCKING[if ARM SVE feature is supported]` in configure. > make/autoconf/lib-vmath.m4 line 102: > >> 100: fi >> 101: >> 102: AC_SUBST(LIBSLEEF_FOUND) > > Do not export LIBSLEEF_FOUND. It is okay to use internally here, but you should instead export ENABLE_LIBSLEEF, using true/false (instead of yes/no). This is the way we handle all other optional components. Make sense to me. Thanks for the comment! > make/autoconf/libraries.m4 line 129: > >> 127: LIB_SETUP_LIBFFI >> 128: LIB_SETUP_MISC_LIBS >> 129: LIB_SETUP_VMATH > > The function (and file) should be named after "sleef", not "vmath". Yes, it seems weird. But the library we want to built out is `libvmath.so` instead of `libsleef.so`. And we not only check the sleef library, but also the ARM SVE feature inside it. So using `VMATH` suffix is more reasonable to me. WDYT? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16234#discussion_r1398574834 PR Review Comment: https://git.openjdk.org/jdk/pull/16234#discussion_r1398573871 PR Review Comment: https://git.openjdk.org/jdk/pull/16234#discussion_r1398571212 PR Review Comment: https://git.openjdk.org/jdk/pull/16234#discussion_r1398575161 PR Review Comment: https://git.openjdk.org/jdk/pull/16234#discussion_r1398572906 From rriggs at openjdk.org Mon Nov 20 03:24:39 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Mon, 20 Nov 2023 03:24:39 GMT Subject: RFR: 8317742: ISO Standard Date Format implementation consistency on DateTimeFormatter and String.format [v8] In-Reply-To: References: Message-ID: On Sun, 19 Nov 2023 02:19:52 GMT, Shaojin Wen wrote: >> `JapaneseChronology` is not extending `IsoChronology`, and that is the gist of the change I suggested. > > I added the testcase of IsoChronology and it also passed. The distinction is pretty subtle, I was referring to the `Chronology.isISOBased()` method. (True for JapaneseChronology). IsoChronology is final, so there are no subclasses. This does address the compatibility issue and is an improvement over the original proposal. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16033#discussion_r1398626377 From jbhateja at openjdk.org Mon Nov 20 05:38:31 2023 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Mon, 20 Nov 2023 05:38:31 GMT Subject: RFR: 8318650: Optimized subword gather for x86 targets. [v7] In-Reply-To: <5IoBfWZuhhO06Sy3vjPv-kKXWuCuzX86fsbg5g6JXm4=.59f4fd89-e3fc-4e7e-ad3b-0a5d6e48f809@github.com> References: <6trfINWUmYQ7emAfsQAeLPzXSWZGRubI7v8s-wWcGn4=.91ef2dc5-dc4b-4fdd-aa0d-1e7f809cd060@github.com> <5IoBfWZuhhO06Sy3vjPv-kKXWuCuzX86fsbg5g6JXm4=.59f4fd89-e3fc-4e7e-ad3b-0a5d6e48f809@github.com> Message-ID: On Mon, 20 Nov 2023 01:34:57 GMT, Xiaohong Gong wrote: > > > BTW, I have two questions: > > > > > > 1. An intrinsic which should accept the vector as index like non-subword gather is more benefical in real applications. See: [8287289: Gather/Scatter with Index Vector?panama-vector#201](https://github.com/openjdk/panama-vector/pull/201) please. > > > 2. Do you have the plan for adding such optimization for subword scatter in future? > > > > > > Thanks, Xiaohong > > > > > > I agree, proposal looks reasonable to me, but given that x86 ISA does not have direct sub-word gather instruction hence we will always need to pass index array to inline expander. Existing interface provisions passing both index array and vector. > > So in the x86 backend implementation, are the indexs finally stored into a vector register? Per my understand, it looks that way. If so, maybe an alternative is 1) just making the intrinsics accept an index vector like non-subword types, and 2) calling several times such load-gather intrinsics in java implementation of the subword gather (e.g. 4 load-gather for byte gather with int indexes). That means we can move the complex operations to java side, and compiler should only cover a single load-gather operation. This may make the subword unify with non-subword gathers in compiler/intrinsics side. Maybe it was not clear from my previous comments, for x86 and targets which do not support direct sub-word gather backends will need an index array, for other cases there are two options, a target specific lowering of gather IR / extend the inline expander to emit a specialized IR or accommodate multiple index vector loads penalty if it still wins over existing fallback implementation. In-addition due lane size incompatibility b/w gather vector lane and index lane it will pose challenges for masked gather operation. On the other hand, since the patch already demonstrates performance gain other targets backends can also be implemented on the same lines. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16354#issuecomment-1818256345 From psadhukhan at openjdk.org Mon Nov 20 06:42:40 2023 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Mon, 20 Nov 2023 06:42:40 GMT Subject: RFR: 8318364: Add an FFM-based implementation of harfbuzz OpenType layout [v4] In-Reply-To: References: Message-ID: <8tu4D5zX989IFr6DuSuReyYGd9Z-fOcmXcgePojFmvQ=.4dfbd237-f683-44fa-930d-fa89999b3242@github.com> On Wed, 25 Oct 2023 23:42:08 GMT, Phil Race wrote: >> 8318364: Add an FFM-based implementation of harfbuzz OpenType layout > > Phil Race has updated the pull request incrementally with one additional commit since the last revision: > > indentation src/java.desktop/share/classes/sun/font/HBShaper.java line 628: > 626: MemorySegment glyphInfoArr = glyphInfo.reinterpret(glyphInfoSize); > 627: > 628: for (int i=0; i 656: startPt.x = advX; > 657: startPt.y = advY; > 658: startPt.x = advX; duplicate assignment of startPt.x to advX... src/java.desktop/share/classes/sun/font/SunLayoutEngine.java line 167: > 165: } > 166: > 167: static boolean useFFM = true; So, we want to enable FFM by default? src/java.desktop/share/classes/sun/font/SunLayoutEngine.java line 184: > 182: FontStrike strike = font.getStrike(desc); > 183: if (useFFM) { > 184: java.lang.foreign.MemorySegment face = HBShaper.getFace(font); Guess import at start will be more nicer... src/java.desktop/share/native/libfontmanager/HBShaper_Panama.c line 141: > 139: hb_buffer_destroy (buffer); > 140: hb_font_destroy(hbfont); > 141: if (features != NULL) free(features); Guess coding style warrants braces { and next statement in separate line... src/java.desktop/share/native/libfontmanager/hb-jdk-font-p.cc line 238: > 236: HBFloatToFixed(ptSize*devScale), > 237: HBFloatToFixed(ptSize*devScale)); > 238: return font; indentation is off.. test/jdk/java/awt/font/GlyphVector/LayoutCompatTest.java line 29: > 27: /* > 28: @test > 29: @summary verify JNI and FFM harfbuzz OpenType layout implementations are equivalent. bug id is missing test/jdk/java/awt/font/GlyphVector/LayoutCompatTest.java line 45: > 43: public class LayoutCompatTest { > 44: > 45: static String jni = "jni.txt"; Seems test is failing without fix with Exception in jtreg java.io.FileNotFoundException: jni.txt (The system cannot find the file specified) Also in standalone mode. I was expecting it will fail with RuntimeException "files differ byte offset" ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15476#discussion_r1395720270 PR Review Comment: https://git.openjdk.org/jdk/pull/15476#discussion_r1395721851 PR Review Comment: https://git.openjdk.org/jdk/pull/15476#discussion_r1395723605 PR Review Comment: https://git.openjdk.org/jdk/pull/15476#discussion_r1395726378 PR Review Comment: https://git.openjdk.org/jdk/pull/15476#discussion_r1395748600 PR Review Comment: https://git.openjdk.org/jdk/pull/15476#discussion_r1395750344 PR Review Comment: https://git.openjdk.org/jdk/pull/15476#discussion_r1395752417 PR Review Comment: https://git.openjdk.org/jdk/pull/15476#discussion_r1395788998 From thartmann at openjdk.org Mon Nov 20 06:54:32 2023 From: thartmann at openjdk.org (Tobias Hartmann) Date: Mon, 20 Nov 2023 06:54:32 GMT Subject: RFR: 8310159: Bulk copy with Unsafe::arrayCopy is slower compared to memcpy [v4] In-Reply-To: <9j8PVvxFrzJHxtdVNMgvDZHKsjuBVNhl8q45OenHOIA=.2ed68c3d-dddd-4aba-bfab-c4da636662cb@github.com> References: <9j8PVvxFrzJHxtdVNMgvDZHKsjuBVNhl8q45OenHOIA=.2ed68c3d-dddd-4aba-bfab-c4da636662cb@github.com> Message-ID: <5T_6ZWKTN2o8CAbrDqFhQQWJvUSJQUuw1UOtNUcv6vE=.515d733f-2e35-42b6-88af-24e7cea40a70@github.com> On Thu, 16 Nov 2023 21:26:47 GMT, Steve Dohrmann wrote: >> Below is baseline data collected using a modified version of the java.lang.foreign.xor micro benchmark referenced by @mcimadamore in the bug report. I collected data on an Ubuntu 22.04 laptop with a Tigerlake i7-1185G7, which does support AVX512. >> >> Baseline data >> Benchmark (arrayKind) (sizeKind) Mode Cnt Score Error Units >> -------------------------------------------------------------------------------------- >> XorTest.copy ELEMENTS SMALL avgt 30 584737355.767 ? 60414308.540 ns/op >> XorTest.copy ELEMENTS MEDIUM avgt 30 272248995.683 ? 2924954.498 ns/op >> XorTest.copy ELEMENTS LARGE avgt 30 1019200210.900 ? 28334453.652 ns/op >> XorTest.copy REGION SMALL avgt 30 7399944.164 ? 216821.819 ns/op >> XorTest.copy REGION MEDIUM avgt 30 20591454.558 ? 147398.572 ns/op >> XorTest.copy REGION LARGE avgt 30 21649266.051 ? 179263.875 ns/op >> XorTest.copy CRITICAL SMALL avgt 30 51079.357 ? 542.482 ns/op >> XorTest.copy CRITICAL MEDIUM avgt 30 2496.961 ? 11.375 ns/op >> XorTest.copy CRITICAL LARGE avgt 30 515.454 ? 5.831 ns/op >> XorTest.copy FOREIGN SMALL avgt 30 7558432.075 ? 79489.276 ns/op >> XorTest.copy FOREIGN MEDIUM avgt 30 19730666.341 ? 500505.099 ns/op >> XorTest.copy FOREIGN LARGE avgt 30 34616758.085 ? 340300.726 ns/op >> XorTest.xor ELEMENTS SMALL avgt 30 219832692.489 ? 2329417.319 ns/op >> XorTest.xor ELEMENTS MEDIUM avgt 30 505138197.167 ? 3818334.424 ns/op >> XorTest.xor ELEMENTS LARGE avgt 30 1189608474.667 ? 5877981.900 ns/op >> XorTest.xor REGION SMALL avgt 30 64093872.804 ? 599704.491 ns/op >> XorTest.xor REGION MEDIUM avgt 30 81544576.454 ? 1406342.118 ns/op >> XorTest.xor REGION LARGE avgt 30 90091424.883 ? 775577.613 ns/op >> XorTest.xor CRITICAL SMALL avgt 30 57231375.744 ? 438223.342 ns/op >> XorTest.xor CRITICAL MEDIUM avgt 30 58583884.930 ? 375355.215 ns/op >> XorTest.xor CRITICAL LARGE avgt 30 60644832.949 ? 588120.738 ns/op >> XorTest.xor FOREIGN SMALL avgt 30 73868679.405 ? 819965.524 ns/op >> XorTest.xor FOREIGN MEDIUM avgt 30 88156275.944 ? 1051257.152 ns/op >> Xo... > > Steve Dohrmann has updated the pull request incrementally with one additional commit since the last revision: > > - fix whitespace error Thanks, I re-submitted testing. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16575#issuecomment-1818334820 From thartmann at openjdk.org Mon Nov 20 07:29:32 2023 From: thartmann at openjdk.org (Tobias Hartmann) Date: Mon, 20 Nov 2023 07:29:32 GMT Subject: RFR: 8310159: Bulk copy with Unsafe::arrayCopy is slower compared to memcpy [v4] In-Reply-To: <9j8PVvxFrzJHxtdVNMgvDZHKsjuBVNhl8q45OenHOIA=.2ed68c3d-dddd-4aba-bfab-c4da636662cb@github.com> References: <9j8PVvxFrzJHxtdVNMgvDZHKsjuBVNhl8q45OenHOIA=.2ed68c3d-dddd-4aba-bfab-c4da636662cb@github.com> Message-ID: On Thu, 16 Nov 2023 21:26:47 GMT, Steve Dohrmann wrote: >> Below is baseline data collected using a modified version of the java.lang.foreign.xor micro benchmark referenced by @mcimadamore in the bug report. I collected data on an Ubuntu 22.04 laptop with a Tigerlake i7-1185G7, which does support AVX512. >> >> Baseline data >> Benchmark (arrayKind) (sizeKind) Mode Cnt Score Error Units >> -------------------------------------------------------------------------------------- >> XorTest.copy ELEMENTS SMALL avgt 30 584737355.767 ? 60414308.540 ns/op >> XorTest.copy ELEMENTS MEDIUM avgt 30 272248995.683 ? 2924954.498 ns/op >> XorTest.copy ELEMENTS LARGE avgt 30 1019200210.900 ? 28334453.652 ns/op >> XorTest.copy REGION SMALL avgt 30 7399944.164 ? 216821.819 ns/op >> XorTest.copy REGION MEDIUM avgt 30 20591454.558 ? 147398.572 ns/op >> XorTest.copy REGION LARGE avgt 30 21649266.051 ? 179263.875 ns/op >> XorTest.copy CRITICAL SMALL avgt 30 51079.357 ? 542.482 ns/op >> XorTest.copy CRITICAL MEDIUM avgt 30 2496.961 ? 11.375 ns/op >> XorTest.copy CRITICAL LARGE avgt 30 515.454 ? 5.831 ns/op >> XorTest.copy FOREIGN SMALL avgt 30 7558432.075 ? 79489.276 ns/op >> XorTest.copy FOREIGN MEDIUM avgt 30 19730666.341 ? 500505.099 ns/op >> XorTest.copy FOREIGN LARGE avgt 30 34616758.085 ? 340300.726 ns/op >> XorTest.xor ELEMENTS SMALL avgt 30 219832692.489 ? 2329417.319 ns/op >> XorTest.xor ELEMENTS MEDIUM avgt 30 505138197.167 ? 3818334.424 ns/op >> XorTest.xor ELEMENTS LARGE avgt 30 1189608474.667 ? 5877981.900 ns/op >> XorTest.xor REGION SMALL avgt 30 64093872.804 ? 599704.491 ns/op >> XorTest.xor REGION MEDIUM avgt 30 81544576.454 ? 1406342.118 ns/op >> XorTest.xor REGION LARGE avgt 30 90091424.883 ? 775577.613 ns/op >> XorTest.xor CRITICAL SMALL avgt 30 57231375.744 ? 438223.342 ns/op >> XorTest.xor CRITICAL MEDIUM avgt 30 58583884.930 ? 375355.215 ns/op >> XorTest.xor CRITICAL LARGE avgt 30 60644832.949 ? 588120.738 ns/op >> XorTest.xor FOREIGN SMALL avgt 30 73868679.405 ? 819965.524 ns/op >> XorTest.xor FOREIGN MEDIUM avgt 30 88156275.944 ? 1051257.152 ns/op >> Xo... > > Steve Dohrmann has updated the pull request incrementally with one additional commit since the last revision: > > - fix whitespace error test/micro/org/openjdk/bench/java/lang/foreign/xor/XorOp.java line 10: > 8: void copy(int count, byte[] src, int sOff, byte[] dst, int dOff, int len); > 9: ======= > 10: >>>>>>> 9727f4bdddc071e6f59806087339f345405ab004 You have multiple merge conflicts in the micro benchmark files. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16575#discussion_r1398749880 From mbaesken at openjdk.org Mon Nov 20 07:55:30 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Mon, 20 Nov 2023 07:55:30 GMT Subject: RFR: 8320348: java.io.File.getAbsolutePath fails if working directory is not on drive C In-Reply-To: References: Message-ID: On Fri, 17 Nov 2023 21:51:06 GMT, Brian Burkhalter wrote: > The method `windowsDriveRelative` of the test `java/io/File/GetAbsolutePath` was incorrectly translated from its previous version to the current JUnit 5 version. Marked as reviewed by mbaesken (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/16720#pullrequestreview-1739135298 From mbaesken at openjdk.org Mon Nov 20 07:55:32 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Mon, 20 Nov 2023 07:55:32 GMT Subject: RFR: 8320348: java.io.File.getAbsolutePath fails if working directory is not on drive C In-Reply-To: References: Message-ID: On Sat, 18 Nov 2023 12:30:18 GMT, Matthias Baesken wrote: > > @MBaesken I would appreciate it if you would try out this proposed change > > to see whether it fixes the problem that you reported. Thanks! > > Hi Brian, I added your patch to our tests. After adding the patch, the errors seen before in our test runs are gone. Thanks for the patch ! ------------- PR Comment: https://git.openjdk.org/jdk/pull/16720#issuecomment-1818401211 From eliu at openjdk.org Mon Nov 20 09:29:32 2023 From: eliu at openjdk.org (Eric Liu) Date: Mon, 20 Nov 2023 09:29:32 GMT Subject: RFR: 8319872: AArch64: [vectorapi] Implementation of unsigned (zero extended) casts [v2] In-Reply-To: References: Message-ID: <_i1HpqtJBEarrwnOEQ4l1mgaNeqfJv59Aq5if7e_heU=.9bd7cd18-8e26-46a4-a7be-188c73121f0f@github.com> On Thu, 16 Nov 2023 08:59:09 GMT, Andrew Haley wrote: >> Eric Liu has updated the pull request incrementally with one additional commit since the last revision: >> >> update m4 >> >> Change-Id: I82bf5f9384f79e09965a0498ad2de45cec6f0a29 > > src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp line 1415: > >> 1413: break; >> 1414: case S: >> 1415: (this->*unpklo)(dst, H, src); > > AS above: try making` is_unsigned` a parameter. Got it. I will fix it soon. Thanks! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16670#discussion_r1398872059 From abimpoudis at openjdk.org Mon Nov 20 09:36:25 2023 From: abimpoudis at openjdk.org (Aggelos Biboudis) Date: Mon, 20 Nov 2023 09:36:25 GMT Subject: RFR: 8303374: Compiler Implementation for Primitive types in patterns, instanceof, and switch (Preview) [v32] In-Reply-To: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com> References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com> Message-ID: > This is the proposed patch for Primitive types in patterns, instanceof, and switch (Preview). > > Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/latest/ Aggelos Biboudis has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 38 commits: - Merge branch 'master' into primitive-patterns - Merge branch 'master' into primitive-patterns - Merge branch 'master' into primitive-patterns - Small cleanup in PrimitivePatternsSwitch - Add test for instanceof as a pattern on with record patterns - Merge branch 'master' into primitive-patterns # Conflicts: # src/jdk.compiler/share/classes/com/sun/tools/javac/code/Preview.java # src/jdk.compiler/share/classes/com/sun/tools/javac/code/Source.java - Add tests for new data types in switch statements - Fix Bootstrap initialization error by using `explicitCastArguments` for integral tests - Fix SwitchBootstraps for pattern matching over longs - Merge branch 'master' into primitive-patterns - ... and 28 more: https://git.openjdk.org/jdk/compare/de51aa19...584a4a30 ------------- Changes: https://git.openjdk.org/jdk/pull/15638/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=31 Stats: 3199 lines in 41 files changed: 2943 ins; 111 del; 145 mod Patch: https://git.openjdk.org/jdk/pull/15638.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15638/head:pull/15638 PR: https://git.openjdk.org/jdk/pull/15638 From aturbanov at openjdk.org Mon Nov 20 09:44:43 2023 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Mon, 20 Nov 2023 09:44:43 GMT Subject: Integrated: 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`. This pull request has now been integrated. Changeset: 6c5e15c1 Author: Andrey Turbanov URL: https://git.openjdk.org/jdk/commit/6c5e15c1a291ca5ba1e4c3a90351bc71665ce988 Stats: 42 lines in 10 files changed: 2 ins; 13 del; 27 mod 8316557: Make fields final in 'sun.util' package Reviewed-by: pminborg, naoto ------------- PR: https://git.openjdk.org/jdk/pull/15736 From djelinski at openjdk.org Mon Nov 20 10:19:54 2023 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Mon, 20 Nov 2023 10:19:54 GMT Subject: RFR: 8320386: Remove java/nio/channels/vthread/BlockingChannelOps.java#direct-register from ProblemList Message-ID: The direct-register test variant was removed in c099cf53f25496c99629dc578045aa5186e1109d. The failing test case was also modified - the socket timeout is much shorter now, so even if the receive operation gets stuck for the full duration, the test will still pass. ------------- Commit messages: - Problemlist cleanup Changes: https://git.openjdk.org/jdk/pull/16732/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16732&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8320386 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/16732.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16732/head:pull/16732 PR: https://git.openjdk.org/jdk/pull/16732 From alanb at openjdk.org Mon Nov 20 10:33:28 2023 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 20 Nov 2023 10:33:28 GMT Subject: RFR: 8320386: Remove java/nio/channels/vthread/BlockingChannelOps.java#direct-register from ProblemList In-Reply-To: References: Message-ID: On Mon, 20 Nov 2023 10:09:36 GMT, Daniel Jeli?ski wrote: > The direct-register test variant was removed in c099cf53f25496c99629dc578045aa5186e1109d. The failing test case was also modified - the socket timeout is much shorter now, so even if the receive operation gets stuck for the full duration, the test will still pass. Yes, this exclude list was missed with the poller update so the test id no longer matches. It's okay to remove now. ------------- Marked as reviewed by alanb (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16732#pullrequestreview-1739458698 From vklang at openjdk.org Mon Nov 20 11:26:32 2023 From: vklang at openjdk.org (Viktor Klang) Date: Mon, 20 Nov 2023 11:26:32 GMT Subject: RFR: JDK-8319662 ForkJoinPool trims worker threads too slowly In-Reply-To: References: Message-ID: On Sun, 19 Nov 2023 17:36:01 GMT, Doug Lea
    wrote: > This update cascades timeouts to trim subsequent workers after the first keepAlive inactive period. src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 2140: > 2138: Thread.interrupted(); // clear for next park > 2139: if (deadline != 0L && // try to trim on timeout > 2140: deadline - System.currentTimeMillis() < TIMEOUT_SLOP) { Since `currentTimeMillis()` is fetched from system time, I think it might be more appropriate to use nanoTime() to track delays. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16725#discussion_r1399055155 From vklang at openjdk.org Mon Nov 20 11:29:30 2023 From: vklang at openjdk.org (Viktor Klang) Date: Mon, 20 Nov 2023 11:29:30 GMT Subject: RFR: JDK-8319662 ForkJoinPool trims worker threads too slowly In-Reply-To: References: Message-ID: On Sun, 19 Nov 2023 17:36:01 GMT, Doug Lea
    wrote: > This update cascades timeouts to trim subsequent workers after the first keepAlive inactive period. src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 680: > 678: * time out and terminate if the pool has remained quiescent for > 679: * period given by field keepAlive (default 60sec), which applies > 680: * to the first timeout of a fully populated pool. Subsequent (or If I understand this correctly, it means that the entire pool needs to have no work (at all) before starting to decommission workers. Is that the case? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16725#discussion_r1399058194 From aturbanov at openjdk.org Mon Nov 20 11:45:49 2023 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Mon, 20 Nov 2023 11:45:49 GMT Subject: RFR: 8320400: Make fields final in 'jdk.internal.util.xml.impl' package Message-ID: A few classes in `jdk.internal.util.xml.impl` package have non-final fields which could easily be marked `final`. ------------- Commit messages: - [PATCH] Make fields final in jdk.internal.util.xml.impl package Changes: https://git.openjdk.org/jdk/pull/15691/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15691&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8320400 Stats: 38 lines in 7 files changed: 0 ins; 0 del; 38 mod Patch: https://git.openjdk.org/jdk/pull/15691.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15691/head:pull/15691 PR: https://git.openjdk.org/jdk/pull/15691 From mcimadamore at openjdk.org Mon Nov 20 11:58:48 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 20 Nov 2023 11:58:48 GMT Subject: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v21] In-Reply-To: References: Message-ID: On Fri, 17 Nov 2023 13:56:13 GMT, Jim Laskey wrote: >> Address changes from JEP 445 to JEP 463. >> >> - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. >> >> - Don't mark class on read. >> >> - Remove reflection and annotation processing related to unnamed classes. >> >> - Simplify main method search. > > Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: > > Allow nested class of same name as file > > Since it doesn't create a conflicting symbol and would produce a confusing error otherwise. src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java line 464: > 462: } > 463: for (Symbol sym = s.owner; sym != null; sym = sym.owner) { > 464: if (sym.kind == TYP && sym.name == name && sym.name != names.error && Looks good! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16461#discussion_r1399091826 From mcimadamore at openjdk.org Mon Nov 20 11:58:48 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 20 Nov 2023 11:58:48 GMT Subject: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v21] In-Reply-To: References: Message-ID: On Mon, 20 Nov 2023 11:53:35 GMT, Maurizio Cimadamore wrote: >> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: >> >> Allow nested class of same name as file >> >> Since it doesn't create a conflicting symbol and would produce a confusing error otherwise. > > src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java line 464: > >> 462: } >> 463: for (Symbol sym = s.owner; sym != null; sym = sym.owner) { >> 464: if (sym.kind == TYP && sym.name == name && sym.name != names.error && > > Looks good! I recommend adding a test for this (if not already done) - checking cases like: // A.java void m() { } class A {} but also where A is nested deeper: // A.java void m() { } class B { class A { } } And then also check that the test still works for other classes defined in the implicit unit: // A.java void m() { } class B { class B { } //error } ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16461#discussion_r1399096324 From info at birkeheeren.de Mon Nov 20 12:00:13 2023 From: info at birkeheeren.de (Birke Heeren) Date: Mon, 20 Nov 2023 13:00:13 +0100 (CET) Subject: enum irk Message-ID: <1070798656.2536167.1700481613692@webmail.strato.com> package irk; public enum Irk { IRK, END_IRK, HASH, END_HASH, COLON, ARRAY, END_ARRAY, QUOTE, END_QUOTE, COMMA; public static String is_irk = " i**********irk0"; // when the character irk is detected, the language irk is present public static String is_end_irk = " i**********irk1"; public static String is_hash = " i**********irk2"; public static String is_end_hash = " i**********irk3"; public static String is_colon = " i**********irk4"; public static String is_array = " i**********irk5"; public static String is_end_array = " i**********irk6"; public static String is_quote = " i**********irk7"; public static String is_end_quote = " i**********irk8"; public static String is_comma = " i**********irk9"; public static String do_irk_pattern = " i**********irk0 i**********irk0 i**********irk2 i**********irk4 i**********irk3 i**********irk1 i**********irk1"; public static String is_irk_double = " i**********irk0 i**********irk0"; public static String is_irk_content = " i**********irk0 i**********irk0 i**********irk2"; public static String is_irk_content_okay = " i**********irk0 i**********irk0 i**********irk2 i**********irk4"; public static String is_irk_content_end = " i**********irk0 i**********irk0 i**********irk2 i**********irk4 i**********irk3"; public static String is_irk_end = " i**********irk0 i**********irk0 i**********irk2 i**********irk4 i**********irk3 i**********irk1"; public static String is_irk_complete = " i**********irk0 i**********irk0 i**********irk2 i**********irk4 i**********irk3 i**********irk1 i**********irk1"; public static String is_irk_pattern = " i**********irk0 i**********irk1"; public static String is_hash_pattern = " i**********irk2 i**********irk3"; public static String is_colon_pattern = " i**********irk4"; public static String do_irk_key = " i**********irk7 i**********irk8"; public static String is_quote_pattern = " i**********irk7 i**********irk8"; public static String do_irk_value_array = " i**********irk5 i**********irk6"; // if list value public static String is_array_pattern = " i**********irk5 i**********irk6"; public static String do_irk_value_quotes = " i**********irk7 i**********irk8"; // if single value // is_quote_pattern public static String do_irk_value_hash = " i**********irk2 i**********irk3"; // if hash value // is_hash_pattern public static String is_comma_pattern = " i**********irk9"; } -------------- next part -------------- An HTML attachment was scrubbed... URL: From info at birkeheeren.de Mon Nov 20 12:07:13 2023 From: info at birkeheeren.de (Birke Heeren) Date: Mon, 20 Nov 2023 13:07:13 +0100 (CET) Subject: enum irk with comments Message-ID: <1250957219.2537937.1700482033959@webmail.strato.com> package irk; public enum Irk { IRK, END_IRK, HASH, END_HASH, COLON, ARRAY, END_ARRAY, QUOTE, END_QUOTE, COMMA; public static String is_irk = " i**********irk0"; // when the character irk is detected, the language irk is present public static String is_end_irk = " i**********irk1"; public static String is_hash = " i**********irk2"; public static String is_end_hash = " i**********irk3"; public static String is_colon = " i**********irk4"; public static String is_array = " i**********irk5"; public static String is_end_array = " i**********irk6"; public static String is_quote = " i**********irk7"; public static String is_end_quote = " i**********irk8"; public static String is_comma = " i**********irk9"; /* * How to start writing irk on disk * */ public static String do_irk_pattern = " i**********irk0 i**********irk0 i**********irk2 i**********irk4 i**********irk3 i**********irk1 i**********irk1"; // is_irk public static String is_irk_double = " i**********irk0 i**********irk0"; public static String is_irk_content = " i**********irk0 i**********irk0 i**********irk2"; public static String is_irk_content_okay = " i**********irk0 i**********irk0 i**********irk2 i**********irk4"; public static String is_irk_content_end = " i**********irk0 i**********irk0 i**********irk2 i**********irk4 i**********irk3"; public static String is_irk_end = " i**********irk0 i**********irk0 i**********irk2 i**********irk4 i**********irk3 i**********irk1"; public static String is_irk_complete = " i**********irk0 i**********irk0 i**********irk2 i**********irk4 i**********irk3 i**********irk1 i**********irk1"; public static String is_irk_pattern = " i**********irk0 i**********irk1"; public static String is_hash_pattern = " i**********irk2 i**********irk3"; public static String is_colon_pattern = " i**********irk4"; public static String do_irk_key = " i**********irk7 i**********irk8"; public static String is_quote_pattern = " i**********irk7 i**********irk8"; public static String do_irk_value_array = " i**********irk5 i**********irk6"; // if list value public static String is_array_pattern = " i**********irk5 i**********irk6"; public static String do_irk_value_quotes = " i**********irk7 i**********irk8"; // if single value // is_quote_pattern public static String do_irk_value_hash = " i**********irk2 i**********irk3"; // if hash value // is_hash_pattern public static String is_comma_pattern = " i**********irk9"; } -------------- next part -------------- An HTML attachment was scrubbed... URL: From info at birkeheeren.de Mon Nov 20 12:48:09 2023 From: info at birkeheeren.de (Birke Heeren) Date: Mon, 20 Nov 2023 13:48:09 +0100 (CET) Subject: enum irk and hardware programming instructions for assembler Message-ID: <2115287396.2550098.1700484489414@webmail.strato.com> package irk; public enum Irk { IRK, END_IRK, HASH, END_HASH, COLON, ARRAY, END_ARRAY, QUOTE, END_QUOTE, COMMA; public static String is_irk = " i**********irk0"; // when the character irk is detected, the language irk is present public static String is_end_irk = " i**********irk1"; public static String is_hash = " i**********irk2"; public static String is_end_hash = " i**********irk3"; public static String is_colon = " i**********irk4"; public static String is_array = " i**********irk5"; public static String is_end_array = " i**********irk6"; public static String is_quote = " i**********irk7"; public static String is_end_quote = " i**********irk8"; public static String is_comma = " i**********irk9"; // start single public static String do_irk_pattern = " i**********irk0 i**********irk0 i**********irk2 i**********irk4 i**********irk3 i**********irk1 i**********irk1"; // is_irk public static String is_irk_double = " i**********irk0 i**********irk0"; public static String is_irk_content = " i**********irk0 i**********irk0 i**********irk2"; public static String is_irk_content_okay = " i**********irk0 i**********irk0 i**********irk2 i**********irk4"; public static String is_irk_content_end = " i**********irk0 i**********irk0 i**********irk2 i**********irk4 i**********irk3"; public static String is_irk_end = " i**********irk0 i**********irk0 i**********irk2 i**********irk4 i**********irk3 i**********irk1"; public static String is_irk_complete = " i**********irk0 i**********irk0 i**********irk2 i**********irk4 i**********irk3 i**********irk1 i**********irk1"; public static String check_irk_pattern_present = " i**********irk0 i**********irk1"; public static String check_hash_pattern_present = " i**********irk2 i**********irk3"; public static String check_is_colon_pattern_present = " i**********irk4"; public static String find_insert_for_key = " i**********irk2 i**********irk4"; public static String do_irk_key = " i**********irk7 i**********irk8"; public static String is_quote_pattern = " i**********irk7 i**********irk8"; //| store physical address of key public static String find_insert_for_value = " i**********irk4 i**********irk3"; // if list value // go sub public static String do_irk_value_array = " i**********irk5 i**********irk6"; public static String is_array_pattern = " i**********irk5 i**********irk6"; //| store physical address of array value // end sub // if single value // go sub public static String do_irk_value_quotes = " i**********irk7 i**********irk8"; // is_quote_pattern //| store physical address of single value // end sub // if hash value // go sub public static String do_irk_value_hash = " i**********irk2 i**********irk3"; // is_hash_pattern //| store physical address of hash value // end sub // stop public static String is_comma_pattern = " i**********irk9"; } -------------- next part -------------- An HTML attachment was scrubbed... URL: From djelinski at openjdk.org Mon Nov 20 12:49:44 2023 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Mon, 20 Nov 2023 12:49:44 GMT Subject: RFR: 8320386: Remove java/nio/channels/vthread/BlockingChannelOps.java#direct-register from ProblemList In-Reply-To: References: Message-ID: <2iTYgMqcdyUHbkNu43RWMYvMsCHoWYagaIFK0Om-0gs=.12f16611-3621-4fa6-b4aa-82ff2896df52@github.com> On Mon, 20 Nov 2023 10:09:36 GMT, Daniel Jeli?ski wrote: > The direct-register test variant was removed in c099cf53f25496c99629dc578045aa5186e1109d. The failing test case was also modified - the socket timeout is much shorter now, so even if the receive operation gets stuck for the full duration, the test will still pass. Thanks for the quick review. Given the trivial nature of this change, I'm going to integrate it now. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16732#issuecomment-1818996881 From djelinski at openjdk.org Mon Nov 20 12:49:45 2023 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Mon, 20 Nov 2023 12:49:45 GMT Subject: Integrated: 8320386: Remove java/nio/channels/vthread/BlockingChannelOps.java#direct-register from ProblemList In-Reply-To: References: Message-ID: On Mon, 20 Nov 2023 10:09:36 GMT, Daniel Jeli?ski wrote: > The direct-register test variant was removed in c099cf53f25496c99629dc578045aa5186e1109d. The failing test case was also modified - the socket timeout is much shorter now, so even if the receive operation gets stuck for the full duration, the test will still pass. This pull request has now been integrated. Changeset: 9f6a4a3f Author: Daniel Jeli?ski URL: https://git.openjdk.org/jdk/commit/9f6a4a3f9c5ee0fbb65c794d657fffca7d19927f Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod 8320386: Remove java/nio/channels/vthread/BlockingChannelOps.java#direct-register from ProblemList Reviewed-by: alanb ------------- PR: https://git.openjdk.org/jdk/pull/16732 From dl at openjdk.org Mon Nov 20 13:34:34 2023 From: dl at openjdk.org (Doug Lea) Date: Mon, 20 Nov 2023 13:34:34 GMT Subject: RFR: JDK-8319662 ForkJoinPool trims worker threads too slowly In-Reply-To: References: Message-ID: On Mon, 20 Nov 2023 11:23:54 GMT, Viktor Klang wrote: >> This update cascades timeouts to trim subsequent workers after the first keepAlive inactive period. > > src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 2140: > >> 2138: Thread.interrupted(); // clear for next park >> 2139: if (deadline != 0L && // try to trim on timeout >> 2140: deadline - System.currentTimeMillis() < TIMEOUT_SLOP) { > > Since `currentTimeMillis()` is fetched from system time, I think it might be more appropriate to use nanoTime() to track delays. It would be better, but absolute-time Unsafe.park only operates at millisecond accuracy (and even at that may misfire early, requiring TIMEOUT_SLOP.) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16725#discussion_r1399210760 From jlaskey at openjdk.org Mon Nov 20 13:45:12 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Mon, 20 Nov 2023 13:45:12 GMT Subject: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v27] In-Reply-To: References: Message-ID: > Address changes from JEP 445 to JEP 463. > > - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. > > - Don't mark class on read. > > - Remove reflection and annotation processing related to unnamed classes. > > - Simplify main method search. Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: Move Implicitly Declared Classes to single directory ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16461/files - new: https://git.openjdk.org/jdk/pull/16461/files/27de4fec..c5992d58 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16461&range=26 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16461&range=25-26 Stats: 0 lines in 5 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/16461.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16461/head:pull/16461 PR: https://git.openjdk.org/jdk/pull/16461 From pminborg at openjdk.org Mon Nov 20 13:46:36 2023 From: pminborg at openjdk.org (Per Minborg) Date: Mon, 20 Nov 2023 13:46:36 GMT Subject: RFR: 8320400: Make fields final in 'jdk.internal.util.xml.impl' package In-Reply-To: References: Message-ID: On Tue, 12 Sep 2023 19:59:57 GMT, Andrey Turbanov wrote: > A few classes in `jdk.internal.util.xml.impl` package have non-final fields which could easily be marked `final`. > > Also fixed a few typos and incorrect javadoc links. There are also some typo fixes. I think this could be mentioned in the PR description. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15691#issuecomment-1819090804 From pminborg at openjdk.org Mon Nov 20 13:51:36 2023 From: pminborg at openjdk.org (Per Minborg) Date: Mon, 20 Nov 2023 13:51:36 GMT Subject: RFR: 8320400: Make fields final in 'jdk.internal.util.xml.impl' package In-Reply-To: References: Message-ID: On Tue, 12 Sep 2023 19:59:57 GMT, Andrey Turbanov wrote: > A few classes in `jdk.internal.util.xml.impl` package have non-final fields which could easily be marked `final`. > > Also fixed a few typos and incorrect javadoc links. src/java.base/share/classes/jdk/internal/util/xml/impl/XMLStreamWriterImpl.java line 78: > 76: private boolean _doIndent = true; > 77: //The system line separator for writing out line breaks. > 78: private final char[] _lineSep = System.lineSeparator().toCharArray(); The method System.lineSeparator() is specified such that it will always return the same value. Hene, I proposes: @Stable private static final char[] LINE_SEP = System.lineSeparator().toCharArray(); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15691#discussion_r1399231282 From alanb at openjdk.org Mon Nov 20 13:53:52 2023 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 20 Nov 2023 13:53:52 GMT Subject: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v26] In-Reply-To: References: Message-ID: On Sun, 19 Nov 2023 20:14:10 GMT, Jim Laskey wrote: >> Address changes from JEP 445 to JEP 463. >> >> - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. >> >> - Don't mark class on read. >> >> - Remove reflection and annotation processing related to unnamed classes. >> >> - Simplify main method search. > > Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: > > Additional tests for getMainMethod src/java.base/share/classes/java/lang/Class.java line 4839: > 4837: @PreviewFeature(feature=PreviewFeature.Feature.IMPLICIT_CLASSES) > 4838: @CallerSensitive > 4839: public Method getMainMethod() { This is a new addition in the last few days. It's somewhat surprising as the launch protocol has never really surfaced in the API, there's nothing to identify the main class for example. I'm in two minds on surfacing this but it does make the java launcher code much simpler. Class.getMethod/getMethods return public methods, the proposed getMainMethod may return a public or non-public method and may walk the class hierarchy. So I'm not sure about the naming, it feels more like a findMainMethod to emphasize the search or just mainMethod. The javadoc probably needs to be fleshed out a bit more to specify how the main method is found. It currently says "be declared this class's hierarchy" (typo) but it has to say more and make it clear that it may return a Method with a declared class that may be a superclass. "(@jls 8.4.2)", I assume that should be "{@jls 8.4.2}". The return description says "the candidate main method". This begs the question if there are other candidates, how do I find them? The SM permission check looks right, it has to be the same as getDeclaredMethod. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16461#discussion_r1399233970 From cstein at openjdk.org Mon Nov 20 13:58:49 2023 From: cstein at openjdk.org (Christian Stein) Date: Mon, 20 Nov 2023 13:58:49 GMT Subject: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v26] In-Reply-To: References: Message-ID: On Mon, 20 Nov 2023 13:50:45 GMT, Alan Bateman wrote: > [...] it does make the java launcher code much simpler. Yes. That's a very nice effect of surfacing the launch protocol directyl in `java.lang.Class` > So I'm not sure about the naming, it feels more like a `findMainMethod` to emphasize the search or just `mainMethod`. +1 for `findMainMethod`, and also an explicit `Optional` as the return type. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16461#discussion_r1399240835 From vklang at openjdk.org Mon Nov 20 14:31:59 2023 From: vklang at openjdk.org (Viktor Klang) Date: Mon, 20 Nov 2023 14:31:59 GMT Subject: RFR: JDK-8319662 ForkJoinPool trims worker threads too slowly In-Reply-To: References: Message-ID: <24lkVT4KYkoULx16ZEgpOTNBJ3B5-pDJRvDck9aswnQ=.651f1e61-27ad-4329-a87a-d6d0778801cc@github.com> On Mon, 20 Nov 2023 13:31:42 GMT, Doug Lea
    wrote: >> src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 2140: >> >>> 2138: Thread.interrupted(); // clear for next park >>> 2139: if (deadline != 0L && // try to trim on timeout >>> 2140: deadline - System.currentTimeMillis() < TIMEOUT_SLOP) { >> >> Since `currentTimeMillis()` is fetched from system time, I think it might be more appropriate to use nanoTime() to track delays. > > It would be better, but absolute-time Unsafe.park only operates at millisecond accuracy (and even at that may misfire early, requiring TIMEOUT_SLOP.) I was thinking more about cases where system clock moves backwards in time. (currentTimeMillis() isn't spec:ed to be monotonic, right?) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16725#discussion_r1399283296 From jlaskey at openjdk.org Mon Nov 20 14:47:26 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Mon, 20 Nov 2023 14:47:26 GMT Subject: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v28] In-Reply-To: References: Message-ID: <7lwdp_OMcqBVy3fCLGHE4ZwpFecsUCGSt_BkSYcRQyM=.49a40270-108b-4376-b2a6-08836690350c@github.com> > Address changes from JEP 445 to JEP 463. > > - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. > > - Don't mark class on read. > > - Remove reflection and annotation processing related to unnamed classes. > > - Simplify main method search. Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: Add nested class test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16461/files - new: https://git.openjdk.org/jdk/pull/16461/files/c5992d58..5542947a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16461&range=27 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16461&range=26-27 Stats: 109 lines in 1 file changed: 109 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/16461.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16461/head:pull/16461 PR: https://git.openjdk.org/jdk/pull/16461 From mcimadamore at openjdk.org Mon Nov 20 14:56:05 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 20 Nov 2023 14:56:05 GMT Subject: RFR: 8319928: Exceptions thrown by cleanup actions should be handled correctly [v6] In-Reply-To: References: Message-ID: <4zOEwya7keJq4hdojEWn9CDumrTko3weIHLfhN-KUIY=.f5b18afb-1846-4d6f-8d7e-2e789791ce6b@github.com> > This simplePR tweaks the factory which wraps custom cleanup actions passed to `MemorySegment::reinterpret`, so that any exception thrown by the custom cleanup is swallowed when the arena is closed. > > This aligns the behavior of confined/shared session with that of implicit session (as implicit sessions are backed by a `Cleaner`, there is no way for cleanup exception to bubble up). Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains ten additional commits since the last revision: - Merge branch 'master' into swallow_cleanup_exceptions - Merge branch 'master' into swallow_cleanup_exceptions - Add test to check for self-suppression - Drop unused import - Address CSR comments - More javadoc tweaks - Tweak javadoc - Catch all cleanup failures in `CleanupException` - Initial push ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16619/files - new: https://git.openjdk.org/jdk/pull/16619/files/b1dde897..37b6a033 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16619&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16619&range=04-05 Stats: 611705 lines in 972 files changed: 82566 ins; 469878 del; 59261 mod Patch: https://git.openjdk.org/jdk/pull/16619.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16619/head:pull/16619 PR: https://git.openjdk.org/jdk/pull/16619 From mcimadamore at openjdk.org Mon Nov 20 15:06:17 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 20 Nov 2023 15:06:17 GMT Subject: Integrated: 8319928: Exceptions thrown by cleanup actions should be handled correctly In-Reply-To: References: Message-ID: <3sZgfH-QqcFgdP1mIuxoLmr-m24A4Gjm9veLgyLMqrg=.2eb2ec93-591e-4456-ac22-6838d330c4d0@github.com> On Fri, 10 Nov 2023 16:34:11 GMT, Maurizio Cimadamore wrote: > This simplePR tweaks the factory which wraps custom cleanup actions passed to `MemorySegment::reinterpret`, so that any exception thrown by the custom cleanup is swallowed when the arena is closed. > > This aligns the behavior of confined/shared session with that of implicit session (as implicit sessions are backed by a `Cleaner`, there is no way for cleanup exception to bubble up). This pull request has now been integrated. Changeset: 7f231109 Author: Maurizio Cimadamore URL: https://git.openjdk.org/jdk/commit/7f231109c2e172493114cd0835cbb770331d1635 Stats: 87 lines in 3 files changed: 85 ins; 1 del; 1 mod 8319928: Exceptions thrown by cleanup actions should be handled correctly Reviewed-by: jvernee ------------- PR: https://git.openjdk.org/jdk/pull/16619 From sgehwolf at openjdk.org Mon Nov 20 15:10:50 2023 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Mon, 20 Nov 2023 15:10:50 GMT Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged modules being present [v8] In-Reply-To: <3DpzMArCkz5ehvgoid5DPvhy6SQmw9mkKzOBqj6vItU=.54099d82-259c-48ca-8c61-e7b783640ed8@github.com> References: <3DpzMArCkz5ehvgoid5DPvhy6SQmw9mkKzOBqj6vItU=.54099d82-259c-48ca-8c61-e7b783640ed8@github.com> Message-ID: On Thu, 16 Nov 2023 19:00:57 GMT, Mandy Chung wrote: >> Thanks. >> >>> How can the user know what plugins are applied to `image2`? i.e. what is the jlink command to produce `image2` if running from `jdk22` with the packaged modules present? >> >> The only way to know is by knowing the chain of `jlink` commands yielding up to the final image. Let `jlink'` be the jlink using packaged modules. Currently this can be at most two. In addition, the contents of `argfile` needs to be known. That doesn't seem to be very different to the status quo, though. See below. >> >>> Reading the changes, I'm not sure but I think it's not equivalent to: >>> >>> ``` >>> jdk22/bin/jlink --add-modules jdk.jlink --output image2 --vendor-bug.url https://xyz.com/bugs --save-jlink-argfiles argfile --generate-jli-classes jli_trace.txt --strip-debug --add-options "-Dcom.foo.XYZ=true" --add-options "-Dcom.acme.name=BAR" >>> ``` >> >> Note that plugins like `--add-options` have been modified so that only the options passed at the current CLI will propagate to the final image. So in this case, `image1` would have property `com.foo.XYZ` set, but not `image2`. Incidentally, what you probably intended to use was `--add-options "-Dcom.foo.XYZ=true -Dcom.acme.name=BAR". >> >> Having said that, depending on the contents of `argfile`, those could be equivalent. In fact, they are with `--unlock-run-image`, and an empty `argfile`. `--unlock-run-image` avoids adding the marker file, which is the only difference when we extract the image. >> >> `--save-jlink-argfiles` brings a strange angle to this discussion, but it's conceivable to get a similarly different image, even with --keep-packaged-modules. Consider: >> >> >> echo '--add-options=-XX:+UseParallelGC' > argfile >> ./jdk22/bin/jlink --save-jlink-argfiles argfile --strip-debug --add-modules jdk.jlink --keep-packaged-modules ./image_a/jmods --output image_a >> ./image_a/bin/jlink --add-modules java.base --output image_b >> >> >> It's not very apparent that `image_b` will have `-XX:+UseParallelGC`. So you need some sort of track record what you've used previously already in order to know how `image_b` got produced (short of `--save-opts`)? >> >>> I think this behavior should be documented. >> >> Makes a lot of sense. Where? In the CSR? >> >>> > Note that plugins like `--add-options` have been modified so that only the options passed at the current CLI will propagate to the final image. So in this case, `image1` would have property `com.foo.XYZ` set, but not `image2`. Incidentally, what you probably intended to use... > >> > We need to go through each plugin and decide on its behavior. >> >> OK. I'll add documentation to the `--list-plugins` help should there be deviations. > > It'd be helpful if you write down your proposed behavior for each plugin for discussion. Otherwise, we will have to find out from the code. > >> > I'm also pondering how the Plugin API should support this run-time image based linking. >> >> It could, but doesn't need to IMO. OTOH, `transform()` could grow an argument to indicate packaged-modules vs runtime image link. > > I'm not sure if it needs the extra argument. As the plugin knows what files it adds, it can always check its existence as the current implementation is doing. What I'm thinking if the plugin will need to indicate if it'd concatenate, retain or drop the transformation from `image1` when creating `image2. This will get the plugin author to consider that when the plugin is developed. > > Regarding the name of the `runimage_resources` file, this file is only used by jlink and so it can be a resource file in `jdk.jlink` module like `jdk.jlink/jdk/tools/jlink/internal/runtime/$MODULE_resources` (e.g. `jdk.jlink/jdk/tools/jlink/internal/runtime/java.base_resources`) @mlchung Just as an FYI, I'm working on it. Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/14787#issuecomment-1819243946 From dfuchs at openjdk.org Mon Nov 20 15:30:26 2023 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Mon, 20 Nov 2023 15:30:26 GMT Subject: RFR: JDK-8319569: Several java/util tests should be updated to accept VM flags [v2] In-Reply-To: <8rH8ig7VH--LUeng8Kxp1tyHaJ09F2clpU22hMkmXJQ=.ccca251a-60cf-49e6-8995-071412195ace@github.com> References: <8rH8ig7VH--LUeng8Kxp1tyHaJ09F2clpU22hMkmXJQ=.ccca251a-60cf-49e6-8995-071412195ace@github.com> Message-ID: On Fri, 17 Nov 2023 20:20:43 GMT, Justin Lu wrote: >> Please review this PR which allows these _j.util_ tests to launch new JVM processes with VM flags, >> >> This is primarily done using by switching to `ProcessTools::createTestJavaProcessBuilder`. >> >> _PropertiesTest.sh_ was updated with `@requires vm.flagless`. > > Justin Lu has updated the pull request incrementally with one additional commit since the last revision: > > reflect review comments Changes to the logging tests LGTM. Thanks for the update @justin-curtis-lu . ------------- PR Comment: https://git.openjdk.org/jdk/pull/16705#issuecomment-1819284286 From duke at openjdk.org Mon Nov 20 16:22:54 2023 From: duke at openjdk.org (Glavo) Date: Mon, 20 Nov 2023 16:22:54 GMT Subject: RFR: 8310901: Convert String::newStringNoRepl with Latin-1 to String::newStringLatin1NoRepl [v8] In-Reply-To: References: Message-ID: > Added a new method `newStringLatin1NoRepl` to the `JavaLangAccess`. > > Reasons: > > * Most use cases of `newStringNoRepl` use `ISO_8859_1` as the charset, creating a new shortcut can make writing shorter; > * Since all possible values of `byte` are legal Latin-1 characters, `newStringLatin1NoRepl` **will not throw `CharacterCodingException`**, so users can make the compiler happy without using useless try-catch statements. Glavo has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision: - Merge branch 'openjdk:master' into latin1-no-repl - Merge branch 'openjdk:master' into latin1-no-repl - Use newStringLatin1NoRepl in UUID - Merge branch 'openjdk:master' into latin1-no-repl - Merge branch 'openjdk:master' into latin1-no-repl - Merge branch 'openjdk:master' into latin1-no-repl - update javadoc - clean newStringNoRepl1 - clean newStringNoRepl1 - Rename jla to JLA - ... and 1 more: https://git.openjdk.org/jdk/compare/40b5fa87...3898c8e5 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14655/files - new: https://git.openjdk.org/jdk/pull/14655/files/e92a877c..3898c8e5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14655&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14655&range=06-07 Stats: 678717 lines in 2808 files changed: 115107 ins; 487865 del; 75745 mod Patch: https://git.openjdk.org/jdk/pull/14655.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14655/head:pull/14655 PR: https://git.openjdk.org/jdk/pull/14655 From duke at openjdk.org Mon Nov 20 16:24:31 2023 From: duke at openjdk.org (Glavo) Date: Mon, 20 Nov 2023 16:24:31 GMT Subject: RFR: 8310837: Use ByteArrayLittleEndian in java.util.zip [v6] In-Reply-To: References: Message-ID: <3t7-samFVSG-gKrTp9-slrWbUqk0zCO_JzNJtlpPKXE=.5dbb8f64-f1b2-49d6-8f18-8f1451e77006@github.com> > 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 six additional commits since the last revision: - Merge branch 'openjdk:master' into zip-utils - Merge branch 'openjdk:master' into zip-utils - Merge branch 'openjdk:master' into zip-utils - Merge branch 'openjdk:master' into zip-utils - 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/efdc185b..72175ea1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14632&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14632&range=04-05 Stats: 678717 lines in 2808 files changed: 115107 ins; 487865 del; 75745 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 ihse at openjdk.org Mon Nov 20 16:41:39 2023 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 20 Nov 2023 16:41:39 GMT Subject: RFR: 8306055: Add a built-in Catalog to JDK XML module [v2] In-Reply-To: <6Z_nwDH5HB8r4MDO8PvBiakQhl8XZZl2bs4i_V_3miI=.9e811013-6c90-42c7-b8e8-e555f63cb167@github.com> References: <6Z_nwDH5HB8r4MDO8PvBiakQhl8XZZl2bs4i_V_3miI=.9e811013-6c90-42c7-b8e8-e555f63cb167@github.com> Message-ID: On Sun, 19 Nov 2023 23:36:16 GMT, Joe Wang wrote: >> Implement the built-in Catalog. > > Joe Wang has updated the pull request incrementally with one additional commit since the last revision: > > remove J2SE directory; add note explaining how DTDs are resolved Build change trivially okay ------------- Marked as reviewed by ihse (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16719#pullrequestreview-1740258583 From zjx001202 at gmail.com Mon Nov 20 16:44:54 2023 From: zjx001202 at gmail.com (Glavo) Date: Tue, 21 Nov 2023 00:44:54 +0800 Subject: Improve performance of decompressing jimage files Message-ID: I created a PR[1] to improve performance of decompressing jimage files, and got very good results. I used `jlink --compress 1 --add-modules jdk.compiler` to generate a javac runtime image and then used it to compile HelloWorld twenty times, this PR reduces the total time from 17830ms to 13598ms (31.12% faster). Can anyone review it? Thank you so much! Glavo [1]: https://github.com/openjdk/jdk/pull/16556 -------------- next part -------------- An HTML attachment was scrubbed... URL: From lancea at openjdk.org Mon Nov 20 16:51:27 2023 From: lancea at openjdk.org (Lance Andersen) Date: Mon, 20 Nov 2023 16:51:27 GMT Subject: RFR: 8306055: Add a built-in Catalog to JDK XML module [v2] In-Reply-To: <6Z_nwDH5HB8r4MDO8PvBiakQhl8XZZl2bs4i_V_3miI=.9e811013-6c90-42c7-b8e8-e555f63cb167@github.com> References: <6Z_nwDH5HB8r4MDO8PvBiakQhl8XZZl2bs4i_V_3miI=.9e811013-6c90-42c7-b8e8-e555f63cb167@github.com> Message-ID: On Sun, 19 Nov 2023 23:36:16 GMT, Joe Wang wrote: >> Implement the built-in Catalog. > > Joe Wang has updated the pull request incrementally with one additional commit since the last revision: > > remove J2SE directory; add note explaining how DTDs are resolved Hi Joe, Thank you for all of your hard work and perseverance to drive this project as I realize it was a lot of work and iterations based on feedback from the team. Overall looks good. A couple of minor comments below src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/XMLEntityManager.java line 1084: > 1082: String publicId, String systemId) { > 1083: InputSource is = resolveWithCatalog(cr, cFile, publicId, systemId); > 1084: // if (is != null && !is.isEmpty()) { Probably can delete this src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/XMLEntityManager.java line 1101: > 1099: return cr.resolveEntity(publicId, systemId); > 1100: } catch (CatalogException e) { > 1101: fErrorReporter.reportError(XMLMessageFormatter.XML_DOMAIN,"CatalogException", Alignment looks like it needs to be sanity checked here ------------- PR Review: https://git.openjdk.org/jdk/pull/16719#pullrequestreview-1739611943 PR Review Comment: https://git.openjdk.org/jdk/pull/16719#discussion_r1399080861 PR Review Comment: https://git.openjdk.org/jdk/pull/16719#discussion_r1399081930 From jbhateja at openjdk.org Mon Nov 20 17:01:23 2023 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Mon, 20 Nov 2023 17:01:23 GMT Subject: RFR: 8310159: Bulk copy with Unsafe::arrayCopy is slower compared to memcpy [v4] In-Reply-To: <9j8PVvxFrzJHxtdVNMgvDZHKsjuBVNhl8q45OenHOIA=.2ed68c3d-dddd-4aba-bfab-c4da636662cb@github.com> References: <9j8PVvxFrzJHxtdVNMgvDZHKsjuBVNhl8q45OenHOIA=.2ed68c3d-dddd-4aba-bfab-c4da636662cb@github.com> Message-ID: <-osTgmQ5tpMNOjVtR0ccmW4xOHifkFWHhApu3_Vkxw0=.627d5cfa-16da-4b1a-989c-26b6b9201570@github.com> On Thu, 16 Nov 2023 21:26:47 GMT, Steve Dohrmann wrote: >> Below is baseline data collected using a modified version of the java.lang.foreign.xor micro benchmark referenced by @mcimadamore in the bug report. I collected data on an Ubuntu 22.04 laptop with a Tigerlake i7-1185G7, which does support AVX512. >> >> Baseline data >> Benchmark (arrayKind) (sizeKind) Mode Cnt Score Error Units >> -------------------------------------------------------------------------------------- >> XorTest.copy ELEMENTS SMALL avgt 30 584737355.767 ? 60414308.540 ns/op >> XorTest.copy ELEMENTS MEDIUM avgt 30 272248995.683 ? 2924954.498 ns/op >> XorTest.copy ELEMENTS LARGE avgt 30 1019200210.900 ? 28334453.652 ns/op >> XorTest.copy REGION SMALL avgt 30 7399944.164 ? 216821.819 ns/op >> XorTest.copy REGION MEDIUM avgt 30 20591454.558 ? 147398.572 ns/op >> XorTest.copy REGION LARGE avgt 30 21649266.051 ? 179263.875 ns/op >> XorTest.copy CRITICAL SMALL avgt 30 51079.357 ? 542.482 ns/op >> XorTest.copy CRITICAL MEDIUM avgt 30 2496.961 ? 11.375 ns/op >> XorTest.copy CRITICAL LARGE avgt 30 515.454 ? 5.831 ns/op >> XorTest.copy FOREIGN SMALL avgt 30 7558432.075 ? 79489.276 ns/op >> XorTest.copy FOREIGN MEDIUM avgt 30 19730666.341 ? 500505.099 ns/op >> XorTest.copy FOREIGN LARGE avgt 30 34616758.085 ? 340300.726 ns/op >> XorTest.xor ELEMENTS SMALL avgt 30 219832692.489 ? 2329417.319 ns/op >> XorTest.xor ELEMENTS MEDIUM avgt 30 505138197.167 ? 3818334.424 ns/op >> XorTest.xor ELEMENTS LARGE avgt 30 1189608474.667 ? 5877981.900 ns/op >> XorTest.xor REGION SMALL avgt 30 64093872.804 ? 599704.491 ns/op >> XorTest.xor REGION MEDIUM avgt 30 81544576.454 ? 1406342.118 ns/op >> XorTest.xor REGION LARGE avgt 30 90091424.883 ? 775577.613 ns/op >> XorTest.xor CRITICAL SMALL avgt 30 57231375.744 ? 438223.342 ns/op >> XorTest.xor CRITICAL MEDIUM avgt 30 58583884.930 ? 375355.215 ns/op >> XorTest.xor CRITICAL LARGE avgt 30 60644832.949 ? 588120.738 ns/op >> XorTest.xor FOREIGN SMALL avgt 30 73868679.405 ? 819965.524 ns/op >> XorTest.xor FOREIGN MEDIUM avgt 30 88156275.944 ? 1051257.152 ns/op >> Xo... > > Steve Dohrmann has updated the pull request incrementally with one additional commit since the last revision: > > - fix whitespace error Hi @steveatgh , X86 code changes looks good to me. ------------- Marked as reviewed by jbhateja (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16575#pullrequestreview-1740295564 From bpb at openjdk.org Mon Nov 20 17:05:02 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Mon, 20 Nov 2023 17:05:02 GMT Subject: RFR: 8320348: test/jdk/java/io/File/GetAbsolutePath.windowsDriveRelative fails if working directory is not on drive C In-Reply-To: References: Message-ID: On Sat, 18 Nov 2023 06:50:32 GMT, Alan Bateman wrote: > I've renamed the JBS issue, hope that is okay. No problem: this is more apt. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16720#issuecomment-1819465944 From bpb at openjdk.org Mon Nov 20 17:05:00 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Mon, 20 Nov 2023 17:05:00 GMT Subject: RFR: 8320348: test/jdk/java/io/File/GetAbsolutePath.windowsDriveRelative fails if working directory is not on drive C In-Reply-To: References: Message-ID: On Mon, 20 Nov 2023 07:53:27 GMT, Matthias Baesken wrote: > After adding the patch, the errors seen before in our test runs are gone. Thanks for the patch ! Thanks for verifying! ------------- PR Comment: https://git.openjdk.org/jdk/pull/16720#issuecomment-1819464929 From asotona at openjdk.org Mon Nov 20 17:17:15 2023 From: asotona at openjdk.org (Adam Sotona) Date: Mon, 20 Nov 2023 17:17:15 GMT Subject: RFR: 8320222: Wrong bytecode accepted, and StackMap table generated [v2] In-Reply-To: References: Message-ID: > Stack map generator in ClassFile API performs only minimal checks in favour of performance. > However it led to situations where it generates invalid stack maps for corrupted code. > This patch adds basic checks of stack when two frames are merged and throws an exception in case of stack size or content mismatch. Generated or transformed code with inconsistent stack will fail on stack maps generation. > Relevant tests are added. > > Please review. > > Thanks, > Adam Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: changed StackMapGenerator::generatorError to return an exception instead of directly throw ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16685/files - new: https://git.openjdk.org/jdk/pull/16685/files/594e4797..3c3ac9be Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16685&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16685&range=00-01 Stats: 27 lines in 1 file changed: 0 ins; 0 del; 27 mod Patch: https://git.openjdk.org/jdk/pull/16685.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16685/head:pull/16685 PR: https://git.openjdk.org/jdk/pull/16685 From jlaskey at openjdk.org Mon Nov 20 17:17:19 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Mon, 20 Nov 2023 17:17:19 GMT Subject: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v21] In-Reply-To: References: Message-ID: On Mon, 20 Nov 2023 11:55:57 GMT, Maurizio Cimadamore wrote: >> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java line 464: >> >>> 462: } >>> 463: for (Symbol sym = s.owner; sym != null; sym = sym.owner) { >>> 464: if (sym.kind == TYP && sym.name == name && sym.name != names.error && >> >> Looks good! > > I recommend adding a test for this (if not already done) - checking cases like: > > // A.java > void m() { } > class A {} > > > but also where A is nested deeper: > > > // A.java > void m() { } > class B { > class A { } > } > > > And then also check that the test still works for other classes defined in the implicit unit: > > > // A.java > void m() { } > class B { > class B { } //error > } Added ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16461#discussion_r1399513053 From asotona at openjdk.org Mon Nov 20 17:17:16 2023 From: asotona at openjdk.org (Adam Sotona) Date: Mon, 20 Nov 2023 17:17:16 GMT Subject: RFR: 8320222: Wrong bytecode accepted, and StackMap table generated [v2] In-Reply-To: References: Message-ID: On Thu, 16 Nov 2023 11:25:07 GMT, Chen Liang wrote: >> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: >> >> changed StackMapGenerator::generatorError to return an exception instead of directly throw > > src/java.base/share/classes/jdk/internal/classfile/impl/StackMapGenerator.java line 1138: > >> 1136: } >> 1137: if (stackSize != target.stackSize) { >> 1138: generatorError("Stack size mismatch"); > > Just a side comment, `generatorError` should return a Throwable than throw directly, so when used as `throw generatorError()`, it is more clear that the code branch will terminate to javac. Good point, changed, thanks. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16685#discussion_r1399513530 From joehw at openjdk.org Mon Nov 20 17:46:53 2023 From: joehw at openjdk.org (Joe Wang) Date: Mon, 20 Nov 2023 17:46:53 GMT Subject: RFR: 8306055: Add a built-in Catalog to JDK XML module [v3] In-Reply-To: References: Message-ID: > Implement the built-in Catalog. Joe Wang has updated the pull request incrementally with one additional commit since the last revision: add a note; fix alignment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16719/files - new: https://git.openjdk.org/jdk/pull/16719/files/c1059a84..4914278a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16719&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16719&range=01-02 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/16719.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16719/head:pull/16719 PR: https://git.openjdk.org/jdk/pull/16719 From joehw at openjdk.org Mon Nov 20 17:46:56 2023 From: joehw at openjdk.org (Joe Wang) Date: Mon, 20 Nov 2023 17:46:56 GMT Subject: RFR: 8306055: Add a built-in Catalog to JDK XML module [v2] In-Reply-To: References: <6Z_nwDH5HB8r4MDO8PvBiakQhl8XZZl2bs4i_V_3miI=.9e811013-6c90-42c7-b8e8-e555f63cb167@github.com> Message-ID: <85Fu-McD_jFbchRNo-Y1JZqWpO8PQcBhb_NnzwL0wmU=.15c3400d-4657-4549-bd3e-e9954a5687eb@github.com> On Mon, 20 Nov 2023 16:38:54 GMT, Magnus Ihse Bursie wrote: > Build change trivially okay Thanks Magnus! ------------- PR Comment: https://git.openjdk.org/jdk/pull/16719#issuecomment-1819529895 From joehw at openjdk.org Mon Nov 20 17:52:53 2023 From: joehw at openjdk.org (Joe Wang) Date: Mon, 20 Nov 2023 17:52:53 GMT Subject: RFR: 8306055: Add a built-in Catalog to JDK XML module [v2] In-Reply-To: References: <6Z_nwDH5HB8r4MDO8PvBiakQhl8XZZl2bs4i_V_3miI=.9e811013-6c90-42c7-b8e8-e555f63cb167@github.com> Message-ID: On Mon, 20 Nov 2023 16:48:51 GMT, Lance Andersen wrote: > Hi Joe, > > Thank you for all of your hard work and perseverance to drive this project as I realize it was a lot of work and iterations based on feedback from the team. > > Overall looks good. A couple of minor comments below Thanks Lance for your help with all that iterations and feedbacks. I really appreciate it! I'm glad we were able to split the project into smaller/more manageable tasks. Changeset this size feels a lot easier to handle. > src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/XMLEntityManager.java line 1084: > >> 1082: String publicId, String systemId) { >> 1083: InputSource is = resolveWithCatalog(cr, cFile, publicId, systemId); >> 1084: // if (is != null && !is.isEmpty()) { > > Probably can delete this Changed to a note, as a reminder that empty source isn't considered resolved in this case. > src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/XMLEntityManager.java line 1101: > >> 1099: return cr.resolveEntity(publicId, systemId); >> 1100: } catch (CatalogException e) { >> 1101: fErrorReporter.reportError(XMLMessageFormatter.XML_DOMAIN,"CatalogException", > > Alignment looks like it needs to be sanity checked here Fixed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16719#issuecomment-1819538297 PR Review Comment: https://git.openjdk.org/jdk/pull/16719#discussion_r1399549063 PR Review Comment: https://git.openjdk.org/jdk/pull/16719#discussion_r1399549587 From lancea at openjdk.org Mon Nov 20 18:05:49 2023 From: lancea at openjdk.org (Lance Andersen) Date: Mon, 20 Nov 2023 18:05:49 GMT Subject: RFR: 8306055: Add a built-in Catalog to JDK XML module [v3] In-Reply-To: References: Message-ID: On Mon, 20 Nov 2023 17:46:53 GMT, Joe Wang wrote: >> Implement the built-in Catalog. > > Joe Wang has updated the pull request incrementally with one additional commit since the last revision: > > add a note; fix alignment Thank you Joe. All good by me and Congrats on moving this across the goal line ------------- Marked as reviewed by lancea (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16719#pullrequestreview-1740399188 From jlaskey at openjdk.org Mon Nov 20 18:24:16 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Mon, 20 Nov 2023 18:24:16 GMT Subject: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v29] In-Reply-To: References: Message-ID: > Address changes from JEP 445 to JEP 463. > > - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. > > - Don't mark class on read. > > - Remove reflection and annotation processing related to unnamed classes. > > - Simplify main method search. Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: Update findMainMethod as requested ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16461/files - new: https://git.openjdk.org/jdk/pull/16461/files/5542947a..abe35d53 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16461&range=28 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16461&range=27-28 Stats: 22 lines in 3 files changed: 8 ins; 0 del; 14 mod Patch: https://git.openjdk.org/jdk/pull/16461.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16461/head:pull/16461 PR: https://git.openjdk.org/jdk/pull/16461 From naoto at openjdk.org Mon Nov 20 18:24:45 2023 From: naoto at openjdk.org (Naoto Sato) Date: Mon, 20 Nov 2023 18:24:45 GMT Subject: RFR: 8317742: ISO Standard Date Format implementation consistency on DateTimeFormatter and String.format [v10] In-Reply-To: References: Message-ID: On Sat, 18 Nov 2023 17:38:48 GMT, Shaojin Wen wrote: >> j.u.Formatter now prints "%tF" (iso standard date) and the result is incorrect when processing year < 0 or year > 9999 > > Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: > > add JapaneseChronology testcase Looks good. Thanks for fixing the issue. Please change the copyright year from 2022 to 2023 in the test before integrating. ------------- Marked as reviewed by naoto (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16033#pullrequestreview-1740431565 From bpb at openjdk.org Mon Nov 20 18:25:48 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Mon, 20 Nov 2023 18:25:48 GMT Subject: Integrated: 8320348: test/jdk/java/io/File/GetAbsolutePath.windowsDriveRelative fails if working directory is not on drive C In-Reply-To: References: Message-ID: <55c8R7G4yfekPfssUaAYQ8Pmcn1r3JyZIEIcvKpd9LA=.7df6d183-f5e8-4e11-95a9-3bd3d754b45a@github.com> On Fri, 17 Nov 2023 21:51:06 GMT, Brian Burkhalter wrote: > The method `windowsDriveRelative` of the test `java/io/File/GetAbsolutePath` was incorrectly translated from its previous version to the current JUnit 5 version. This pull request has now been integrated. Changeset: 32098ce3 Author: Brian Burkhalter URL: https://git.openjdk.org/jdk/commit/32098ce33cfd38e115c1e13d11c72815f7c2d4cd Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 mod 8320348: test/jdk/java/io/File/GetAbsolutePath.windowsDriveRelative fails if working directory is not on drive C Reviewed-by: alanb, mbaesken ------------- PR: https://git.openjdk.org/jdk/pull/16720 From jlaskey at openjdk.org Mon Nov 20 18:36:44 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Mon, 20 Nov 2023 18:36:44 GMT Subject: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v26] In-Reply-To: References: Message-ID: On Mon, 20 Nov 2023 13:56:13 GMT, Christian Stein wrote: >> src/java.base/share/classes/java/lang/Class.java line 4839: >> >>> 4837: @PreviewFeature(feature=PreviewFeature.Feature.IMPLICIT_CLASSES) >>> 4838: @CallerSensitive >>> 4839: public Method getMainMethod() { >> >> This is a new addition in the last few days. It's somewhat surprising as the launch protocol has never really surfaced in the API, there's nothing to identify the main class for example. I'm in two minds on surfacing this but it does make the java launcher code much simpler. >> >> Class.getMethod/getMethods return public methods, the proposed getMainMethod may return a public or non-public method and may walk the class hierarchy. So I'm not sure about the naming, it feels more like a findMainMethod to emphasize the search or just mainMethod. >> >> The javadoc probably needs to be fleshed out a bit more to specify how the main method is found. It currently says "be declared this class's hierarchy" (typo) but it has to say more and make it clear that it may return a Method with a declared class that may be a superclass. >> >> "(@jls 8.4.2)", I assume that should be "{@jls 8.4.2}". >> >> The return description says "the candidate main method". This begs the question if there are other candidates, how do I find them? >> >> The SM permission check looks right, it has to be the same as getDeclaredMethod. > >> [...] it does make the java launcher code much simpler. > > Yes. That's a very nice effect of surfacing the launch protocol directyl in `java.lang.Class` > >> So I'm not sure about the naming, it feels more like a `findMainMethod` to emphasize the search or just `mainMethod`. > > +1 for `findMainMethod`, and also an explicit `Optional` as the return type. > > Or `Optional mainMethod()` similar to [ModuleDescriptor::mainClass](https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/lang/module/ModuleDescriptor.html#mainClass()) Updated. Optional is stylizing preference. Since this method is used frequently (almost always) at startup, loading extra classes should probably be avoided. It's not hard to simply `Optional.ofNullable(cls.findMainMethod())`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16461#discussion_r1399597600 From prr at openjdk.org Mon Nov 20 18:40:33 2023 From: prr at openjdk.org (Phil Race) Date: Mon, 20 Nov 2023 18:40:33 GMT Subject: RFR: 8318364: Add an FFM-based implementation of harfbuzz OpenType layout [v7] In-Reply-To: References: Message-ID: <375g5CqMLrLiy3qX7ntQIUG4Rmomyqo9xrz8NWOAWYU=.c92ad36a-a12e-412b-817b-c10b9640d53f@github.com> > 8318364: Add an FFM-based implementation of harfbuzz OpenType layout Phil Race has updated the pull request incrementally with one additional commit since the last revision: 8318364 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15476/files - new: https://git.openjdk.org/jdk/pull/15476/files/ee60f7e9..e435902d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15476&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15476&range=05-06 Stats: 8 lines in 4 files changed: 3 ins; 1 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/15476.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15476/head:pull/15476 PR: https://git.openjdk.org/jdk/pull/15476 From prr at openjdk.org Mon Nov 20 18:40:41 2023 From: prr at openjdk.org (Phil Race) Date: Mon, 20 Nov 2023 18:40:41 GMT Subject: RFR: 8318364: Add an FFM-based implementation of harfbuzz OpenType layout [v4] In-Reply-To: <8tu4D5zX989IFr6DuSuReyYGd9Z-fOcmXcgePojFmvQ=.4dfbd237-f683-44fa-930d-fa89999b3242@github.com> References: <8tu4D5zX989IFr6DuSuReyYGd9Z-fOcmXcgePojFmvQ=.4dfbd237-f683-44fa-930d-fa89999b3242@github.com> Message-ID: On Thu, 16 Nov 2023 13:48:38 GMT, Prasanta Sadhukhan wrote: >> Phil Race has updated the pull request incrementally with one additional commit since the last revision: >> >> indentation > > src/java.desktop/share/classes/sun/font/HBShaper.java line 628: > >> 626: MemorySegment glyphInfoArr = glyphInfo.reinterpret(glyphInfoSize); >> 627: >> 628: for (int i=0; i > Spacing between operators fixed > src/java.desktop/share/classes/sun/font/HBShaper.java line 658: > >> 656: startPt.x = advX; >> 657: startPt.y = advY; >> 658: startPt.x = advX; > > duplicate assignment of startPt.x to advX... fixed > src/java.desktop/share/classes/sun/font/SunLayoutEngine.java line 167: > >> 165: } >> 166: >> 167: static boolean useFFM = true; > > So, we want to enable FFM by default? yes > src/java.desktop/share/classes/sun/font/SunLayoutEngine.java line 184: > >> 182: FontStrike strike = font.getStrike(desc); >> 183: if (useFFM) { >> 184: java.lang.foreign.MemorySegment face = HBShaper.getFace(font); > > Guess import at start will be more nicer... ok .. although I do sometimes do this pattern when there's only one usage in the file. > src/java.desktop/share/native/libfontmanager/HBShaper_Panama.c line 141: > >> 139: hb_buffer_destroy (buffer); >> 140: hb_font_destroy(hbfont); >> 141: if (features != NULL) free(features); > > Guess coding style warrants braces { and next statement in separate line... fixed > src/java.desktop/share/native/libfontmanager/hb-jdk-font-p.cc line 238: > >> 236: HBFloatToFixed(ptSize*devScale), >> 237: HBFloatToFixed(ptSize*devScale)); >> 238: return font; > > indentation is off.. fixed > test/jdk/java/awt/font/GlyphVector/LayoutCompatTest.java line 29: > >> 27: /* >> 28: @test >> 29: @summary verify JNI and FFM harfbuzz OpenType layout implementations are equivalent. > > bug id is missing Because there isn't a "bug". It is just a test for new functionality. > test/jdk/java/awt/font/GlyphVector/LayoutCompatTest.java line 45: > >> 43: public class LayoutCompatTest { >> 44: >> 45: static String jni = "jni.txt"; > > Seems test is failing without fix with Exception in jtreg > java.io.FileNotFoundException: jni.txt (The system cannot find the file specified) > > Also in standalone mode. I was expecting it will fail with RuntimeException "files differ byte offset" I'm not sure why it matters what this test does in a JDK without the fix, although logically, since the new system property isn't known, both cases would end up using JNI, and I'd expect the test to pass. I am not sure why you say it should fail. And I can't reproduce your first problem, I ran this test in jtreg on an unmodified JDK22 and it passed, as I expected, for the reason given above. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15476#discussion_r1399596923 PR Review Comment: https://git.openjdk.org/jdk/pull/15476#discussion_r1399597001 PR Review Comment: https://git.openjdk.org/jdk/pull/15476#discussion_r1399597224 PR Review Comment: https://git.openjdk.org/jdk/pull/15476#discussion_r1399597892 PR Review Comment: https://git.openjdk.org/jdk/pull/15476#discussion_r1399598026 PR Review Comment: https://git.openjdk.org/jdk/pull/15476#discussion_r1399598126 PR Review Comment: https://git.openjdk.org/jdk/pull/15476#discussion_r1399598208 PR Review Comment: https://git.openjdk.org/jdk/pull/15476#discussion_r1399596012 From javalists at cbfiddle.com Mon Nov 20 18:50:16 2023 From: javalists at cbfiddle.com (Alan Snyder) Date: Mon, 20 Nov 2023 10:50:16 -0800 Subject: Automatic modules and jpackage References: Message-ID: <0CA01AC2-56FC-4558-940A-04601B1395D1@cbfiddle.com> Adding core-iibs-dev? This suggestion sounds useful to me. I have considered modularizing one particular library, but have chosen not to, in part because of the issue raised here. Alan > Begin forwarded message: > > From: Mark Raynsford > Date: November 11, 2023 at 1:18:21?PM PST > To: jigsaw-dev at openjdk.org > > Hello! > > I have multiple applications that are modularized; all of the > application modules are named modules and make heavy use of services. > However, I do have many (transitive) dependencies that are only > automatic modules (using Automatic-Module-Name declarations in the > manifests). > > I want to use jpackage to produce platform-specific application > distributions, but the automatic modules are causing me problems. > Essentially, as far as I can tell, there are exactly two approaches > that jpackage will take: > > 1. Put all of your application jars inside an app directory inside > the app image, and configure the runtime such that all of those > jars end up on the class path. > > 2. Take all of the application modules and compile them into the > resulting app image runtime using jlink. > > It would _really_ help myself (and possibly others, given that I've > never seen a Java application consisting of 100% named modules) if > there was a third option: > > 3. Take all of the application jars and place them inside an app > directory inside the app image, and configure the runtime such > that all of those jars _end up on the module path_. > > Effectively, I'd like a runtime that behaves as if "java -p app" > had been specified on the command-line. I don't care about minimizing > the size of the runtime with jlink by discarding unused modules. I > _do_ care about having a nice double-clickable exe on Windows that > has a nice icon, identifies itself properly in Process Explorer, and > has all of my jars on the module path so that the services work. > > Is anything like this on the horizon? I believe I've published more > JPMS modules than any other individual on the planet, but I've never > been able to make any use of jlink due to the entire world not having > been modularized. I don't want to be rewriting my dependencies with > Moditect and other tools: My dependencies already work correctly on the > module path, I just can't seem to get them into anything jpackage will > produce! > > -- > Mark Raynsford | https://www.io7m.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From asotona at openjdk.org Mon Nov 20 19:13:51 2023 From: asotona at openjdk.org (Adam Sotona) Date: Mon, 20 Nov 2023 19:13:51 GMT Subject: RFR: 8308753: Class-File API transition to Preview [v28] 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: added new package-info snippets and fixed ClassFile::parse throws javadoc description ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15706/files - new: https://git.openjdk.org/jdk/pull/15706/files/8c80afff..3860e6c9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15706&range=27 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15706&range=26-27 Stats: 43 lines in 3 files changed: 36 ins; 0 del; 7 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 jlu at openjdk.org Mon Nov 20 19:15:18 2023 From: jlu at openjdk.org (Justin Lu) Date: Mon, 20 Nov 2023 19:15:18 GMT Subject: RFR: JDK-8319569: Several java/util tests should be updated to accept VM flags [v3] In-Reply-To: References: Message-ID: > Please review this PR which allows these _j.util_ tests to launch new JVM processes with VM flags, > > This is primarily done using by switching to `ProcessTools::createTestJavaProcessBuilder`. Justin Lu has updated the pull request incrementally with one additional commit since the last revision: Pass test.java.opts to PropertiesTest.sh ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16705/files - new: https://git.openjdk.org/jdk/pull/16705/files/30c735d5..cb144025 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16705&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16705&range=01-02 Stats: 6 lines in 1 file changed: 0 ins; 1 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/16705.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16705/head:pull/16705 PR: https://git.openjdk.org/jdk/pull/16705 From jlu at openjdk.org Mon Nov 20 19:15:21 2023 From: jlu at openjdk.org (Justin Lu) Date: Mon, 20 Nov 2023 19:15:21 GMT Subject: RFR: JDK-8319569: Several java/util tests should be updated to accept VM flags [v3] In-Reply-To: <3eJZlzFtYI1_j5l2ZCccMC-4iXFFBAKZZxRM3SR9YuE=.a5477211-fc86-420c-85b8-750718614b4d@github.com> References: <3eJZlzFtYI1_j5l2ZCccMC-4iXFFBAKZZxRM3SR9YuE=.a5477211-fc86-420c-85b8-750718614b4d@github.com> Message-ID: On Fri, 17 Nov 2023 20:17:28 GMT, Justin Lu wrote: >> test/jdk/java/util/Currency/PropertiesTest.sh line 30: >> >>> 28: # @summary tests the capability of replacing the currency data with user >>> 29: # specified currency properties file >>> 30: # @requires vm.flagless >> >> Does this actually do anything? Since it is a shell script, it does not call any `ProcessBuilder` methods. In fact, the script includes `${TESTVMOPTS}` on launching the test java process correctly. > > IIUC, using `@requires vm.flagless` simply signifies that any JVMs launched within the test do not support VM flags, (regardless if it was launched from ProcessBuilder). > > However, it is odd that this test was flagged since it does pass `${TESTVMOPTS}` to `run()` like you stated. > > Perhaps @lmesnik has further understanding of what to do here? _PropertiesTest.sh_ needs to pass both test.vm.opts **and** test.java.opts. Added `${TESTJAVAOPTS}` and unmarked as `@requires vm.flagless` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16705#discussion_r1399629617 From rriggs at openjdk.org Mon Nov 20 19:23:35 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Mon, 20 Nov 2023 19:23:35 GMT Subject: RFR: 8311906: Improve robustness of String constructors with mutable array inputs [v9] In-Reply-To: <6SKlGLh5MmxoEx07wHCCUc8KWbbhcspLJmcc1uxQ_FI=.ca33bfb4-fa5c-45f0-b49f-ee6c5c6b68b4@github.com> References: <6SKlGLh5MmxoEx07wHCCUc8KWbbhcspLJmcc1uxQ_FI=.ca33bfb4-fa5c-45f0-b49f-ee6c5c6b68b4@github.com> Message-ID: > Strings, after construction, are immutable but may be constructed from mutable arrays of bytes, characters, or integers. > The string constructors should guard against the effects of mutating the arrays during construction that might invalidate internal invariants for the correct behavior of operations on the resulting strings. In particular, a number of operations have optimizations for operations on pairs of latin1 strings and pairs of non-latin1 strings, while operations between latin1 and non-latin1 strings use a more general implementation. > > The changes include: > > - Adding a warning to each constructor with an array as an argument to indicate that the results are indeterminate > if the input array is modified before the constructor returns. > The resulting string may contain any combination of characters sampled from the input array. > > - Ensure that strings that are represented as non-latin1 contain at least one non-latin1 character. > For latin1 inputs, whether the arrays contain ASCII, ISO-8859-1, UTF8, or another encoding decoded to latin1 the scanning and compression is unchanged. > If a non-latin1 character is found, the string is represented as non-latin1 with the added verification that a non-latin1 character is present at the same index. > If that character is found to be latin1, then the input array has been modified and the result of the scan may be incorrect. > Though a ConcurrentModificationException could be thrown, the risk to an existing application of an unexpected exception should be avoided. > Instead, the non-latin1 copy of the input is re-scanned and compressed; that scan determines whether the latin1 or the non-latin1 representation is returned. > > - The methods that scan for non-latin1 characters and their intrinsic implementations are updated to return the index of the non-latin1 character. > > - String construction from StringBuilder and CharSequence must also be guarded as their contents may be modified during construction. Roger Riggs has updated the pull request incrementally with two additional commits since the last revision: - Normalize the spec for undefined behavior of String constructors, StringBuilder, and Appendable methods in the case where the input arguments are modified during construction or a StringBuilder or Appendable method call. - Speed up getting the coder from a byte array returned from StringUTF16.compress and normalize calling sequence ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16425/files - new: https://git.openjdk.org/jdk/pull/16425/files/3e3607e9..7924118b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16425&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16425&range=07-08 Stats: 73 lines in 4 files changed: 15 ins; 0 del; 58 mod Patch: https://git.openjdk.org/jdk/pull/16425.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16425/head:pull/16425 PR: https://git.openjdk.org/jdk/pull/16425 From asotona at openjdk.org Mon Nov 20 19:27:01 2023 From: asotona at openjdk.org (Adam Sotona) Date: Mon, 20 Nov 2023 19:27:01 GMT Subject: RFR: 8308753: Class-File API transition to Preview [v29] In-Reply-To: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com> References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com> Message-ID: > Classfile API is an internal library under package `jdk.internal.classfile`?in JDK 21. > This pull request turns the Classfile API into a preview feature and moves it into `java.lang.classfile`. > It repackages all uses across JDK and tests and adds lots of missing Javadoc. > > This PR goes in sync with?[JDK-8308754](https://bugs.openjdk.org/browse/JDK-8308754): Class-File API (Preview) (CSR) > and?[JDK-8280389](https://bugs.openjdk.org/browse/JDK-8280389): Class-File API (Preview) (JEP). > > Online javadoc is available at:? > https://cr.openjdk.org/~asotona/JDK-8308753-preview/api/java.base/java/lang/classfile/package-summary.html > > In addition to the primary transition to preview, this pull request also includes: > - All?Classfile*?classes ranamed to?ClassFile*?(based on JEP discussion). > - A new preview feature, `CLASSFILE_API`, has been added. > - Buildsystem tool required a little patch to support annotated modules. > - All JDK modules using the Classfile API are newly participating in the preview. > - All tests that use the Classfile API now have preview enabled. > - A few Javac tests not allowing preview have been partially reverted; their conversion can be re-applied when the Classfile API leaves preview mode. > > Despite the number of affected files, this pull request is relatively straight-forward. The preview version of the Classfile API is based on the internal version of the library from the JDK master branch, and there are no API features added. > > Please review this pull request to help the Classfile API turn into a preview. > > Any comments are welcome. > > Thanks, > Adam Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 365 commits: - Merge branch 'master' into JDK-8308753-preview # Conflicts: # test/langtools/tools/javac/7199823/InnerClassCannotBeVerified.java - added new package-info snippets and fixed ClassFile::parse throws javadoc description - fixed lambda tests - Merge branch 'master' into JDK-8308753-preview - fixed SignaturesTest - fixed condy tests - Merge branch 'master' into JDK-8308753-preview - Merge branch 'master' into JDK-8308753-preview # Conflicts: # test/jdk/tools/lib/tests/JImageValidator.java - fixed jdk.jfr - Merge branch 'master' into JDK-8308753-preview # Conflicts: # src/java.base/share/classes/module-info.java - ... and 355 more: https://git.openjdk.org/jdk/compare/6b96bb64...46ad6906 ------------- Changes: https://git.openjdk.org/jdk/pull/15706/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15706&range=28 Stats: 32339 lines in 784 files changed: 14659 ins; 14109 del; 3571 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 rriggs at openjdk.org Mon Nov 20 19:35:27 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Mon, 20 Nov 2023 19:35:27 GMT Subject: RFR: 8311906: Improve robustness of String constructors with mutable array inputs [v10] In-Reply-To: <6SKlGLh5MmxoEx07wHCCUc8KWbbhcspLJmcc1uxQ_FI=.ca33bfb4-fa5c-45f0-b49f-ee6c5c6b68b4@github.com> References: <6SKlGLh5MmxoEx07wHCCUc8KWbbhcspLJmcc1uxQ_FI=.ca33bfb4-fa5c-45f0-b49f-ee6c5c6b68b4@github.com> Message-ID: > Strings, after construction, are immutable but may be constructed from mutable arrays of bytes, characters, or integers. > The string constructors should guard against the effects of mutating the arrays during construction that might invalidate internal invariants for the correct behavior of operations on the resulting strings. In particular, a number of operations have optimizations for operations on pairs of latin1 strings and pairs of non-latin1 strings, while operations between latin1 and non-latin1 strings use a more general implementation. > > The changes include: > > - Adding a warning to each constructor with an array as an argument to indicate that the results are indeterminate > if the input array is modified before the constructor returns. > The resulting string may contain any combination of characters sampled from the input array. > > - Ensure that strings that are represented as non-latin1 contain at least one non-latin1 character. > For latin1 inputs, whether the arrays contain ASCII, ISO-8859-1, UTF8, or another encoding decoded to latin1 the scanning and compression is unchanged. > If a non-latin1 character is found, the string is represented as non-latin1 with the added verification that a non-latin1 character is present at the same index. > If that character is found to be latin1, then the input array has been modified and the result of the scan may be incorrect. > Though a ConcurrentModificationException could be thrown, the risk to an existing application of an unexpected exception should be avoided. > Instead, the non-latin1 copy of the input is re-scanned and compressed; that scan determines whether the latin1 or the non-latin1 representation is returned. > > - The methods that scan for non-latin1 characters and their intrinsic implementations are updated to return the index of the non-latin1 character. > > - String construction from StringBuilder and CharSequence must also be guarded as their contents may be modified during construction. Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: undo noise chars ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16425/files - new: https://git.openjdk.org/jdk/pull/16425/files/7924118b..04d58779 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16425&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16425&range=08-09 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/16425.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16425/head:pull/16425 PR: https://git.openjdk.org/jdk/pull/16425 From duke at openjdk.org Mon Nov 20 20:07:25 2023 From: duke at openjdk.org (Shaojin Wen) Date: Mon, 20 Nov 2023 20:07:25 GMT Subject: RFR: 8317742: ISO Standard Date Format implementation consistency on DateTimeFormatter and String.format [v11] In-Reply-To: References: Message-ID: > j.u.Formatter now prints "%tF" (iso standard date) and the result is incorrect when processing year < 0 or year > 9999 Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: update copyright ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16033/files - new: https://git.openjdk.org/jdk/pull/16033/files/0fa1f882..fec8f5e8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16033&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16033&range=09-10 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/16033.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16033/head:pull/16033 PR: https://git.openjdk.org/jdk/pull/16033 From jlaskey at openjdk.org Mon Nov 20 20:45:22 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Mon, 20 Nov 2023 20:45:22 GMT Subject: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v30] In-Reply-To: References: Message-ID: > Address changes from JEP 445 to JEP 463. > > - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. > > - Don't mark class on read. > > - Remove reflection and annotation processing related to unnamed classes. > > - Simplify main method search. Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: Update test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16461/files - new: https://git.openjdk.org/jdk/pull/16461/files/abe35d53..b14c6a54 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16461&range=29 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16461&range=28-29 Stats: 6 lines in 1 file changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/16461.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16461/head:pull/16461 PR: https://git.openjdk.org/jdk/pull/16461 From rgiulietti at openjdk.org Mon Nov 20 22:32:15 2023 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Mon, 20 Nov 2023 22:32:15 GMT Subject: RFR: 8311906: Improve robustness of String constructors with mutable array inputs [v10] In-Reply-To: References: <6SKlGLh5MmxoEx07wHCCUc8KWbbhcspLJmcc1uxQ_FI=.ca33bfb4-fa5c-45f0-b49f-ee6c5c6b68b4@github.com> Message-ID: On Mon, 20 Nov 2023 19:35:27 GMT, Roger Riggs wrote: >> Strings, after construction, are immutable but may be constructed from mutable arrays of bytes, characters, or integers. >> The string constructors should guard against the effects of mutating the arrays during construction that might invalidate internal invariants for the correct behavior of operations on the resulting strings. In particular, a number of operations have optimizations for operations on pairs of latin1 strings and pairs of non-latin1 strings, while operations between latin1 and non-latin1 strings use a more general implementation. >> >> The changes include: >> >> - Adding a warning to each constructor with an array as an argument to indicate that the results are indeterminate >> if the input array is modified before the constructor returns. >> The resulting string may contain any combination of characters sampled from the input array. >> >> - Ensure that strings that are represented as non-latin1 contain at least one non-latin1 character. >> For latin1 inputs, whether the arrays contain ASCII, ISO-8859-1, UTF8, or another encoding decoded to latin1 the scanning and compression is unchanged. >> If a non-latin1 character is found, the string is represented as non-latin1 with the added verification that a non-latin1 character is present at the same index. >> If that character is found to be latin1, then the input array has been modified and the result of the scan may be incorrect. >> Though a ConcurrentModificationException could be thrown, the risk to an existing application of an unexpected exception should be avoided. >> Instead, the non-latin1 copy of the input is re-scanned and compressed; that scan determines whether the latin1 or the non-latin1 representation is returned. >> >> - The methods that scan for non-latin1 characters and their intrinsic implementations are updated to return the index of the non-latin1 character. >> >> - String construction from StringBuilder and CharSequence must also be guarded as their contents may be modified during construction. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > undo noise chars Looks good. Maybe use `StringUTF16.coderFromArrayLen()` where suggested in the comments before integrating. src/java.base/share/classes/java/lang/String.java line 359: > 357: if (COMPACT_STRINGS) { > 358: byte[] val = StringUTF16.compress(codePoints, offset, count); > 359: this.coder = (val.length == count) ? LATIN1 : UTF16; Maybe worth using `StringUTF16.coderFromArrayLen()` even here. src/java.base/share/classes/java/lang/String.java line 4845: > 4843: if (COMPACT_STRINGS && asb.maybeLatin1) { > 4844: this.value = StringUTF16.compress(val, 0, length); > 4845: this.coder = (this.value.length == length) ? LATIN1 : UTF16; `StringUTF16.coderFromArrayLen()`? ------------- Marked as reviewed by rgiulietti (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16425#pullrequestreview-1740808291 PR Review Comment: https://git.openjdk.org/jdk/pull/16425#discussion_r1399824712 PR Review Comment: https://git.openjdk.org/jdk/pull/16425#discussion_r1399825374 From naoto at openjdk.org Mon Nov 20 22:43:08 2023 From: naoto at openjdk.org (Naoto Sato) Date: Mon, 20 Nov 2023 22:43:08 GMT Subject: RFR: JDK-8319569: Several java/util tests should be updated to accept VM flags [v3] In-Reply-To: References: Message-ID: <-6v0PdQaHcIUYQS_usNrlAkFyUcW6mzyIakiGBGthk8=.ddeeb5ab-44bc-42cc-bd60-23337bf2b307@github.com> On Mon, 20 Nov 2023 19:15:18 GMT, Justin Lu wrote: >> Please review this PR which allows these _j.util_ tests to launch new JVM processes with VM flags, >> >> This is primarily done using by switching to `ProcessTools::createTestJavaProcessBuilder`. > > Justin Lu has updated the pull request incrementally with one additional commit since the last revision: > > Pass test.java.opts to PropertiesTest.sh LGTM. It is out of this fix's scope, but `PropertiesTest.sh` may better be converted into a Java test case. ------------- Marked as reviewed by naoto (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16705#pullrequestreview-1740822747 From duke at openjdk.org Mon Nov 20 22:50:19 2023 From: duke at openjdk.org (Steve Dohrmann) Date: Mon, 20 Nov 2023 22:50:19 GMT Subject: RFR: 8310159: Bulk copy with Unsafe::arrayCopy is slower compared to memcpy [v5] In-Reply-To: References: Message-ID: > Below is baseline data collected using a modified version of the java.lang.foreign.xor micro benchmark referenced by @mcimadamore in the bug report. I collected data on an Ubuntu 22.04 laptop with a Tigerlake i7-1185G7, which does support AVX512. > > Baseline data > Benchmark (arrayKind) (sizeKind) Mode Cnt Score Error Units > -------------------------------------------------------------------------------------- > XorTest.copy ELEMENTS SMALL avgt 30 584737355.767 ? 60414308.540 ns/op > XorTest.copy ELEMENTS MEDIUM avgt 30 272248995.683 ? 2924954.498 ns/op > XorTest.copy ELEMENTS LARGE avgt 30 1019200210.900 ? 28334453.652 ns/op > XorTest.copy REGION SMALL avgt 30 7399944.164 ? 216821.819 ns/op > XorTest.copy REGION MEDIUM avgt 30 20591454.558 ? 147398.572 ns/op > XorTest.copy REGION LARGE avgt 30 21649266.051 ? 179263.875 ns/op > XorTest.copy CRITICAL SMALL avgt 30 51079.357 ? 542.482 ns/op > XorTest.copy CRITICAL MEDIUM avgt 30 2496.961 ? 11.375 ns/op > XorTest.copy CRITICAL LARGE avgt 30 515.454 ? 5.831 ns/op > XorTest.copy FOREIGN SMALL avgt 30 7558432.075 ? 79489.276 ns/op > XorTest.copy FOREIGN MEDIUM avgt 30 19730666.341 ? 500505.099 ns/op > XorTest.copy FOREIGN LARGE avgt 30 34616758.085 ? 340300.726 ns/op > XorTest.xor ELEMENTS SMALL avgt 30 219832692.489 ? 2329417.319 ns/op > XorTest.xor ELEMENTS MEDIUM avgt 30 505138197.167 ? 3818334.424 ns/op > XorTest.xor ELEMENTS LARGE avgt 30 1189608474.667 ? 5877981.900 ns/op > XorTest.xor REGION SMALL avgt 30 64093872.804 ? 599704.491 ns/op > XorTest.xor REGION MEDIUM avgt 30 81544576.454 ? 1406342.118 ns/op > XorTest.xor REGION LARGE avgt 30 90091424.883 ? 775577.613 ns/op > XorTest.xor CRITICAL SMALL avgt 30 57231375.744 ? 438223.342 ns/op > XorTest.xor CRITICAL MEDIUM avgt 30 58583884.930 ? 375355.215 ns/op > XorTest.xor CRITICAL LARGE avgt 30 60644832.949 ? 588120.738 ns/op > XorTest.xor FOREIGN SMALL avgt 30 73868679.405 ? 819965.524 ns/op > XorTest.xor FOREIGN MEDIUM avgt 30 88156275.944 ? 1051257.152 ns/op > XorTest.xor FOREIGN LARGE avgt 30 123115513... Steve Dohrmann has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits: - Merge branch 'master' into memcpy - Update full name Previous commit (fcbbc0d7880) added org.openjdk.bench.java.lang.ArrayCopyAlignedLarge benchmark - - remerge upstream master - remove ::copy test from XorTest - Merge branch 'master' into memcpy - - fix whitespace error - Merge branch 'master' of https://git.openjdk.org/jdk into memcpy - - bug fix: only generate / use large copy code if MaxVectorSize == 64 - - fix whitespace issues - fix xor test foreign impl constructor signature - - initial commit -- optimize large array cases in StubGenerator::generate_disjoint_copy_avx3_masked - add src address prefetches - switch to non-temporal writes - added modified jmh benchmark based on xor benchmark from Maurizio Cimadamore ------------- Changes: https://git.openjdk.org/jdk/pull/16575/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16575&range=04 Stats: 264 lines in 5 files changed: 264 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/16575.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16575/head:pull/16575 PR: https://git.openjdk.org/jdk/pull/16575 From duke at openjdk.org Tue Nov 21 00:12:10 2023 From: duke at openjdk.org (Steve Dohrmann) Date: Tue, 21 Nov 2023 00:12:10 GMT Subject: RFR: 8310159: Bulk copy with Unsafe::arrayCopy is slower compared to memcpy [v5] In-Reply-To: References: Message-ID: On Mon, 20 Nov 2023 22:50:19 GMT, Steve Dohrmann wrote: >> Update: the XorTest::xor results shown in this message used test code from PR commit 7cc272e862791 which was based on Maurizio Cimadamore's commit a788f066af17. The XorTest has since been updated and XorTest::copy is no longer needed and has been removed from this pull request. See comment [here](https://github.com/openjdk/jdk/pull/16575#issuecomment-1820006548) for updated performance data. >> >> Below is baseline data collected using a modified version of the java.lang.foreign.xor micro benchmark referenced by @mcimadamore in the bug report. I collected data on an Ubuntu 22.04 laptop with a Tigerlake i7-1185G7, which does support AVX512. >> >> Baseline data >> Benchmark (arrayKind) (sizeKind) Mode Cnt Score Error Units >> -------------------------------------------------------------------------------------- >> XorTest.copy ELEMENTS SMALL avgt 30 584737355.767 ? 60414308.540 ns/op >> XorTest.copy ELEMENTS MEDIUM avgt 30 272248995.683 ? 2924954.498 ns/op >> XorTest.copy ELEMENTS LARGE avgt 30 1019200210.900 ? 28334453.652 ns/op >> XorTest.copy REGION SMALL avgt 30 7399944.164 ? 216821.819 ns/op >> XorTest.copy REGION MEDIUM avgt 30 20591454.558 ? 147398.572 ns/op >> XorTest.copy REGION LARGE avgt 30 21649266.051 ? 179263.875 ns/op >> XorTest.copy CRITICAL SMALL avgt 30 51079.357 ? 542.482 ns/op >> XorTest.copy CRITICAL MEDIUM avgt 30 2496.961 ? 11.375 ns/op >> XorTest.copy CRITICAL LARGE avgt 30 515.454 ? 5.831 ns/op >> XorTest.copy FOREIGN SMALL avgt 30 7558432.075 ? 79489.276 ns/op >> XorTest.copy FOREIGN MEDIUM avgt 30 19730666.341 ? 500505.099 ns/op >> XorTest.copy FOREIGN LARGE avgt 30 34616758.085 ? 340300.726 ns/op >> XorTest.xor ELEMENTS SMALL avgt 30 219832692.489 ? 2329417.319 ns/op >> XorTest.xor ELEMENTS MEDIUM avgt 30 505138197.167 ? 3818334.424 ns/op >> XorTest.xor ELEMENTS LARGE avgt 30 1189608474.667 ? 5877981.900 ns/op >> XorTest.xor REGION SMALL avgt 30 64093872.804 ? 599704.491 ns/op >> XorTest.xor REGION MEDIUM avgt 30 81544576.454 ? 1406342.118 ns/op >> XorTest.xor REGION LARGE avgt 30 90091424.883 ? 775577.613 ns/op >> XorTest.xor CRITICAL SMALL avgt ... > > Steve Dohrmann has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits: > > - Merge branch 'master' into memcpy > - Update full name > Previous commit (fcbbc0d7880) added org.openjdk.bench.java.lang.ArrayCopyAlignedLarge benchmark > - - remerge upstream master > - remove ::copy test from XorTest > - Merge branch 'master' into memcpy > - - fix whitespace error > - Merge branch 'master' of https://git.openjdk.org/jdk into memcpy > - - bug fix: only generate / use large copy code if MaxVectorSize == 64 > - - fix whitespace issues > - fix xor test foreign impl constructor signature > - - initial commit -- optimize large array cases in StubGenerator::generate_disjoint_copy_avx3_masked > - add src address prefetches > - switch to non-temporal writes > - added modified jmh benchmark based on xor benchmark from Maurizio Cimadamore The micros:java.lang.foreign.xor.XorTest::xor benchmark results shown in the introductory comment above XorTest code from PR commit 7cc272e86279 which was based on Maurizio Cimadamore's commit a788f066af17. The XorTest has since been updated and the XorTest::copy is no longer needed and has been removed from this pull request. Performance can be evaluated using both the new XorTest and a new org.openjdk.bench.java.lang.ArrayCopyAlignedLarge benchmark added to this PR. Results from these two benchmarks are show below: In the ArrayCopyAlignedLarge.testByte benchmark below, the PR code is active in sizes 5MB and 10MB. // Baseline Benchmark (length) Mode Cnt Score Error Units ArrayCopyAlignedLarge.testByte 100000 avgt 15 2434.515 ? 11.526 ns/op ArrayCopyAlignedLarge.testByte 1000000 avgt 15 51211.235 ? 539.355 ns/op ArrayCopyAlignedLarge.testByte 2000000 avgt 15 104837.012 ? 1338.823 ns/op ArrayCopyAlignedLarge.testByte 5000000 avgt 15 293357.745 ? 3233.745 ns/op ArrayCopyAlignedLarge.testByte 10000000 avgt 15 957068.292 ? 15509.983 ns/op // PR Benchmark (length) Mode Cnt Score Error Units ArrayCopyAlignedLarge.testByte 100000 avgt 15 2443.354 ? 17.996 ns/op ArrayCopyAlignedLarge.testByte 1000000 avgt 15 50854.800 ? 1253.863 ns/op ArrayCopyAlignedLarge.testByte 2000000 avgt 15 105105.124 ? 1286.606 ns/op ArrayCopyAlignedLarge.testByte 5000000 avgt 15 207298.875 ? 1260.289 ns/op ArrayCopyAlignedLarge.testByte 10000000 avgt 15 457461.404 ? 8628.867 ns/op In the XorTest::xor benchmark below, the PR code is active in 3 of the LARGE case runs: FOREIGN_NO_INIT, FOREIGN_INIT, and UNSAFE. // New xor test - Baseline Benchmark (arrayKind) (sizeKind) Mode Cnt Score Error Units XorTest.xor JNI_ELEMENTS SMALL avgt 30 0.220 ? 0.002 ms/op XorTest.xor JNI_ELEMENTS MEDIUM avgt 30 2.859 ? 0.034 ms/op XorTest.xor JNI_ELEMENTS LARGE avgt 30 117.436 ? 1.708 ms/op XorTest.xor JNI_REGION SMALL avgt 30 0.066 ? 0.001 ms/op XorTest.xor JNI_REGION MEDIUM avgt 30 1.623 ? 0.013 ms/op XorTest.xor JNI_REGION LARGE avgt 30 8.923 ? 0.095 ms/op XorTest.xor JNI_CRITICAL SMALL avgt 30 0.058 ? 0.001 ms/op XorTest.xor JNI_CRITICAL MEDIUM avgt 30 1.215 ? 0.012 ms/op XorTest.xor JNI_CRITICAL LARGE avgt 30 6.246 ? 0.048 ms/op XorTest.xor FOREIGN_NO_INIT SMALL avgt 30 0.066 ? 0.001 ms/op XorTest.xor FOREIGN_NO_INIT MEDIUM avgt 30 1.572 ? 0.018 ms/op XorTest.xor FOREIGN_NO_INIT LARGE avgt 30 10.204 ? 0.116 ms/op XorTest.xor FOREIGN_INIT SMALL avgt 30 0.071 ? 0.001 ms/op XorTest.xor FOREIGN_INIT MEDIUM avgt 30 1.697 ? 0.008 ms/op XorTest.xor FOREIGN_INIT LARGE avgt 30 12.056 ? 0.152 ms/op XorTest.xor FOREIGN_CRITICAL SMALL avgt 30 0.059 ? 0.001 ms/op XorTest.xor FOREIGN_CRITICAL MEDIUM avgt 30 1.215 ? 0.012 ms/op XorTest.xor FOREIGN_CRITICAL LARGE avgt 30 6.301 ? 0.110 ms/op XorTest.xor UNSAFE SMALL avgt 30 0.066 ? 0.001 ms/op XorTest.xor UNSAFE MEDIUM avgt 30 1.589 ? 0.029 ms/op XorTest.xor UNSAFE LARGE avgt 30 10.177 ? 0.108 ms/op // New xor test - PR Benchmark (arrayKind) (sizeKind) Mode Cnt Score Error Units XorTest.xor JNI_ELEMENTS SMALL avgt 30 0.224 ? 0.003 ms/op XorTest.xor JNI_ELEMENTS MEDIUM avgt 30 2.873 ? 0.025 ms/op XorTest.xor JNI_ELEMENTS LARGE avgt 30 118.523 ? 0.951 ms/op XorTest.xor JNI_REGION SMALL avgt 30 0.066 ? 0.001 ms/op XorTest.xor JNI_REGION MEDIUM avgt 30 1.639 ? 0.019 ms/op XorTest.xor JNI_REGION LARGE avgt 30 8.890 ? 0.124 ms/op XorTest.xor JNI_CRITICAL SMALL avgt 30 0.059 ? 0.001 ms/op XorTest.xor JNI_CRITICAL MEDIUM avgt 30 1.213 ? 0.013 ms/op XorTest.xor JNI_CRITICAL LARGE avgt 30 6.241 ? 0.099 ms/op XorTest.xor FOREIGN_NO_INIT SMALL avgt 30 0.066 ? 0.001 ms/op XorTest.xor FOREIGN_NO_INIT MEDIUM avgt 30 1.580 ? 0.015 ms/op XorTest.xor FOREIGN_NO_INIT LARGE avgt 30 8.936 ? 0.059 ms/op XorTest.xor FOREIGN_INIT SMALL avgt 30 0.071 ? 0.001 ms/op XorTest.xor FOREIGN_INIT MEDIUM avgt 30 1.727 ? 0.028 ms/op XorTest.xor FOREIGN_INIT LARGE avgt 30 10.544 ? 0.114 ms/op XorTest.xor FOREIGN_CRITICAL SMALL avgt 30 0.059 ? 0.001 ms/op XorTest.xor FOREIGN_CRITICAL MEDIUM avgt 30 1.215 ? 0.014 ms/op XorTest.xor FOREIGN_CRITICAL LARGE avgt 30 6.230 ? 0.029 ms/op XorTest.xor UNSAFE SMALL avgt 30 0.066 ? 0.001 ms/op XorTest.xor UNSAFE MEDIUM avgt 30 1.578 ? 0.020 ms/op XorTest.xor UNSAFE LARGE avgt 30 8.910 ? 0.100 ms/op ------------- PR Comment: https://git.openjdk.org/jdk/pull/16575#issuecomment-1820006548 From duke at openjdk.org Tue Nov 21 00:18:07 2023 From: duke at openjdk.org (Steve Dohrmann) Date: Tue, 21 Nov 2023 00:18:07 GMT Subject: RFR: 8310159: Bulk copy with Unsafe::arrayCopy is slower compared to memcpy [v4] In-Reply-To: References: <9j8PVvxFrzJHxtdVNMgvDZHKsjuBVNhl8q45OenHOIA=.2ed68c3d-dddd-4aba-bfab-c4da636662cb@github.com> Message-ID: On Mon, 20 Nov 2023 07:27:12 GMT, Tobias Hartmann wrote: >> Steve Dohrmann has updated the pull request incrementally with one additional commit since the last revision: >> >> - fix whitespace error > > test/micro/org/openjdk/bench/java/lang/foreign/xor/XorOp.java line 10: > >> 8: void copy(int count, byte[] src, int sOff, byte[] dst, int dOff, int len); >> 9: ======= >> 10: >>>>>>> 9727f4bdddc071e6f59806087339f345405ab004 > > You have multiple merge conflicts in the micro benchmark files. Sorry, not sure how I missed the conflicts. They should be resolved now. Thanks! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16575#discussion_r1399887729 From sviswanathan at openjdk.org Tue Nov 21 01:52:13 2023 From: sviswanathan at openjdk.org (Sandhya Viswanathan) Date: Tue, 21 Nov 2023 01:52:13 GMT Subject: RFR: 8310159: Bulk copy with Unsafe::arrayCopy is slower compared to memcpy [v5] In-Reply-To: References: Message-ID: On Mon, 20 Nov 2023 22:50:19 GMT, Steve Dohrmann wrote: >> Update: the XorTest::xor results shown in this message used test code from PR commit 7cc272e862791 which was based on Maurizio Cimadamore's commit a788f066af17. The XorTest has since been updated and XorTest::copy is no longer needed and has been removed from this pull request. See comment [here](https://github.com/openjdk/jdk/pull/16575#issuecomment-1820006548) for updated performance data. >> >> Below is baseline data collected using a modified version of the java.lang.foreign.xor micro benchmark referenced by @mcimadamore in the bug report. I collected data on an Ubuntu 22.04 laptop with a Tigerlake i7-1185G7, which does support AVX512. >> >> Baseline data >> Benchmark (arrayKind) (sizeKind) Mode Cnt Score Error Units >> -------------------------------------------------------------------------------------- >> XorTest.copy ELEMENTS SMALL avgt 30 584737355.767 ? 60414308.540 ns/op >> XorTest.copy ELEMENTS MEDIUM avgt 30 272248995.683 ? 2924954.498 ns/op >> XorTest.copy ELEMENTS LARGE avgt 30 1019200210.900 ? 28334453.652 ns/op >> XorTest.copy REGION SMALL avgt 30 7399944.164 ? 216821.819 ns/op >> XorTest.copy REGION MEDIUM avgt 30 20591454.558 ? 147398.572 ns/op >> XorTest.copy REGION LARGE avgt 30 21649266.051 ? 179263.875 ns/op >> XorTest.copy CRITICAL SMALL avgt 30 51079.357 ? 542.482 ns/op >> XorTest.copy CRITICAL MEDIUM avgt 30 2496.961 ? 11.375 ns/op >> XorTest.copy CRITICAL LARGE avgt 30 515.454 ? 5.831 ns/op >> XorTest.copy FOREIGN SMALL avgt 30 7558432.075 ? 79489.276 ns/op >> XorTest.copy FOREIGN MEDIUM avgt 30 19730666.341 ? 500505.099 ns/op >> XorTest.copy FOREIGN LARGE avgt 30 34616758.085 ? 340300.726 ns/op >> XorTest.xor ELEMENTS SMALL avgt 30 219832692.489 ? 2329417.319 ns/op >> XorTest.xor ELEMENTS MEDIUM avgt 30 505138197.167 ? 3818334.424 ns/op >> XorTest.xor ELEMENTS LARGE avgt 30 1189608474.667 ? 5877981.900 ns/op >> XorTest.xor REGION SMALL avgt 30 64093872.804 ? 599704.491 ns/op >> XorTest.xor REGION MEDIUM avgt 30 81544576.454 ? 1406342.118 ns/op >> XorTest.xor REGION LARGE avgt 30 90091424.883 ? 775577.613 ns/op >> XorTest.xor CRITICAL SMALL avgt ... > > Steve Dohrmann has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits: > > - Merge branch 'master' into memcpy > - Update full name > Previous commit (fcbbc0d7880) added org.openjdk.bench.java.lang.ArrayCopyAlignedLarge benchmark > - - remerge upstream master > - remove ::copy test from XorTest > - Merge branch 'master' into memcpy > - - fix whitespace error > - Merge branch 'master' of https://git.openjdk.org/jdk into memcpy > - - bug fix: only generate / use large copy code if MaxVectorSize == 64 > - - fix whitespace issues > - fix xor test foreign impl constructor signature > - - initial commit -- optimize large array cases in StubGenerator::generate_disjoint_copy_avx3_masked > - add src address prefetches > - switch to non-temporal writes > - added modified jmh benchmark based on xor benchmark from Maurizio Cimadamore src/hotspot/cpu/x86/stubGenerator_x86_64_arraycopy.cpp line 753: > 751: Label L_pre_main_post_large; > 752: > 753: if (MaxVectorSize == 64) { This should be an assert here instead of if check as this method shouldn't be called if MaxVectorSize is < 64. src/hotspot/cpu/x86/stubGenerator_x86_64_arraycopy.cpp line 768: > 766: } > 767: __ movq(temp3, temp2); > 768: copy64_masked_avx(to, from, xmm1, k2, temp3, temp4, temp1, shift, 0); The last argument should be "true" or "1" instead of "0" or "false". This is as temp3 (length) could be less than 32 as well. This case is only handled when use64byteVector argument is true. src/hotspot/cpu/x86/stubGenerator_x86_64_arraycopy.cpp line 777: > 775: > 776: __ BIND(L_main_pre_loop_large); > 777: __ subq(temp1, loop_size[shift]); // whay is this here Spurious comment. src/hotspot/cpu/x86/stubGenerator_x86_64_arraycopy.cpp line 797: > 795: __ jcc(Assembler::lessEqual, L_exit_large); > 796: arraycopy_avx3_special_cases_256(xmm1, k2, from, to, temp1, shift, > 797: temp4, temp3, L_entry_large, L_exit_large); When we come here to arraycopy_avx3_special_cases_256 only up to 256 bytes need to be copied so we don't need to go back to L_entry_large. src/hotspot/cpu/x86/stubGenerator_x86_64_arraycopy.cpp line 1058: > 1056: }; > 1057: > 1058: if (MaxVectorSize == 64) { This should be an assert here instead of if check as this method shouldn't be called if MaxVectorSize is < 64. src/hotspot/cpu/x86/stubGenerator_x86_64_arraycopy.cpp line 1175: > 1173: void StubGenerator::copy256_avx3(Register dst, Register src, Register index, XMMRegister xmm1, > 1174: XMMRegister xmm2, XMMRegister xmm3, XMMRegister xmm4, > 1175: bool conjoint, int shift, int offset) { The conjoint parameter is not used so could be removed from this function. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16575#discussion_r1399916497 PR Review Comment: https://git.openjdk.org/jdk/pull/16575#discussion_r1399918640 PR Review Comment: https://git.openjdk.org/jdk/pull/16575#discussion_r1399896421 PR Review Comment: https://git.openjdk.org/jdk/pull/16575#discussion_r1399934713 PR Review Comment: https://git.openjdk.org/jdk/pull/16575#discussion_r1399916567 PR Review Comment: https://git.openjdk.org/jdk/pull/16575#discussion_r1399881916 From psadhukhan at openjdk.org Tue Nov 21 03:42:12 2023 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Tue, 21 Nov 2023 03:42:12 GMT Subject: RFR: 8318364: Add an FFM-based implementation of harfbuzz OpenType layout [v7] In-Reply-To: <375g5CqMLrLiy3qX7ntQIUG4Rmomyqo9xrz8NWOAWYU=.c92ad36a-a12e-412b-817b-c10b9640d53f@github.com> References: <375g5CqMLrLiy3qX7ntQIUG4Rmomyqo9xrz8NWOAWYU=.c92ad36a-a12e-412b-817b-c10b9640d53f@github.com> Message-ID: On Mon, 20 Nov 2023 18:40:33 GMT, Phil Race wrote: >> 8318364: Add an FFM-based implementation of harfbuzz OpenType layout > > Phil Race has updated the pull request incrementally with one additional commit since the last revision: > > 8318364 Marked as reviewed by psadhukhan (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/15476#pullrequestreview-1741064594 From psadhukhan at openjdk.org Tue Nov 21 03:42:15 2023 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Tue, 21 Nov 2023 03:42:15 GMT Subject: RFR: 8318364: Add an FFM-based implementation of harfbuzz OpenType layout [v4] In-Reply-To: References: <8tu4D5zX989IFr6DuSuReyYGd9Z-fOcmXcgePojFmvQ=.4dfbd237-f683-44fa-930d-fa89999b3242@github.com> Message-ID: On Mon, 20 Nov 2023 18:34:13 GMT, Phil Race wrote: >> test/jdk/java/awt/font/GlyphVector/LayoutCompatTest.java line 29: >> >>> 27: /* >>> 28: @test >>> 29: @summary verify JNI and FFM harfbuzz OpenType layout implementations are equivalent. >> >> bug id is missing > > Because there isn't a "bug". It is just a test for new functionality. OK. I was thinking of somehow documenting 8318364 to link this new test against the enhancement.. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15476#discussion_r1399990564 From qamai at openjdk.org Tue Nov 21 04:28:11 2023 From: qamai at openjdk.org (Quan Anh Mai) Date: Tue, 21 Nov 2023 04:28:11 GMT Subject: RFR: 8318650: Optimized subword gather for x86 targets. [v7] In-Reply-To: <6trfINWUmYQ7emAfsQAeLPzXSWZGRubI7v8s-wWcGn4=.91ef2dc5-dc4b-4fdd-aa0d-1e7f809cd060@github.com> References: <6trfINWUmYQ7emAfsQAeLPzXSWZGRubI7v8s-wWcGn4=.91ef2dc5-dc4b-4fdd-aa0d-1e7f809cd060@github.com> Message-ID: On Wed, 15 Nov 2023 02:17:58 GMT, Jatin Bhateja wrote: >> Hi All, >> >> This patch optimizes sub-word gather operation for x86 targets with AVX2 and AVX512 features. >> >> Following is the summary of changes:- >> >> 1) Intrinsify sub-word gather with high performance backend implementation based on hybrid algorithm which initially partially unrolls scalar loop to accumulates values from gather indices into a quadword(64bit) slice followed by vector permutation to place the slice into appropriate vector lanes, it prevents code bloating and generates compact >> JIT sequence. This coupled with savings from expansive array allocation in existing java implementation translates into significant performance of 1.3-5x gains with included micro. >> >> >> ![image](https://github.com/openjdk/jdk/assets/59989778/e25ba4ad-6a61-42fa-9566-452f741a9c6d) >> >> >> 2) Patch was also compared against modified java fallback implementation by replacing temporary array allocation with zero initialized vector and a scalar loops which inserts gathered values into vector. But, vector insert operation in higher vector lanes is a three step process which first extracts the upper vector 128 bit lane, updates it with gather subword value and then inserts the lane back to its original position. This makes inserts into higher order lanes costly w.r.t to proposed solution. In addition generated JIT code for modified fallback implementation was very bulky. This may impact in-lining decisions into caller contexts. >> >> 3) Some minor adjustments in existing gather instruction pattens for double/quad words. >> >> >> Kindly review and share your feedback. >> >> >> Best Regards, >> Jatin > > Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: > > Fix incorrect comment I have not thought about this thoroughly so it may be incorrect. Can we delegate the gather to `int` and extract the result from it. vpand(xtmp1, idx, bt == T_SHORT ? -2 : -4); // align the index so that the address is aligned for int accesses vpgatherdd(xtmp2, mask, Address(base, xtmp1, bt == T_SHORT ? times_2 : times_1, offset)); vpand(xtmp1, idx, bt == T_SHORT ? 1 : 3); // Need to align the requested elements vpslld(xtmp1, xtmp1, bt == T_SHORT ? 4 : 3); vpsrlvd(xtmp1, xtmp2, xtmp1); vpmovdw(dst, xtmp1); ------------- PR Comment: https://git.openjdk.org/jdk/pull/16354#issuecomment-1820220589 From dholmes at openjdk.org Tue Nov 21 05:24:33 2023 From: dholmes at openjdk.org (David Holmes) Date: Tue, 21 Nov 2023 05:24:33 GMT Subject: RFR: 8318776: Require supports_cx8 to always be true [v4] In-Reply-To: References: Message-ID: > As discussed in JBS all platforms (some tweaks to Zero are in progress) actually do support `cx8` i.e. 64-bit compare-and-exchange, so we can strip out the locked-based alternatives to using it and just add a guarantee that it is true at runtime. And all platforms except some ARM variants set `SUPPORTS_NATIVE_CX8`, so we can greatly simplify things. Summary of changes: > - `_supports_cx8` field is only needed when `SUPPORTS_NATIVE_CX8` is not defined > - Assertions for `supports_cx8()` are removed > - Compiler predicates requiring `supports_cx8()` are removed > - Access backend is greatly simplified without the need for lock-based alternative > - `java.util.concurrent.AtomicLongFieldUpdater` is simplified without the need for a lock-based alternative > > I did consider moving all the ARM `kuser_helper` related code to be only defined when `SUPPORTS_NATIVE_CX8` is not defined, but there was a theoretical risk this could change the behaviour if ARMv7 binaries were run on other ARM CPU's. I added a note to that effect in vm_version_linux_arm32.cpp so the ARM port maintainers could clean this up further if desired. > > Testing: > - All Oracle tiers 1-5 builds (which includes an ARMv7 build) > - GHA builds/tests > - Oracle tiers 1-3 sanity testing > > Zero changes coming in via [JDK-8319777](https://bugs.openjdk.org/browse/JDK-8319777) will be merged when they arrive. > > Thanks. David Holmes has updated the pull request incrementally with one additional commit since the last revision: Remove unnecessary includes of vm_version.hpp. Fix copyright years. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16625/files - new: https://git.openjdk.org/jdk/pull/16625/files/65871144..597cef53 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16625&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16625&range=02-03 Stats: 4 lines in 4 files changed: 0 ins; 3 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/16625.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16625/head:pull/16625 PR: https://git.openjdk.org/jdk/pull/16625 From eosterlund at openjdk.org Tue Nov 21 06:06:11 2023 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Tue, 21 Nov 2023 06:06:11 GMT Subject: RFR: 8318776: Require supports_cx8 to always be true [v4] In-Reply-To: References: Message-ID: On Tue, 21 Nov 2023 05:24:33 GMT, David Holmes wrote: >> As discussed in JBS all platforms (some tweaks to Zero are in progress) actually do support `cx8` i.e. 64-bit compare-and-exchange, so we can strip out the locked-based alternatives to using it and just add a guarantee that it is true at runtime. And all platforms except some ARM variants set `SUPPORTS_NATIVE_CX8`, so we can greatly simplify things. Summary of changes: >> - `_supports_cx8` field is only needed when `SUPPORTS_NATIVE_CX8` is not defined >> - Assertions for `supports_cx8()` are removed >> - Compiler predicates requiring `supports_cx8()` are removed >> - Access backend is greatly simplified without the need for lock-based alternative >> - `java.util.concurrent.AtomicLongFieldUpdater` is simplified without the need for a lock-based alternative >> >> I did consider moving all the ARM `kuser_helper` related code to be only defined when `SUPPORTS_NATIVE_CX8` is not defined, but there was a theoretical risk this could change the behaviour if ARMv7 binaries were run on other ARM CPU's. I added a note to that effect in vm_version_linux_arm32.cpp so the ARM port maintainers could clean this up further if desired. >> >> Testing: >> - All Oracle tiers 1-5 builds (which includes an ARMv7 build) >> - GHA builds/tests >> - Oracle tiers 1-3 sanity testing >> >> Zero changes coming in via [JDK-8319777](https://bugs.openjdk.org/browse/JDK-8319777) will be merged when they arrive. >> >> Thanks. > > David Holmes has updated the pull request incrementally with one additional commit since the last revision: > > Remove unnecessary includes of vm_version.hpp. > Fix copyright years. This looks great! ------------- Marked as reviewed by eosterlund (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16625#pullrequestreview-1741175703 From duke at openjdk.org Tue Nov 21 06:41:17 2023 From: duke at openjdk.org (Shaojin Wen) Date: Tue, 21 Nov 2023 06:41:17 GMT Subject: RFR: 8316704: Regex-free parsing of Formatter and FormatProcessor specifiers [v5] In-Reply-To: <4Svt2bqEKfvhgxaORRHwDTQQ7kqWN2UoD9pTusfZ0nM=.9c0cf5b5-201d-4fb5-ad70-5fedf512cdd8@github.com> References: <9UsU73B_0Tc03SRJoJFOxsQrmhTUdSPJAi-S0nTD_lk=.7b6782f9-b578-47a0-a0c6-a6f384f60785@github.com> <4Svt2bqEKfvhgxaORRHwDTQQ7kqWN2UoD9pTusfZ0nM=.9c0cf5b5-201d-4fb5-ad70-5fedf512cdd8@github.com> Message-ID: On Sat, 21 Oct 2023 01:22:04 GMT, Shaojin Wen wrote: >> @cl4es made performance optimizations for the simple specifiers of String.format in PR https://github.com/openjdk/jdk/pull/2830. Based on the same idea, I continued to make improvements. I made patterns like %2d %02d also be optimized. >> >> The following are the test results based on MacBookPro M1 Pro: >> >> >> -Benchmark Mode Cnt Score Error Units >> -StringFormat.complexFormat avgt 15 1862.233 ? 217.479 ns/op >> -StringFormat.int02Format avgt 15 312.491 ? 26.021 ns/op >> -StringFormat.intFormat avgt 15 84.432 ? 4.145 ns/op >> -StringFormat.longFormat avgt 15 87.330 ? 6.111 ns/op >> -StringFormat.stringFormat avgt 15 63.985 ? 11.366 ns/op >> -StringFormat.stringIntFormat avgt 15 87.422 ? 0.147 ns/op >> -StringFormat.widthStringFormat avgt 15 250.740 ? 32.639 ns/op >> -StringFormat.widthStringIntFormat avgt 15 312.474 ? 16.309 ns/op >> >> +Benchmark Mode Cnt Score Error Units >> +StringFormat.complexFormat avgt 15 740.626 ? 66.671 ns/op (+151.45) >> +StringFormat.int02Format avgt 15 131.049 ? 0.432 ns/op (+138.46) >> +StringFormat.intFormat avgt 15 67.229 ? 4.155 ns/op (+25.59) >> +StringFormat.longFormat avgt 15 66.444 ? 0.614 ns/op (+31.44) >> +StringFormat.stringFormat avgt 15 62.619 ? 4.652 ns/op (+2.19) >> +StringFormat.stringIntFormat avgt 15 89.606 ? 13.966 ns/op (-2.44) >> +StringFormat.widthStringFormat avgt 15 52.462 ? 15.649 ns/op (+377.95) >> +StringFormat.widthStringIntFormat avgt 15 101.814 ? 3.147 ns/op (+206.91) > > Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: > > fix from @rgiulietti 's review @RogerRiggs Can you help me review this PR? ------------- PR Comment: https://git.openjdk.org/jdk/pull/15776#issuecomment-1820323156 From vklang at openjdk.org Tue Nov 21 09:21:11 2023 From: vklang at openjdk.org (Viktor Klang) Date: Tue, 21 Nov 2023 09:21:11 GMT Subject: RFR: 8314480: Memory ordering spec updates in java.lang.ref In-Reply-To: References: Message-ID: On Mon, 13 Nov 2023 22:31:16 GMT, Brent Christian wrote: > Classes in the `java.lang.ref` package would benefit from an update to bring the spec in line with how the VM already behaves. The changes would focus on _happens-before_ edges at some key points during reference processing. > > A couple key things we want to be able to say are: > - `Reference.reachabilityFence(x)` _happens-before_ reference processing occurs for 'x'. > - `Cleaner.register()` _happens-before_ the Cleaner thread runs the registered cleaning action. > > This will bring Cleaner in line (or close) with the memory visibility guarantees made for finalizers in [JLS 17.4.5](https://docs.oracle.com/javase/specs/jls/se18/html/jls-17.html#jls-17.4.5): > _"There is a happens-before edge from the end of a constructor of an object to the start of a finalizer (?12.6) for that object."_ src/java.base/share/classes/java/lang/ref/Reference.java line 405: > 403: *

    This method is invoked only by Java code; when the garbage collector > 404: * clears references it does so directly, without invoking this method. The > 405: * {@link #enqueue} method also clears references directly, without invoking The last sentence might make sense to have as an apiNote? ? src/java.base/share/classes/java/lang/ref/Reference.java line 497: > 495: * or {@link ReferenceQueue#remove}. > 496: * > 497: *

    This method is invoked only by Java code; when the garbage collector Perhaps something along the lines of: Suggestion: *

    This method is only invoked explicitly; when the garbage collector ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16644#discussion_r1400243561 PR Review Comment: https://git.openjdk.org/jdk/pull/16644#discussion_r1400249718 From vklang at openjdk.org Tue Nov 21 09:21:14 2023 From: vklang at openjdk.org (Viktor Klang) Date: Tue, 21 Nov 2023 09:21:14 GMT Subject: RFR: 8314480: Memory ordering spec updates in java.lang.ref In-Reply-To: References: Message-ID: On Wed, 15 Nov 2023 22:33:03 GMT, Stuart Marks wrote: >> Classes in the `java.lang.ref` package would benefit from an update to bring the spec in line with how the VM already behaves. The changes would focus on _happens-before_ edges at some key points during reference processing. >> >> A couple key things we want to be able to say are: >> - `Reference.reachabilityFence(x)` _happens-before_ reference processing occurs for 'x'. >> - `Cleaner.register()` _happens-before_ the Cleaner thread runs the registered cleaning action. >> >> This will bring Cleaner in line (or close) with the memory visibility guarantees made for finalizers in [JLS 17.4.5](https://docs.oracle.com/javase/specs/jls/se18/html/jls-17.html#jls-17.4.5): >> _"There is a happens-before edge from the end of a constructor of an object to the start of a finalizer (?12.6) for that object."_ > > src/java.base/share/classes/java/lang/ref/Reference.java line 495: > >> 493: * happen-before >> 494: * the reference is removed from the queue by {@link ReferenceQueue#poll} >> 495: * or {@link ReferenceQueue#remove}. > > Should there be an explicit statement about an unsuccessful call having no memory consistency effects? Perhaps something along the lines of "A failed {@code enqueue} has no defined memory consistency effects."? > src/java.base/share/classes/java/lang/ref/Reference.java line 505: > >> 503: * to return this reference even though the referent is still strongly >> 504: * reachable. That is, before the referent has reached the expected >> 505: * reachability level. > > The wording here is kind of awkward. We could try to wordsmith it, but there is also the possibility that there are valid use cases for using enqueue(), which makes this caution seem misplaced. An alternative would simply be to omit this paragraph. Might be better to leave out the last sencence? > src/java.base/share/classes/java/lang/ref/Reference.java line 564: > >> 562: * {@code reachabilityFence(x)} >> 563: * happen-before >> 564: * the garbage collector clears any reference to {code x}. > > This is a fairly low-level specification, so the relationship described here is "reachabilityFence **hb** clearing". The relationships "clearing **hb** enqueue" and "enqueue **hb** dequeue" are described elsewhere. Thus the mention of Cleaner above seems misplaced. > > However, the whole chain of relationships > >> RF **hb** clearing **hb** enqueue **hb** dequeue **hb** cleaning-action > > is important. Should this be described somewhere? Perhaps in each of these places add a link to #Memory Consistency Properties ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16644#discussion_r1400247244 PR Review Comment: https://git.openjdk.org/jdk/pull/16644#discussion_r1400251257 PR Review Comment: https://git.openjdk.org/jdk/pull/16644#discussion_r1400254380 From jlahoda at openjdk.org Tue Nov 21 09:57:06 2023 From: jlahoda at openjdk.org (Jan Lahoda) Date: Tue, 21 Nov 2023 09:57:06 GMT Subject: RFR: 8304446: javap --system flag doesn't override system APIs [v3] In-Reply-To: References: Message-ID: On Fri, 10 Nov 2023 08:38:09 GMT, Adam Sotona wrote: >> Javap ignores --system option when searching for JDK classes. >> This patch prepends search over JDK system modules. >> >> Please review. >> >> Thanks, >> Adam > > Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: > > applied suggested changes Looks good to me. ------------- Marked as reviewed by jlahoda (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16476#pullrequestreview-1741556690 From jlahoda at openjdk.org Tue Nov 21 10:01:06 2023 From: jlahoda at openjdk.org (Jan Lahoda) Date: Tue, 21 Nov 2023 10:01:06 GMT Subject: RFR: 8320222: Wrong bytecode accepted, and StackMap table generated [v2] In-Reply-To: References: Message-ID: On Mon, 20 Nov 2023 17:17:15 GMT, Adam Sotona wrote: >> Stack map generator in ClassFile API performs only minimal checks in favour of performance. >> However it led to situations where it generates invalid stack maps for corrupted code. >> This patch adds basic checks of stack when two frames are merged and throws an exception in case of stack size or content mismatch. Generated or transformed code with inconsistent stack will fail on stack maps generation. >> Relevant tests are added. >> >> Please review. >> >> Thanks, >> Adam > > Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: > > changed StackMapGenerator::generatorError to return an exception instead of directly throw Looks reasonable to me. ------------- Marked as reviewed by jlahoda (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16685#pullrequestreview-1741564607 From asotona at openjdk.org Tue Nov 21 10:08:34 2023 From: asotona at openjdk.org (Adam Sotona) Date: Tue, 21 Nov 2023 10:08:34 GMT Subject: Integrated: 8304446: javap --system flag doesn't override system APIs In-Reply-To: References: Message-ID: On Thu, 2 Nov 2023 13:49:17 GMT, Adam Sotona wrote: > Javap ignores --system option when searching for JDK classes. > This patch prepends search over JDK system modules. > > Please review. > > Thanks, > Adam This pull request has now been integrated. Changeset: 604d29a8 Author: Adam Sotona URL: https://git.openjdk.org/jdk/commit/604d29a8c911c1064ba0fab17f9192bb4e640709 Stats: 13 lines in 1 file changed: 13 ins; 0 del; 0 mod 8304446: javap --system flag doesn't override system APIs Reviewed-by: jlahoda ------------- PR: https://git.openjdk.org/jdk/pull/16476 From vklang at openjdk.org Tue Nov 21 10:11:28 2023 From: vklang at openjdk.org (Viktor Klang) Date: Tue, 21 Nov 2023 10:11:28 GMT Subject: RFR: 8319123: Implement JEP 461: Stream Gatherers (Preview) [v13] In-Reply-To: References: Message-ID: > This Pull-Request implements [JEP-461](https://openjdk.org/jeps/461) Viktor Klang has updated the pull request incrementally with one additional commit since the last revision: Javadoc clarifications for Gatherer type parameters, correcting descriptions of Integrator type parameters, and more consistently use "initializer function" instead of "supplier function". ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16420/files - new: https://git.openjdk.org/jdk/pull/16420/files/48b7e329..ec841740 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16420&range=12 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16420&range=11-12 Stats: 13 lines in 1 file changed: 0 ins; 0 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/16420.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16420/head:pull/16420 PR: https://git.openjdk.org/jdk/pull/16420 From asotona at openjdk.org Tue Nov 21 10:12:41 2023 From: asotona at openjdk.org (Adam Sotona) Date: Tue, 21 Nov 2023 10:12:41 GMT Subject: Integrated: 8320222: Wrong bytecode accepted, and StackMap table generated In-Reply-To: References: Message-ID: <77Ft-Ik2aRvLBjLvdDi_tRi51LGED1ruJYCNjU-gYxE=.af5e2062-8bb1-4500-8fea-be2790e088de@github.com> On Thu, 16 Nov 2023 10:00:44 GMT, Adam Sotona wrote: > Stack map generator in ClassFile API performs only minimal checks in favour of performance. > However it led to situations where it generates invalid stack maps for corrupted code. > This patch adds basic checks of stack when two frames are merged and throws an exception in case of stack size or content mismatch. Generated or transformed code with inconsistent stack will fail on stack maps generation. > Relevant tests are added. > > Please review. > > Thanks, > Adam This pull request has now been integrated. Changeset: c4aee66d Author: Adam Sotona URL: https://git.openjdk.org/jdk/commit/c4aee66d742008848e5b5bc8ce3b2e3032a39bc3 Stats: 74 lines in 2 files changed: 46 ins; 0 del; 28 mod 8320222: Wrong bytecode accepted, and StackMap table generated Reviewed-by: jlahoda ------------- PR: https://git.openjdk.org/jdk/pull/16685 From asotona at openjdk.org Tue Nov 21 10:33:22 2023 From: asotona at openjdk.org (Adam Sotona) Date: Tue, 21 Nov 2023 10:33:22 GMT Subject: RFR: 8308753: Class-File API transition to Preview [v30] In-Reply-To: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com> References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com> Message-ID: > Classfile API is an internal library under package `jdk.internal.classfile`?in JDK 21. > This pull request turns the Classfile API into a preview feature and moves it into `java.lang.classfile`. > It repackages all uses across JDK and tests and adds lots of missing Javadoc. > > This PR goes in sync with?[JDK-8308754](https://bugs.openjdk.org/browse/JDK-8308754): Class-File API (Preview) (CSR) > and?[JDK-8280389](https://bugs.openjdk.org/browse/JDK-8280389): Class-File API (Preview) (JEP). > > Online javadoc is available at:? > https://cr.openjdk.org/~asotona/JDK-8308753-preview/api/java.base/java/lang/classfile/package-summary.html > > In addition to the primary transition to preview, this pull request also includes: > - All?Classfile*?classes ranamed to?ClassFile*?(based on JEP discussion). > - A new preview feature, `CLASSFILE_API`, has been added. > - Buildsystem tool required a little patch to support annotated modules. > - All JDK modules using the Classfile API are newly participating in the preview. > - All tests that use the Classfile API now have preview enabled. > - A few Javac tests not allowing preview have been partially reverted; their conversion can be re-applied when the Classfile API leaves preview mode. > > Despite the number of affected files, this pull request is relatively straight-forward. The preview version of the Classfile API is based on the internal version of the library from the JDK master branch, and there are no API features added. > > Please review this pull request to help the Classfile API turn into a preview. > > Any comments are welcome. > > Thanks, > Adam Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 366 commits: - Merge branch 'master' into JDK-8308753-preview # Conflicts: # test/jdk/jdk/classfile/StackMapsTest.java - Merge branch 'master' into JDK-8308753-preview # Conflicts: # test/langtools/tools/javac/7199823/InnerClassCannotBeVerified.java - added new package-info snippets and fixed ClassFile::parse throws javadoc description - fixed lambda tests - Merge branch 'master' into JDK-8308753-preview - fixed SignaturesTest - fixed condy tests - Merge branch 'master' into JDK-8308753-preview - Merge branch 'master' into JDK-8308753-preview # Conflicts: # test/jdk/tools/lib/tests/JImageValidator.java - fixed jdk.jfr - ... and 356 more: https://git.openjdk.org/jdk/compare/e055fae1...48aa8ba8 ------------- Changes: https://git.openjdk.org/jdk/pull/15706/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15706&range=29 Stats: 32342 lines in 784 files changed: 14659 ins; 14109 del; 3574 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 prappo at openjdk.org Tue Nov 21 10:41:42 2023 From: prappo at openjdk.org (Pavel Rappo) Date: Tue, 21 Nov 2023 10:41:42 GMT Subject: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v19] In-Reply-To: References: Message-ID: On Wed, 15 Nov 2023 15:54:26 GMT, Jim Laskey wrote: >> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: >> >> Filter abstract main methods and search interfaces for default main methods. > > Look at the spec https://bugs.openjdk.org/browse/JDK-8319252 under 7.3 Compilation Units. > > - It is not abstract (8.1.1.1 ?). > - It is final (8.1.1.2 ?). > - It is a member of an unnamed package (7.4.2 ?) and **has package access**. Its direct superclass is Object (8.1.4 ?). > - It does not have any direct superinterfaces (8.1.5 ?). > - The body of the class contains every ClassMemberDeclaration (these are declarations of fields (8.3 ?), methods (8.4 ?), member classes (8.5 ?), and member interfaces (9.1.1.3 ?)) from the simple compilation unit. It is not possible for a simple compilation unit to declare an instance initializer (8.6 ?), static initializer (8.7 ?), or constructor (8.8 ?). > -It has an implicitly declared default constructor (8.8.9 ?). @JimLaskey, in my experiments for JDK-8308715 (Create a mechanism for Implicitly Declared Class javadoc), I found that `javax.lang.model.util.Elements.getOrigin` reports `Origin.EXPLICIT` for the implicitly declared class and `Origin.MANDATED` for that class' constructor. Shouldn't they both be `Origin.MANDATED` because the elements are created from source, not class files, which have some limitations on `ACC_MANDATED`? ------------- PR Comment: https://git.openjdk.org/jdk/pull/16461#issuecomment-1820659000 From dholmes at openjdk.org Tue Nov 21 11:00:11 2023 From: dholmes at openjdk.org (David Holmes) Date: Tue, 21 Nov 2023 11:00:11 GMT Subject: RFR: 8318776: Require supports_cx8 to always be true [v4] In-Reply-To: References: Message-ID: On Tue, 21 Nov 2023 06:03:38 GMT, Erik ?sterlund wrote: >> David Holmes has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove unnecessary includes of vm_version.hpp. >> Fix copyright years. > > This looks great! Thanks for the review @fisk ! I have to wait for a few Zero related PRs to get integrated then re-merge, before I can integrate. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16625#issuecomment-1820689855 From duke at openjdk.org Tue Nov 21 11:33:46 2023 From: duke at openjdk.org (suchismith1993) Date: Tue, 21 Nov 2023 11:33:46 GMT Subject: RFR: JDK-8317799 : AIX PPC64: FFI symbol lookup doesn't find symbols [v2] In-Reply-To: References: Message-ID: <9V9GMJiIZMxB_t8kheXDAkdaZ0LwcIK5DI-KPahuiaE=.9f939e93-2460-481d-b6f0-969f6a96da35@github.com> > The math library in AIX specifically, is a static archive. Doing a -lm wont suffice, because when the symbols are looked up using dlsym or accessing native code through Java, it will lead to failures. > Hence we had to come up with a list of symbols to allow math library symbols to be accesible. > Also, there are parts of libc library that are static too, and hence those symbols also are present in this list. > Without this change, the StdLibTest and multiple other tests which make native function calls using FFI, fail with NoSuchElementException. > > > 1. Adding required compiler flags. > 2. Adding required symbols. > > > JBS-ISSUE : [JDK-8317799](https://bugs.openjdk.org/browse/JDK-8317799) suchismith1993 has updated the pull request incrementally with 172 additional commits since the last revision: - Provide support for math library in inline way. - Symbol Resolution fix for Panama changes. 1. Adding required compiler flags. 2. Adding required symbols. - 8320348: test/jdk/java/io/File/GetAbsolutePath.windowsDriveRelative fails if working directory is not on drive C Reviewed-by: alanb, mbaesken - 8320372: test/jdk/sun/security/x509/DNSName/LeadingPeriod.java validity check failed Reviewed-by: alanb - 8320234: Merge doclint.Env.AccessKind with tool.AccessKind Reviewed-by: jjg - 8319817: Charset constructor should make defensive copy of aliases Reviewed-by: rriggs, alanb, bpb, iris, jpai - 8320147: Remove DumpSharedSpaces Reviewed-by: ccheung, matsaave - 8319973: AArch64: Save and restore FPCR in the call stub Reviewed-by: adinn, stuefe - 8320410: Reflow markdown in building.md Reviewed-by: erikj - 8319928: Exceptions thrown by cleanup actions should be handled correctly Reviewed-by: jvernee - ... and 162 more: https://git.openjdk.org/jdk/compare/c340abf0...9c77fa98 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16414/files - new: https://git.openjdk.org/jdk/pull/16414/files/c340abf0..9c77fa98 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16414&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16414&range=00-01 Stats: 629149 lines in 1218 files changed: 87938 ins; 478201 del; 63010 mod Patch: https://git.openjdk.org/jdk/pull/16414.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16414/head:pull/16414 PR: https://git.openjdk.org/jdk/pull/16414 From mdoerr at openjdk.org Tue Nov 21 11:33:46 2023 From: mdoerr at openjdk.org (Martin Doerr) Date: Tue, 21 Nov 2023 11:33:46 GMT Subject: RFR: JDK-8317799 : AIX PPC64: FFI symbol lookup doesn't find symbols [v2] In-Reply-To: <9V9GMJiIZMxB_t8kheXDAkdaZ0LwcIK5DI-KPahuiaE=.9f939e93-2460-481d-b6f0-969f6a96da35@github.com> References: <9V9GMJiIZMxB_t8kheXDAkdaZ0LwcIK5DI-KPahuiaE=.9f939e93-2460-481d-b6f0-969f6a96da35@github.com> Message-ID: On Tue, 21 Nov 2023 11:21:40 GMT, suchismith1993 wrote: >> The math library in AIX specifically, is a static archive. Doing a -lm wont suffice, because when the symbols are looked up using dlsym or accessing native code through Java, it will lead to failures. >> Hence we had to come up with a list of symbols to allow math library symbols to be accesible. >> Also, there are parts of libc library that are static too, and hence those symbols also are present in this list. >> Without this change, the StdLibTest and multiple other tests which make native function calls using FFI, fail with NoSuchElementException. >> >> >> 1. Adding required compiler flags. >> 2. Adding required symbols. >> >> >> JBS-ISSUE : [JDK-8317799](https://bugs.openjdk.org/browse/JDK-8317799) > > suchismith1993 has updated the pull request incrementally with 172 additional commits since the last revision: > > - Provide support for math library in inline way. > - Symbol Resolution fix for Panama changes. > 1. Adding required compiler flags. > 2. Adding required symbols. > - 8320348: test/jdk/java/io/File/GetAbsolutePath.windowsDriveRelative fails if working directory is not on drive C > > Reviewed-by: alanb, mbaesken > - 8320372: test/jdk/sun/security/x509/DNSName/LeadingPeriod.java validity check failed > > Reviewed-by: alanb > - 8320234: Merge doclint.Env.AccessKind with tool.AccessKind > > Reviewed-by: jjg > - 8319817: Charset constructor should make defensive copy of aliases > > Reviewed-by: rriggs, alanb, bpb, iris, jpai > - 8320147: Remove DumpSharedSpaces > > Reviewed-by: ccheung, matsaave > - 8319973: AArch64: Save and restore FPCR in the call stub > > Reviewed-by: adinn, stuefe > - 8320410: Reflow markdown in building.md > > Reviewed-by: erikj > - 8319928: Exceptions thrown by cleanup actions should be handled correctly > > Reviewed-by: jvernee > - ... and 162 more: https://git.openjdk.org/jdk/compare/c340abf0...9c77fa98 It's messed up, now. Can you revert the last step? ------------- Changes requested by mdoerr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16414#pullrequestreview-1741741189 From duke at openjdk.org Tue Nov 21 11:52:23 2023 From: duke at openjdk.org (suchismith1993) Date: Tue, 21 Nov 2023 11:52:23 GMT Subject: RFR: JDK-8317799 : AIX PPC64: FFI symbol lookup doesn't find symbols [v3] In-Reply-To: References: Message-ID: > The math library in AIX specifically, is a static archive. Doing a -lm wont suffice, because when the symbols are looked up using dlsym or accessing native code through Java, it will lead to failures. > Hence we had to come up with a list of symbols to allow math library symbols to be accesible. > Also, there are parts of libc library that are static too, and hence those symbols also are present in this list. > Without this change, the StdLibTest and multiple other tests which make native function calls using FFI, fail with NoSuchElementException. > > > 1. Adding required compiler flags. > 2. Adding required symbols. > > > JBS-ISSUE : [JDK-8317799](https://bugs.openjdk.org/browse/JDK-8317799) suchismith1993 has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits: - Remove symbols file after using inline way. - Provide support for math library in inline way. - Update symbols-aix-foreign Remove comments from export list, causes build failures. - Symbol Resolution fix for Panama changes. 1.Adding required compiler flags. 2. Adding required symbols. ------------- Changes: https://git.openjdk.org/jdk/pull/16414/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16414&range=02 Stats: 179 lines in 2 files changed: 177 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/16414.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16414/head:pull/16414 PR: https://git.openjdk.org/jdk/pull/16414 From duke at openjdk.org Tue Nov 21 11:56:27 2023 From: duke at openjdk.org (suchismith1993) Date: Tue, 21 Nov 2023 11:56:27 GMT Subject: RFR: JDK-8317799 : AIX PPC64: FFI symbol lookup doesn't find symbols [v4] In-Reply-To: References: Message-ID: > The math library in AIX specifically, is a static archive. Doing a -lm wont suffice, because when the symbols are looked up using dlsym or accessing native code through Java, it will lead to failures. > Hence we had to come up with a list of symbols to allow math library symbols to be accesible. > Also, there are parts of libc library that are static too, and hence those symbols also are present in this list. > Without this change, the StdLibTest and multiple other tests which make native function calls using FFI, fail with NoSuchElementException. > > > 1. Adding required compiler flags. > 2. Adding required symbols. > > > JBS-ISSUE : [JDK-8317799](https://bugs.openjdk.org/browse/JDK-8317799) suchismith1993 has updated the pull request incrementally with two additional commits since the last revision: - Remove extra symbols. - Remove additional lines ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16414/files - new: https://git.openjdk.org/jdk/pull/16414/files/4899c975..47e5fb5a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16414&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16414&range=02-03 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/16414.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16414/head:pull/16414 PR: https://git.openjdk.org/jdk/pull/16414 From mdoerr at openjdk.org Tue Nov 21 11:56:30 2023 From: mdoerr at openjdk.org (Martin Doerr) Date: Tue, 21 Nov 2023 11:56:30 GMT Subject: RFR: JDK-8317799 : AIX PPC64: FFI symbol lookup doesn't find symbols [v3] In-Reply-To: References: Message-ID: On Tue, 21 Nov 2023 11:52:23 GMT, suchismith1993 wrote: >> The math library in AIX specifically, is a static archive. Doing a -lm wont suffice, because when the symbols are looked up using dlsym or accessing native code through Java, it will lead to failures. >> Hence we had to come up with a list of symbols to allow math library symbols to be accesible. >> Also, there are parts of libc library that are static too, and hence those symbols also are present in this list. >> Without this change, the StdLibTest and multiple other tests which make native function calls using FFI, fail with NoSuchElementException. >> >> >> 1. Adding required compiler flags. >> 2. Adding required symbols. >> >> >> JBS-ISSUE : [JDK-8317799](https://bugs.openjdk.org/browse/JDK-8317799) > > suchismith1993 has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits: > > - Remove symbols file after using inline way. > - Provide support for math library in inline way. > - Update symbols-aix-foreign > > Remove comments from export list, causes build failures. > - Symbol Resolution fix for Panama changes. > 1.Adding required compiler flags. > 2. Adding required symbols. Nice! This solution looks better. But, please don't modify the shared version of syslookup.c. You can create one for AIX here: src/java.base/aix/native/libsyslookup ------------- Changes requested by mdoerr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16414#pullrequestreview-1741796785 From duke at openjdk.org Tue Nov 21 13:01:50 2023 From: duke at openjdk.org (suchismith1993) Date: Tue, 21 Nov 2023 13:01:50 GMT Subject: RFR: JDK-8317799 : AIX PPC64: FFI symbol lookup doesn't find symbols [v5] In-Reply-To: References: Message-ID: <9dap2JQR-16gIJUvJwhXqdDcSH1IJr5OSmOkSHNVqSA=.c851717a-f4b1-4213-9bc1-50d8944198ea@github.com> > The math library in AIX specifically, is a static archive. Doing a -lm wont suffice, because when the symbols are looked up using dlsym or accessing native code through Java, it will lead to failures. > Hence we had to come up with a list of symbols to allow math library symbols to be accesible. > Also, there are parts of libc library that are static too, and hence those symbols also are present in this list. > Without this change, the StdLibTest and multiple other tests which make native function calls using FFI, fail with NoSuchElementException. > > > 1. Adding required compiler flags. > 2. Adding required symbols. > > > JBS-ISSUE : [JDK-8317799](https://bugs.openjdk.org/browse/JDK-8317799) suchismith1993 has updated the pull request incrementally with two additional commits since the last revision: - Update Copyright - Revert lookup file in share directory. Add lookup file for AIX specific implementation. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16414/files - new: https://git.openjdk.org/jdk/pull/16414/files/47e5fb5a..e0b22d47 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16414&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16414&range=03-04 Stats: 177 lines in 2 files changed: 0 ins; 176 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/16414.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16414/head:pull/16414 PR: https://git.openjdk.org/jdk/pull/16414 From jlaskey at openjdk.org Tue Nov 21 13:01:31 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Tue, 21 Nov 2023 13:01:31 GMT Subject: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v19] In-Reply-To: References: Message-ID: <4jr199o9QUudtSL9ccL9_wt-4khvBgvEmLg_rXeCfDE=.791b2144-48c6-4ec2-b3a8-cb23ad4a1cb6@github.com> On Tue, 21 Nov 2023 10:38:36 GMT, Pavel Rappo wrote: >> Look at the spec https://bugs.openjdk.org/browse/JDK-8319252 under 7.3 Compilation Units. >> >> - It is not abstract (8.1.1.1 ?). >> - It is final (8.1.1.2 ?). >> - It is a member of an unnamed package (7.4.2 ?) and **has package access**. Its direct superclass is Object (8.1.4 ?). >> - It does not have any direct superinterfaces (8.1.5 ?). >> - The body of the class contains every ClassMemberDeclaration (these are declarations of fields (8.3 ?), methods (8.4 ?), member classes (8.5 ?), and member interfaces (9.1.1.3 ?)) from the simple compilation unit. It is not possible for a simple compilation unit to declare an instance initializer (8.6 ?), static initializer (8.7 ?), or constructor (8.8 ?). >> -It has an implicitly declared default constructor (8.8.9 ?). > > @JimLaskey, in my experiments for JDK-8308715 (Create a mechanism for Implicitly Declared Class javadoc), I found that `javax.lang.model.util.Elements.getOrigin` reports `Origin.EXPLICIT` for the implicitly declared class and `Origin.MANDATED` for that class' constructor. Shouldn't they both be `Origin.MANDATED` because the elements are created from source, not class files, which have some limitations on `ACC_MANDATED`? @pavelrappo Classes can?t be MANDATED. Looking at the code I see that EXPLICIT is the default return value when no other conditions apply. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16461#issuecomment-1820879428 From mdoerr at openjdk.org Tue Nov 21 13:05:13 2023 From: mdoerr at openjdk.org (Martin Doerr) Date: Tue, 21 Nov 2023 13:05:13 GMT Subject: RFR: JDK-8317799 : AIX PPC64: FFI symbol lookup doesn't find symbols [v5] In-Reply-To: <9dap2JQR-16gIJUvJwhXqdDcSH1IJr5OSmOkSHNVqSA=.c851717a-f4b1-4213-9bc1-50d8944198ea@github.com> References: <9dap2JQR-16gIJUvJwhXqdDcSH1IJr5OSmOkSHNVqSA=.c851717a-f4b1-4213-9bc1-50d8944198ea@github.com> Message-ID: <-IlY7XWHL6YpvL6v_ZW-MDOCuT6S1kA9v9Bn66T29dA=.290c0ba1-e8f2-475c-a7ae-d3860f86bde8@github.com> On Tue, 21 Nov 2023 13:01:50 GMT, suchismith1993 wrote: >> The math library in AIX specifically, is a static archive. Doing a -lm wont suffice, because when the symbols are looked up using dlsym or accessing native code through Java, it will lead to failures. >> Hence we had to come up with a list of symbols to allow math library symbols to be accesible. >> Also, there are parts of libc library that are static too, and hence those symbols also are present in this list. >> Without this change, the StdLibTest and multiple other tests which make native function calls using FFI, fail with NoSuchElementException. >> >> >> 1. Adding required compiler flags. >> 2. Adding required symbols. >> >> >> JBS-ISSUE : [JDK-8317799](https://bugs.openjdk.org/browse/JDK-8317799) > > suchismith1993 has updated the pull request incrementally with two additional commits since the last revision: > > - Update Copyright > - Revert lookup file in share directory. > Add lookup file for AIX specific implementation. Thanks! This looks good, now. One question: Are all the `#include`s needed? ------------- Marked as reviewed by mdoerr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16414#pullrequestreview-1741972916 From duke at openjdk.org Tue Nov 21 13:07:35 2023 From: duke at openjdk.org (Ryan Wallace) Date: Tue, 21 Nov 2023 13:07:35 GMT Subject: RFR: 8318971:Better Error Handling for Jar Tool Processing of "@File" [v4] In-Reply-To: References: Message-ID: > Hi all, > > Please review this fix for jar tool not producing an archive if there is a missing file supplied. > The current behaviour will recognise missing files as an error but continue processing, > creating a temporary archive and then deleting it without moving to the current directory. > The fix is to return false when a missing file is supplied and exit immediately without continuing with any wasted processing. > > Thanks, > Ryan. Ryan Wallace has updated the pull request with a new target base 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: - 8318971: Better Error Handling for Jar Tool Processing of "@File" - Merge branch 'master' into 8318971 - Merge branch 'master' into 8318971 - 8318971: jar v17 should either exit on error immediately or create archive as jar v1.8 did - 8318971: jar v17 should either exit on error immediately or create archive as jar v1.8 did - Merge branch 'master' into 8318971 - 8318971: jar v17 should either exit on error immediately or create archive as jar v1.8 did - 8318971: jar v17 should either exit on error immediately or create archive as jar v1.8 did ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16423/files - new: https://git.openjdk.org/jdk/pull/16423/files/c7b18741..cee20934 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16423&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16423&range=02-03 Stats: 632825 lines in 1230 files changed: 90078 ins; 478477 del; 64270 mod Patch: https://git.openjdk.org/jdk/pull/16423.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16423/head:pull/16423 PR: https://git.openjdk.org/jdk/pull/16423 From eliu at openjdk.org Tue Nov 21 13:24:34 2023 From: eliu at openjdk.org (Eric Liu) Date: Tue, 21 Nov 2023 13:24:34 GMT Subject: RFR: 8319872: AArch64: [vectorapi] Implementation of unsigned (zero extended) casts [v3] In-Reply-To: References: Message-ID: > Vector API defines zero-extend operations [1], which are going to be intrinsified and generated to `VectorUCastNode` by C2. This patch adds backend implementation for `VectorUCastNode` on AArch64. > > The micro benchmark shows significant performance improvement. In my test machine (SVE, 256-bit), the result is shown as below: > > > > Benchmark Before After Units Gain > VectorZeroExtend.byte2Int 3168.251 243012.399 ops/ms 75.70 > VectorZeroExtend.byte2Long 3212.201 216291.588 ops/ms 66.33 > VectorZeroExtend.byte2Short 3391.968 182655.365 ops/ms 52.85 > VectorZeroExtend.int2Long 1012.197 80448.553 ops/ms 78.48 > VectorZeroExtend.short2Int 1812.471 153416.828 ops/ms 83.65 > VectorZeroExtend.short2Long 1788.382 129794.814 ops/ms 71.58 > > > On other Neon systems, we can get similar performance boost as a result of intrinsification success. > > Since `VectorUCastNode` only used in Vector API's zero extension currently, this patch also adds assertion on nodes' definitions to clarify their usages. > > [TEST] > compiler/vectorapi and jdk/incubator/vector passed on NEON and SVE machines. > > [1] https://github.com/openjdk/jdk/blob/master/src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorOperators.java#L726 Eric Liu has updated the pull request incrementally with one additional commit since the last revision: add _sve_xunpk & remove dead code Change-Id: Ic19836feb8a73ea7e65443794f2a0eb1363f6e2f ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16670/files - new: https://git.openjdk.org/jdk/pull/16670/files/4fb3128f..68748e7f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16670&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16670&range=01-02 Stats: 85 lines in 2 files changed: 17 ins; 32 del; 36 mod Patch: https://git.openjdk.org/jdk/pull/16670.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16670/head:pull/16670 PR: https://git.openjdk.org/jdk/pull/16670 From eliu at openjdk.org Tue Nov 21 13:32:05 2023 From: eliu at openjdk.org (Eric Liu) Date: Tue, 21 Nov 2023 13:32:05 GMT Subject: RFR: 8319872: AArch64: [vectorapi] Implementation of unsigned (zero extended) casts [v2] In-Reply-To: <_i1HpqtJBEarrwnOEQ4l1mgaNeqfJv59Aq5if7e_heU=.9bd7cd18-8e26-46a4-a7be-188c73121f0f@github.com> References: <_i1HpqtJBEarrwnOEQ4l1mgaNeqfJv59Aq5if7e_heU=.9bd7cd18-8e26-46a4-a7be-188c73121f0f@github.com> Message-ID: On Mon, 20 Nov 2023 09:26:43 GMT, Eric Liu wrote: >> src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp line 1415: >> >>> 1413: break; >>> 1414: case S: >>> 1415: (this->*unpklo)(dst, H, src); >> >> AS above: try making` is_unsigned` a parameter. > > Got it. I will fix it soon. Thanks! compiler/vectorapi and jdk/incubator/vector passed. Full test is running. I would report the result when it has been finished. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16670#discussion_r1400602423 From ihse at openjdk.org Tue Nov 21 13:51:18 2023 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 21 Nov 2023 13:51:18 GMT Subject: RFR: JDK-8317799 : AIX PPC64: FFI symbol lookup doesn't find symbols [v5] In-Reply-To: <9dap2JQR-16gIJUvJwhXqdDcSH1IJr5OSmOkSHNVqSA=.c851717a-f4b1-4213-9bc1-50d8944198ea@github.com> References: <9dap2JQR-16gIJUvJwhXqdDcSH1IJr5OSmOkSHNVqSA=.c851717a-f4b1-4213-9bc1-50d8944198ea@github.com> Message-ID: On Tue, 21 Nov 2023 13:01:50 GMT, suchismith1993 wrote: >> The math library in AIX specifically, is a static archive. Doing a -lm wont suffice, because when the symbols are looked up using dlsym or accessing native code through Java, it will lead to failures. >> Hence we had to come up with a list of symbols to allow math library symbols to be accesible. >> Also, there are parts of libc library that are static too, and hence those symbols also are present in this list. >> Without this change, the StdLibTest and multiple other tests which make native function calls using FFI, fail with NoSuchElementException. >> >> >> 1. Adding required compiler flags. >> 2. Adding required symbols. >> >> >> JBS-ISSUE : [JDK-8317799](https://bugs.openjdk.org/browse/JDK-8317799) > > suchismith1993 has updated the pull request incrementally with two additional commits since the last revision: > > - Update Copyright > - Revert lookup file in share directory. > Add lookup file for AIX specific implementation. This looks like a much saner solution than the original attempt. src/java.base/aix/native/libsyslookup/syslookup.c line 33: > 31: #include > 32: > 33: // Simple dummy function so this library appears as a normal library to tooling. I assume this comment should be on line 207 instead..? ------------- PR Comment: https://git.openjdk.org/jdk/pull/16414#issuecomment-1820957256 PR Review Comment: https://git.openjdk.org/jdk/pull/16414#discussion_r1400626367 From mdoerr at openjdk.org Tue Nov 21 13:51:20 2023 From: mdoerr at openjdk.org (Martin Doerr) Date: Tue, 21 Nov 2023 13:51:20 GMT Subject: RFR: JDK-8317799 : AIX PPC64: FFI symbol lookup doesn't find symbols [v5] In-Reply-To: <9dap2JQR-16gIJUvJwhXqdDcSH1IJr5OSmOkSHNVqSA=.c851717a-f4b1-4213-9bc1-50d8944198ea@github.com> References: <9dap2JQR-16gIJUvJwhXqdDcSH1IJr5OSmOkSHNVqSA=.c851717a-f4b1-4213-9bc1-50d8944198ea@github.com> Message-ID: On Tue, 21 Nov 2023 13:01:50 GMT, suchismith1993 wrote: >> The math library in AIX specifically, is a static archive. Doing a -lm wont suffice, because when the symbols are looked up using dlsym or accessing native code through Java, it will lead to failures. >> Hence we had to come up with a list of symbols to allow math library symbols to be accesible. >> Also, there are parts of libc library that are static too, and hence those symbols also are present in this list. >> Without this change, the StdLibTest and multiple other tests which make native function calls using FFI, fail with NoSuchElementException. >> >> >> 1. Adding required compiler flags. >> 2. Adding required symbols. >> >> >> JBS-ISSUE : [JDK-8317799](https://bugs.openjdk.org/browse/JDK-8317799) > > suchismith1993 has updated the pull request incrementally with two additional commits since the last revision: > > - Update Copyright > - Revert lookup file in share directory. > Add lookup file for AIX specific implementation. src/java.base/aix/native/libsyslookup/syslookup.c line 209: > 207: char* syslookup() { > 208: return "syslookup"; > 209: } This is probably not needed, either (see Windows version). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16414#discussion_r1400629119 From asotona at openjdk.org Tue Nov 21 14:06:18 2023 From: asotona at openjdk.org (Adam Sotona) Date: Tue, 21 Nov 2023 14:06:18 GMT Subject: RFR: 8320360: ClassFile.parse: Some defect class files cause unexpected exceptions to be thrown Message-ID: ClassFile API throws `IndexOutOfBoundsException` when classfile structure is corrupted so the parser attempts to read beyond the classfile bounds. General contract is that only `IllegalArgumentException` or its subclasses is expected when parser fails. This patch wraps `IndexOutOfBoundsExceptions` thrown from all `ClassReaderImpl.buffer` manipulations into an `IllegalArgumentException("Reading beyond classfile bounds", iOOBECause)`. Relevant tests are added. Please review. Thanks, Adam ------------- Commit messages: - added bug # to the test - 8320360: ClassFile.parse: Some defect class files cause unexpected exceptions to be thrown Changes: https://git.openjdk.org/jdk/pull/16762/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16762&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8320360 Stats: 69 lines in 2 files changed: 47 ins; 0 del; 22 mod Patch: https://git.openjdk.org/jdk/pull/16762.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16762/head:pull/16762 PR: https://git.openjdk.org/jdk/pull/16762 From ihse at openjdk.org Tue Nov 21 14:16:11 2023 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 21 Nov 2023 14:16:11 GMT Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations with SLEEF [v3] In-Reply-To: References: Message-ID: On Mon, 20 Nov 2023 01:47:34 GMT, Xiaohong Gong wrote: >> make/autoconf/lib-vmath.m4 line 92: >> >>> 90: [] >>> 91: ) >>> 92: AC_MSG_RESULT([${SVE_FEATURE_SUPPORT}]) >> >> What is this test even for? I can't see any usage of SVE_FEATURE_SUPPORT outside this function. > > This is just used to print the result of `AC_MSG_CEHCKING[if ARM SVE feature is supported]` in configure. Ah, now I se what you are trying to do here. First of all, in the detection part, only set `SVE_FEATURE_SUPPORT`. Then you can handle the `SVE_CFLAGS` addition elsewhere/later. Secondly, you should not mix these `SVE_CFLAGS` with the spleef C flags. Keeping them separate will allow for LIBSLEEF_CFLAGS to be named just that. Thirdly, I do not like at all how you just come crashing in setting `-march` like that. The `-march` flag is handled by `FLAGS_SETUP_ABI_PROFILE`. Actually, now that I think of it, this is just completely wrong! You are checking on features on the build machine, to determine what target machine code to generate, with no way to override. You need to break out the -march handling separately. It should be moved to FLAGS_SETUP_ABI_PROFILE. I'm guessing you will need to make something like a `aarch64-sve` profile, and possibly try to auto-select it based on the result of the sve test program above. But changing `OPENJDK_TARGET_ABI_PROFILE` can have further consequences; I do not know the full extent on the top of my head. >> make/autoconf/libraries.m4 line 129: >> >>> 127: LIB_SETUP_LIBFFI >>> 128: LIB_SETUP_MISC_LIBS >>> 129: LIB_SETUP_VMATH >> >> The function (and file) should be named after "sleef", not "vmath". > > Yes, it seems weird. But the library we want to built out is `libvmath.so` instead of `libsleef.so`. And we not only check the sleef library, but also the ARM SVE feature inside it. So using `VMATH` suffix is more reasonable to me. WDYT? As I said above, you should not mix the two together. Keep the library handling for libsleef. Move the march setting to where it belongs. And rename the files, functions and variables after this. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16234#discussion_r1400663476 PR Review Comment: https://git.openjdk.org/jdk/pull/16234#discussion_r1400665010 From dl at openjdk.org Tue Nov 21 14:36:33 2023 From: dl at openjdk.org (Doug Lea) Date: Tue, 21 Nov 2023 14:36:33 GMT Subject: RFR: JDK-8319662 ForkJoinPool trims worker threads too slowly [v2] In-Reply-To: References: Message-ID: > This update cascades timeouts to trim subsequent workers after the first keepAlive inactive period. Doug Lea has updated the pull request incrementally with one additional commit since the last revision: tweak cascades; reinstate an @Contended; resolve JDK-8319498 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16725/files - new: https://git.openjdk.org/jdk/pull/16725/files/bd5df5ea..a3c96c6a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16725&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16725&range=00-01 Stats: 56 lines in 1 file changed: 20 ins; 5 del; 31 mod Patch: https://git.openjdk.org/jdk/pull/16725.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16725/head:pull/16725 PR: https://git.openjdk.org/jdk/pull/16725 From darcy at openjdk.org Tue Nov 21 14:43:26 2023 From: darcy at openjdk.org (Joe Darcy) Date: Tue, 21 Nov 2023 14:43:26 GMT Subject: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v19] In-Reply-To: References: Message-ID: On Tue, 21 Nov 2023 10:38:36 GMT, Pavel Rappo wrote: >> Look at the spec https://bugs.openjdk.org/browse/JDK-8319252 under 7.3 Compilation Units. >> >> - It is not abstract (8.1.1.1 ?). >> - It is final (8.1.1.2 ?). >> - It is a member of an unnamed package (7.4.2 ?) and **has package access**. Its direct superclass is Object (8.1.4 ?). >> - It does not have any direct superinterfaces (8.1.5 ?). >> - The body of the class contains every ClassMemberDeclaration (these are declarations of fields (8.3 ?), methods (8.4 ?), member classes (8.5 ?), and member interfaces (9.1.1.3 ?)) from the simple compilation unit. It is not possible for a simple compilation unit to declare an instance initializer (8.6 ?), static initializer (8.7 ?), or constructor (8.8 ?). >> -It has an implicitly declared default constructor (8.8.9 ?). > > @JimLaskey, in my experiments for JDK-8308715 (Create a mechanism for Implicitly Declared Class javadoc), I found that `javax.lang.model.util.Elements.getOrigin` reports `Origin.EXPLICIT` for the implicitly declared class and `Origin.MANDATED` for that class' constructor. Shouldn't they both be `Origin.MANDATED` because the elements are created from source, not class files, which have some limitations on `ACC_MANDATED`? > @pavelrappo Classes can?t be MANDATED. Looking at the code I see that EXPLICIT is the default return value when no other conditions apply. While it is true that the class file format cannot capture MANDATED status for classes, that doesn't necessarily imply mandated-ness shouldn't be track for classes created from sources while inside javac. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16461#issuecomment-1821055805 From aph at openjdk.org Tue Nov 21 14:52:09 2023 From: aph at openjdk.org (Andrew Haley) Date: Tue, 21 Nov 2023 14:52:09 GMT Subject: RFR: 8319872: AArch64: [vectorapi] Implementation of unsigned (zero extended) casts [v3] In-Reply-To: References: Message-ID: <2a0rAGSjl418fCuDKr77yxcSiviewvwa7dmnogUGjZM=.94b28304-3d1d-44da-9e73-248586244e42@github.com> On Tue, 21 Nov 2023 13:24:34 GMT, Eric Liu wrote: >> Vector API defines zero-extend operations [1], which are going to be intrinsified and generated to `VectorUCastNode` by C2. This patch adds backend implementation for `VectorUCastNode` on AArch64. >> >> The micro benchmark shows significant performance improvement. In my test machine (SVE, 256-bit), the result is shown as below: >> >> >> >> Benchmark Before After Units Gain >> VectorZeroExtend.byte2Int 3168.251 243012.399 ops/ms 75.70 >> VectorZeroExtend.byte2Long 3212.201 216291.588 ops/ms 66.33 >> VectorZeroExtend.byte2Short 3391.968 182655.365 ops/ms 52.85 >> VectorZeroExtend.int2Long 1012.197 80448.553 ops/ms 78.48 >> VectorZeroExtend.short2Int 1812.471 153416.828 ops/ms 83.65 >> VectorZeroExtend.short2Long 1788.382 129794.814 ops/ms 71.58 >> >> >> On other Neon systems, we can get similar performance boost as a result of intrinsification success. >> >> Since `VectorUCastNode` only used in Vector API's zero extension currently, this patch also adds assertion on nodes' definitions to clarify their usages. >> >> [TEST] >> compiler/vectorapi and jdk/incubator/vector passed on NEON and SVE machines. >> >> [1] https://github.com/openjdk/jdk/blob/master/src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorOperators.java#L726 > > Eric Liu has updated the pull request incrementally with one additional commit since the last revision: > > add _sve_xunpk & remove dead code > > Change-Id: Ic19836feb8a73ea7e65443794f2a0eb1363f6e2f src/hotspot/cpu/aarch64/assembler_aarch64.hpp line 3872: > 3870: void sve_sunpklo(FloatRegister Zd, SIMD_RegVariant T, FloatRegister Zn) { > 3871: _sve_xunpk(/* is_unsigned */ false, /* is_high */ false, Zd, T, Zn); > 3872: } This code expansion does not look right. You should be able to make this change without so much code expansion. #define INSN(NAME, unsigned, high) void name(FloatRegister Zd, SIMD_RegVariant T, FloatRegister Zn) { \ _sve_xunpk(unsigned, high, T, Zn); \ } INSN(sve_uunpkhi, true, true) ... ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16670#discussion_r1400716627 From dl at openjdk.org Tue Nov 21 15:03:10 2023 From: dl at openjdk.org (Doug Lea) Date: Tue, 21 Nov 2023 15:03:10 GMT Subject: RFR: JDK-8319662 ForkJoinPool trims worker threads too slowly [v2] In-Reply-To: <24lkVT4KYkoULx16ZEgpOTNBJ3B5-pDJRvDck9aswnQ=.651f1e61-27ad-4329-a87a-d6d0778801cc@github.com> References: <24lkVT4KYkoULx16ZEgpOTNBJ3B5-pDJRvDck9aswnQ=.651f1e61-27ad-4329-a87a-d6d0778801cc@github.com> Message-ID: On Mon, 20 Nov 2023 14:28:15 GMT, Viktor Klang wrote: >> It would be better, but absolute-time Unsafe.park only operates at millisecond accuracy (and even at that may misfire early, requiring TIMEOUT_SLOP.) > > I was thinking more about cases where system clock moves backwards in time. (currentTimeMillis() isn't spec:ed to be monotonic, right?) Yes. But because this is a performance not correctness issue, it's OK to (rarely) speed up or slow down trims. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16725#discussion_r1400732882 From aph at openjdk.org Tue Nov 21 15:10:14 2023 From: aph at openjdk.org (Andrew Haley) Date: Tue, 21 Nov 2023 15:10:14 GMT Subject: RFR: 8319872: AArch64: [vectorapi] Implementation of unsigned (zero extended) casts [v3] In-Reply-To: References: Message-ID: On Tue, 21 Nov 2023 13:24:34 GMT, Eric Liu wrote: >> Vector API defines zero-extend operations [1], which are going to be intrinsified and generated to `VectorUCastNode` by C2. This patch adds backend implementation for `VectorUCastNode` on AArch64. >> >> The micro benchmark shows significant performance improvement. In my test machine (SVE, 256-bit), the result is shown as below: >> >> >> >> Benchmark Before After Units Gain >> VectorZeroExtend.byte2Int 3168.251 243012.399 ops/ms 75.70 >> VectorZeroExtend.byte2Long 3212.201 216291.588 ops/ms 66.33 >> VectorZeroExtend.byte2Short 3391.968 182655.365 ops/ms 52.85 >> VectorZeroExtend.int2Long 1012.197 80448.553 ops/ms 78.48 >> VectorZeroExtend.short2Int 1812.471 153416.828 ops/ms 83.65 >> VectorZeroExtend.short2Long 1788.382 129794.814 ops/ms 71.58 >> >> >> On other Neon systems, we can get similar performance boost as a result of intrinsification success. >> >> Since `VectorUCastNode` only used in Vector API's zero extension currently, this patch also adds assertion on nodes' definitions to clarify their usages. >> >> [TEST] >> compiler/vectorapi and jdk/incubator/vector passed on NEON and SVE machines. >> >> [1] https://github.com/openjdk/jdk/blob/master/src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorOperators.java#L726 > > Eric Liu has updated the pull request incrementally with one additional commit since the last revision: > > add _sve_xunpk & remove dead code > > Change-Id: Ic19836feb8a73ea7e65443794f2a0eb1363f6e2f src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp line 1412: > 1410: _sve_xunpk(is_unsigned, /* is_high */ false, dst, S, dst); > 1411: _sve_xunpk(is_unsigned, /* is_high */ false, dst, D, dst); > 1412: break; Why is this change here? It doesn't do anything. Does it? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16670#discussion_r1400743499 From robilad at openjdk.org Tue Nov 21 15:17:10 2023 From: robilad at openjdk.org (Dalibor Topic) Date: Tue, 21 Nov 2023 15:17:10 GMT Subject: RFR: 8319577: x86_64 AVX2 intrinsics for Arrays.sort methods (int, float arrays) [v2] In-Reply-To: References: Message-ID: On Thu, 16 Nov 2023 07:09:31 GMT, David Holmes wrote: >> Srinivas Vamsi Parasa has updated the pull request with a new target base 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: >> >> - Disable AVX2 sort for 64-bit types >> - Merge branch 'master' of https://git.openjdk.java.net/jdk into simdsort >> - fix jcheck failures due to windows encoding >> - fix carriage return and change insertion sort thresholds >> - fix formatting and white spaces >> - cleanup unused code >> - fix insertion sort thresholds >> - add insertion sort >> - fix headers >> - revert to xss-common-qsort >> - ... and 1 more: https://git.openjdk.org/jdk/compare/d6a8ebf0...08307b6a > > src/java.base/linux/native/libsimdsort/avx2-32bit-qsort.hpp line 3: > >> 1: /* >> 2: * Copyright (c) 2021, 2023, Intel Corporation. All rights reserved. >> 3: * Copyright (c) 2021 Serge Sans Paille. All rights reserved. > > Is this person an OpenJDK Contributor? Not listed here: https://oca.opensource.oracle.com/?ojr=contributors ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16534#discussion_r1400753295 From rriggs at openjdk.org Tue Nov 21 15:26:51 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 21 Nov 2023 15:26:51 GMT Subject: RFR: 8311906: Improve robustness of String constructors with mutable array inputs [v11] In-Reply-To: <6SKlGLh5MmxoEx07wHCCUc8KWbbhcspLJmcc1uxQ_FI=.ca33bfb4-fa5c-45f0-b49f-ee6c5c6b68b4@github.com> References: <6SKlGLh5MmxoEx07wHCCUc8KWbbhcspLJmcc1uxQ_FI=.ca33bfb4-fa5c-45f0-b49f-ee6c5c6b68b4@github.com> Message-ID: > Strings, after construction, are immutable but may be constructed from mutable arrays of bytes, characters, or integers. > The string constructors should guard against the effects of mutating the arrays during construction that might invalidate internal invariants for the correct behavior of operations on the resulting strings. In particular, a number of operations have optimizations for operations on pairs of latin1 strings and pairs of non-latin1 strings, while operations between latin1 and non-latin1 strings use a more general implementation. > > The changes include: > > - Adding a warning to each constructor with an array as an argument to indicate that the results are indeterminate > if the input array is modified before the constructor returns. > The resulting string may contain any combination of characters sampled from the input array. > > - Ensure that strings that are represented as non-latin1 contain at least one non-latin1 character. > For latin1 inputs, whether the arrays contain ASCII, ISO-8859-1, UTF8, or another encoding decoded to latin1 the scanning and compression is unchanged. > If a non-latin1 character is found, the string is represented as non-latin1 with the added verification that a non-latin1 character is present at the same index. > If that character is found to be latin1, then the input array has been modified and the result of the scan may be incorrect. > Though a ConcurrentModificationException could be thrown, the risk to an existing application of an unexpected exception should be avoided. > Instead, the non-latin1 copy of the input is re-scanned and compressed; that scan determines whether the latin1 or the non-latin1 representation is returned. > > - The methods that scan for non-latin1 characters and their intrinsic implementations are updated to return the index of the non-latin1 character. > > - String construction from StringBuilder and CharSequence must also be guarded as their contents may be modified during construction. Roger Riggs has updated the pull request incrementally with two additional commits since the last revision: - Merge pull request #4 from cl4es/8311906_x64_intr_opt Simplified and slightly optimized x86 char_array_compress - Simplified and slightly optimized x86 char_array_compress ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16425/files - new: https://git.openjdk.org/jdk/pull/16425/files/04d58779..0256b9e0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16425&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16425&range=09-10 Stats: 61 lines in 1 file changed: 7 ins; 20 del; 34 mod Patch: https://git.openjdk.org/jdk/pull/16425.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16425/head:pull/16425 PR: https://git.openjdk.org/jdk/pull/16425 From alanb at openjdk.org Tue Nov 21 15:37:31 2023 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 21 Nov 2023 15:37:31 GMT Subject: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v30] In-Reply-To: References: Message-ID: On Mon, 20 Nov 2023 20:45:22 GMT, Jim Laskey wrote: >> Address changes from JEP 445 to JEP 463. >> >> - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. >> >> - Don't mark class on read. >> >> - Remove reflection and annotation processing related to unnamed classes. >> >> - Simplify main method search. > > Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: > > Update test src/java.base/share/classes/java/lang/Class.java line 4847: > 4845: @PreviewFeature(feature=PreviewFeature.Feature.IMPLICIT_CLASSES) > 4846: @CallerSensitive > 4847: public Method findMainMethod() { Renaming it to findMainMethod separates it from the existing getXXXMethod methods (good) but it makes it more obvious that this is a method for launchers. I'm not 100% sure that java.lang.Class is the right place for this, it feels out of place. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16461#discussion_r1400785014 From alanb at openjdk.org Tue Nov 21 16:39:07 2023 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 21 Nov 2023 16:39:07 GMT Subject: RFR: 8319668: Fixup of jar filename typo in BadFactoryTest.sh In-Reply-To: References: Message-ID: On Thu, 9 Nov 2023 16:49:41 GMT, Gaurav Chaudhari wrote: > The file test/jdk/javax/script/JDK_8196959/BadFactoryTest.sh contains a typo. When running without security manager, the test references 'badfactoty.jar' instead of 'badfactory.jar'. This change addresses this by correcting the jar name. Looks okay. This test is begging to be re-written in Java, maybe some day. I assume the copyright header will be updated before this change is integrated. ------------- Marked as reviewed by alanb (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16585#pullrequestreview-1742482324 From shade at openjdk.org Tue Nov 21 17:01:12 2023 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 21 Nov 2023 17:01:12 GMT Subject: RFR: 8318776: Require supports_cx8 to always be true [v4] In-Reply-To: References: Message-ID: On Tue, 21 Nov 2023 06:03:38 GMT, Erik ?sterlund wrote: >> David Holmes has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove unnecessary includes of vm_version.hpp. >> Fix copyright years. > > This looks great! > Thanks for the review @fisk ! I have to wait for a few Zero related PRs to get integrated then re-merge, before I can integrate. Zero patches were pushed, please re-merge. I checked current mainline works well with at least linux-arm-zero-fastdebug, and I would like to re-test it with this patch. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16625#issuecomment-1821309132 From duke at openjdk.org Tue Nov 21 17:03:24 2023 From: duke at openjdk.org (Shaojin Wen) Date: Tue, 21 Nov 2023 17:03:24 GMT Subject: Integrated: 8317742: ISO Standard Date Format implementation consistency on DateTimeFormatter and String.format In-Reply-To: References: Message-ID: On Tue, 3 Oct 2023 21:37:46 GMT, Shaojin Wen wrote: > j.u.Formatter now prints "%tF" (iso standard date) and the result is incorrect when processing year < 0 or year > 9999 This pull request has now been integrated. Changeset: 61d81d64 Author: Shaojin Wen Committer: Naoto Sato URL: https://git.openjdk.org/jdk/commit/61d81d6496a38e43a6039abc041b67626f06f5c9 Stats: 83 lines in 2 files changed: 81 ins; 0 del; 2 mod 8317742: ISO Standard Date Format implementation consistency on DateTimeFormatter and String.format Reviewed-by: rriggs, naoto ------------- PR: https://git.openjdk.org/jdk/pull/16033 From dl at openjdk.org Tue Nov 21 17:12:39 2023 From: dl at openjdk.org (Doug Lea) Date: Tue, 21 Nov 2023 17:12:39 GMT Subject: RFR: JDK-8319662 ForkJoinPool trims worker threads too slowly [v3] In-Reply-To: References: Message-ID: > This update cascades timeouts to trim subsequent workers after the first keepAlive inactive period. 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 three additional commits since the last revision: - Merge branch 'openjdk:master' into JDK-8319662 - tweak cascades; reinstate an @Contended; resolve JDK-8319498 - Support cascading idle timeouts ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16725/files - new: https://git.openjdk.org/jdk/pull/16725/files/a3c96c6a..6d352608 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16725&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16725&range=01-02 Stats: 6770 lines in 217 files changed: 3887 ins; 868 del; 2015 mod Patch: https://git.openjdk.org/jdk/pull/16725.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16725/head:pull/16725 PR: https://git.openjdk.org/jdk/pull/16725 From abimpoudis at openjdk.org Tue Nov 21 17:21:33 2023 From: abimpoudis at openjdk.org (Aggelos Biboudis) Date: Tue, 21 Nov 2023 17:21:33 GMT Subject: RFR: 8303374: Compiler Implementation for Primitive types in patterns, instanceof, and switch (Preview) [v33] In-Reply-To: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com> References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com> Message-ID: > This is the proposed patch for Primitive types in patterns, instanceof, and switch (Preview). > > Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/latest/ Aggelos Biboudis has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 39 commits: - Merge branch 'master' into primitive-patterns - Merge branch 'master' into primitive-patterns - Merge branch 'master' into primitive-patterns - Merge branch 'master' into primitive-patterns - Small cleanup in PrimitivePatternsSwitch - Add test for instanceof as a pattern on with record patterns - Merge branch 'master' into primitive-patterns # Conflicts: # src/jdk.compiler/share/classes/com/sun/tools/javac/code/Preview.java # src/jdk.compiler/share/classes/com/sun/tools/javac/code/Source.java - Add tests for new data types in switch statements - Fix Bootstrap initialization error by using `explicitCastArguments` for integral tests - Fix SwitchBootstraps for pattern matching over longs - ... and 29 more: https://git.openjdk.org/jdk/compare/61d81d64...2b2405cc ------------- Changes: https://git.openjdk.org/jdk/pull/15638/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=32 Stats: 3199 lines in 41 files changed: 2943 ins; 111 del; 145 mod Patch: https://git.openjdk.org/jdk/pull/15638.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15638/head:pull/15638 PR: https://git.openjdk.org/jdk/pull/15638 From tprinzing at openjdk.org Tue Nov 21 17:30:20 2023 From: tprinzing at openjdk.org (Tim Prinzing) Date: Tue, 21 Nov 2023 17:30:20 GMT Subject: RFR: 8319571: Update jni/nullCaller/NullCallerTest.java to accept flags or mark as flagless [v2] In-Reply-To: References: Message-ID: > Marked as flagless. Tim Prinzing has updated the pull request with a new target base 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: - use ProcessTools helper class to run test. - Merge branch 'master' into JDK-8319571 - Merge branch 'master' into JDK-8319571 - 8319571: Update jni/nullCaller/NullCallerTest.java to accept flags or mark as flagless Marked as flagless. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16711/files - new: https://git.openjdk.org/jdk/pull/16711/files/bbcbb810..b947469b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16711&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16711&range=00-01 Stats: 12689 lines in 337 files changed: 6298 ins; 3150 del; 3241 mod Patch: https://git.openjdk.org/jdk/pull/16711.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16711/head:pull/16711 PR: https://git.openjdk.org/jdk/pull/16711 From duke at openjdk.org Tue Nov 21 17:49:43 2023 From: duke at openjdk.org (suchismith1993) Date: Tue, 21 Nov 2023 17:49:43 GMT Subject: RFR: JDK-8317799 : AIX PPC64: FFI symbol lookup doesn't find symbols [v6] In-Reply-To: References: Message-ID: > The math library in AIX specifically, is a static archive. Doing a -lm wont suffice, because when the symbols are looked up using dlsym or accessing native code through Java, it will lead to failures. > Hence we had to come up with a list of symbols to allow math library symbols to be accesible. > Also, there are parts of libc library that are static too, and hence those symbols also are present in this list. > Without this change, the StdLibTest and multiple other tests which make native function calls using FFI, fail with NoSuchElementException. > > > 1. Adding required compiler flags. > 2. Adding required symbols. > > > JBS-ISSUE : [JDK-8317799](https://bugs.openjdk.org/browse/JDK-8317799) suchismith1993 has updated the pull request incrementally with two additional commits since the last revision: - Comments - Change comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16414/files - new: https://git.openjdk.org/jdk/pull/16414/files/e0b22d47..48a69c59 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16414&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16414&range=04-05 Stats: 5 lines in 1 file changed: 0 ins; 4 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/16414.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16414/head:pull/16414 PR: https://git.openjdk.org/jdk/pull/16414 From prr at openjdk.org Tue Nov 21 17:49:37 2023 From: prr at openjdk.org (Phil Race) Date: Tue, 21 Nov 2023 17:49:37 GMT Subject: Integrated: 8318364: Add an FFM-based implementation of harfbuzz OpenType layout In-Reply-To: References: Message-ID: On Tue, 29 Aug 2023 22:04:40 GMT, Phil Race wrote: > 8318364: Add an FFM-based implementation of harfbuzz OpenType layout This pull request has now been integrated. Changeset: f69e6653 Author: Phil Race URL: https://git.openjdk.org/jdk/commit/f69e6653f86a7dd781db6c8523f114c0d3f7ccbc Stats: 1376 lines in 7 files changed: 1373 ins; 0 del; 3 mod 8318364: Add an FFM-based implementation of harfbuzz OpenType layout Reviewed-by: jdv, psadhukhan ------------- PR: https://git.openjdk.org/jdk/pull/15476 From jlaskey at openjdk.org Tue Nov 21 17:52:49 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Tue, 21 Nov 2023 17:52:49 GMT Subject: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v31] In-Reply-To: References: Message-ID: > Address changes from JEP 445 to JEP 463. > > - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. > > - Don't mark class on read. > > - Remove reflection and annotation processing related to unnamed classes. > > - Simplify main method search. Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: Update Class.java ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16461/files - new: https://git.openjdk.org/jdk/pull/16461/files/b14c6a54..fd0c92f8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16461&range=30 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16461&range=29-30 Stats: 34 lines in 1 file changed: 9 ins; 17 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/16461.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16461/head:pull/16461 PR: https://git.openjdk.org/jdk/pull/16461 From mdoerr at openjdk.org Tue Nov 21 17:59:23 2023 From: mdoerr at openjdk.org (Martin Doerr) Date: Tue, 21 Nov 2023 17:59:23 GMT Subject: RFR: JDK-8317799 : AIX PPC64: FFI symbol lookup doesn't find symbols [v6] In-Reply-To: References: Message-ID: <1F0WHhtB_8Pfz-Pq6lvezgjj4A4qcMqvhuFBq--ulMY=.b8aa508c-2eef-4cd6-a180-4fa0f9b8d700@github.com> On Tue, 21 Nov 2023 17:49:43 GMT, suchismith1993 wrote: >> The math library in AIX specifically, is a static archive. Doing a -lm wont suffice, because when the symbols are looked up using dlsym or accessing native code through Java, it will lead to failures. >> Hence we had to come up with a list of symbols to allow math library symbols to be accesible. >> Also, there are parts of libc library that are static too, and hence those symbols also are present in this list. >> Without this change, the StdLibTest and multiple other tests which make native function calls using FFI, fail with NoSuchElementException. >> >> >> 1. Adding required compiler flags. >> 2. Adding required symbols. >> >> >> JBS-ISSUE : [JDK-8317799](https://bugs.openjdk.org/browse/JDK-8317799) > > suchismith1993 has updated the pull request incrementally with two additional commits since the last revision: > > - Comments > - Change comments src/java.base/aix/native/libsyslookup/syslookup.c line 30: > 28: #include > 29: #include > 30: #include Are string.h and stdlib.h needed? I can't see them in the comments below. src/java.base/aix/native/libsyslookup/syslookup.c line 33: > 31: #include > 32: > 33: // Addresses of functions to referenced using static linking. What does "functions to referenced" mean? Typo? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16414#discussion_r1400959365 PR Review Comment: https://git.openjdk.org/jdk/pull/16414#discussion_r1400961995 From duke at openjdk.org Tue Nov 21 17:59:24 2023 From: duke at openjdk.org (suchismith1993) Date: Tue, 21 Nov 2023 17:59:24 GMT Subject: RFR: JDK-8317799 : AIX PPC64: FFI symbol lookup doesn't find symbols [v6] In-Reply-To: <1F0WHhtB_8Pfz-Pq6lvezgjj4A4qcMqvhuFBq--ulMY=.b8aa508c-2eef-4cd6-a180-4fa0f9b8d700@github.com> References: <1F0WHhtB_8Pfz-Pq6lvezgjj4A4qcMqvhuFBq--ulMY=.b8aa508c-2eef-4cd6-a180-4fa0f9b8d700@github.com> Message-ID: On Tue, 21 Nov 2023 17:50:04 GMT, Martin Doerr wrote: >> suchismith1993 has updated the pull request incrementally with two additional commits since the last revision: >> >> - Comments >> - Change comments > > src/java.base/aix/native/libsyslookup/syslookup.c line 30: > >> 28: #include >> 29: #include >> 30: #include > > Are string.h and stdlib.h needed? I can't see them in the comments below. string.h is needed for strlen. Let me check for stdlib.h by excluding it. > src/java.base/aix/native/libsyslookup/syslookup.c line 33: > >> 31: #include >> 32: >> 33: // Addresses of functions to referenced using static linking. > > What does "functions to referenced" mean? Typo? To be Referenced*. Is that the right comment ? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16414#discussion_r1400964039 PR Review Comment: https://git.openjdk.org/jdk/pull/16414#discussion_r1400964522 From mdoerr at openjdk.org Tue Nov 21 17:59:24 2023 From: mdoerr at openjdk.org (Martin Doerr) Date: Tue, 21 Nov 2023 17:59:24 GMT Subject: RFR: JDK-8317799 : AIX PPC64: FFI symbol lookup doesn't find symbols [v6] In-Reply-To: References: <1F0WHhtB_8Pfz-Pq6lvezgjj4A4qcMqvhuFBq--ulMY=.b8aa508c-2eef-4cd6-a180-4fa0f9b8d700@github.com> Message-ID: On Tue, 21 Nov 2023 17:54:08 GMT, suchismith1993 wrote: >> src/java.base/aix/native/libsyslookup/syslookup.c line 30: >> >>> 28: #include >>> 29: #include >>> 30: #include >> >> Are string.h and stdlib.h needed? I can't see them in the comments below. > > string.h is needed for strlen. Let me check for stdlib.h by excluding it. ah, a comment above strlen would help. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16414#discussion_r1400966451 From psandoz at openjdk.org Tue Nov 21 18:17:11 2023 From: psandoz at openjdk.org (Paul Sandoz) Date: Tue, 21 Nov 2023 18:17:11 GMT Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations with SLEEF [v3] In-Reply-To: References: Message-ID: On Mon, 23 Oct 2023 09:02:35 GMT, Xiaohong Gong wrote: > This looks good. As far as I can tell the choice you've made of accuracy matches what we need to meet the spec. Same here . Sinh/cosh/tanh/expm1 are specified to be within 2.5 ulps of the exact result, but i believe sleef does not offer that option, it's either within 1 or 3.5, so we have to pick the former. AFAICT sleef does not say anything about monotonicity, but we relax semi-monotonicity for all but sqrt (we defer to IEEE 754). ------------- PR Comment: https://git.openjdk.org/jdk/pull/16234#issuecomment-1821422985 From prappo at openjdk.org Tue Nov 21 18:44:23 2023 From: prappo at openjdk.org (Pavel Rappo) Date: Tue, 21 Nov 2023 18:44:23 GMT Subject: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v19] In-Reply-To: <4jr199o9QUudtSL9ccL9_wt-4khvBgvEmLg_rXeCfDE=.791b2144-48c6-4ec2-b3a8-cb23ad4a1cb6@github.com> References: <4jr199o9QUudtSL9ccL9_wt-4khvBgvEmLg_rXeCfDE=.791b2144-48c6-4ec2-b3a8-cb23ad4a1cb6@github.com> Message-ID: On Tue, 21 Nov 2023 12:58:42 GMT, Jim Laskey wrote: >> @JimLaskey, in my experiments for JDK-8308715 (Create a mechanism for Implicitly Declared Class javadoc), I found that `javax.lang.model.util.Elements.getOrigin` reports `Origin.EXPLICIT` for the implicitly declared class and `Origin.MANDATED` for that class' constructor. Shouldn't they both be `Origin.MANDATED` because the elements are created from source, not class files, which have some limitations on `ACC_MANDATED`? > > @pavelrappo Classes can?t be MANDATED. Looking at the code I see that EXPLICIT is the default return value when no other conditions apply. @JimLaskey, I note that something weird is happening in relation to comments on method declarations. Comments on field declarations might be affected too, but I haven't checked. Comments on method declarations are correctly captured only if those declarations are minimal. That is, if they consist of a result, name, and parameters. Whenever modifiers like public, protected, private, static, or final appear, the comments disappear. Briefly looking at `com.sun.tools.javac.parser.JavacParser` code (which I have no clue what is doing), I assume the comments are getting misattributed to some other tokens. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16461#issuecomment-1821458574 From jlaskey at openjdk.org Tue Nov 21 18:55:25 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Tue, 21 Nov 2023 18:55:25 GMT Subject: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v31] In-Reply-To: References: Message-ID: On Tue, 21 Nov 2023 17:52:49 GMT, Jim Laskey wrote: >> Address changes from JEP 445 to JEP 463. >> >> - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. >> >> - Don't mark class on read. >> >> - Remove reflection and annotation processing related to unnamed classes. >> >> - Simplify main method search. > > Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: > > Update Class.java The comments are attached to the modifiers (first thing it encounters.) I?m sure the javadoc toolset has a method that gets the comments from the right thing. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16461#issuecomment-1821475235 From prappo at openjdk.org Tue Nov 21 19:02:28 2023 From: prappo at openjdk.org (Pavel Rappo) Date: Tue, 21 Nov 2023 19:02:28 GMT Subject: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v31] In-Reply-To: References: Message-ID: On Tue, 21 Nov 2023 18:51:55 GMT, Jim Laskey wrote: > I?m sure the javadoc toolset has a method that gets the comments from the right thing. That's exactly where those comments disappear from, javadoc. Comments of normal class methods and comments of methods of implicitly declared class seem to be tree-ified differently. Can these comments become lost during copying/reconstruction? I'll try to figure out more. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16461#issuecomment-1821492952 From prappo at openjdk.org Tue Nov 21 19:21:27 2023 From: prappo at openjdk.org (Pavel Rappo) Date: Tue, 21 Nov 2023 19:21:27 GMT Subject: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v31] In-Reply-To: References: Message-ID: On Tue, 21 Nov 2023 18:59:51 GMT, Pavel Rappo wrote: > I'll try to figure out more. So this method seems to be a proximate-ish cause for that behaviour: `JavacParser.topLevelMethodOrFieldDeclaration`. If it gets `null` or comment to attach to `JCTree.JCMethodDecl` later depends on the presence of modifiers. This is not the case with normal class methods, where the comments are robustly attached regardless of whether modifiers are present. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16461#issuecomment-1821538640 From alanb at openjdk.org Tue Nov 21 19:21:30 2023 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 21 Nov 2023 19:21:30 GMT Subject: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v31] In-Reply-To: References: Message-ID: On Tue, 21 Nov 2023 17:52:49 GMT, Jim Laskey wrote: >> Address changes from JEP 445 to JEP 463. >> >> - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. >> >> - Don't mark class on read. >> >> - Remove reflection and annotation processing related to unnamed classes. >> >> - Simplify main method search. > > Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: > > Update Class.java src/java.base/share/classes/java/lang/Class.java line 4823: > 4821: * signatures in a class." > 4822: *

    {@link SecurityException SecurityExceptions} can halt > 4823: * the search. In this case, a null is returned. I see the latest update changes this to return null if denied by the SM. This seems very inconsistent with the other methods so I'm wondering why this has changed? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16461#discussion_r1401056196 From duke at openjdk.org Tue Nov 21 19:30:30 2023 From: duke at openjdk.org (suchismith1993) Date: Tue, 21 Nov 2023 19:30:30 GMT Subject: RFR: JDK-8317799 : AIX PPC64: FFI symbol lookup doesn't find symbols [v7] In-Reply-To: References: Message-ID: > The math library in AIX specifically, is a static archive. Doing a -lm wont suffice, because when the symbols are looked up using dlsym or accessing native code through Java, it will lead to failures. > Hence we had to come up with a list of symbols to allow math library symbols to be accesible. > Also, there are parts of libc library that are static too, and hence those symbols also are present in this list. > Without this change, the StdLibTest and multiple other tests which make native function calls using FFI, fail with NoSuchElementException. > > > 1. Adding required compiler flags. > 2. Adding required symbols. > > > JBS-ISSUE : [JDK-8317799](https://bugs.openjdk.org/browse/JDK-8317799) suchismith1993 has updated the pull request incrementally with two additional commits since the last revision: - Fix Typos - Remove unnecessary includes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16414/files - new: https://git.openjdk.org/jdk/pull/16414/files/48a69c59..efbb245a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16414&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16414&range=05-06 Stats: 6 lines in 1 file changed: 1 ins; 3 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/16414.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16414/head:pull/16414 PR: https://git.openjdk.org/jdk/pull/16414 From mdoerr at openjdk.org Tue Nov 21 19:34:12 2023 From: mdoerr at openjdk.org (Martin Doerr) Date: Tue, 21 Nov 2023 19:34:12 GMT Subject: RFR: JDK-8317799 : AIX PPC64: FFI symbol lookup doesn't find symbols [v7] In-Reply-To: References: Message-ID: On Tue, 21 Nov 2023 19:30:30 GMT, suchismith1993 wrote: >> The math library in AIX specifically, is a static archive. Doing a -lm wont suffice, because when the symbols are looked up using dlsym or accessing native code through Java, it will lead to failures. >> Hence we had to come up with a list of symbols to allow math library symbols to be accesible. >> Also, there are parts of libc library that are static too, and hence those symbols also are present in this list. >> Without this change, the StdLibTest and multiple other tests which make native function calls using FFI, fail with NoSuchElementException. >> >> >> 1. Adding required compiler flags. >> 2. Adding required symbols. >> >> >> JBS-ISSUE : [JDK-8317799](https://bugs.openjdk.org/browse/JDK-8317799) > > suchismith1993 has updated the pull request incrementally with two additional commits since the last revision: > > - Fix Typos > - Remove unnecessary includes Thanks for cleaning it up! LGTM. ------------- Marked as reviewed by mdoerr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16414#pullrequestreview-1742925562 From jlaskey at openjdk.org Tue Nov 21 19:50:23 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Tue, 21 Nov 2023 19:50:23 GMT Subject: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v31] In-Reply-To: References: Message-ID: On Tue, 21 Nov 2023 19:16:06 GMT, Alan Bateman wrote: >> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: >> >> Update Class.java > > src/java.base/share/classes/java/lang/Class.java line 4823: > >> 4821: * signatures in a class." >> 4822: *

    {@link SecurityException SecurityExceptions} can halt >> 4823: * the search. In this case, a null is returned. > > I see the latest update changes this to return null if denied by the SM. This seems very inconsistent with the other methods so I'm wondering why this has changed? Requested by CSR. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16461#discussion_r1401089920 From lancea at openjdk.org Tue Nov 21 19:53:07 2023 From: lancea at openjdk.org (Lance Andersen) Date: Tue, 21 Nov 2023 19:53:07 GMT Subject: RFR: JDK-8319569: Several java/util tests should be updated to accept VM flags [v3] In-Reply-To: References: Message-ID: On Mon, 20 Nov 2023 19:15:18 GMT, Justin Lu wrote: >> Please review this PR which allows these _j.util_ tests to launch new JVM processes with VM flags, >> >> This is primarily done using by switching to `ProcessTools::createTestJavaProcessBuilder`. > > Justin Lu has updated the pull request incrementally with one additional commit since the last revision: > > Pass test.java.opts to PropertiesTest.sh Marked as reviewed by lancea (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/16705#pullrequestreview-1742959505 From jbhateja at openjdk.org Tue Nov 21 19:58:10 2023 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Tue, 21 Nov 2023 19:58:10 GMT Subject: RFR: 8318650: Optimized subword gather for x86 targets. [v7] In-Reply-To: <6trfINWUmYQ7emAfsQAeLPzXSWZGRubI7v8s-wWcGn4=.91ef2dc5-dc4b-4fdd-aa0d-1e7f809cd060@github.com> References: <6trfINWUmYQ7emAfsQAeLPzXSWZGRubI7v8s-wWcGn4=.91ef2dc5-dc4b-4fdd-aa0d-1e7f809cd060@github.com> Message-ID: <2LB_q2HLuam1kfVpMSvYRCKsaddnQVzjR7RC1ZSlJ34=.04f6252e-9062-4ddc-9fa5-6cd4691aa9ee@github.com> On Wed, 15 Nov 2023 02:17:58 GMT, Jatin Bhateja wrote: >> Hi All, >> >> This patch optimizes sub-word gather operation for x86 targets with AVX2 and AVX512 features. >> >> Following is the summary of changes:- >> >> 1) Intrinsify sub-word gather with high performance backend implementation based on hybrid algorithm which initially partially unrolls scalar loop to accumulates values from gather indices into a quadword(64bit) slice followed by vector permutation to place the slice into appropriate vector lanes, it prevents code bloating and generates compact >> JIT sequence. This coupled with savings from expansive array allocation in existing java implementation translates into significant performance of 1.3-5x gains with included micro. >> >> >> ![image](https://github.com/openjdk/jdk/assets/59989778/e25ba4ad-6a61-42fa-9566-452f741a9c6d) >> >> >> 2) Patch was also compared against modified java fallback implementation by replacing temporary array allocation with zero initialized vector and a scalar loops which inserts gathered values into vector. But, vector insert operation in higher vector lanes is a three step process which first extracts the upper vector 128 bit lane, updates it with gather subword value and then inserts the lane back to its original position. This makes inserts into higher order lanes costly w.r.t to proposed solution. In addition generated JIT code for modified fallback implementation was very bulky. This may impact in-lining decisions into caller contexts. >> >> 3) Some minor adjustments in existing gather instruction pattens for double/quad words. >> >> >> Kindly review and share your feedback. >> >> >> Best Regards, >> Jatin > > Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: > > Fix incorrect comment > I have not thought about this thoroughly so it may be incorrect. Can we delegate the gather to `int` and extract the result from it. > > ``` > vpand(xtmp1, idx, bt == T_SHORT ? -2 : -4); // align the index so that the address is aligned for int accesses > vpgatherdd(xtmp2, mask, Address(base, xtmp1, bt == T_SHORT ? times_2 : times_1, offset)); > vpand(xtmp1, idx, bt == T_SHORT ? 1 : 3); // Need to align the requested elements > vpslld(xtmp1, xtmp1, bt == T_SHORT ? 4 : 3); > vpsrlvd(xtmp1, xtmp2, xtmp1); > vpmovdw(dst, xtmp1); > ``` > I have not thought about this thoroughly so it may be incorrect. Can we delegate the gather to `int` and extract the result from it. > > ``` > vpand(xtmp1, idx, bt == T_SHORT ? -2 : -4); // align the index so that the address is aligned for int accesses > vpgatherdd(xtmp2, mask, Address(base, xtmp1, bt == T_SHORT ? times_2 : times_1, offset)); > vpand(xtmp1, idx, bt == T_SHORT ? 1 : 3); // Need to align the requested elements > vpslld(xtmp1, xtmp1, bt == T_SHORT ? 4 : 3); > vpsrlvd(xtmp1, xtmp2, xtmp1); > vpmovdw(dst, xtmp1); > ``` Double word gather will always try to access 4 contiguous byte from a normalized index, and will not be able to prevent access violations if other 3 bytes in double word are non accessible. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16354#issuecomment-1821586982 From duke at openjdk.org Tue Nov 21 20:02:06 2023 From: duke at openjdk.org (Gaurav Chaudhari) Date: Tue, 21 Nov 2023 20:02:06 GMT Subject: RFR: 8319668: Fixup of jar filename typo in BadFactoryTest.sh In-Reply-To: References: Message-ID: On Tue, 21 Nov 2023 16:36:26 GMT, Alan Bateman wrote: > Looks okay. This test is begging to be re-written in Java, maybe some day. > > I assume the copyright header will be updated before this change is integrated. Hi @AlanBateman, do I have to update the copyright year to 2023 manually and amend the commit before `/integrate` ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/16585#issuecomment-1821594845 From duke at openjdk.org Tue Nov 21 20:17:05 2023 From: duke at openjdk.org (Eirik Bjorsnos) Date: Tue, 21 Nov 2023 20:17:05 GMT Subject: RFR: 8319668: Fixup of jar filename typo in BadFactoryTest.sh In-Reply-To: References: Message-ID: On Tue, 21 Nov 2023 16:36:26 GMT, Alan Bateman wrote: >> The file test/jdk/javax/script/JDK_8196959/BadFactoryTest.sh contains a typo. When running without security manager, the test references 'badfactoty.jar' instead of 'badfactory.jar'. This change addresses this by correcting the jar name. > > Looks okay. This test is begging to be re-written in Java, maybe some day. > > I assume the copyright header will be updated before this change is integrated. > Hi @AlanBateman, do I have to update the copyright year to 2023 manually and amend the commit before `/integrate` ? @Deigue Not sure if this was a question on the formatting of the copyright header, but the year should not simply be updated to `2023`, but instead to the range `2018, 2023`. So in your case, the first line should read: # Copyright (c) 2018, 2023, Oracle and/or its affiliates. All rights reserved. Once you push that commit, a reviewer can approve the PR and you can `/integrate` ------------- PR Comment: https://git.openjdk.org/jdk/pull/16585#issuecomment-1821612336 From tprinzing at openjdk.org Tue Nov 21 20:25:15 2023 From: tprinzing at openjdk.org (Tim Prinzing) Date: Tue, 21 Nov 2023 20:25:15 GMT Subject: RFR: 8310994: Add JFR event for selection operations Message-ID: Added mirror event with static methods: jdk.internal.event.SelectionEvent that provides the duration of select calls and the count of how many keys are available. Emit the event from SelectorImpl::lockAndDoSelect Test at jdk.jfr.event.io.TestSelectionEvents ------------- Commit messages: - remove trailing whitespace - event logic outside of the lock, selector in try block - remove unused import - fix TestConfigure failure - add event defaults - Merge branch 'master' into JDK-8310994 - minor test cleanup - Merge branch 'master' into JDK-8310994 - 8310994: Add JFR event for selection operations Changes: https://git.openjdk.org/jdk/pull/16710/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16710&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8310994 Stats: 265 lines in 9 files changed: 264 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/16710.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16710/head:pull/16710 PR: https://git.openjdk.org/jdk/pull/16710 From alanb at openjdk.org Tue Nov 21 20:25:16 2023 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 21 Nov 2023 20:25:16 GMT Subject: RFR: 8310994: Add JFR event for selection operations In-Reply-To: References: Message-ID: On Fri, 17 Nov 2023 16:22:55 GMT, Tim Prinzing wrote: > Added mirror event with static methods: jdk.internal.event.SelectionEvent that provides the duration of select calls and the count of how many keys are available. > > Emit the event from SelectorImpl::lockAndDoSelect > > Test at jdk.jfr.event.io.TestSelectionEvents src/java.base/share/classes/sun/nio/ch/SelectorImpl.java line 141: > 139: SelectionEvent.commit(start, duration, n); > 140: } > 141: return n; I'd prefer if the existing code moved to implLockAndDoSelect so that lockAndDoSelect commits the event outside of the locked region. test/jdk/jdk/jfr/event/io/TestSelectionEvents.java line 70: > 68: SocketChannel sc2 = ssc.accept()) { > 69: > 70: Selector sel = Selector.open(); You can add this to the try block so that the selector is closed too. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16710#discussion_r1397596209 PR Review Comment: https://git.openjdk.org/jdk/pull/16710#discussion_r1397593894 From jjg at openjdk.org Tue Nov 21 20:44:22 2023 From: jjg at openjdk.org (Jonathan Gibbons) Date: Tue, 21 Nov 2023 20:44:22 GMT Subject: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v31] In-Reply-To: References: Message-ID: <7WfOKRXJUWg0CT8T4RqwC5VzgJp2ZEbnvrr39TLpJHk=.517338f9-dfe0-4b7d-bf18-b117818aa98a@github.com> On Tue, 21 Nov 2023 18:51:55 GMT, Jim Laskey wrote: > The comments are attached to the modifiers (first thing it encounters.) I?m sure the javadoc toolset has a method that gets the comments from the right thing. In the AST created by the parser, doc comments should be attached to _declarations_ (`JCClassDecl`, `JCMethodDecl`, `JCVariableDecl` etc) not modifiers. There is nothing in the javadoc toolset that _gets the comments from the right thing_. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16461#issuecomment-1821645764 From duke at openjdk.org Tue Nov 21 21:03:20 2023 From: duke at openjdk.org (Steve Dohrmann) Date: Tue, 21 Nov 2023 21:03:20 GMT Subject: RFR: 8310159: Bulk copy with Unsafe::arrayCopy is slower compared to memcpy [v6] In-Reply-To: References: Message-ID: > Update: the XorTest::xor results shown in this message used test code from PR commit 7cc272e862791 which was based on Maurizio Cimadamore's commit a788f066af17. The XorTest has since been updated and XorTest::copy is no longer needed and has been removed from this pull request. See comment [here](https://github.com/openjdk/jdk/pull/16575#issuecomment-1820006548) for updated performance data. > > Below is baseline data collected using a modified version of the java.lang.foreign.xor micro benchmark referenced by @mcimadamore in the bug report. I collected data on an Ubuntu 22.04 laptop with a Tigerlake i7-1185G7, which does support AVX512. > > Baseline data > Benchmark (arrayKind) (sizeKind) Mode Cnt Score Error Units > -------------------------------------------------------------------------------------- > XorTest.copy ELEMENTS SMALL avgt 30 584737355.767 ? 60414308.540 ns/op > XorTest.copy ELEMENTS MEDIUM avgt 30 272248995.683 ? 2924954.498 ns/op > XorTest.copy ELEMENTS LARGE avgt 30 1019200210.900 ? 28334453.652 ns/op > XorTest.copy REGION SMALL avgt 30 7399944.164 ? 216821.819 ns/op > XorTest.copy REGION MEDIUM avgt 30 20591454.558 ? 147398.572 ns/op > XorTest.copy REGION LARGE avgt 30 21649266.051 ? 179263.875 ns/op > XorTest.copy CRITICAL SMALL avgt 30 51079.357 ? 542.482 ns/op > XorTest.copy CRITICAL MEDIUM avgt 30 2496.961 ? 11.375 ns/op > XorTest.copy CRITICAL LARGE avgt 30 515.454 ? 5.831 ns/op > XorTest.copy FOREIGN SMALL avgt 30 7558432.075 ? 79489.276 ns/op > XorTest.copy FOREIGN MEDIUM avgt 30 19730666.341 ? 500505.099 ns/op > XorTest.copy FOREIGN LARGE avgt 30 34616758.085 ? 340300.726 ns/op > XorTest.xor ELEMENTS SMALL avgt 30 219832692.489 ? 2329417.319 ns/op > XorTest.xor ELEMENTS MEDIUM avgt 30 505138197.167 ? 3818334.424 ns/op > XorTest.xor ELEMENTS LARGE avgt 30 1189608474.667 ? 5877981.900 ns/op > XorTest.xor REGION SMALL avgt 30 64093872.804 ? 599704.491 ns/op > XorTest.xor REGION MEDIUM avgt 30 81544576.454 ? 1406342.118 ns/op > XorTest.xor REGION LARGE avgt 30 90091424.883 ? 775577.613 ns/op > XorTest.xor CRITICAL SMALL avgt 30 57231375.744 ? 438223.342 ns/op > XorTest.x... Steve Dohrmann has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits: - Merge branch 'master' into memcpy - Updates based on reviewer (sviswa7) comments including - use asserts instead of conditionals in two logically unreachable blocks - remove unused function parmeters - use 64-byte vector path in pre-loop masked write - Merge branch 'master' into memcpy - Update full name Previous commit (fcbbc0d7880) added org.openjdk.bench.java.lang.ArrayCopyAlignedLarge benchmark - - remerge upstream master - remove ::copy test from XorTest - Merge branch 'master' into memcpy - - fix whitespace error - Merge branch 'master' of https://git.openjdk.org/jdk into memcpy - - bug fix: only generate / use large copy code if MaxVectorSize == 64 - - fix whitespace issues - fix xor test foreign impl constructor signature - ... and 1 more: https://git.openjdk.org/jdk/compare/e47cf611...02ad27fa ------------- Changes: https://git.openjdk.org/jdk/pull/16575/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16575&range=05 Stats: 259 lines in 5 files changed: 259 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/16575.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16575/head:pull/16575 PR: https://git.openjdk.org/jdk/pull/16575 From duke at openjdk.org Tue Nov 21 21:03:25 2023 From: duke at openjdk.org (Steve Dohrmann) Date: Tue, 21 Nov 2023 21:03:25 GMT Subject: RFR: 8310159: Bulk copy with Unsafe::arrayCopy is slower compared to memcpy [v5] In-Reply-To: References: Message-ID: On Tue, 21 Nov 2023 01:10:40 GMT, Sandhya Viswanathan wrote: >> Steve Dohrmann has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits: >> >> - Merge branch 'master' into memcpy >> - Update full name >> Previous commit (fcbbc0d7880) added org.openjdk.bench.java.lang.ArrayCopyAlignedLarge benchmark >> - - remerge upstream master >> - remove ::copy test from XorTest >> - Merge branch 'master' into memcpy >> - - fix whitespace error >> - Merge branch 'master' of https://git.openjdk.org/jdk into memcpy >> - - bug fix: only generate / use large copy code if MaxVectorSize == 64 >> - - fix whitespace issues >> - fix xor test foreign impl constructor signature >> - - initial commit -- optimize large array cases in StubGenerator::generate_disjoint_copy_avx3_masked >> - add src address prefetches >> - switch to non-temporal writes >> - added modified jmh benchmark based on xor benchmark from Maurizio Cimadamore > > src/hotspot/cpu/x86/stubGenerator_x86_64_arraycopy.cpp line 753: > >> 751: Label L_pre_main_post_large; >> 752: >> 753: if (MaxVectorSize == 64) { > > This should be an assert here instead of if check as this method shouldn't be called if MaxVectorSize is < 64. Thanks, done. > src/hotspot/cpu/x86/stubGenerator_x86_64_arraycopy.cpp line 777: > >> 775: >> 776: __ BIND(L_main_pre_loop_large); >> 777: __ subq(temp1, loop_size[shift]); // whay is this here > > Spurious comment. Thanks, done > src/hotspot/cpu/x86/stubGenerator_x86_64_arraycopy.cpp line 797: > >> 795: __ jcc(Assembler::lessEqual, L_exit_large); >> 796: arraycopy_avx3_special_cases_256(xmm1, k2, from, to, temp1, shift, >> 797: temp4, temp3, L_entry_large, L_exit_large); > > When we come here to arraycopy_avx3_special_cases_256 only up to 256 bytes need to be copied so we don't need to go back to L_entry_large. Thanks, done > src/hotspot/cpu/x86/stubGenerator_x86_64_arraycopy.cpp line 1058: > >> 1056: }; >> 1057: >> 1058: if (MaxVectorSize == 64) { > > This should be an assert here instead of if check as this method shouldn't be called if MaxVectorSize is < 64. Thanks, done. > src/hotspot/cpu/x86/stubGenerator_x86_64_arraycopy.cpp line 1175: > >> 1173: void StubGenerator::copy256_avx3(Register dst, Register src, Register index, XMMRegister xmm1, >> 1174: XMMRegister xmm2, XMMRegister xmm3, XMMRegister xmm4, >> 1175: bool conjoint, int shift, int offset) { > > The conjoint parameter is not used so could be removed from this function. Thanks, done. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16575#discussion_r1401179711 PR Review Comment: https://git.openjdk.org/jdk/pull/16575#discussion_r1401178991 PR Review Comment: https://git.openjdk.org/jdk/pull/16575#discussion_r1401180641 PR Review Comment: https://git.openjdk.org/jdk/pull/16575#discussion_r1401180258 PR Review Comment: https://git.openjdk.org/jdk/pull/16575#discussion_r1401177983 From duke at openjdk.org Tue Nov 21 21:19:05 2023 From: duke at openjdk.org (Eirik Bjorsnos) Date: Tue, 21 Nov 2023 21:19:05 GMT Subject: RFR: 8319668: Fixup of jar filename typo in BadFactoryTest.sh In-Reply-To: References: Message-ID: On Thu, 9 Nov 2023 16:49:41 GMT, Gaurav Chaudhari wrote: > The file test/jdk/javax/script/JDK_8196959/BadFactoryTest.sh contains a typo. When running without security manager, the test references 'badfactoty.jar' instead of 'badfactory.jar'. This change addresses this by correcting the jar name. The typo you found here reveals that the test runs fine without having the jar file on the classpath. All the necessary class files already seem to be in `${TESTCLASSES}` So it's not clear to me why this test uses a jar file at all, it does not seem necessary. Perhaps you could clean this up in this PR? That would include: - Removing the code which creates the JAR - Updating the two `-classpath` options to just `"${TESTCLASSES}"` If you feel this is out of scope for this PR, I'm fine with that as well. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16585#issuecomment-1821701137 From vklang at openjdk.org Tue Nov 21 21:30:08 2023 From: vklang at openjdk.org (Viktor Klang) Date: Tue, 21 Nov 2023 21:30:08 GMT Subject: RFR: JDK-8319662 ForkJoinPool trims worker threads too slowly [v3] In-Reply-To: References: Message-ID: <6tj5Bxz_qc-g6VHVYpofvxhuT2d8UorA_kJW-ByTM5U=.8ac6e944-3177-4c19-8656-7e9638904448@github.com> On Tue, 21 Nov 2023 17:12:39 GMT, Doug Lea

    wrote: >> This update cascades timeouts to trim subsequent workers after the first keepAlive inactive period. > > 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 three additional commits since the last revision: > > - Merge branch 'openjdk:master' into JDK-8319662 > - tweak cascades; reinstate an @Contended; resolve JDK-8319498 > - Support cascading idle timeouts src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 3116: > 3114: } catch (Exception ex) { > 3115: throw new RuntimeException(ex); > 3116: } Suggestion: try { return task.join(); } catch (RuntimeException | Error unchecked) { throw unchecked; } catch (Exception checked) { throw new RuntimeException(checked); } ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16725#discussion_r1401218927 From duke at openjdk.org Tue Nov 21 21:39:10 2023 From: duke at openjdk.org (Steve Dohrmann) Date: Tue, 21 Nov 2023 21:39:10 GMT Subject: RFR: 8310159: Bulk copy with Unsafe::arrayCopy is slower compared to memcpy [v5] In-Reply-To: References: Message-ID: <_EmjFJMdWPCyCPi4kqrPQ5z7pBndhUzkDujH5MFe2Ag=.67c7f4e1-6f73-45d4-87b4-4a693f797c00@github.com> On Tue, 21 Nov 2023 01:14:49 GMT, Sandhya Viswanathan wrote: >> Steve Dohrmann has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits: >> >> - Merge branch 'master' into memcpy >> - Update full name >> Previous commit (fcbbc0d7880) added org.openjdk.bench.java.lang.ArrayCopyAlignedLarge benchmark >> - - remerge upstream master >> - remove ::copy test from XorTest >> - Merge branch 'master' into memcpy >> - - fix whitespace error >> - Merge branch 'master' of https://git.openjdk.org/jdk into memcpy >> - - bug fix: only generate / use large copy code if MaxVectorSize == 64 >> - - fix whitespace issues >> - fix xor test foreign impl constructor signature >> - - initial commit -- optimize large array cases in StubGenerator::generate_disjoint_copy_avx3_masked >> - add src address prefetches >> - switch to non-temporal writes >> - added modified jmh benchmark based on xor benchmark from Maurizio Cimadamore > > src/hotspot/cpu/x86/stubGenerator_x86_64_arraycopy.cpp line 768: > >> 766: } >> 767: __ movq(temp3, temp2); >> 768: copy64_masked_avx(to, from, xmm1, k2, temp3, temp4, temp1, shift, 0); > > The last argument should be "true" or "1" instead of "0" or "false". This is as temp3 (length) could be less than 32 as well. This case is only handled when use64byteVector argument is true. Thanks, done. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16575#discussion_r1401229608 From rriggs at openjdk.org Tue Nov 21 22:49:09 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 21 Nov 2023 22:49:09 GMT Subject: RFR: 8314480: Memory ordering spec updates in java.lang.ref In-Reply-To: References: Message-ID: On Wed, 15 Nov 2023 22:31:35 GMT, Stuart Marks wrote: >> Classes in the `java.lang.ref` package would benefit from an update to bring the spec in line with how the VM already behaves. The changes would focus on _happens-before_ edges at some key points during reference processing. >> >> A couple key things we want to be able to say are: >> - `Reference.reachabilityFence(x)` _happens-before_ reference processing occurs for 'x'. >> - `Cleaner.register()` _happens-before_ the Cleaner thread runs the registered cleaning action. >> >> This will bring Cleaner in line (or close) with the memory visibility guarantees made for finalizers in [JLS 17.4.5](https://docs.oracle.com/javase/specs/jls/se18/html/jls-17.html#jls-17.4.5): >> _"There is a happens-before edge from the end of a constructor of an object to the start of a finalizer (?12.6) for that object."_ > > src/java.base/share/classes/java/lang/ref/Reference.java line 489: > >> 487: *

    If this reference was already enqueued (by the garbage collector, or a >> 488: * previous call to {@code enqueue}), this method is not successful, >> 489: * and returns false. > > If we're going to talk about successful and unsuccessful calls, we should define what success is first. I guess that would be something like: if this ref is registered with a queue and not already enqueued, it is enqueued successfully and the method returns true. Otherwise, not successful, and returns false. This could be worded as a post condition, after the call the ref is enqueued with the queue; the return is true iff the ref was not previously enqueued. The enqueuing is not conditional (assuming the queue is non-null). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16644#discussion_r1401302710 From ihse at openjdk.org Tue Nov 21 22:58:11 2023 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 21 Nov 2023 22:58:11 GMT Subject: RFR: JDK-8317799 : AIX PPC64: FFI symbol lookup doesn't find symbols [v7] In-Reply-To: References: Message-ID: On Tue, 21 Nov 2023 19:30:30 GMT, suchismith1993 wrote: >> The math library in AIX specifically, is a static archive. Doing a -lm wont suffice, because when the symbols are looked up using dlsym or accessing native code through Java, it will lead to failures. >> Hence we had to come up with a list of symbols to allow math library symbols to be accesible. >> Also, there are parts of libc library that are static too, and hence those symbols also are present in this list. >> Without this change, the StdLibTest and multiple other tests which make native function calls using FFI, fail with NoSuchElementException. >> >> >> 1. Adding required compiler flags. >> 2. Adding required symbols. >> >> >> JBS-ISSUE : [JDK-8317799](https://bugs.openjdk.org/browse/JDK-8317799) > > suchismith1993 has updated the pull request incrementally with two additional commits since the last revision: > > - Fix Typos > - Remove unnecessary includes Marked as reviewed by ihse (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/16414#pullrequestreview-1743290191 From rriggs at openjdk.org Tue Nov 21 23:01:06 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 21 Nov 2023 23:01:06 GMT Subject: RFR: 8314480: Memory ordering spec updates in java.lang.ref In-Reply-To: References: Message-ID: On Mon, 13 Nov 2023 22:31:16 GMT, Brent Christian wrote: > Classes in the `java.lang.ref` package would benefit from an update to bring the spec in line with how the VM already behaves. The changes would focus on _happens-before_ edges at some key points during reference processing. > > A couple key things we want to be able to say are: > - `Reference.reachabilityFence(x)` _happens-before_ reference processing occurs for 'x'. > - `Cleaner.register()` _happens-before_ the Cleaner thread runs the registered cleaning action. > > This will bring Cleaner in line (or close) with the memory visibility guarantees made for finalizers in [JLS 17.4.5](https://docs.oracle.com/javase/specs/jls/se18/html/jls-17.html#jls-17.4.5): > _"There is a happens-before edge from the end of a constructor of an object to the start of a finalizer (?12.6) for that object."_ src/java.base/share/classes/java/lang/ref/Reference.java line 552: > 550: * of this method. > 551: * Invocation of this method does not itself initiate reference processing, > 552: * garbage collection, or finalization. My understanding was that it is not the object instance that is being guarded, only that the reference holding the object is considered a strong root and is only used to delimit a range of bytecodes for which the reference is considered to be strong. In particular, the invocation of the method itself has no semantics, only that a control flow could reach that statement and the reference was considered strong as long as the reference was in a scope that included the reachability fence. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16644#discussion_r1401310991 From psandoz at openjdk.org Wed Nov 22 00:08:08 2023 From: psandoz at openjdk.org (Paul Sandoz) Date: Wed, 22 Nov 2023 00:08:08 GMT Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations with SLEEF [v3] In-Reply-To: References: Message-ID: <97YS_I-DY-Q5agE6mE-iBkoVxtvL7R4Q3NebjTsXMvI=.dac0dc99-84d7-4cbd-ada6-5190564688a9@github.com> On Wed, 15 Nov 2023 01:32:00 GMT, Xiaohong Gong wrote: >> Currently the vector floating-point math APIs like `VectorOperators.SIN/COS/TAN...` are not intrinsified on AArch64 platform, which causes large performance gap on AArch64. Note that those APIs are optimized by C2 compiler on X86 platforms by calling Intel's SVML code [1]. To close the gap, we would like to optimize these APIs for AArch64 by calling a third-party vector library called libsleef [2], which are available in mainstream Linux distros (e.g. [3] [4]). >> >> SLEEF supports multiple accuracies. To match Vector API's requirement and implement the math ops on AArch64, we 1) call 1.0 ULP accuracy with FMA instructions used stubs in libsleef for most of the operations by default, and 2) add the vector calling convention to apply with the runtime calls to stub code in libsleef. Note that for those APIs that libsleef does not support 1.0 ULP, we choose 0.5 ULP instead. >> >> To help loading the expected libsleef library, this patch also adds an experimental JVM option (i.e. `-XX:UseSleefLib`) for AArch64 platforms. People can use it to denote the libsleef path/name explicitly. By default, it points to the system installed library. If the library does not exist or the dynamic loading of it in runtime fails, the math vector ops will fall-back to use the default scalar version without error. But a warning is printed out if people specifies a nonexistent library explicitly. >> >> Note that this is a part of the original proposed patch in panama-dev [5], just with some initial review comments addressed. And now we'd like to get some wider feedbacks from more hotspot experts. >> >> [1] https://github.com/openjdk/jdk/pull/3638 >> [2] https://sleef.org/ >> [3] https://packages.fedoraproject.org/pkgs/sleef/sleef/ >> [4] https://packages.debian.org/bookworm/libsleef3 >> [5] https://mail.openjdk.org/pipermail/panama-dev/2022-December/018172.html > > Xiaohong Gong has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: > > - Add a bundled native lib in jdk as a bridge to libsleef > - Merge 'jdk:master' into JDK-8312425 > - Disable sleef by default > - Merge 'jdk:master' into JDK-8312425 > - 8312425: [vectorapi] AArch64: Optimize vector math operations with SLEEF Have you considered the possibility of copying the sleef source to the OpenJDK repository and thereby it becomes part of the build process? I don't know how straightforward that is technically and IANAL but I think it's worth exploring. Also it may enable us to use sleef for other platforms where we have gaps (looking at Table 1.1 of https://sleef.org/). Further out it should inspire us to do a Java Vector API port to as indicated in a prior comment. > Yes, libsleef is used to build the binary if found. And at runtime, if the libsleef with right version is not found, `dlopen` to the libvmath.so will fail. And then all the operations will be fall-back to the java default implementation. X86_64 has also bundled the Intel's SVML binary to jdk image at build time. And we use the same way loading/opening the library at runtime. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16234#issuecomment-1821885433 From qamai at openjdk.org Wed Nov 22 01:39:10 2023 From: qamai at openjdk.org (Quan Anh Mai) Date: Wed, 22 Nov 2023 01:39:10 GMT Subject: RFR: 8318650: Optimized subword gather for x86 targets. [v7] In-Reply-To: <6trfINWUmYQ7emAfsQAeLPzXSWZGRubI7v8s-wWcGn4=.91ef2dc5-dc4b-4fdd-aa0d-1e7f809cd060@github.com> References: <6trfINWUmYQ7emAfsQAeLPzXSWZGRubI7v8s-wWcGn4=.91ef2dc5-dc4b-4fdd-aa0d-1e7f809cd060@github.com> Message-ID: On Wed, 15 Nov 2023 02:17:58 GMT, Jatin Bhateja wrote: >> Hi All, >> >> This patch optimizes sub-word gather operation for x86 targets with AVX2 and AVX512 features. >> >> Following is the summary of changes:- >> >> 1) Intrinsify sub-word gather with high performance backend implementation based on hybrid algorithm which initially partially unrolls scalar loop to accumulates values from gather indices into a quadword(64bit) slice followed by vector permutation to place the slice into appropriate vector lanes, it prevents code bloating and generates compact >> JIT sequence. This coupled with savings from expansive array allocation in existing java implementation translates into significant performance of 1.3-5x gains with included micro. >> >> >> ![image](https://github.com/openjdk/jdk/assets/59989778/e25ba4ad-6a61-42fa-9566-452f741a9c6d) >> >> >> 2) Patch was also compared against modified java fallback implementation by replacing temporary array allocation with zero initialized vector and a scalar loops which inserts gathered values into vector. But, vector insert operation in higher vector lanes is a three step process which first extracts the upper vector 128 bit lane, updates it with gather subword value and then inserts the lane back to its original position. This makes inserts into higher order lanes costly w.r.t to proposed solution. In addition generated JIT code for modified fallback implementation was very bulky. This may impact in-lining decisions into caller contexts. >> >> 3) Some minor adjustments in existing gather instruction pattens for double/quad words. >> >> >> Kindly review and share your feedback. >> >> >> Best Regards, >> Jatin > > Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: > > Fix incorrect comment But since accesses are aligned they must lie in the same page, which means if a byte is accessible then the whole double word is accessible ------------- PR Comment: https://git.openjdk.org/jdk/pull/16354#issuecomment-1821952667 From xgong at openjdk.org Wed Nov 22 01:45:11 2023 From: xgong at openjdk.org (Xiaohong Gong) Date: Wed, 22 Nov 2023 01:45:11 GMT Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations with SLEEF [v3] In-Reply-To: References: Message-ID: <1UlAcJ17Pe7VbzAHDUBWF0ruGtSMsdhu6_cc7khS4Y8=.1020cfc6-002a-49f5-9628-657df0c9ba0b@github.com> On Tue, 21 Nov 2023 18:14:41 GMT, Paul Sandoz wrote: > > This looks good. As far as I can tell the choice you've made of accuracy matches what we need to meet the spec. > > Same here . Sinh/cosh/tanh/expm1 are specified to be within 2.5 ulps of the exact result, but i believe sleef does not offer that option, it's either within 1 or 3.5, so we have to pick the former. AFAICT sleef does not say anything about monotonicity, but we relax semi-monotonicity for all but sqrt (we defer to IEEE 754). Yes, that's why we at least have to use the 1up in sleef here. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16234#issuecomment-1821956522 From xgong at openjdk.org Wed Nov 22 01:55:06 2023 From: xgong at openjdk.org (Xiaohong Gong) Date: Wed, 22 Nov 2023 01:55:06 GMT Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations with SLEEF [v3] In-Reply-To: <97YS_I-DY-Q5agE6mE-iBkoVxtvL7R4Q3NebjTsXMvI=.dac0dc99-84d7-4cbd-ada6-5190564688a9@github.com> References: <97YS_I-DY-Q5agE6mE-iBkoVxtvL7R4Q3NebjTsXMvI=.dac0dc99-84d7-4cbd-ada6-5190564688a9@github.com> Message-ID: On Wed, 22 Nov 2023 00:05:26 GMT, Paul Sandoz wrote: > Have you considered the possibility of copying the sleef source to the OpenJDK repository and thereby it becomes part of the build process? I don't know how straightforward that is technically and IANAL but I think it's worth exploring. > Hi @PaulSandoz ! Thanks for the suggestion! Copying the sleef source sounds good. However, I actually have no idea about how to handle the third-party licence in OpenJDK project. Do you have any idea about this area? Some suggestions/guidence from the JDK team will be much helpful. Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/16234#issuecomment-1821965636 From dholmes at openjdk.org Wed Nov 22 02:09:38 2023 From: dholmes at openjdk.org (David Holmes) Date: Wed, 22 Nov 2023 02:09:38 GMT Subject: RFR: 8318776: Require supports_cx8 to always be true [v5] In-Reply-To: References: Message-ID: > As discussed in JBS all platforms (some tweaks to Zero are in progress) actually do support `cx8` i.e. 64-bit compare-and-exchange, so we can strip out the locked-based alternatives to using it and just add a guarantee that it is true at runtime. And all platforms except some ARM variants set `SUPPORTS_NATIVE_CX8`, so we can greatly simplify things. Summary of changes: > - `_supports_cx8` field is only needed when `SUPPORTS_NATIVE_CX8` is not defined > - Assertions for `supports_cx8()` are removed > - Compiler predicates requiring `supports_cx8()` are removed > - Access backend is greatly simplified without the need for lock-based alternative > - `java.util.concurrent.AtomicLongFieldUpdater` is simplified without the need for a lock-based alternative > > I did consider moving all the ARM `kuser_helper` related code to be only defined when `SUPPORTS_NATIVE_CX8` is not defined, but there was a theoretical risk this could change the behaviour if ARMv7 binaries were run on other ARM CPU's. I added a note to that effect in vm_version_linux_arm32.cpp so the ARM port maintainers could clean this up further if desired. > > Testing: > - All Oracle tiers 1-5 builds (which includes an ARMv7 build) > - GHA builds/tests > - Oracle tiers 1-3 sanity testing > > Zero changes coming in via [JDK-8319777](https://bugs.openjdk.org/browse/JDK-8319777) will be merged when they arrive. > > Thanks. David Holmes has updated the pull request with a new target base 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 with master and update Zero code accordingly - Merge branch 'master' into 8318776-supports_cx8 - Remove unnecessary includes of vm_version.hpp. Fix copyright years. - Remove cx8 comment as no longer relevant (the spinlock is used regardless of cx8) - Remove suports_cx8() checks from gtest - Remove test for VMSupportsCX8 - 8318776: Require supports_cx8 to always be true ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16625/files - new: https://git.openjdk.org/jdk/pull/16625/files/597cef53..aad0a4c4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16625&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16625&range=03-04 Stats: 621905 lines in 1279 files changed: 89413 ins; 471113 del; 61379 mod Patch: https://git.openjdk.org/jdk/pull/16625.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16625/head:pull/16625 PR: https://git.openjdk.org/jdk/pull/16625 From dholmes at openjdk.org Wed Nov 22 02:21:05 2023 From: dholmes at openjdk.org (David Holmes) Date: Wed, 22 Nov 2023 02:21:05 GMT Subject: RFR: 8318776: Require supports_cx8 to always be true [v4] In-Reply-To: References: Message-ID: On Tue, 21 Nov 2023 16:58:21 GMT, Aleksey Shipilev wrote: >> This looks great! > >> Thanks for the review @fisk ! I have to wait for a few Zero related PRs to get integrated then re-merge, before I can integrate. > > Zero patches were pushed, please re-merge. I checked current mainline works well with at least linux-arm-zero-fastdebug, and I would like to re-test it with this patch. @shipilev I have re-merged and update the Zero changes (ifdef around `_saupports_cx8`). @viktorklang-ora and/or @DougLea could I ask you to look at the `java.util.concurrent.AtomicLongFieldUpdater` changes please. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16625#issuecomment-1821983975 From eliu at openjdk.org Wed Nov 22 02:21:07 2023 From: eliu at openjdk.org (Eric Liu) Date: Wed, 22 Nov 2023 02:21:07 GMT Subject: RFR: 8319872: AArch64: [vectorapi] Implementation of unsigned (zero extended) casts [v3] In-Reply-To: References: Message-ID: <4mFjuz7TksaNGb1AXirVsXZF_95oJ2-UiHCP9Y7lxFM=.fd477fa9-85c1-4df3-a0c1-061c6f451873@github.com> On Tue, 21 Nov 2023 15:07:48 GMT, Andrew Haley wrote: >> Eric Liu has updated the pull request incrementally with one additional commit since the last revision: >> >> add _sve_xunpk & remove dead code >> >> Change-Id: Ic19836feb8a73ea7e65443794f2a0eb1363f6e2f > > src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp line 1412: > >> 1410: _sve_xunpk(is_unsigned, /* is_high */ false, dst, S, dst); >> 1411: _sve_xunpk(is_unsigned, /* is_high */ false, dst, D, dst); >> 1412: break; > > Why is this change here? It doesn't do anything. Does it? `is_unsigned` is also used in this function. It is used in VectorUCastNode for zero extending. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16670#discussion_r1401423194 From haosun at openjdk.org Wed Nov 22 02:39:21 2023 From: haosun at openjdk.org (Hao Sun) Date: Wed, 22 Nov 2023 02:39:21 GMT Subject: RFR: 8320131: Zero build fails on macOS after JDK-8254693 Message-ID: The fix is trivial. We should include the standard C header `stdlib.h` [1], rather than non-standard one `malloc.h`. [1] https://en.cppreference.com/w/c/memory/malloc ------------- Commit messages: - 8320131: Zero build fails on macOS after JDK-8254693 Changes: https://git.openjdk.org/jdk/pull/16775/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16775&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8320131 Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/16775.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16775/head:pull/16775 PR: https://git.openjdk.org/jdk/pull/16775 From dholmes at openjdk.org Wed Nov 22 03:00:06 2023 From: dholmes at openjdk.org (David Holmes) Date: Wed, 22 Nov 2023 03:00:06 GMT Subject: RFR: 8320131: Zero build fails on macOS after JDK-8254693 In-Reply-To: References: Message-ID: <1AbSrPtGjc3D18Lz3fG0-qz5mYB31m8uA7Y6NdUaDwc=.84fb6505-d693-4ddd-a8c7-e61919edce67@github.com> On Wed, 22 Nov 2023 02:06:29 GMT, Hao Sun wrote: > The fix is trivial. We should include the standard C header `stdlib.h` [1], rather than non-standard one `malloc.h`. > > [1] https://en.cppreference.com/w/c/memory/malloc Looks good and trivial. Thanks for fixing. ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16775#pullrequestreview-1743469194 From jvernee at openjdk.org Wed Nov 22 03:32:06 2023 From: jvernee at openjdk.org (Jorn Vernee) Date: Wed, 22 Nov 2023 03:32:06 GMT Subject: RFR: 8320131: Zero build fails on macOS after JDK-8254693 In-Reply-To: References: Message-ID: <51DmZ-ZwK0FxyQiEqeZJ0xGa2tMBMyC-fZYRzcxPlh4=.f8f8f2b7-4b2b-4b67-8f9a-7d27285b83ad@github.com> On Wed, 22 Nov 2023 02:06:29 GMT, Hao Sun wrote: > The fix is trivial. We should include the standard C header `stdlib.h` [1], rather than non-standard one `malloc.h`. > > [1] https://en.cppreference.com/w/c/memory/malloc Thanks. ------------- Marked as reviewed by jvernee (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16775#pullrequestreview-1743488802 From sviswanathan at openjdk.org Wed Nov 22 04:52:09 2023 From: sviswanathan at openjdk.org (Sandhya Viswanathan) Date: Wed, 22 Nov 2023 04:52:09 GMT Subject: RFR: 8310159: Bulk copy with Unsafe::arrayCopy is slower compared to memcpy [v6] In-Reply-To: References: Message-ID: On Tue, 21 Nov 2023 21:03:20 GMT, Steve Dohrmann wrote: >> Update: the XorTest::xor results shown in this message used test code from PR commit 7cc272e862791 which was based on Maurizio Cimadamore's commit a788f066af17. The XorTest has since been updated and XorTest::copy is no longer needed and has been removed from this pull request. See comment [here](https://github.com/openjdk/jdk/pull/16575#issuecomment-1820006548) for updated performance data. >> >> Below is baseline data collected using a modified version of the java.lang.foreign.xor micro benchmark referenced by @mcimadamore in the bug report. I collected data on an Ubuntu 22.04 laptop with a Tigerlake i7-1185G7, which does support AVX512. >> >> Baseline data >> Benchmark (arrayKind) (sizeKind) Mode Cnt Score Error Units >> -------------------------------------------------------------------------------------- >> XorTest.copy ELEMENTS SMALL avgt 30 584737355.767 ? 60414308.540 ns/op >> XorTest.copy ELEMENTS MEDIUM avgt 30 272248995.683 ? 2924954.498 ns/op >> XorTest.copy ELEMENTS LARGE avgt 30 1019200210.900 ? 28334453.652 ns/op >> XorTest.copy REGION SMALL avgt 30 7399944.164 ? 216821.819 ns/op >> XorTest.copy REGION MEDIUM avgt 30 20591454.558 ? 147398.572 ns/op >> XorTest.copy REGION LARGE avgt 30 21649266.051 ? 179263.875 ns/op >> XorTest.copy CRITICAL SMALL avgt 30 51079.357 ? 542.482 ns/op >> XorTest.copy CRITICAL MEDIUM avgt 30 2496.961 ? 11.375 ns/op >> XorTest.copy CRITICAL LARGE avgt 30 515.454 ? 5.831 ns/op >> XorTest.copy FOREIGN SMALL avgt 30 7558432.075 ? 79489.276 ns/op >> XorTest.copy FOREIGN MEDIUM avgt 30 19730666.341 ? 500505.099 ns/op >> XorTest.copy FOREIGN LARGE avgt 30 34616758.085 ? 340300.726 ns/op >> XorTest.xor ELEMENTS SMALL avgt 30 219832692.489 ? 2329417.319 ns/op >> XorTest.xor ELEMENTS MEDIUM avgt 30 505138197.167 ? 3818334.424 ns/op >> XorTest.xor ELEMENTS LARGE avgt 30 1189608474.667 ? 5877981.900 ns/op >> XorTest.xor REGION SMALL avgt 30 64093872.804 ? 599704.491 ns/op >> XorTest.xor REGION MEDIUM avgt 30 81544576.454 ? 1406342.118 ns/op >> XorTest.xor REGION LARGE avgt 30 90091424.883 ? 775577.613 ns/op >> XorTest.xor CRITICAL SMALL avgt ... > > Steve Dohrmann has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits: > > - Merge branch 'master' into memcpy > - Updates based on reviewer (sviswa7) comments including > - use asserts instead of conditionals in two logically unreachable blocks > - remove unused function parmeters > - use 64-byte vector path in pre-loop masked write > - Merge branch 'master' into memcpy > - Update full name > Previous commit (fcbbc0d7880) added org.openjdk.bench.java.lang.ArrayCopyAlignedLarge benchmark > - - remerge upstream master > - remove ::copy test from XorTest > - Merge branch 'master' into memcpy > - - fix whitespace error > - Merge branch 'master' of https://git.openjdk.org/jdk into memcpy > - - bug fix: only generate / use large copy code if MaxVectorSize == 64 > - - fix whitespace issues > - fix xor test foreign impl constructor signature > - ... and 1 more: https://git.openjdk.org/jdk/compare/e47cf611...02ad27fa Thanks a lot for taking care of all the review comments. The PR looks good to me now. ------------- Marked as reviewed by sviswanathan (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16575#pullrequestreview-1743562444 From rriggs at openjdk.org Wed Nov 22 05:03:41 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 22 Nov 2023 05:03:41 GMT Subject: RFR: 8311906: Improve robustness of String constructors with mutable array inputs [v12] In-Reply-To: <6SKlGLh5MmxoEx07wHCCUc8KWbbhcspLJmcc1uxQ_FI=.ca33bfb4-fa5c-45f0-b49f-ee6c5c6b68b4@github.com> References: <6SKlGLh5MmxoEx07wHCCUc8KWbbhcspLJmcc1uxQ_FI=.ca33bfb4-fa5c-45f0-b49f-ee6c5c6b68b4@github.com> Message-ID: > Strings, after construction, are immutable but may be constructed from mutable arrays of bytes, characters, or integers. > The string constructors should guard against the effects of mutating the arrays during construction that might invalidate internal invariants for the correct behavior of operations on the resulting strings. In particular, a number of operations have optimizations for operations on pairs of latin1 strings and pairs of non-latin1 strings, while operations between latin1 and non-latin1 strings use a more general implementation. > > The changes include: > > - Adding a warning to each constructor with an array as an argument to indicate that the results are indeterminate > if the input array is modified before the constructor returns. > The resulting string may contain any combination of characters sampled from the input array. > > - Ensure that strings that are represented as non-latin1 contain at least one non-latin1 character. > For latin1 inputs, whether the arrays contain ASCII, ISO-8859-1, UTF8, or another encoding decoded to latin1 the scanning and compression is unchanged. > If a non-latin1 character is found, the string is represented as non-latin1 with the added verification that a non-latin1 character is present at the same index. > If that character is found to be latin1, then the input array has been modified and the result of the scan may be incorrect. > Though a ConcurrentModificationException could be thrown, the risk to an existing application of an unexpected exception should be avoided. > Instead, the non-latin1 copy of the input is re-scanned and compressed; that scan determines whether the latin1 or the non-latin1 representation is returned. > > - The methods that scan for non-latin1 characters and their intrinsic implementations are updated to return the index of the non-latin1 character. > > - String construction from StringBuilder and CharSequence must also be guarded as their contents may be modified during construction. Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: Apply StringUTF16.coderFromArrayLen ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16425/files - new: https://git.openjdk.org/jdk/pull/16425/files/0256b9e0..d201344b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16425&range=11 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16425&range=10-11 Stats: 5 lines in 2 files changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/16425.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16425/head:pull/16425 PR: https://git.openjdk.org/jdk/pull/16425 From haosun at openjdk.org Wed Nov 22 05:35:13 2023 From: haosun at openjdk.org (Hao Sun) Date: Wed, 22 Nov 2023 05:35:13 GMT Subject: RFR: 8320131: Zero build fails on macOS after JDK-8254693 In-Reply-To: References: Message-ID: On Wed, 22 Nov 2023 02:06:29 GMT, Hao Sun wrote: > The fix is trivial. We should include the standard C header `stdlib.h` [1], rather than non-standard one `malloc.h`. > > [1] https://en.cppreference.com/w/c/memory/malloc Thanks for your reviews. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16775#issuecomment-1822140880 From haosun at openjdk.org Wed Nov 22 05:35:14 2023 From: haosun at openjdk.org (Hao Sun) Date: Wed, 22 Nov 2023 05:35:14 GMT Subject: Integrated: 8320131: Zero build fails on macOS after JDK-8254693 In-Reply-To: References: Message-ID: <7kGWWowNy6a0ONYSn7B0bZGgU6ToOLvQAR0kuEGqktU=.43be26e3-1f6e-4969-a609-51dec1d23422@github.com> On Wed, 22 Nov 2023 02:06:29 GMT, Hao Sun wrote: > The fix is trivial. We should include the standard C header `stdlib.h` [1], rather than non-standard one `malloc.h`. > > [1] https://en.cppreference.com/w/c/memory/malloc This pull request has now been integrated. Changeset: b3616c9a Author: Hao Sun URL: https://git.openjdk.org/jdk/commit/b3616c9ac09a29824441dea4588ce53fa443067d Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 mod 8320131: Zero build fails on macOS after JDK-8254693 Reviewed-by: dholmes, jvernee ------------- PR: https://git.openjdk.org/jdk/pull/16775 From dholmes at openjdk.org Wed Nov 22 05:46:12 2023 From: dholmes at openjdk.org (David Holmes) Date: Wed, 22 Nov 2023 05:46:12 GMT Subject: RFR: JDK-8317799 : AIX PPC64: FFI symbol lookup doesn't find symbols [v7] In-Reply-To: References: Message-ID: On Tue, 21 Nov 2023 19:30:30 GMT, suchismith1993 wrote: >> The math library in AIX specifically, is a static archive. Doing a -lm wont suffice, because when the symbols are looked up using dlsym or accessing native code through Java, it will lead to failures. >> Hence we had to come up with a list of symbols to allow math library symbols to be accesible. >> Also, there are parts of libc library that are static too, and hence those symbols also are present in this list. >> Without this change, the StdLibTest and multiple other tests which make native function calls using FFI, fail with NoSuchElementException. >> >> >> 1. Adding required compiler flags. >> 2. Adding required symbols. >> >> >> JBS-ISSUE : [JDK-8317799](https://bugs.openjdk.org/browse/JDK-8317799) > > suchismith1993 has updated the pull request incrementally with two additional commits since the last revision: > > - Fix Typos > - Remove unnecessary includes This is much more palatable and good to be consistent with what is done on Windows. Thank. ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16414#pullrequestreview-1743602440 From jvernee at openjdk.org Wed Nov 22 06:53:12 2023 From: jvernee at openjdk.org (Jorn Vernee) Date: Wed, 22 Nov 2023 06:53:12 GMT Subject: RFR: JDK-8317799 : AIX PPC64: FFI symbol lookup doesn't find symbols [v7] In-Reply-To: References: Message-ID: <_4iloDLR7tRen-QWl8KB9N_r5sU1u3hl215V9Qkn2R4=.e53d41d5-91fd-4b91-8184-8e3947ed9f88@github.com> On Tue, 21 Nov 2023 19:30:30 GMT, suchismith1993 wrote: >> The math library in AIX specifically, is a static archive. Doing a -lm wont suffice, because when the symbols are looked up using dlsym or accessing native code through Java, it will lead to failures. >> Hence we had to come up with a list of symbols to allow math library symbols to be accesible. >> Also, there are parts of libc library that are static too, and hence those symbols also are present in this list. >> Without this change, the StdLibTest and multiple other tests which make native function calls using FFI, fail with NoSuchElementException. >> >> >> 1. Adding required compiler flags. >> 2. Adding required symbols. >> >> >> JBS-ISSUE : [JDK-8317799](https://bugs.openjdk.org/browse/JDK-8317799) > > suchismith1993 has updated the pull request incrementally with two additional commits since the last revision: > > - Fix Typos > - Remove unnecessary includes Note that on Windows we also have a lookup mechanism on the Java side: https://github.com/openjdk/jdk/blob/2c31ca525b1cd70c3dfcb0463c8c984bdd7c886a/src/java.base/share/classes/jdk/internal/foreign/SystemLookup.java#L159 On Windows we need to load the global array, and then grab functions from the array. Why isn't that needed on AIX? Is `dlsym` able to find the statically linked functions as well? ------------- PR Comment: https://git.openjdk.org/jdk/pull/16414#issuecomment-1822205442 From eliu at openjdk.org Wed Nov 22 07:05:21 2023 From: eliu at openjdk.org (Eric Liu) Date: Wed, 22 Nov 2023 07:05:21 GMT Subject: RFR: 8319872: AArch64: [vectorapi] Implementation of unsigned (zero extended) casts [v4] In-Reply-To: References: Message-ID: > Vector API defines zero-extend operations [1], which are going to be intrinsified and generated to `VectorUCastNode` by C2. This patch adds backend implementation for `VectorUCastNode` on AArch64. > > The micro benchmark shows significant performance improvement. In my test machine (SVE, 256-bit), the result is shown as below: > > > > Benchmark Before After Units Gain > VectorZeroExtend.byte2Int 3168.251 243012.399 ops/ms 75.70 > VectorZeroExtend.byte2Long 3212.201 216291.588 ops/ms 66.33 > VectorZeroExtend.byte2Short 3391.968 182655.365 ops/ms 52.85 > VectorZeroExtend.int2Long 1012.197 80448.553 ops/ms 78.48 > VectorZeroExtend.short2Int 1812.471 153416.828 ops/ms 83.65 > VectorZeroExtend.short2Long 1788.382 129794.814 ops/ms 71.58 > > > On other Neon systems, we can get similar performance boost as a result of intrinsification success. > > Since `VectorUCastNode` only used in Vector API's zero extension currently, this patch also adds assertion on nodes' definitions to clarify their usages. > > [TEST] > compiler/vectorapi and jdk/incubator/vector passed on NEON and SVE machines. > > [1] https://github.com/openjdk/jdk/blob/master/src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorOperators.java#L726 Eric Liu has updated the pull request incrementally with one additional commit since the last revision: small fix Change-Id: Icfe9619af1c9e7d5ea8cac457ccebb4eec5c34ad ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16670/files - new: https://git.openjdk.org/jdk/pull/16670/files/68748e7f..268b71db Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16670&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16670&range=02-03 Stats: 17 lines in 1 file changed: 0 ins; 9 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/16670.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16670/head:pull/16670 PR: https://git.openjdk.org/jdk/pull/16670 From eliu at openjdk.org Wed Nov 22 07:08:05 2023 From: eliu at openjdk.org (Eric Liu) Date: Wed, 22 Nov 2023 07:08:05 GMT Subject: RFR: 8319872: AArch64: [vectorapi] Implementation of unsigned (zero extended) casts [v2] In-Reply-To: References: <_i1HpqtJBEarrwnOEQ4l1mgaNeqfJv59Aq5if7e_heU=.9bd7cd18-8e26-46a4-a7be-188c73121f0f@github.com> Message-ID: On Tue, 21 Nov 2023 13:29:32 GMT, Eric Liu wrote: >> Got it. I will fix it soon. Thanks! > > compiler/vectorapi and jdk/incubator/vector passed. Full test is running. I would report the result when it has been finished. Full jtreg passed without new failure. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16670#discussion_r1401594486 From duke at openjdk.org Wed Nov 22 07:32:13 2023 From: duke at openjdk.org (suchismith1993) Date: Wed, 22 Nov 2023 07:32:13 GMT Subject: RFR: JDK-8317799 : AIX PPC64: FFI symbol lookup doesn't find symbols [v7] In-Reply-To: References: Message-ID: On Tue, 21 Nov 2023 19:30:30 GMT, suchismith1993 wrote: >> The math library in AIX specifically, is a static archive. Doing a -lm wont suffice, because when the symbols are looked up using dlsym or accessing native code through Java, it will lead to failures. >> Hence we had to come up with a list of symbols to allow math library symbols to be accesible. >> Also, there are parts of libc library that are static too, and hence those symbols also are present in this list. >> Without this change, the StdLibTest and multiple other tests which make native function calls using FFI, fail with NoSuchElementException. >> >> >> 1. Adding required compiler flags. >> 2. Adding required symbols. >> >> >> JBS-ISSUE : [JDK-8317799](https://bugs.openjdk.org/browse/JDK-8317799) > > suchismith1993 has updated the pull request incrementally with two additional commits since the last revision: > > - Fix Typos > - Remove unnecessary includes Yes.The test cases for lookup of symbols have passed. I think the bexpfull option helps in exporting the right symbols being referenced. On Wednesday, November 22, 2023, Jorn Vernee ***@***.***> wrote: > Note that on Windows we also have a lookup mechanism on the Java side: > https://github.com/openjdk/jdk/blob/2c31ca525b1cd70c3dfcb0463c8c98 > 4bdd7c886a/src/java.base/share/classes/jdk/internal/ > foreign/SystemLookup.java#L159 > > On Windows we need to load the global array, and then grab functions from > the array. Why isn't that needed on AIX? Is dlsym able to find the > statically linked functions as well? > > ? > Reply to this email directly, view it on GitHub > , or > unsubscribe > > . > You are receiving this because you were mentioned.Message ID: > ***@***.***> > ------------- PR Comment: https://git.openjdk.org/jdk/pull/16414#issuecomment-1822243041 From jvernee at openjdk.org Wed Nov 22 07:43:14 2023 From: jvernee at openjdk.org (Jorn Vernee) Date: Wed, 22 Nov 2023 07:43:14 GMT Subject: RFR: JDK-8317799 : AIX PPC64: FFI symbol lookup doesn't find symbols [v7] In-Reply-To: References: Message-ID: On Tue, 21 Nov 2023 19:30:30 GMT, suchismith1993 wrote: >> The math library in AIX specifically, is a static archive. Doing a -lm wont suffice, because when the symbols are looked up using dlsym or accessing native code through Java, it will lead to failures. >> Hence we had to come up with a list of symbols to allow math library symbols to be accesible. >> Also, there are parts of libc library that are static too, and hence those symbols also are present in this list. >> Without this change, the StdLibTest and multiple other tests which make native function calls using FFI, fail with NoSuchElementException. >> >> >> 1. Adding required compiler flags. >> 2. Adding required symbols. >> >> >> JBS-ISSUE : [JDK-8317799](https://bugs.openjdk.org/browse/JDK-8317799) > > suchismith1993 has updated the pull request incrementally with two additional commits since the last revision: > > - Fix Typos > - Remove unnecessary includes Marked as reviewed by jvernee (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/16414#pullrequestreview-1743738561 From aturbanov at openjdk.org Wed Nov 22 08:10:09 2023 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Wed, 22 Nov 2023 08:10:09 GMT Subject: RFR: JDK-8319662 ForkJoinPool trims worker threads too slowly [v3] In-Reply-To: References: Message-ID: On Tue, 21 Nov 2023 17:12:39 GMT, Doug Lea

    wrote: >> This update cascades timeouts to trim subsequent workers after the first keepAlive inactive period. > > 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 three additional commits since the last revision: > > - Merge branch 'openjdk:master' into JDK-8319662 > - tweak cascades; reinstate an @Contended; resolve JDK-8319498 > - Support cascading idle timeouts src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 2149: > 2147: deadline - System.currentTimeMillis() < TIMEOUT_SLOP) { > 2148: long sp = w.stackPred & LMASK, c; > 2149: if ((nextPhase & SMASK) == ((int)(c = ctl) & SMASK) && Suggestion: if ((nextPhase & SMASK) == ((int)(c = ctl) & SMASK) && ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16725#discussion_r1401649883 From aturbanov at openjdk.org Wed Nov 22 08:11:09 2023 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Wed, 22 Nov 2023 08:11:09 GMT Subject: RFR: 8306055: Add a built-in Catalog to JDK XML module [v3] In-Reply-To: References: Message-ID: On Mon, 20 Nov 2023 17:46:53 GMT, Joe Wang wrote: >> Implement the built-in Catalog. > > Joe Wang has updated the pull request incrementally with one additional commit since the last revision: > > add a note; fix alignment src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/XMLEntityManager.java line 1031: > 1029: if (fStaxEntityResolver != null) { > 1030: staxInputSource = fStaxEntityResolver.resolveEntity(ri); > 1031: } else if(fEntityResolver != null){ Suggestion: } else if (fEntityResolver != null){ src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/XMLEntityManager.java line 1033: > 1031: } else if(fEntityResolver != null){ > 1032: xmlInputSource = fEntityResolver.resolveEntity(ri); > 1033: if(xmlInputSource != null){ Suggestion: if (xmlInputSource != null){ test/jaxp/javax/xml/jaxp/unittest/common/catalog/CatalogTestBase.java line 299: > 297: Properties config, Properties[] sysProp, Properties[] apiProp, CustomCatalog cc, > 298: boolean expectError, String error) throws Exception { > 299: testSchema1(filename, xsd, fsp, state, config, sysProp, apiProp, cc, expectError, error); Suggestion: testSchema1(filename, xsd, fsp, state, config, sysProp, apiProp, cc, expectError, error); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16719#discussion_r1401651121 PR Review Comment: https://git.openjdk.org/jdk/pull/16719#discussion_r1401651265 PR Review Comment: https://git.openjdk.org/jdk/pull/16719#discussion_r1401651537 From shade at openjdk.org Wed Nov 22 09:00:13 2023 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 22 Nov 2023 09:00:13 GMT Subject: RFR: 8318776: Require supports_cx8 to always be true [v5] In-Reply-To: References: Message-ID: On Wed, 22 Nov 2023 02:09:38 GMT, David Holmes wrote: >> As discussed in JBS all platforms (some tweaks to Zero are in progress) actually do support `cx8` i.e. 64-bit compare-and-exchange, so we can strip out the locked-based alternatives to using it and just add a guarantee that it is true at runtime. And all platforms except some ARM variants set `SUPPORTS_NATIVE_CX8`, so we can greatly simplify things. Summary of changes: >> - `_supports_cx8` field is only needed when `SUPPORTS_NATIVE_CX8` is not defined >> - Assertions for `supports_cx8()` are removed >> - Compiler predicates requiring `supports_cx8()` are removed >> - Access backend is greatly simplified without the need for lock-based alternative >> - `java.util.concurrent.AtomicLongFieldUpdater` is simplified without the need for a lock-based alternative >> >> I did consider moving all the ARM `kuser_helper` related code to be only defined when `SUPPORTS_NATIVE_CX8` is not defined, but there was a theoretical risk this could change the behaviour if ARMv7 binaries were run on other ARM CPU's. I added a note to that effect in vm_version_linux_arm32.cpp so the ARM port maintainers could clean this up further if desired. >> >> Testing: >> - All Oracle tiers 1-5 builds (which includes an ARMv7 build) >> - GHA builds/tests >> - Oracle tiers 1-3 sanity testing >> >> Zero changes coming in via [JDK-8319777](https://bugs.openjdk.org/browse/JDK-8319777) will be merged when they arrive. >> >> Thanks. > > David Holmes has updated the pull request with a new target base 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 with master and update Zero code accordingly > - Merge branch 'master' into 8318776-supports_cx8 > - Remove unnecessary includes of vm_version.hpp. > Fix copyright years. > - Remove cx8 comment as no longer relevant (the spinlock is used regardless of cx8) > - Remove suports_cx8() checks from gtest > - Remove test for VMSupportsCX8 > - 8318776: Require supports_cx8 to always be true Thanks! Zero tests are running. The PR looks great, except extra safety suggestion in x86 part: src/hotspot/cpu/x86/vm_version_x86.cpp line 819: > 817: } > 818: > 819: _supports_cx8 = supports_cmpxchg8(); I think we should leave the runtime check here (under `ifndef`, like in ARM?). This covers the remaining case of running on legacy x86 without CX8 implemented: the init guarantee would then fire and prevent any other surprises at runtime. Sure, it would be hard to come up with such a platform today, but it would be safer to refuse to run there right away on the off-chance someone actually has it :) ------------- PR Review: https://git.openjdk.org/jdk/pull/16625#pullrequestreview-1743847107 PR Review Comment: https://git.openjdk.org/jdk/pull/16625#discussion_r1401696816 From alanb at openjdk.org Wed Nov 22 09:01:09 2023 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 22 Nov 2023 09:01:09 GMT Subject: RFR: 8306055: Add a built-in Catalog to JDK XML module [v3] In-Reply-To: References: Message-ID: On Mon, 20 Nov 2023 17:46:53 GMT, Joe Wang wrote: >> Implement the built-in Catalog. > > Joe Wang has updated the pull request incrementally with one additional commit since the last revision: > > add a note; fix alignment I'm happy with the addition of the JDK built-in catalog, the inclusion of the DTD defined by Java SE, and the docs updates. ------------- Marked as reviewed by alanb (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16719#pullrequestreview-1743867203 From aph at openjdk.org Wed Nov 22 09:08:09 2023 From: aph at openjdk.org (Andrew Haley) Date: Wed, 22 Nov 2023 09:08:09 GMT Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations with SLEEF [v3] In-Reply-To: References: <97YS_I-DY-Q5agE6mE-iBkoVxtvL7R4Q3NebjTsXMvI=.dac0dc99-84d7-4cbd-ada6-5190564688a9@github.com> Message-ID: On Wed, 22 Nov 2023 01:52:51 GMT, Xiaohong Gong wrote: > > Have you considered the possibility of copying the sleef source to the OpenJDK repository and thereby it becomes part of the build process? I don't know how straightforward that is technically and IANAL but I think it's worth exploring. > > Hi @PaulSandoz ! Thanks for the suggestion! Copying the sleef source sounds good. However, I actually have no idea about how to handle the third-party licence in OpenJDK project. Do you have any idea about this area? Some suggestions/guidence from the JDK team will be much helpful. Thanks! >From a legal pespective, we can do this. SLEEF is distributed under Boost Software License Version 1.0., which is a GPL-compatible free software licence. The only issue is whether we want to do so. It would certainly be convenient. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16234#issuecomment-1822364670 From aph at openjdk.org Wed Nov 22 09:10:07 2023 From: aph at openjdk.org (Andrew Haley) Date: Wed, 22 Nov 2023 09:10:07 GMT Subject: RFR: 8319872: AArch64: [vectorapi] Implementation of unsigned (zero extended) casts [v3] In-Reply-To: <4mFjuz7TksaNGb1AXirVsXZF_95oJ2-UiHCP9Y7lxFM=.fd477fa9-85c1-4df3-a0c1-061c6f451873@github.com> References: <4mFjuz7TksaNGb1AXirVsXZF_95oJ2-UiHCP9Y7lxFM=.fd477fa9-85c1-4df3-a0c1-061c6f451873@github.com> Message-ID: On Wed, 22 Nov 2023 02:18:32 GMT, Eric Liu wrote: >> src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp line 1412: >> >>> 1410: _sve_xunpk(is_unsigned, /* is_high */ false, dst, S, dst); >>> 1411: _sve_xunpk(is_unsigned, /* is_high */ false, dst, D, dst); >>> 1412: break; >> >> Why is this change here? It doesn't do anything. Does it? > > `is_unsigned` is also used in this function. It is used in VectorUCastNode for zero extending. Ah, I see. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16670#discussion_r1401721522 From shade at openjdk.org Wed Nov 22 09:27:11 2023 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 22 Nov 2023 09:27:11 GMT Subject: RFR: 8318776: Require supports_cx8 to always be true [v5] In-Reply-To: References: Message-ID: On Wed, 22 Nov 2023 02:09:38 GMT, David Holmes wrote: >> As discussed in JBS all platforms (some tweaks to Zero are in progress) actually do support `cx8` i.e. 64-bit compare-and-exchange, so we can strip out the locked-based alternatives to using it and just add a guarantee that it is true at runtime. And all platforms except some ARM variants set `SUPPORTS_NATIVE_CX8`, so we can greatly simplify things. Summary of changes: >> - `_supports_cx8` field is only needed when `SUPPORTS_NATIVE_CX8` is not defined >> - Assertions for `supports_cx8()` are removed >> - Compiler predicates requiring `supports_cx8()` are removed >> - Access backend is greatly simplified without the need for lock-based alternative >> - `java.util.concurrent.AtomicLongFieldUpdater` is simplified without the need for a lock-based alternative >> >> I did consider moving all the ARM `kuser_helper` related code to be only defined when `SUPPORTS_NATIVE_CX8` is not defined, but there was a theoretical risk this could change the behaviour if ARMv7 binaries were run on other ARM CPU's. I added a note to that effect in vm_version_linux_arm32.cpp so the ARM port maintainers could clean this up further if desired. >> >> Testing: >> - All Oracle tiers 1-5 builds (which includes an ARMv7 build) >> - GHA builds/tests >> - Oracle tiers 1-3 sanity testing >> >> Zero changes coming in via [JDK-8319777](https://bugs.openjdk.org/browse/JDK-8319777) will be merged when they arrive. >> >> Thanks. > > David Holmes has updated the pull request with a new target base 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 with master and update Zero code accordingly > - Merge branch 'master' into 8318776-supports_cx8 > - Remove unnecessary includes of vm_version.hpp. > Fix copyright years. > - Remove cx8 comment as no longer relevant (the spinlock is used regardless of cx8) > - Remove suports_cx8() checks from gtest > - Remove test for VMSupportsCX8 > - 8318776: Require supports_cx8 to always be true src/hotspot/share/runtime/vm_version.cpp line 33: > 31: void VM_Version_init() { > 32: VM_Version::initialize(); > 33: guarantee(VM_Version::supports_cx8(), "Support for 64-bit atomic operations in required in this release"); Typo: "in required in". Also, no need to mention "this release" at all? Suggestion for message: "JVM requires platform support for 64-bit atomic operations" ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16625#discussion_r1401743607 From varadam at openjdk.org Wed Nov 22 09:53:14 2023 From: varadam at openjdk.org (Varada M) Date: Wed, 22 Nov 2023 09:53:14 GMT Subject: RFR: JDK-8320309: AIX: pthreads created by foreign test library don't work as expected Message-ID: <98Q44DyEq4dkLDuIMsaAzDzDnYJAgg2Wlc-NjhtOq6Y=.5e7b3e15-476d-404f-a286-91143a055b23@github.com> Following test fails due to missing pthread attributes on AIX : java/foreign/TestUpcallAsync.java java/foreign/stackwalk/TestAsyncStackWalk.java java/foreign/loaderLookup/TestLoaderLookupJNI.java java/foreign/enablenativeaccess/TestEnableNativeAccessJarManifest.java java/foreign/enablenativeaccess/TestEnableNativeAccess.java Note : Test needs the changes from [pull/16579](https://github.com/openjdk/jdk/pull/16579) and [pull/16414](https://github.com/openjdk/jdk/pull/16414 ) JBS Issue : [JDK-8320309](https://bugs.openjdk.org/browse/JDK-8320309) ------------- Commit messages: - added pthread_attr_destroy - added pthread attributes Changes: https://git.openjdk.org/jdk/pull/16757/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16757&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8320309 Stats: 6 lines in 1 file changed: 5 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/16757.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16757/head:pull/16757 PR: https://git.openjdk.org/jdk/pull/16757 From mdoerr at openjdk.org Wed Nov 22 09:53:15 2023 From: mdoerr at openjdk.org (Martin Doerr) Date: Wed, 22 Nov 2023 09:53:15 GMT Subject: RFR: JDK-8320309: AIX: pthreads created by foreign test library don't work as expected In-Reply-To: <98Q44DyEq4dkLDuIMsaAzDzDnYJAgg2Wlc-NjhtOq6Y=.5e7b3e15-476d-404f-a286-91143a055b23@github.com> References: <98Q44DyEq4dkLDuIMsaAzDzDnYJAgg2Wlc-NjhtOq6Y=.5e7b3e15-476d-404f-a286-91143a055b23@github.com> Message-ID: On Tue, 21 Nov 2023 10:09:04 GMT, Varada M wrote: > Following test fails due to missing pthread attributes on AIX : > java/foreign/TestUpcallAsync.java > java/foreign/stackwalk/TestAsyncStackWalk.java > java/foreign/loaderLookup/TestLoaderLookupJNI.java > java/foreign/enablenativeaccess/TestEnableNativeAccessJarManifest.java > java/foreign/enablenativeaccess/TestEnableNativeAccess.java > > Note : Test needs the changes from [pull/16579](https://github.com/openjdk/jdk/pull/16579) and [pull/16414](https://github.com/openjdk/jdk/pull/16414 ) > > JBS Issue : [JDK-8320309](https://bugs.openjdk.org/browse/JDK-8320309) Thanks for fixing it! LGTM. Thanks for providing a fix! This helps. All test/jdk/java/foreign tests have passed when testing together with Sutchi's 2 PRs. I think `pthread_attr_destroy` should be added. Otherwise, looks good. ------------- Marked as reviewed by mdoerr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16757#pullrequestreview-1743945918 PR Comment: https://git.openjdk.org/jdk/pull/16757#issuecomment-1821023741 From varadam at openjdk.org Wed Nov 22 09:53:17 2023 From: varadam at openjdk.org (Varada M) Date: Wed, 22 Nov 2023 09:53:17 GMT Subject: RFR: JDK-8320309: AIX: pthreads created by foreign test library don't work as expected In-Reply-To: References: <98Q44DyEq4dkLDuIMsaAzDzDnYJAgg2Wlc-NjhtOq6Y=.5e7b3e15-476d-404f-a286-91143a055b23@github.com> Message-ID: On Tue, 21 Nov 2023 14:24:47 GMT, Martin Doerr wrote: >> Following test fails due to missing pthread attributes on AIX : >> java/foreign/TestUpcallAsync.java >> java/foreign/stackwalk/TestAsyncStackWalk.java >> java/foreign/loaderLookup/TestLoaderLookupJNI.java >> java/foreign/enablenativeaccess/TestEnableNativeAccessJarManifest.java >> java/foreign/enablenativeaccess/TestEnableNativeAccess.java >> >> Note : Test needs the changes from [pull/16579](https://github.com/openjdk/jdk/pull/16579) and [pull/16414](https://github.com/openjdk/jdk/pull/16414 ) >> >> JBS Issue : [JDK-8320309](https://bugs.openjdk.org/browse/JDK-8320309) > > Thanks for providing a fix! This helps. All test/jdk/java/foreign tests have passed when testing together with Sutchi's 2 PRs. > I think `pthread_attr_destroy` should be added. Otherwise, looks good. @TheRealMDoerr : That's a good news. I have added `pthread_attr_destroy` as well. Should I wait for Suchi's PRs to be merged or can I make this PR "Ready for Review"? ------------- PR Comment: https://git.openjdk.org/jdk/pull/16757#issuecomment-1822385824 From mdoerr at openjdk.org Wed Nov 22 09:53:17 2023 From: mdoerr at openjdk.org (Martin Doerr) Date: Wed, 22 Nov 2023 09:53:17 GMT Subject: RFR: JDK-8320309: AIX: pthreads created by foreign test library don't work as expected In-Reply-To: References: <98Q44DyEq4dkLDuIMsaAzDzDnYJAgg2Wlc-NjhtOq6Y=.5e7b3e15-476d-404f-a286-91143a055b23@github.com> Message-ID: <5DWQvdTvSU1v3rbixH7DhNr9RjVGy86GlLWfWTzgAS4=.1637f690-569e-4aef-8570-f69b73d4fd77@github.com> On Tue, 21 Nov 2023 14:24:47 GMT, Martin Doerr wrote: >> Following test fails due to missing pthread attributes on AIX : >> java/foreign/TestUpcallAsync.java >> java/foreign/stackwalk/TestAsyncStackWalk.java >> java/foreign/loaderLookup/TestLoaderLookupJNI.java >> java/foreign/enablenativeaccess/TestEnableNativeAccessJarManifest.java >> java/foreign/enablenativeaccess/TestEnableNativeAccess.java >> >> Note : Test needs the changes from [pull/16579](https://github.com/openjdk/jdk/pull/16579) and [pull/16414](https://github.com/openjdk/jdk/pull/16414 ) >> >> JBS Issue : [JDK-8320309](https://bugs.openjdk.org/browse/JDK-8320309) > > Thanks for providing a fix! This helps. All test/jdk/java/foreign tests have passed when testing together with Sutchi's 2 PRs. > I think `pthread_attr_destroy` should be added. Otherwise, looks good. > @TheRealMDoerr : That's a good news. I have added `pthread_attr_destroy` as well. Should I wait for Suchi's PRs to be merged or can I make this PR "Ready for Review"? It's good to go. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16757#issuecomment-1822416974 From duke at openjdk.org Wed Nov 22 10:09:04 2023 From: duke at openjdk.org (Eirik Bjorsnos) Date: Wed, 22 Nov 2023 10:09:04 GMT Subject: RFR: 8319668: Fixup of jar filename typo in BadFactoryTest.sh In-Reply-To: References: Message-ID: On Tue, 21 Nov 2023 21:16:41 GMT, Eirik Bjorsnos wrote: > So it's not clear to me why this test uses a jar file at all, it does not seem necessary. On a closer look, `${TESTCLASSES}` contains the compiled java classes, but not the service definition file `META-INF/services/javax.script.ScriptEngineFactory`. That probably explains the jar file. Adding `${TESTSRC}` to the class paths would incude the service definition file: -classpath "${TESTCLASSES}${PS}${TESTSRC}" But perhaps not a big improvement. Might be better to spend efforts re-writing this in Java, as suggested by Alan. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16585#issuecomment-1822463159 From shade at openjdk.org Wed Nov 22 10:38:08 2023 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 22 Nov 2023 10:38:08 GMT Subject: RFR: 8318776: Require supports_cx8 to always be true [v5] In-Reply-To: References: Message-ID: On Wed, 22 Nov 2023 08:57:11 GMT, Aleksey Shipilev wrote: > Zero tests are running. Caught the `guarantee` on linux-arm-zero-fastdebug! But that is actually the fault in my previous patch: #16779. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16625#issuecomment-1822510325 From amitkumar at openjdk.org Wed Nov 22 11:26:06 2023 From: amitkumar at openjdk.org (Amit Kumar) Date: Wed, 22 Nov 2023 11:26:06 GMT Subject: RFR: JDK-8318175 : AIX PPC64: Handle alignment of double in structs In-Reply-To: <2TGtA0RwdjsEIrxdaWvt-mR4J0Ni0BPqTZbrhxUsMoY=.bf393d8c-a3af-438e-898f-23c2287d1449@github.com> References: <2TGtA0RwdjsEIrxdaWvt-mR4J0Ni0BPqTZbrhxUsMoY=.bf393d8c-a3af-438e-898f-23c2287d1449@github.com> Message-ID: <20nybcFfGxc5o8cwS36JuG8IiZooaFGU2TOvLLQdgJk=.d8fe0a5f-0550-46af-ae48-5fa6a1cce67e@github.com> On Thu, 9 Nov 2023 09:22:45 GMT, suchismith1993 wrote: > 1. use pragma directive to handle alignment. > > JBS Issue: [JDK-8318175](https://bugs.openjdk.org/browse/JDK-8318175) LGTM ------------- Marked as reviewed by amitkumar (Committer). PR Review: https://git.openjdk.org/jdk/pull/16579#pullrequestreview-1744157050 From dl at openjdk.org Wed Nov 22 11:27:05 2023 From: dl at openjdk.org (Doug Lea) Date: Wed, 22 Nov 2023 11:27:05 GMT Subject: RFR: JDK-8319662 ForkJoinPool trims worker threads too slowly [v3] In-Reply-To: References: Message-ID: <6TE0r04OSd_PhBMV2VL2lnto82t0mNzTZvupgZTnE0o=.cd5a85ab-2561-4804-98ee-37e93ccdb092@github.com> On Wed, 22 Nov 2023 08:07:00 GMT, Andrey Turbanov wrote: >> 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 three additional commits since the last revision: >> >> - Merge branch 'openjdk:master' into JDK-8319662 >> - tweak cascades; reinstate an @Contended; resolve JDK-8319498 >> - Support cascading idle timeouts > > src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 2149: > >> 2147: deadline - System.currentTimeMillis() < TIMEOUT_SLOP) { >> 2148: long sp = w.stackPred & LMASK, c; >> 2149: if ((nextPhase & SMASK) == ((int)(c = ctl) & SMASK) && > > Suggestion: > > if ((nextPhase & SMASK) == ((int)(c = ctl) & SMASK) && Thanks; done ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16725#discussion_r1401900689 From dl at openjdk.org Wed Nov 22 11:27:08 2023 From: dl at openjdk.org (Doug Lea) Date: Wed, 22 Nov 2023 11:27:08 GMT Subject: RFR: JDK-8319662 ForkJoinPool trims worker threads too slowly [v3] In-Reply-To: <6tj5Bxz_qc-g6VHVYpofvxhuT2d8UorA_kJW-ByTM5U=.8ac6e944-3177-4c19-8656-7e9638904448@github.com> References: <6tj5Bxz_qc-g6VHVYpofvxhuT2d8UorA_kJW-ByTM5U=.8ac6e944-3177-4c19-8656-7e9638904448@github.com> Message-ID: On Tue, 21 Nov 2023 21:27:08 GMT, Viktor Klang wrote: >> 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 three additional commits since the last revision: >> >> - Merge branch 'openjdk:master' into JDK-8319662 >> - tweak cascades; reinstate an @Contended; resolve JDK-8319498 >> - Support cascading idle timeouts > > src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 3116: > >> 3114: } catch (Exception ex) { >> 3115: throw new RuntimeException(ex); >> 3116: } > > Suggestion: > > try { > return task.join(); > } catch (RuntimeException | Error unchecked) { > throw unchecked; > } catch (Exception checked) { > throw new RuntimeException(checked); > } Thanks. Done ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16725#discussion_r1401902341 From duke at openjdk.org Wed Nov 22 11:35:04 2023 From: duke at openjdk.org (Eirik Bjorsnos) Date: Wed, 22 Nov 2023 11:35:04 GMT Subject: RFR: 8319668: Fixup of jar filename typo in BadFactoryTest.sh In-Reply-To: References: Message-ID: On Tue, 21 Nov 2023 19:59:16 GMT, Gaurav Chaudhari wrote: >> Looks okay. This test is begging to be re-written in Java, maybe some day. >> >> I assume the copyright header will be updated before this change is integrated. > >> Looks okay. This test is begging to be re-written in Java, maybe some day. >> >> I assume the copyright header will be updated before this change is integrated. > > Hi @AlanBateman, do I have to update the copyright year to 2023 manually and amend the commit before `/integrate` ? @Deigue I was able to update `BadFactoryTest.java` to work as a pure Java test by adding the following jtreg header before the imports: /* * @test * @bug 8196959 * @summary BadFactory that results in NPE being thrown from ScriptEngineManager * @library /javax/script/JDK_8196959 * @build BadFactory BadFactoryTest * @run main/othervm BadFactoryTest * @run main/othervm -Djava.security.manager=allow BadFactoryTest */ I think we should add some code in the main method which validates that the BadFactory ScriptEngineFactory is loaded. (This validation would have caught the jar file typo): ScriptEngineManager m = new ScriptEngineManager(); m.getEngineFactories().stream() .filter(c -> c.getClass() == BadFactory.class) .findAny() .orElseThrow(() -> new IllegalStateException("Expected to find BadFactory")); Would you like to include these changes in your PR? If not, I'm happy to create a separate PR to convert this test to Java. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16585#issuecomment-1822599642 From isipka at openjdk.org Wed Nov 22 11:39:14 2023 From: isipka at openjdk.org (Ivan =?UTF-8?B?xaBpcGth?=) Date: Wed, 22 Nov 2023 11:39:14 GMT Subject: RFR: 8320586: update manual test/jdk/TEST.groups Message-ID: @mahendrachhipa @bwhuang-us ------------- Commit messages: - 8316121: JDK22 ATR tasks job definition updates Changes: https://git.openjdk.org/jdk/pull/16782/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16782&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8320586 Stats: 10 lines in 1 file changed: 5 ins; 2 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/16782.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16782/head:pull/16782 PR: https://git.openjdk.org/jdk/pull/16782 From dfuchs at openjdk.org Wed Nov 22 12:13:11 2023 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Wed, 22 Nov 2023 12:13:11 GMT Subject: RFR: 8310994: Add JFR event for selection operations In-Reply-To: References: Message-ID: On Fri, 17 Nov 2023 16:22:55 GMT, Tim Prinzing wrote: > Added mirror event with static methods: jdk.internal.event.SelectionEvent that provides the duration of select calls and the count of how many keys are available. > > Emit the event from SelectorImpl::lockAndDoSelect > > Test at jdk.jfr.event.io.TestSelectionEvents src/java.base/share/classes/jdk/internal/event/SelectionEvent.java line 35: > 33: * {@link #commit(long, long, int)} method > 34: * must be the same as the order of the fields. > 35: */ You should probably define what a "selection operation" is and put a link to `Selector::select`. src/java.base/share/classes/jdk/internal/event/SelectionEvent.java line 38: > 36: public class SelectionEvent extends Event { > 37: > 38: public int count; It could also be interesting to provide the `timeout` that was given to the selection operation. src/java.base/share/classes/sun/nio/ch/SelectorImpl.java line 150: > 148: long duration = SelectionEvent.timestamp() - start; > 149: if (SelectionEvent.shouldCommit(duration)) { > 150: SelectionEvent.commit(start, duration, n); Maybe the value of `timeout` should be provided here? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16710#discussion_r1401948063 PR Review Comment: https://git.openjdk.org/jdk/pull/16710#discussion_r1401950078 PR Review Comment: https://git.openjdk.org/jdk/pull/16710#discussion_r1401951825 From mbaesken at openjdk.org Wed Nov 22 12:29:05 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 22 Nov 2023 12:29:05 GMT Subject: RFR: JDK-8320309: AIX: pthreads created by foreign test library don't work as expected In-Reply-To: <98Q44DyEq4dkLDuIMsaAzDzDnYJAgg2Wlc-NjhtOq6Y=.5e7b3e15-476d-404f-a286-91143a055b23@github.com> References: <98Q44DyEq4dkLDuIMsaAzDzDnYJAgg2Wlc-NjhtOq6Y=.5e7b3e15-476d-404f-a286-91143a055b23@github.com> Message-ID: On Tue, 21 Nov 2023 10:09:04 GMT, Varada M wrote: > Following test fails due to missing pthread attributes on AIX : > java/foreign/TestUpcallAsync.java > java/foreign/stackwalk/TestAsyncStackWalk.java > java/foreign/loaderLookup/TestLoaderLookupJNI.java > java/foreign/enablenativeaccess/TestEnableNativeAccessJarManifest.java > java/foreign/enablenativeaccess/TestEnableNativeAccess.java > > Note : Test needs the changes from [pull/16579](https://github.com/openjdk/jdk/pull/16579) and [pull/16414](https://github.com/openjdk/jdk/pull/16414 ) > > JBS Issue : [JDK-8320309](https://bugs.openjdk.org/browse/JDK-8320309) LGTM ------------- Marked as reviewed by mbaesken (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16757#pullrequestreview-1744264111 From alanb at openjdk.org Wed Nov 22 12:30:06 2023 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 22 Nov 2023 12:30:06 GMT Subject: RFR: 8310994: Add JFR event for selection operations In-Reply-To: References: Message-ID: On Fri, 17 Nov 2023 16:22:55 GMT, Tim Prinzing wrote: > Added mirror event with static methods: jdk.internal.event.SelectionEvent that provides the duration of select calls and the count of how many keys are available. > > Emit the event from SelectorImpl::lockAndDoSelect > > Test at jdk.jfr.event.io.TestSelectionEvents src/jdk.jfr/share/classes/jdk/jfr/events/SelectionEvent.java line 43: > 41: > 42: @Label("Selection Count") > 43: @Description("Number of channels selected") I suspect you'll need to rename this event to something like "SelectorSelect" as "Selection" could be anything. We'll to find a better name for the field and its label too. There are two form of selection operations. One form operates on a selected-key set where the select/selectNow methods returns the number of keys aded to the Selector's ready set. The other form performs an action on each selected key. I'll try to come up a suggestions for the names, I suspect a label "number of channels ready for I/O or added to ready set" would be the most accurate. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16710#discussion_r1401970073 From alanb at openjdk.org Wed Nov 22 12:36:06 2023 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 22 Nov 2023 12:36:06 GMT Subject: RFR: 8310994: Add JFR event for selection operations In-Reply-To: References: Message-ID: <1ysPxgEJtBJ-Isq2-punGaxcWpN0fXvTA2sBsE9zJjI=.d3b2aeb0-b7c6-429a-a2e3-a9c8658c5bc4@github.com> On Fri, 17 Nov 2023 16:22:55 GMT, Tim Prinzing wrote: > Added mirror event with static methods: jdk.internal.event.SelectionEvent that provides the duration of select calls and the count of how many keys are available. > > Emit the event from SelectorImpl::lockAndDoSelect > > Test at jdk.jfr.event.io.TestSelectionEvents src/jdk.jfr/share/conf/jfr/default.jfc line 745: > 743: true > 744: true > 745: 20 ms The default threshold is 20ms but that means the default won't emit en event when spinning. If this event is used for performance and troubleshooting purposes then maybe we should emit an event when select returns 0 and not emit an event when selectNow returns 0 (selectNow is used to flush channels from the Selector so returning 0 is normal and not interesting). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16710#discussion_r1401979076 From stuefe at openjdk.org Wed Nov 22 13:13:05 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Wed, 22 Nov 2023 13:13:05 GMT Subject: RFR: JDK-8320309: AIX: pthreads created by foreign test library don't work as expected In-Reply-To: <98Q44DyEq4dkLDuIMsaAzDzDnYJAgg2Wlc-NjhtOq6Y=.5e7b3e15-476d-404f-a286-91143a055b23@github.com> References: <98Q44DyEq4dkLDuIMsaAzDzDnYJAgg2Wlc-NjhtOq6Y=.5e7b3e15-476d-404f-a286-91143a055b23@github.com> Message-ID: <9DJt_J0lJ3nbDykzPfrFVIPZ_VVZoaghwbZbRDSrWcc=.b6591547-cc6d-4c45-b16c-563bc4f84d7f@github.com> On Tue, 21 Nov 2023 10:09:04 GMT, Varada M wrote: > Following test fails due to missing pthread attributes on AIX : > java/foreign/TestUpcallAsync.java > java/foreign/stackwalk/TestAsyncStackWalk.java > java/foreign/loaderLookup/TestLoaderLookupJNI.java > java/foreign/enablenativeaccess/TestEnableNativeAccessJarManifest.java > java/foreign/enablenativeaccess/TestEnableNativeAccess.java > > Note : Test needs the changes from [pull/16579](https://github.com/openjdk/jdk/pull/16579) and [pull/16414](https://github.com/openjdk/jdk/pull/16414 ) > > JBS Issue : [JDK-8320309](https://bugs.openjdk.org/browse/JDK-8320309) +1 ------------- Marked as reviewed by stuefe (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16757#pullrequestreview-1744345772 From varadam at openjdk.org Wed Nov 22 13:27:06 2023 From: varadam at openjdk.org (Varada M) Date: Wed, 22 Nov 2023 13:27:06 GMT Subject: RFR: JDK-8320309: AIX: pthreads created by foreign test library don't work as expected In-Reply-To: <98Q44DyEq4dkLDuIMsaAzDzDnYJAgg2Wlc-NjhtOq6Y=.5e7b3e15-476d-404f-a286-91143a055b23@github.com> References: <98Q44DyEq4dkLDuIMsaAzDzDnYJAgg2Wlc-NjhtOq6Y=.5e7b3e15-476d-404f-a286-91143a055b23@github.com> Message-ID: <_LyWqt1_94Pwv4TI3IGlvYR8xNgqG4MZ1PGP8AMh-6I=.4d50f3c1-c506-4709-ab43-06e5abe0fc9f@github.com> On Tue, 21 Nov 2023 10:09:04 GMT, Varada M wrote: > Following test fails due to missing pthread attributes on AIX : > java/foreign/TestUpcallAsync.java > java/foreign/stackwalk/TestAsyncStackWalk.java > java/foreign/loaderLookup/TestLoaderLookupJNI.java > java/foreign/enablenativeaccess/TestEnableNativeAccessJarManifest.java > java/foreign/enablenativeaccess/TestEnableNativeAccess.java > > Note : Test needs the changes from [pull/16579](https://github.com/openjdk/jdk/pull/16579) and [pull/16414](https://github.com/openjdk/jdk/pull/16414 ) > > JBS Issue : [JDK-8320309](https://bugs.openjdk.org/browse/JDK-8320309) Thanks all ------------- PR Comment: https://git.openjdk.org/jdk/pull/16757#issuecomment-1822766924 From amitkumar at openjdk.org Wed Nov 22 13:30:16 2023 From: amitkumar at openjdk.org (Amit Kumar) Date: Wed, 22 Nov 2023 13:30:16 GMT Subject: RFR: JDK-8317799 : AIX PPC64: FFI symbol lookup doesn't find symbols [v7] In-Reply-To: References: Message-ID: On Tue, 21 Nov 2023 19:30:30 GMT, suchismith1993 wrote: >> The math library in AIX specifically, is a static archive. Doing a -lm wont suffice, because when the symbols are looked up using dlsym or accessing native code through Java, it will lead to failures. >> Hence we had to come up with a list of symbols to allow math library symbols to be accesible. >> Also, there are parts of libc library that are static too, and hence those symbols also are present in this list. >> Without this change, the StdLibTest and multiple other tests which make native function calls using FFI, fail with NoSuchElementException. >> >> >> 1. Adding required compiler flags. >> 2. Adding required symbols. >> >> >> JBS-ISSUE : [JDK-8317799](https://bugs.openjdk.org/browse/JDK-8317799) > > suchismith1993 has updated the pull request incrementally with two additional commits since the last revision: > > - Fix Typos > - Remove unnecessary includes src/java.base/aix/native/libsyslookup/syslookup.c line 3: > 1: /* > 2: * Copyright (c) 2023, Oracle and/or its affiliates. All rights reserved. > 3: * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. Suggestion: * Copyright (c) 2023, Oracle and/or its affiliates. All rights reserved. * Copyright (c) 2023, IBM Corp. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16414#discussion_r1402047735 From duke at openjdk.org Wed Nov 22 13:33:35 2023 From: duke at openjdk.org (suchismith1993) Date: Wed, 22 Nov 2023 13:33:35 GMT Subject: RFR: JDK-8317799 : AIX PPC64: FFI symbol lookup doesn't find symbols [v8] In-Reply-To: References: Message-ID: > The math library in AIX specifically, is a static archive. Doing a -lm wont suffice, because when the symbols are looked up using dlsym or accessing native code through Java, it will lead to failures. > Hence we had to come up with a list of symbols to allow math library symbols to be accesible. > Also, there are parts of libc library that are static too, and hence those symbols also are present in this list. > Without this change, the StdLibTest and multiple other tests which make native function calls using FFI, fail with NoSuchElementException. > > > 1. Adding required compiler flags. > 2. Adding required symbols. > > > JBS-ISSUE : [JDK-8317799](https://bugs.openjdk.org/browse/JDK-8317799) suchismith1993 has updated the pull request incrementally with one additional commit since the last revision: Update src/java.base/aix/native/libsyslookup/syslookup.c copyright Co-authored-by: Amit Kumar ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16414/files - new: https://git.openjdk.org/jdk/pull/16414/files/efbb245a..7a683132 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16414&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16414&range=06-07 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/16414.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16414/head:pull/16414 PR: https://git.openjdk.org/jdk/pull/16414 From duke at openjdk.org Wed Nov 22 13:36:14 2023 From: duke at openjdk.org (suchismith1993) Date: Wed, 22 Nov 2023 13:36:14 GMT Subject: RFR: JDK-8317799 : AIX PPC64: FFI symbol lookup doesn't find symbols [v7] In-Reply-To: <_4iloDLR7tRen-QWl8KB9N_r5sU1u3hl215V9Qkn2R4=.e53d41d5-91fd-4b91-8184-8e3947ed9f88@github.com> References: <_4iloDLR7tRen-QWl8KB9N_r5sU1u3hl215V9Qkn2R4=.e53d41d5-91fd-4b91-8184-8e3947ed9f88@github.com> Message-ID: On Wed, 22 Nov 2023 06:50:07 GMT, Jorn Vernee wrote: >> suchismith1993 has updated the pull request incrementally with two additional commits since the last revision: >> >> - Fix Typos >> - Remove unnecessary includes > > Note that on Windows we also have a lookup mechanism on the Java side: https://github.com/openjdk/jdk/blob/2c31ca525b1cd70c3dfcb0463c8c984bdd7c886a/src/java.base/share/classes/jdk/internal/foreign/SystemLookup.java#L159 > > On Windows we need to load the global array, and then grab functions from the array. Why isn't that needed on AIX? Is `dlsym` able to find the statically linked functions as well? Thank you @JornVernee @magicus @dholmes-ora @TheRealMDoerr @erikj79 Thanks for enocuraging to work towards a better solution which enabled me to understand and explore windows code as well. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16414#issuecomment-1822780431 From duke at openjdk.org Wed Nov 22 13:42:18 2023 From: duke at openjdk.org (suchismith1993) Date: Wed, 22 Nov 2023 13:42:18 GMT Subject: Integrated: JDK-8318175 : AIX PPC64: Handle alignment of double in structs In-Reply-To: <2TGtA0RwdjsEIrxdaWvt-mR4J0Ni0BPqTZbrhxUsMoY=.bf393d8c-a3af-438e-898f-23c2287d1449@github.com> References: <2TGtA0RwdjsEIrxdaWvt-mR4J0Ni0BPqTZbrhxUsMoY=.bf393d8c-a3af-438e-898f-23c2287d1449@github.com> Message-ID: On Thu, 9 Nov 2023 09:22:45 GMT, suchismith1993 wrote: > 1. use pragma directive to handle alignment. > > JBS Issue: [JDK-8318175](https://bugs.openjdk.org/browse/JDK-8318175) This pull request has now been integrated. Changeset: bf0a904f Author: suchismith Committer: Martin Doerr URL: https://git.openjdk.org/jdk/commit/bf0a904f0e2f29e9967c38e437b702d92c096e88 Stats: 14 lines in 2 files changed: 14 ins; 0 del; 0 mod 8318175: AIX PPC64: Handle alignment of double in structs Reviewed-by: mdoerr, amitkumar ------------- PR: https://git.openjdk.org/jdk/pull/16579 From varadam at openjdk.org Wed Nov 22 13:46:19 2023 From: varadam at openjdk.org (Varada M) Date: Wed, 22 Nov 2023 13:46:19 GMT Subject: Integrated: JDK-8320309: AIX: pthreads created by foreign test library don't work as expected In-Reply-To: <98Q44DyEq4dkLDuIMsaAzDzDnYJAgg2Wlc-NjhtOq6Y=.5e7b3e15-476d-404f-a286-91143a055b23@github.com> References: <98Q44DyEq4dkLDuIMsaAzDzDnYJAgg2Wlc-NjhtOq6Y=.5e7b3e15-476d-404f-a286-91143a055b23@github.com> Message-ID: <7xSfQtHVL0zlbNSe9-7tpYkc7dh0Ud-90kiObqmmxac=.06b9b4b9-4941-4423-9523-661fc95a7790@github.com> On Tue, 21 Nov 2023 10:09:04 GMT, Varada M wrote: > Following test fails due to missing pthread attributes on AIX : > java/foreign/TestUpcallAsync.java > java/foreign/stackwalk/TestAsyncStackWalk.java > java/foreign/loaderLookup/TestLoaderLookupJNI.java > java/foreign/enablenativeaccess/TestEnableNativeAccessJarManifest.java > java/foreign/enablenativeaccess/TestEnableNativeAccess.java > > Note : Test needs the changes from [pull/16579](https://github.com/openjdk/jdk/pull/16579) and [pull/16414](https://github.com/openjdk/jdk/pull/16414 ) > > JBS Issue : [JDK-8320309](https://bugs.openjdk.org/browse/JDK-8320309) This pull request has now been integrated. Changeset: 8b47a149 Author: Varada M Committer: Matthias Baesken URL: https://git.openjdk.org/jdk/commit/8b47a14958913c70291d46afdde4e527f9bdc91a Stats: 6 lines in 1 file changed: 5 ins; 0 del; 1 mod 8320309: AIX: pthreads created by foreign test library don't work as expected Reviewed-by: mdoerr, mbaesken, stuefe ------------- PR: https://git.openjdk.org/jdk/pull/16757 From jlaskey at openjdk.org Wed Nov 22 15:29:08 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Wed, 22 Nov 2023 15:29:08 GMT Subject: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v32] In-Reply-To: References: Message-ID: <1-xpQnCScwxwkKoJgPybXoeI_U3LPuBvNcfHzI0vtqs=.c817ed49-2ed7-4b4c-9f19-75e6c5c6b5a6@github.com> > Address changes from JEP 445 to JEP 463. > > - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. > > - Don't mark class on read. > > - Remove reflection and annotation processing related to unnamed classes. > > - Simplify main method search. Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: Handle javadoc on top level elements properly ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16461/files - new: https://git.openjdk.org/jdk/pull/16461/files/fd0c92f8..222e3346 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16461&range=31 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16461&range=30-31 Stats: 8 lines in 1 file changed: 0 ins; 1 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/16461.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16461/head:pull/16461 PR: https://git.openjdk.org/jdk/pull/16461 From duke at openjdk.org Wed Nov 22 15:46:27 2023 From: duke at openjdk.org (suchismith1993) Date: Wed, 22 Nov 2023 15:46:27 GMT Subject: Integrated: JDK-8317799 : AIX PPC64: FFI symbol lookup doesn't find symbols In-Reply-To: References: Message-ID: On Mon, 30 Oct 2023 10:54:48 GMT, suchismith1993 wrote: > The math library in AIX specifically, is a static archive. Doing a -lm wont suffice, because when the symbols are looked up using dlsym or accessing native code through Java, it will lead to failures. > Hence we had to come up with a list of symbols to allow math library symbols to be accesible. > Also, there are parts of libc library that are static too, and hence those symbols also are present in this list. > Without this change, the StdLibTest and multiple other tests which make native function calls using FFI, fail with NoSuchElementException. > > > 1. Adding required compiler flags. > 2. Adding required symbols. > > > JBS-ISSUE : [JDK-8317799](https://bugs.openjdk.org/browse/JDK-8317799) This pull request has now been integrated. Changeset: 25cebe8c Author: suchismith1993 Committer: Amit Kumar URL: https://git.openjdk.org/jdk/commit/25cebe8c3ed5c03b4da2da5bb2f7637c8cd40581 Stats: 206 lines in 2 files changed: 206 ins; 0 del; 0 mod 8317799: AIX PPC64: FFI symbol lookup doesn't find symbols Reviewed-by: mdoerr, ihse, dholmes, jvernee ------------- PR: https://git.openjdk.org/jdk/pull/16414 From dl at openjdk.org Wed Nov 22 15:53:12 2023 From: dl at openjdk.org (Doug Lea) Date: Wed, 22 Nov 2023 15:53:12 GMT Subject: RFR: 8318776: Require supports_cx8 to always be true [v5] In-Reply-To: References: Message-ID: On Wed, 22 Nov 2023 02:09:38 GMT, David Holmes wrote: >> As discussed in JBS all platforms (some tweaks to Zero are in progress) actually do support `cx8` i.e. 64-bit compare-and-exchange, so we can strip out the locked-based alternatives to using it and just add a guarantee that it is true at runtime. And all platforms except some ARM variants set `SUPPORTS_NATIVE_CX8`, so we can greatly simplify things. Summary of changes: >> - `_supports_cx8` field is only needed when `SUPPORTS_NATIVE_CX8` is not defined >> - Assertions for `supports_cx8()` are removed >> - Compiler predicates requiring `supports_cx8()` are removed >> - Access backend is greatly simplified without the need for lock-based alternative >> - `java.util.concurrent.AtomicLongFieldUpdater` is simplified without the need for a lock-based alternative >> >> I did consider moving all the ARM `kuser_helper` related code to be only defined when `SUPPORTS_NATIVE_CX8` is not defined, but there was a theoretical risk this could change the behaviour if ARMv7 binaries were run on other ARM CPU's. I added a note to that effect in vm_version_linux_arm32.cpp so the ARM port maintainers could clean this up further if desired. >> >> Testing: >> - All Oracle tiers 1-5 builds (which includes an ARMv7 build) >> - GHA builds/tests >> - Oracle tiers 1-3 sanity testing >> >> Zero changes coming in via [JDK-8319777](https://bugs.openjdk.org/browse/JDK-8319777) will be merged when they arrive. >> >> Thanks. > > David Holmes has updated the pull request with a new target base 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 with master and update Zero code accordingly > - Merge branch 'master' into 8318776-supports_cx8 > - Remove unnecessary includes of vm_version.hpp. > Fix copyright years. > - Remove cx8 comment as no longer relevant (the spinlock is used regardless of cx8) > - Remove suports_cx8() checks from gtest > - Remove test for VMSupportsCX8 > - 8318776: Require supports_cx8 to always be true The deletion of backup code and the check for it in java.util.concurrent.AtomicLongFieldUpdater are clearly OK. We always thought the need for it was transient. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16625#issuecomment-1823026095 From clanger at openjdk.org Wed Nov 22 16:14:23 2023 From: clanger at openjdk.org (Christoph Langer) Date: Wed, 22 Nov 2023 16:14:23 GMT Subject: RFR: 8320601: ProblemList java/lang/invoke/lambda/LambdaFileEncodingSerialization.java on linux-all Message-ID: java/lang/invoke/lambda/LambdaFileEncodingSerialization.java is already problem listed on linux-x64. However, the issue is not processor specific. We see the failure on linux on other architectures as well. ------------- Commit messages: - Update ProblemList.txt Changes: https://git.openjdk.org/jdk/pull/16784/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16784&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8320601 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/16784.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16784/head:pull/16784 PR: https://git.openjdk.org/jdk/pull/16784 From joehw at openjdk.org Wed Nov 22 17:09:05 2023 From: joehw at openjdk.org (Joe Wang) Date: Wed, 22 Nov 2023 17:09:05 GMT Subject: RFR: 8306055: Add a built-in Catalog to JDK XML module [v4] In-Reply-To: References: Message-ID: > Implement the built-in Catalog. Joe Wang has updated the pull request incrementally with one additional commit since the last revision: fix whitespace ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16719/files - new: https://git.openjdk.org/jdk/pull/16719/files/4914278a..d7a7c9a0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16719&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16719&range=02-03 Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/16719.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16719/head:pull/16719 PR: https://git.openjdk.org/jdk/pull/16719 From joehw at openjdk.org Wed Nov 22 17:09:09 2023 From: joehw at openjdk.org (Joe Wang) Date: Wed, 22 Nov 2023 17:09:09 GMT Subject: RFR: 8306055: Add a built-in Catalog to JDK XML module [v3] In-Reply-To: References: Message-ID: On Wed, 22 Nov 2023 08:08:39 GMT, Andrey Turbanov wrote: >> Joe Wang has updated the pull request incrementally with one additional commit since the last revision: >> >> add a note; fix alignment > > test/jaxp/javax/xml/jaxp/unittest/common/catalog/CatalogTestBase.java line 299: > >> 297: Properties config, Properties[] sysProp, Properties[] apiProp, CustomCatalog cc, >> 298: boolean expectError, String error) throws Exception { >> 299: testSchema1(filename, xsd, fsp, state, config, sysProp, apiProp, cc, expectError, error); > > Suggestion: > > testSchema1(filename, xsd, fsp, state, config, sysProp, apiProp, cc, expectError, error); Thanks. Fixed whitespace. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16719#discussion_r1402418756 From joehw at openjdk.org Wed Nov 22 17:14:18 2023 From: joehw at openjdk.org (Joe Wang) Date: Wed, 22 Nov 2023 17:14:18 GMT Subject: RFR: 8306055: Add a built-in Catalog to JDK XML module [v3] In-Reply-To: References: Message-ID: On Wed, 22 Nov 2023 08:58:41 GMT, Alan Bateman wrote: > I'm happy with the addition of the JDK built-in catalog, the inclusion of the DTD defined by Java SE, and the docs updates. Thanks again, Alan, I really appreciate it! Finally got all pieces together, a nice foundation for the next. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16719#issuecomment-1823167935 From joehw at openjdk.org Wed Nov 22 17:14:18 2023 From: joehw at openjdk.org (Joe Wang) Date: Wed, 22 Nov 2023 17:14:18 GMT Subject: Integrated: 8306055: Add a built-in Catalog to JDK XML module In-Reply-To: References: Message-ID: On Fri, 17 Nov 2023 20:22:40 GMT, Joe Wang wrote: > Implement the built-in Catalog. This pull request has now been integrated. Changeset: 93bdc2a6 Author: Joe Wang URL: https://git.openjdk.org/jdk/commit/93bdc2a6db91a95d6ee52ec92080e586c694dad5 Stats: 1647 lines in 50 files changed: 1434 ins; 118 del; 95 mod 8306055: Add a built-in Catalog to JDK XML module Reviewed-by: ihse, lancea, alanb ------------- PR: https://git.openjdk.org/jdk/pull/16719 From duke at openjdk.org Wed Nov 22 17:57:22 2023 From: duke at openjdk.org (Gaurav Chaudhari) Date: Wed, 22 Nov 2023 17:57:22 GMT Subject: RFR: 8319668: Fixup of jar filename typo in BadFactoryTest.sh [v2] In-Reply-To: References: Message-ID: <_AwsuoLG-Y_sYz25yJodFyY4KYggZdZzrW6fSdKRh8I=.bd4fb6d6-4a84-4228-8c90-507c38066844@github.com> > The file test/jdk/javax/script/JDK_8196959/BadFactoryTest.sh contains a typo. When running without security manager, the test references 'badfactoty.jar' instead of 'badfactory.jar'. This change addresses this by correcting the jar name. Gaurav Chaudhari 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: 8319668: Fixup of jar filename typo in BadFactoryTest.sh ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16585/files - new: https://git.openjdk.org/jdk/pull/16585/files/5cd537cb..0780ad32 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16585&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16585&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/16585.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16585/head:pull/16585 PR: https://git.openjdk.org/jdk/pull/16585 From duke at openjdk.org Wed Nov 22 17:57:23 2023 From: duke at openjdk.org (Gaurav Chaudhari) Date: Wed, 22 Nov 2023 17:57:23 GMT Subject: RFR: 8319668: Fixup of jar filename typo in BadFactoryTest.sh [v2] In-Reply-To: References: Message-ID: On Wed, 22 Nov 2023 11:32:13 GMT, Eirik Bjorsnos wrote: >>> Looks okay. This test is begging to be re-written in Java, maybe some day. >>> >>> I assume the copyright header will be updated before this change is integrated. >> >> Hi @AlanBateman, do I have to update the copyright year to 2023 manually and amend the commit before `/integrate` ? > > @Deigue > > I was able to update `BadFactoryTest.java` to work as a pure Java test by adding the following jtreg header before the imports: > > > /* > * @test > * @bug 8196959 > * @summary BadFactory that results in NPE being thrown from ScriptEngineManager > * @library /javax/script/JDK_8196959 > * @build BadFactory BadFactoryTest > * @run main/othervm BadFactoryTest > * @run main/othervm -Djava.security.manager=allow BadFactoryTest > */ > > > I think we should also add a sanity check that the BadFactory ScriptEngineFactory is actually loaded. (This validation would have caught the jar file typo): > > > ScriptEngineManager m = new ScriptEngineManager(); > m.getEngineFactories().stream() > .filter(c -> c.getClass() == BadFactory.class) > .findAny() > .orElseThrow(() -> new IllegalStateException("Expected to find BadFactory")); > > > Would you like to include these changes in your PR? If not, I'm happy to create a separate PR to convert this test to Java. @eirbjo Yes, as you noticed, the jar file does matter. And the reason I suspected it wasn't noticed was because it was in the scenario of running without security manager, So may that part of the code wasn't being actively executed. As for the rewrite, it does look good. But would it make more sense to bring this change as a separate PR having a own openjdk bug issue # designated to reworking of BadFactoryTest.sh for tracking purposes? ------------- PR Comment: https://git.openjdk.org/jdk/pull/16585#issuecomment-1823228953 From duke at openjdk.org Wed Nov 22 18:04:07 2023 From: duke at openjdk.org (Eirik Bjorsnos) Date: Wed, 22 Nov 2023 18:04:07 GMT Subject: RFR: 8319668: Fixup of jar filename typo in BadFactoryTest.sh [v2] In-Reply-To: References: Message-ID: <6mykWP1swWPnVEyhG-sEgEHc4kIMoCdi8_jfXYxDj78=.b4d2c29a-47e6-43c8-82e7-54091b77b3c5@github.com> On Wed, 22 Nov 2023 17:53:33 GMT, Gaurav Chaudhari wrote: > As for the rewrite, it does look good. But would it make more sense to bring this change as a separate PR having a own openjdk bug issue # designated to reworking of BadFactoryTest.sh for tracking purposes? We have two options: - Withdraw this PR, submit a new PR for the rewrite - Repurpose this PR for the rewrite, updating JBS and PR titles accordingly In either case, I can help updating/creating JBS isssues as required. I have a slight preference for repurposing, but it's up to you. What do you prefer? ------------- PR Comment: https://git.openjdk.org/jdk/pull/16585#issuecomment-1823238308 From duke at openjdk.org Wed Nov 22 18:21:08 2023 From: duke at openjdk.org (Gaurav Chaudhari) Date: Wed, 22 Nov 2023 18:21:08 GMT Subject: RFR: 8319668: Fixup of jar filename typo in BadFactoryTest.sh [v2] In-Reply-To: <6mykWP1swWPnVEyhG-sEgEHc4kIMoCdi8_jfXYxDj78=.b4d2c29a-47e6-43c8-82e7-54091b77b3c5@github.com> References: <6mykWP1swWPnVEyhG-sEgEHc4kIMoCdi8_jfXYxDj78=.b4d2c29a-47e6-43c8-82e7-54091b77b3c5@github.com> Message-ID: On Wed, 22 Nov 2023 18:01:21 GMT, Eirik Bjorsnos wrote: >> @eirbjo Yes, as you noticed, the jar file does matter. And the reason I suspected it wasn't noticed was because it was in the scenario of running without security manager, So may that part of the code wasn't being actively executed. >> >> As for the rewrite, it does look good. But would it make more sense to bring this change as a separate PR having a own openjdk bug issue # designated to reworking of BadFactoryTest.sh for tracking purposes? > >> As for the rewrite, it does look good. But would it make more sense to bring this change as a separate PR having a own openjdk bug issue # designated to reworking of BadFactoryTest.sh for tracking purposes? > > We have two options: > > - Withdraw this PR, submit a new PR for the rewrite > - Repurpose this PR for the rewrite, updating JBS and PR titles accordingly > > In either case, I can help updating/creating JBS isssues as required. > > I have a slight preference for repurposing, but it's up to you. What do you prefer? @eirbjo If it makes sense from perspective of commiters/reviewers, I'll be happy to integrate the changes here and tweak so that it looks good. I also wonder if we have BadFactoryTest.java instead of BadFactoryTest.sh , will certain references elsewhere need to be adjusted accordingly, in case these jtreg tests are being referenced in a certain way somewhere. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16585#issuecomment-1823259262 From duke at openjdk.org Wed Nov 22 18:31:06 2023 From: duke at openjdk.org (Eirik Bjorsnos) Date: Wed, 22 Nov 2023 18:31:06 GMT Subject: RFR: 8319668: Fixup of jar filename typo in BadFactoryTest.sh [v2] In-Reply-To: <6mykWP1swWPnVEyhG-sEgEHc4kIMoCdi8_jfXYxDj78=.b4d2c29a-47e6-43c8-82e7-54091b77b3c5@github.com> References: <6mykWP1swWPnVEyhG-sEgEHc4kIMoCdi8_jfXYxDj78=.b4d2c29a-47e6-43c8-82e7-54091b77b3c5@github.com> Message-ID: On Wed, 22 Nov 2023 18:01:21 GMT, Eirik Bjorsnos wrote: >> @eirbjo Yes, as you noticed, the jar file does matter. And the reason I suspected it wasn't noticed was because it was in the scenario of running without security manager, So may that part of the code wasn't being actively executed. >> >> As for the rewrite, it does look good. But would it make more sense to bring this change as a separate PR having a own openjdk bug issue # designated to reworking of BadFactoryTest.sh for tracking purposes? > >> As for the rewrite, it does look good. But would it make more sense to bring this change as a separate PR having a own openjdk bug issue # designated to reworking of BadFactoryTest.sh for tracking purposes? > > We have two options: > > - Withdraw this PR, submit a new PR for the rewrite > - Repurpose this PR for the rewrite, updating JBS and PR titles accordingly > > In either case, I can help updating/creating JBS isssues as required. > > I have a slight preference for repurposing, but it's up to you. What do you prefer? > @eirbjo If it makes sense from perspective of commiters/reviewers, I'll be happy to integrate the changes here and tweak so that it looks good. Reviewer time is a scarce resource. It would be wasteful to spend review cycles on getting a fix of this `.sh` test integrated now and then immediately follow up with a delete in the rewrite PR. I think we should handle this change in one PR, not two. If you prefer to keep the history of your `.sh` fix documented, we can repurpose this PR, otherwise we start fresh with a new PR for the rewrite. > I also wonder if we have BadFactoryTest.java instead of BadFactoryTest.sh , will certain references elsewhere need to be adjusted accordingly, in case these jtreg tests are being referenced in a certain way somewhere. jtreg will pick this up automatically. I did a search of `BadFactoryTest` across the code base, and it is not referenced outside the file itself. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16585#issuecomment-1823271462 From dcubed at openjdk.org Wed Nov 22 18:39:10 2023 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Wed, 22 Nov 2023 18:39:10 GMT Subject: RFR: 8318776: Require supports_cx8 to always be true [v5] In-Reply-To: References: Message-ID: <6TkAoQRK_49MtT6wjb_JAwFzUATAvAx_rX9yxMa9Vfs=.7d1d5bf6-f088-44df-9d01-cc336bdeecaa@github.com> On Wed, 22 Nov 2023 02:09:38 GMT, David Holmes wrote: >> As discussed in JBS all platforms (some tweaks to Zero are in progress) actually do support `cx8` i.e. 64-bit compare-and-exchange, so we can strip out the locked-based alternatives to using it and just add a guarantee that it is true at runtime. And all platforms except some ARM variants set `SUPPORTS_NATIVE_CX8`, so we can greatly simplify things. Summary of changes: >> - `_supports_cx8` field is only needed when `SUPPORTS_NATIVE_CX8` is not defined >> - Assertions for `supports_cx8()` are removed >> - Compiler predicates requiring `supports_cx8()` are removed >> - Access backend is greatly simplified without the need for lock-based alternative >> - `java.util.concurrent.AtomicLongFieldUpdater` is simplified without the need for a lock-based alternative >> >> I did consider moving all the ARM `kuser_helper` related code to be only defined when `SUPPORTS_NATIVE_CX8` is not defined, but there was a theoretical risk this could change the behaviour if ARMv7 binaries were run on other ARM CPU's. I added a note to that effect in vm_version_linux_arm32.cpp so the ARM port maintainers could clean this up further if desired. >> >> Testing: >> - All Oracle tiers 1-5 builds (which includes an ARMv7 build) >> - GHA builds/tests >> - Oracle tiers 1-3 sanity testing >> >> Zero changes coming in via [JDK-8319777](https://bugs.openjdk.org/browse/JDK-8319777) will be merged when they arrive. >> >> Thanks. > > David Holmes has updated the pull request with a new target base 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 with master and update Zero code accordingly > - Merge branch 'master' into 8318776-supports_cx8 > - Remove unnecessary includes of vm_version.hpp. > Fix copyright years. > - Remove cx8 comment as no longer relevant (the spinlock is used regardless of cx8) > - Remove suports_cx8() checks from gtest > - Remove test for VMSupportsCX8 > - 8318776: Require supports_cx8 to always be true Wow! This PR is much larger than I expected. Thumbs up! ------------- Marked as reviewed by dcubed (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16625#pullrequestreview-1745089631 From dcubed at openjdk.org Wed Nov 22 18:39:15 2023 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Wed, 22 Nov 2023 18:39:15 GMT Subject: RFR: 8318776: Require supports_cx8 to always be true [v5] In-Reply-To: References: Message-ID: On Wed, 22 Nov 2023 08:48:09 GMT, Aleksey Shipilev wrote: >> David Holmes has updated the pull request with a new target base 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 with master and update Zero code accordingly >> - Merge branch 'master' into 8318776-supports_cx8 >> - Remove unnecessary includes of vm_version.hpp. >> Fix copyright years. >> - Remove cx8 comment as no longer relevant (the spinlock is used regardless of cx8) >> - Remove suports_cx8() checks from gtest >> - Remove test for VMSupportsCX8 >> - 8318776: Require supports_cx8 to always be true > > src/hotspot/cpu/x86/vm_version_x86.cpp line 819: > >> 817: } >> 818: >> 819: _supports_cx8 = supports_cmpxchg8(); > > I think we should leave the runtime check here (under `ifndef`, like in ARM?). This covers the remaining case of running on legacy x86 without CX8 implemented: the init guarantee would then fire and prevent any other surprises at runtime. Sure, it would be hard to come up with such a platform today, but it would be safer to refuse to run there right away on the off-chance someone actually has it :) @shipilev - Do you have a particular legacy x86 in mind? > src/hotspot/share/runtime/vm_version.cpp line 33: > >> 31: void VM_Version_init() { >> 32: VM_Version::initialize(); >> 33: guarantee(VM_Version::supports_cx8(), "Support for 64-bit atomic operations in required in this release"); > > Typo: "in required in". Also, no need to mention "this release" at all? > Suggestion for message: "JVM requires platform support for 64-bit atomic operations" Or the simpler change: s/in required/is required/ ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16625#discussion_r1402515036 PR Review Comment: https://git.openjdk.org/jdk/pull/16625#discussion_r1402528045 From psandoz at openjdk.org Wed Nov 22 19:09:06 2023 From: psandoz at openjdk.org (Paul Sandoz) Date: Wed, 22 Nov 2023 19:09:06 GMT Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations with SLEEF [v3] In-Reply-To: References: <97YS_I-DY-Q5agE6mE-iBkoVxtvL7R4Q3NebjTsXMvI=.dac0dc99-84d7-4cbd-ada6-5190564688a9@github.com> Message-ID: On Wed, 22 Nov 2023 09:05:31 GMT, Andrew Haley wrote: > > Have you considered the possibility of copying the sleef source to the OpenJDK repository and thereby it becomes part of the build process? I don't know how straightforward that is technically and IANAL but I think it's worth exploring. > > Hi @PaulSandoz ! Thanks for the suggestion! Copying the sleef source sounds good. However, I actually have no idea about how to handle the third-party licence in OpenJDK project. Do you have any idea about this area? Some suggestions/guidence from the JDK team will be much helpful. Thanks! We (Oracle Java Platform Group) can handle the required "paperwork" on any third party dependencies and attribution of copyright before any PR can be integrated, if you can help detail what those are. First i think we need to determine if this is feasible e.g., copying a subset and integrating it into the build system, since it does not make sense to bring in the support for quad floats and DFT, which IIUC brings in a dependency on compiler support for OpenMP. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16234#issuecomment-1823335443 From ihse at openjdk.org Wed Nov 22 19:30:13 2023 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 22 Nov 2023 19:30:13 GMT Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations with SLEEF [v3] In-Reply-To: References: Message-ID: On Wed, 15 Nov 2023 01:32:00 GMT, Xiaohong Gong wrote: >> Currently the vector floating-point math APIs like `VectorOperators.SIN/COS/TAN...` are not intrinsified on AArch64 platform, which causes large performance gap on AArch64. Note that those APIs are optimized by C2 compiler on X86 platforms by calling Intel's SVML code [1]. To close the gap, we would like to optimize these APIs for AArch64 by calling a third-party vector library called libsleef [2], which are available in mainstream Linux distros (e.g. [3] [4]). >> >> SLEEF supports multiple accuracies. To match Vector API's requirement and implement the math ops on AArch64, we 1) call 1.0 ULP accuracy with FMA instructions used stubs in libsleef for most of the operations by default, and 2) add the vector calling convention to apply with the runtime calls to stub code in libsleef. Note that for those APIs that libsleef does not support 1.0 ULP, we choose 0.5 ULP instead. >> >> To help loading the expected libsleef library, this patch also adds an experimental JVM option (i.e. `-XX:UseSleefLib`) for AArch64 platforms. People can use it to denote the libsleef path/name explicitly. By default, it points to the system installed library. If the library does not exist or the dynamic loading of it in runtime fails, the math vector ops will fall-back to use the default scalar version without error. But a warning is printed out if people specifies a nonexistent library explicitly. >> >> Note that this is a part of the original proposed patch in panama-dev [5], just with some initial review comments addressed. And now we'd like to get some wider feedbacks from more hotspot experts. >> >> [1] https://github.com/openjdk/jdk/pull/3638 >> [2] https://sleef.org/ >> [3] https://packages.fedoraproject.org/pkgs/sleef/sleef/ >> [4] https://packages.debian.org/bookworm/libsleef3 >> [5] https://mail.openjdk.org/pipermail/panama-dev/2022-December/018172.html > > Xiaohong Gong has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: > > - Add a bundled native lib in jdk as a bridge to libsleef > - Merge 'jdk:master' into JDK-8312425 > - Disable sleef by default > - Merge 'jdk:master' into JDK-8312425 > - 8312425: [vectorapi] AArch64: Optimize vector math operations with SLEEF I think it can be a good idea to start with using an external library, as is done in this PR. For all our other bundled libraries, we also always support the option of building with the "system" library instead of the bundled one, so this code will still be required. If we should push this PR first, and then add the source in a separate PR, or if we should bake everything together (both external library and bundled sources) into a single PR, I cannot say. But I expect it is easier to take it piece-wise. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16234#issuecomment-1823387045 From jlaskey at openjdk.org Wed Nov 22 20:30:22 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Wed, 22 Nov 2023 20:30:22 GMT Subject: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v32] In-Reply-To: <1-xpQnCScwxwkKoJgPybXoeI_U3LPuBvNcfHzI0vtqs=.c817ed49-2ed7-4b4c-9f19-75e6c5c6b5a6@github.com> References: <1-xpQnCScwxwkKoJgPybXoeI_U3LPuBvNcfHzI0vtqs=.c817ed49-2ed7-4b4c-9f19-75e6c5c6b5a6@github.com> Message-ID: On Wed, 22 Nov 2023 15:29:08 GMT, Jim Laskey wrote: >> Address changes from JEP 445 to JEP 463. >> >> - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. >> >> - Don't mark class on read. >> >> - Remove reflection and annotation processing related to unnamed classes. >> >> - Simplify main method search. > > Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: > > Handle javadoc on top level elements properly I wasn't succinct. I meant modifier tokens. At any rate, I found the issue. VirtualParser was copying `keepDocComments` and `docComments`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16461#issuecomment-1823463925 From msheppar at openjdk.org Wed Nov 22 20:41:02 2023 From: msheppar at openjdk.org (Mark Sheppard) Date: Wed, 22 Nov 2023 20:41:02 GMT Subject: RFR: 8320586: update manual test/jdk/TEST.groups In-Reply-To: References: Message-ID: On Wed, 22 Nov 2023 11:32:53 GMT, Ivan ?ipka wrote: > @mahendrachhipa @bwhuang-us Marked as reviewed by msheppar (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/16782#pullrequestreview-1745344250 From shade at openjdk.org Wed Nov 22 21:46:09 2023 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 22 Nov 2023 21:46:09 GMT Subject: RFR: 8318776: Require supports_cx8 to always be true [v5] In-Reply-To: References: Message-ID: On Wed, 22 Nov 2023 18:26:12 GMT, Daniel D. Daugherty wrote: >> src/hotspot/cpu/x86/vm_version_x86.cpp line 819: >> >>> 817: } >>> 818: >>> 819: _supports_cx8 = supports_cmpxchg8(); >> >> I think we should leave the runtime check here (under `ifndef`, like in ARM?). This covers the remaining case of running on legacy x86 without CX8 implemented: the init guarantee would then fire and prevent any other surprises at runtime. Sure, it would be hard to come up with such a platform today, but it would be safer to refuse to run there right away on the off-chance someone actually has it :) > > @shipilev - Do you have a particular legacy x86 in mind? My point is that it is such an easy thing to do: leave the "cx8" flag sensing code in, and keep setting up `_supports_cx8` based on it. This both provides more safety by failing cleanly on non-CX8 platform, and gives other platforms some guidance: if you can check something is supported, check it. But now that you nerd-sniped me into this... I think non-CX8 platforms would probably predate Pentium. The oldest real machine my lab has is Z530, which already has CX8. But it was easy to also go to my QEMU-driven build-test server, ask for `i486` as platform there, and et voila, no `cx8` in CPU flags: buildworker-debian12-32:~$ lscpu Architecture: i486 CPU op-mode(s): 32-bit Address sizes: 36 bits physical, 32 bits virtual Byte Order: Little Endian CPU(s): 4 On-line CPU(s) list: 0-3 Vendor ID: GenuineIntel Model name: 486 DX/4 CPU family: 4 Model: 8 Thread(s) per core: 4 Core(s) per socket: 1 Socket(s): 1 Stepping: 0 BogoMIPS: 5699.99 Flags: fpu vme pse apic ht cpuid tsc_known_freq x2apic hypervisor cpuid_fault And mainline JDK even starts there! (with interpreter, there are some asserts firing in compiler code, having to do with odd instruction selection on some paths): $ jdk/bin/java -Xint -version openjdk version "22-testing" 2024-03-19 OpenJDK Runtime Environment (fastdebug build 22-testing-builds.shipilev.net-openjdk-jdk-b627-20231121) OpenJDK Server VM (fastdebug build 22-testing-builds.shipilev.net-openjdk-jdk-b627-20231121, interpreted mode, sharing) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16625#discussion_r1402738580 From dcubed at openjdk.org Wed Nov 22 22:01:10 2023 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Wed, 22 Nov 2023 22:01:10 GMT Subject: RFR: 8318776: Require supports_cx8 to always be true [v5] In-Reply-To: References: Message-ID: On Wed, 22 Nov 2023 21:41:50 GMT, Aleksey Shipilev wrote: >> @shipilev - Do you have a particular legacy x86 in mind? > > My point is that it is such an easy thing to do: leave the "cx8" flag sensing code in, and keep setting up `_supports_cx8` based on it for `!_LP64` paths. This both provides more safety by failing cleanly on non-CX8 platform, and gives other platforms some guidance: if you can check something is supported, check it. I think we are generally trying to fail cleanly on unsupported configs, if that is easy to achieve. > > But now that you nerd-sniped me into this... I think non-CX8 platforms would probably predate Pentium. The oldest real machine my lab has is Z530, which already has CX8. But it was easy to also go to my QEMU-driven build-test server, ask for `i486` as platform there, and et voila, no `cx8` in CPU flags: > > > buildworker-debian12-32:~$ lscpu > Architecture: i486 > CPU op-mode(s): 32-bit > Address sizes: 36 bits physical, 32 bits virtual > Byte Order: Little Endian > CPU(s): 4 > On-line CPU(s) list: 0-3 > Vendor ID: GenuineIntel > Model name: 486 DX/4 > CPU family: 4 > Model: 8 > Thread(s) per core: 4 > Core(s) per socket: 1 > Socket(s): 1 > Stepping: 0 > BogoMIPS: 5699.99 > Flags: fpu vme pse apic ht cpuid tsc_known_freq x2apic hypervisor cpuid_fault > > > And mainline JDK even starts there! (with interpreter, there are some asserts firing in compiler code, having to do with odd instruction selection on some paths): > > > $ jdk/bin/java -Xint -version > openjdk version "22-testing" 2024-03-19 > OpenJDK Runtime Environment (fastdebug build 22-testing-builds.shipilev.net-openjdk-jdk-b627-20231121) > OpenJDK Server VM (fastdebug build 22-testing-builds.shipilev.net-openjdk-jdk-b627-20231121, interpreted mode, sharing) Nice spelunking... I was wondering if it was something that old. I wasn't trying to nerd-snipe... I was in the dev lab at Intel when Xenix on the i386 first came up and sent its "Hello World!" email... I left Intel for Sun in 1987 while i486 was still in development, but I still had periodic lunches with folks that worked on those teams. Life was simpler back then... ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16625#discussion_r1402748121 From duke at openjdk.org Wed Nov 22 22:26:08 2023 From: duke at openjdk.org (Yakov Shafranovich) Date: Wed, 22 Nov 2023 22:26:08 GMT Subject: RFR: JDK-8319122: Improve documentation of various Zip-file related APIs [v2] In-Reply-To: References: <8vEqyECjMkTfesVmL3X0dN4Yu8JShPiUdsKpmEz1WV0=.1b541f77-a05f-490b-aaf1-f6b7456c6d77@github.com> Message-ID: <2MTlGUzO3WSUMCNjTsxgKQQk5XCHrIQqVf4HH-jQ1E8=.6f7d081c-a4e6-4007-a9e9-77c7893b65d8@github.com> On Tue, 14 Nov 2023 12:21:42 GMT, Alan Bateman wrote: >> Yakov Shafranovich has updated the pull request incrementally with two additional commits since the last revision: >> >> - Fixed more line breaks >> - fixed line breaks > > src/java.base/share/classes/java/util/zip/ZipInputStream.java line 77: > >> 75: * >> 76: * Whenever possible, {@linkplain ZipFile} should be used for parsing ZIP >> 77: * archives since it correctly reads data from the central directory. > > I think it's okay to extend the existing API note to say that the stream may contain ZIP file entries that are not are not named in the central directory. I think I would replace the sentence "Additionally ..." with "Consequently, a ZipInputStream that reads from a ZIP file may read ZIP file entries that are not in the ZIP file's central directory". > > The sentence "This class might also fail to properly parse ZIP archives that have prepended data" will confuse readers as it hints of unreliability in scenarios and begs too many questions on where the data is prepended. So I think drop this unless you can come up with something better. > > Replacing the sentence "ZipFile may be used ..." is okay but I don't think the proposed text works. The API note starts with text to say that a ZipInputStream doesn't read the CEN so saying "correctly reads from the central directory" is very confusing. ZipInputStream is a JDK 1.1 era API, it is what it is and would be disruptive to deprecate. Thank you, I will work on this ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16424#discussion_r1402764406 From prr at openjdk.org Wed Nov 22 22:44:19 2023 From: prr at openjdk.org (Phil Race) Date: Wed, 22 Nov 2023 22:44:19 GMT Subject: RFR: 8320608: Many jtreg printing tests are missing the @printer keyword Message-ID: Many printing tests do not have the @printer keyword. This adds them to those that need it. I also found one test that has nothing to do with printing in the print folder and moved it out. ------------- Commit messages: - 8320608 Changes: https://git.openjdk.org/jdk/pull/16785/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16785&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8320608 Stats: 232 lines in 142 files changed: 133 ins; 20 del; 79 mod Patch: https://git.openjdk.org/jdk/pull/16785.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16785/head:pull/16785 PR: https://git.openjdk.org/jdk/pull/16785 From jlu at openjdk.org Thu Nov 23 00:30:16 2023 From: jlu at openjdk.org (Justin Lu) Date: Thu, 23 Nov 2023 00:30:16 GMT Subject: Integrated: JDK-8319569: Several java/util tests should be updated to accept VM flags In-Reply-To: References: Message-ID: On Fri, 17 Nov 2023 09:25:40 GMT, Justin Lu wrote: > Please review this PR which allows these _j.util_ tests to launch new JVM processes with VM flags, > > This is primarily done using by switching to `ProcessTools::createTestJavaProcessBuilder`. This pull request has now been integrated. Changeset: 2bb4b939 Author: Justin Lu URL: https://git.openjdk.org/jdk/commit/2bb4b9398d65e3f37f34e45476c969ff0afb1540 Stats: 185 lines in 12 files changed: 20 ins; 42 del; 123 mod 8319569: Several java/util tests should be updated to accept VM flags Reviewed-by: naoto, lancea ------------- PR: https://git.openjdk.org/jdk/pull/16705 From jlu at openjdk.org Thu Nov 23 00:36:36 2023 From: jlu at openjdk.org (Justin Lu) Date: Thu, 23 Nov 2023 00:36:36 GMT Subject: RFR: JDK-8210410: Refactor java.util.Currency:i18n shell tests to plain java tests Message-ID: Please review this PR which converts the shell test, _java/util/currency/PropertiesTest.sh_ to a normal java test. This test is a test runner that launches test methods from _PropertiesTest.java_. It tests both the ways to supersede the default currencies, that is, either using a custom properties file under the lib directory, or setting the path to a custom properties file via the system property. In addition to the conversion, I have updated the test so that the `PropertiesTest` methods are ran by both the default test JDK and the newly created writable JDK, not just the writable JDK. ------------- Commit messages: - resolve conflicts - init Changes: https://git.openjdk.org/jdk/pull/16787/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16787&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8210410 Stats: 303 lines in 2 files changed: 159 ins; 144 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/16787.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16787/head:pull/16787 PR: https://git.openjdk.org/jdk/pull/16787 From xgong at openjdk.org Thu Nov 23 01:31:05 2023 From: xgong at openjdk.org (Xiaohong Gong) Date: Thu, 23 Nov 2023 01:31:05 GMT Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations with SLEEF [v3] In-Reply-To: References: Message-ID: On Tue, 21 Nov 2023 14:12:13 GMT, Magnus Ihse Bursie wrote: >> This is just used to print the result of `AC_MSG_CEHCKING[if ARM SVE feature is supported]` in configure. > > Ah, now I se what you are trying to do here. First of all, in the detection part, only set `SVE_FEATURE_SUPPORT`. Then you can handle the `SVE_CFLAGS` addition elsewhere/later. > > Secondly, you should not mix these `SVE_CFLAGS` with the spleef C flags. Keeping them separate will allow for LIBSLEEF_CFLAGS to be named just that. > > Thirdly, I do not like at all how you just come crashing in setting `-march` like that. The `-march` flag is handled by `FLAGS_SETUP_ABI_PROFILE`. > > Actually, now that I think of it, this is just completely wrong! You are checking on features on the build machine, to determine what target machine code to generate, with no way to override. > > You need to break out the -march handling separately. It should be moved to FLAGS_SETUP_ABI_PROFILE. I'm guessing you will need to make something like a `aarch64-sve` profile, and possibly try to auto-select it based on the result of the sve test program above. But changing `OPENJDK_TARGET_ABI_PROFILE` can have further consequences; I do not know the full extent on the top of my head. Thanks for the advice! I will take a consideration for it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16234#discussion_r1402843737 From xgong at openjdk.org Thu Nov 23 01:44:08 2023 From: xgong at openjdk.org (Xiaohong Gong) Date: Thu, 23 Nov 2023 01:44:08 GMT Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations with SLEEF [v3] In-Reply-To: References: Message-ID: <_CHm262chkVi3EMvai4A5T-dal0pdCySL8aF0kXj_uU=.9d49baad-9de9-45e0-915b-9525feb8d610@github.com> On Tue, 21 Nov 2023 14:13:19 GMT, Magnus Ihse Bursie wrote: >> Yes, it seems weird. But the library we want to built out is `libvmath.so` instead of `libsleef.so`. And we not only check the sleef library, but also the ARM SVE feature inside it. So using `VMATH` suffix is more reasonable to me. WDYT? > > As I said above, you should not mix the two together. Keep the library handling for libsleef. Move the march setting to where it belongs. And rename the files, functions and variables after this. OK, I see. It makes sense that the suffix name should be choosed mainly based on the real module name that is searched/checked in configure. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16234#discussion_r1402847627 From dholmes at openjdk.org Thu Nov 23 03:14:27 2023 From: dholmes at openjdk.org (David Holmes) Date: Thu, 23 Nov 2023 03:14:27 GMT Subject: RFR: 8318776: Require supports_cx8 to always be true [v6] In-Reply-To: References: Message-ID: > As discussed in JBS all platforms (some tweaks to Zero are in progress) actually do support `cx8` i.e. 64-bit compare-and-exchange, so we can strip out the locked-based alternatives to using it and just add a guarantee that it is true at runtime. And all platforms except some ARM variants set `SUPPORTS_NATIVE_CX8`, so we can greatly simplify things. Summary of changes: > - `_supports_cx8` field is only needed when `SUPPORTS_NATIVE_CX8` is not defined > - Assertions for `supports_cx8()` are removed > - Compiler predicates requiring `supports_cx8()` are removed > - Access backend is greatly simplified without the need for lock-based alternative > - `java.util.concurrent.AtomicLongFieldUpdater` is simplified without the need for a lock-based alternative > > I did consider moving all the ARM `kuser_helper` related code to be only defined when `SUPPORTS_NATIVE_CX8` is not defined, but there was a theoretical risk this could change the behaviour if ARMv7 binaries were run on other ARM CPU's. I added a note to that effect in vm_version_linux_arm32.cpp so the ARM port maintainers could clean this up further if desired. > > Testing: > - All Oracle tiers 1-5 builds (which includes an ARMv7 build) > - GHA builds/tests > - Oracle tiers 1-3 sanity testing > > Zero changes coming in via [JDK-8319777](https://bugs.openjdk.org/browse/JDK-8319777) will be merged when they arrive. > > Thanks. David Holmes has updated the pull request incrementally with one additional commit since the last revision: Fix typo ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16625/files - new: https://git.openjdk.org/jdk/pull/16625/files/aad0a4c4..2393b9d4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16625&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16625&range=04-05 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/16625.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16625/head:pull/16625 PR: https://git.openjdk.org/jdk/pull/16625 From dholmes at openjdk.org Thu Nov 23 03:14:32 2023 From: dholmes at openjdk.org (David Holmes) Date: Thu, 23 Nov 2023 03:14:32 GMT Subject: RFR: 8318776: Require supports_cx8 to always be true [v5] In-Reply-To: References: Message-ID: On Wed, 22 Nov 2023 15:50:17 GMT, Doug Lea
    wrote: >> David Holmes has updated the pull request with a new target base 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 with master and update Zero code accordingly >> - Merge branch 'master' into 8318776-supports_cx8 >> - Remove unnecessary includes of vm_version.hpp. >> Fix copyright years. >> - Remove cx8 comment as no longer relevant (the spinlock is used regardless of cx8) >> - Remove suports_cx8() checks from gtest >> - Remove test for VMSupportsCX8 >> - 8318776: Require supports_cx8 to always be true > > The deletion of backup code and the check for it in java.util.concurrent.AtomicLongFieldUpdater are clearly OK. We always thought the need for it was transient. Thanks for looking at this @DougLea ! ------------- PR Comment: https://git.openjdk.org/jdk/pull/16625#issuecomment-1823770525 From dholmes at openjdk.org Thu Nov 23 03:14:34 2023 From: dholmes at openjdk.org (David Holmes) Date: Thu, 23 Nov 2023 03:14:34 GMT Subject: RFR: 8318776: Require supports_cx8 to always be true [v5] In-Reply-To: <6TkAoQRK_49MtT6wjb_JAwFzUATAvAx_rX9yxMa9Vfs=.7d1d5bf6-f088-44df-9d01-cc336bdeecaa@github.com> References: <6TkAoQRK_49MtT6wjb_JAwFzUATAvAx_rX9yxMa9Vfs=.7d1d5bf6-f088-44df-9d01-cc336bdeecaa@github.com> Message-ID: On Wed, 22 Nov 2023 18:35:59 GMT, Daniel D. Daugherty wrote: > Wow! This PR is much larger than I expected. > > Thumbs up! Thanks for the Review Dan! Yes lots of code deletion engineering in this one - and even better I got to delete template code with meta-programming stuff! :D ------------- PR Comment: https://git.openjdk.org/jdk/pull/16625#issuecomment-1823771180 From dholmes at openjdk.org Thu Nov 23 03:14:36 2023 From: dholmes at openjdk.org (David Holmes) Date: Thu, 23 Nov 2023 03:14:36 GMT Subject: RFR: 8318776: Require supports_cx8 to always be true [v6] In-Reply-To: References: Message-ID: On Wed, 22 Nov 2023 21:57:57 GMT, Daniel D. Daugherty wrote: >> My point is that it is such an easy thing to do: leave the "cx8" flag sensing code in, and keep setting up `_supports_cx8` based on it for `!_LP64` paths. This both provides more safety by failing cleanly on non-CX8 platform, and gives other platforms some guidance: if you can check something is supported, check it. I think we are generally trying to fail cleanly on unsupported configs, if that is easy to achieve. >> >> But now that you nerd-sniped me into this... I think non-CX8 platforms would probably predate Pentium. The oldest real machine my lab has is Z530, which already has CX8. But it was easy to also go to my QEMU-driven build-test server, ask for `i486` as platform there, and et voila, no `cx8` in CPU flags: >> >> >> buildworker-debian12-32:~$ lscpu >> Architecture: i486 >> CPU op-mode(s): 32-bit >> Address sizes: 36 bits physical, 32 bits virtual >> Byte Order: Little Endian >> CPU(s): 4 >> On-line CPU(s) list: 0-3 >> Vendor ID: GenuineIntel >> Model name: 486 DX/4 >> CPU family: 4 >> Model: 8 >> Thread(s) per core: 4 >> Core(s) per socket: 1 >> Socket(s): 1 >> Stepping: 0 >> BogoMIPS: 5699.99 >> Flags: fpu vme pse apic ht cpuid tsc_known_freq x2apic hypervisor cpuid_fault >> >> >> And mainline JDK even starts there! (with interpreter, there are some asserts firing in compiler code, having to do with odd instruction selection on some paths): >> >> >> $ jdk/bin/java -Xint -version >> openjdk version "22-testing" 2024-03-19 >> OpenJDK Runtime Environment (fastdebug build 22-testing-builds.shipilev.net-openjdk-jdk-b627-20231121) >> OpenJDK Server VM (fastdebug build 22-testing-builds.shipilev.net-openjdk-jdk-b627-20231121, interpreted mode, sharing) > > Nice spelunking... I was wondering if it was something that old. I wasn't trying to nerd-snipe... > > I was in the dev lab at Intel when Xenix on the i386 first came up and sent its "Hello World!" email... > I left Intel for Sun in 1987 while i486 was still in development, but I still had periodic lunches with > folks that worked on those teams. Life was simpler back then... I politely disagree. The whole point here is to leave the past behind as much as possible. We made a concession for ARM32 as there may still be old ARMv5 and ARMv6 systems in use. IIUC you need to go back to the i486 chip to not have cmpxchg8 support and I'd bet money on it that we can't run on such a chip any more for a whole swag of reasons. In any case I don't have an issue telling i486 machine owners they are stuck with JDK 21! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16625#discussion_r1402877044 From dholmes at openjdk.org Thu Nov 23 03:14:37 2023 From: dholmes at openjdk.org (David Holmes) Date: Thu, 23 Nov 2023 03:14:37 GMT Subject: RFR: 8318776: Require supports_cx8 to always be true [v5] In-Reply-To: References: Message-ID: On Wed, 22 Nov 2023 18:35:33 GMT, Daniel D. Daugherty wrote: >> src/hotspot/share/runtime/vm_version.cpp line 33: >> >>> 31: void VM_Version_init() { >>> 32: VM_Version::initialize(); >>> 33: guarantee(VM_Version::supports_cx8(), "Support for 64-bit atomic operations in required in this release"); >> >> Typo: "in required in". Also, no need to mention "this release" at all? >> Suggestion for message: "JVM requires platform support for 64-bit atomic operations" > > Or the simpler change: > s/in required/is required/ Message tweaked: Support for 64-bit atomic operations is required ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16625#discussion_r1402877940 From alanb at openjdk.org Thu Nov 23 07:06:04 2023 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 23 Nov 2023 07:06:04 GMT Subject: RFR: 8320608: Many jtreg printing tests are missing the @printer keyword In-Reply-To: References: Message-ID: <-qqvX2JKzr3-eQ_FNsovChX5aJjqQaqbewiVgvCamM0=.644272b2-55b3-4d32-8e57-7de1f9ec5590@github.com> On Wed, 22 Nov 2023 19:26:40 GMT, Phil Race wrote: > Many printing tests do not have the @printer keyword. This adds them to those that need it. > I also found one test that has nothing to do with printing in the print folder and moved it out. test/jdk/TEST.ROOT line 15: > 13: # > 14: # Notes on "client" keywords : headful sound printer 2d dnd multimon > 15: # ================================================================== The notes reads well but they're notes for "2d" and "dnd". The heading hints that there will be information on these keywords. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16785#discussion_r1402974534 From vklang at openjdk.org Thu Nov 23 08:12:11 2023 From: vklang at openjdk.org (Viktor Klang) Date: Thu, 23 Nov 2023 08:12:11 GMT Subject: RFR: 8318776: Require supports_cx8 to always be true [v5] In-Reply-To: References: <6TkAoQRK_49MtT6wjb_JAwFzUATAvAx_rX9yxMa9Vfs=.7d1d5bf6-f088-44df-9d01-cc336bdeecaa@github.com> Message-ID: On Thu, 23 Nov 2023 03:11:15 GMT, David Holmes wrote: >> Wow! This PR is much larger than I expected. >> >> Thumbs up! > >> Wow! This PR is much larger than I expected. >> >> Thumbs up! > > Thanks for the Review Dan! Yes lots of code deletion engineering in this one - and even better I got to delete template code with meta-programming stuff! :D @dholmes-ora Just passing by -- impressed by the thorough update! ------------- PR Comment: https://git.openjdk.org/jdk/pull/16625#issuecomment-1823953312 From dholmes at openjdk.org Thu Nov 23 08:16:11 2023 From: dholmes at openjdk.org (David Holmes) Date: Thu, 23 Nov 2023 08:16:11 GMT Subject: RFR: 8318776: Require supports_cx8 to always be true [v5] In-Reply-To: References: <6TkAoQRK_49MtT6wjb_JAwFzUATAvAx_rX9yxMa9Vfs=.7d1d5bf6-f088-44df-9d01-cc336bdeecaa@github.com> Message-ID: On Thu, 23 Nov 2023 08:09:44 GMT, Viktor Klang wrote: >>> Wow! This PR is much larger than I expected. >>> >>> Thumbs up! >> >> Thanks for the Review Dan! Yes lots of code deletion engineering in this one - and even better I got to delete template code with meta-programming stuff! :D > > @dholmes-ora Just passing by -- impressed by the thorough update! Thanks for taking a look @viktorklang-ora ! ------------- PR Comment: https://git.openjdk.org/jdk/pull/16625#issuecomment-1823957279 From shade at openjdk.org Thu Nov 23 08:28:12 2023 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 23 Nov 2023 08:28:12 GMT Subject: RFR: 8318776: Require supports_cx8 to always be true [v6] In-Reply-To: References: Message-ID: On Thu, 23 Nov 2023 03:14:27 GMT, David Holmes wrote: >> As discussed in JBS all platforms (some tweaks to Zero are in progress) actually do support `cx8` i.e. 64-bit compare-and-exchange, so we can strip out the locked-based alternatives to using it and just add a guarantee that it is true at runtime. And all platforms except some ARM variants set `SUPPORTS_NATIVE_CX8`, so we can greatly simplify things. Summary of changes: >> - `_supports_cx8` field is only needed when `SUPPORTS_NATIVE_CX8` is not defined >> - Assertions for `supports_cx8()` are removed >> - Compiler predicates requiring `supports_cx8()` are removed >> - Access backend is greatly simplified without the need for lock-based alternative >> - `java.util.concurrent.AtomicLongFieldUpdater` is simplified without the need for a lock-based alternative >> >> I did consider moving all the ARM `kuser_helper` related code to be only defined when `SUPPORTS_NATIVE_CX8` is not defined, but there was a theoretical risk this could change the behaviour if ARMv7 binaries were run on other ARM CPU's. I added a note to that effect in vm_version_linux_arm32.cpp so the ARM port maintainers could clean this up further if desired. >> >> Testing: >> - All Oracle tiers 1-5 builds (which includes an ARMv7 build) >> - GHA builds/tests >> - Oracle tiers 1-3 sanity testing >> >> Zero changes coming in via [JDK-8319777](https://bugs.openjdk.org/browse/JDK-8319777) will be merged when they arrive. >> >> Thanks. > > David Holmes has updated the pull request incrementally with one additional commit since the last revision: > > Fix typo Ran full jcstress on linux-arm-zero-release on RPi 4 without problem. ------------- Marked as reviewed by shade (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16625#pullrequestreview-1745896266 From xgong at openjdk.org Thu Nov 23 08:44:08 2023 From: xgong at openjdk.org (Xiaohong Gong) Date: Thu, 23 Nov 2023 08:44:08 GMT Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations with SLEEF [v3] In-Reply-To: References: Message-ID: On Thu, 23 Nov 2023 01:28:40 GMT, Xiaohong Gong wrote: >> Ah, now I se what you are trying to do here. First of all, in the detection part, only set `SVE_FEATURE_SUPPORT`. Then you can handle the `SVE_CFLAGS` addition elsewhere/later. >> >> Secondly, you should not mix these `SVE_CFLAGS` with the spleef C flags. Keeping them separate will allow for LIBSLEEF_CFLAGS to be named just that. >> >> Thirdly, I do not like at all how you just come crashing in setting `-march` like that. The `-march` flag is handled by `FLAGS_SETUP_ABI_PROFILE`. >> >> Actually, now that I think of it, this is just completely wrong! You are checking on features on the build machine, to determine what target machine code to generate, with no way to override. >> >> You need to break out the -march handling separately. It should be moved to FLAGS_SETUP_ABI_PROFILE. I'm guessing you will need to make something like a `aarch64-sve` profile, and possibly try to auto-select it based on the result of the sve test program above. But changing `OPENJDK_TARGET_ABI_PROFILE` can have further consequences; I do not know the full extent on the top of my head. > > Thanks for the advice! I will take a consideration for it. > Thirdly, I do not like at all how you just come crashing in setting -march like that. The -march flag is handled by FLAGS_SETUP_ABI_PROFILE. `-march=armv8-a+sve` is just used in this new added module, which may not expect to be used for other libraries. Per my understanding, flags handled by `FLAGS_SETUP_ABI_PROFILE` is not used for a specified module? > Actually, now that I think of it, this is just completely wrong! You are checking on features on the build machine, to determine what target machine code to generate, with no way to override. Yes, that's be a risk, although the usage to the SVE functions are controlled by SVE feature as well in runtime. I need time to find a better solution. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16234#discussion_r1403052964 From xgong at openjdk.org Thu Nov 23 08:52:09 2023 From: xgong at openjdk.org (Xiaohong Gong) Date: Thu, 23 Nov 2023 08:52:09 GMT Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations with SLEEF [v3] In-Reply-To: References: Message-ID: On Wed, 15 Nov 2023 01:32:00 GMT, Xiaohong Gong wrote: >> Currently the vector floating-point math APIs like `VectorOperators.SIN/COS/TAN...` are not intrinsified on AArch64 platform, which causes large performance gap on AArch64. Note that those APIs are optimized by C2 compiler on X86 platforms by calling Intel's SVML code [1]. To close the gap, we would like to optimize these APIs for AArch64 by calling a third-party vector library called libsleef [2], which are available in mainstream Linux distros (e.g. [3] [4]). >> >> SLEEF supports multiple accuracies. To match Vector API's requirement and implement the math ops on AArch64, we 1) call 1.0 ULP accuracy with FMA instructions used stubs in libsleef for most of the operations by default, and 2) add the vector calling convention to apply with the runtime calls to stub code in libsleef. Note that for those APIs that libsleef does not support 1.0 ULP, we choose 0.5 ULP instead. >> >> To help loading the expected libsleef library, this patch also adds an experimental JVM option (i.e. `-XX:UseSleefLib`) for AArch64 platforms. People can use it to denote the libsleef path/name explicitly. By default, it points to the system installed library. If the library does not exist or the dynamic loading of it in runtime fails, the math vector ops will fall-back to use the default scalar version without error. But a warning is printed out if people specifies a nonexistent library explicitly. >> >> Note that this is a part of the original proposed patch in panama-dev [5], just with some initial review comments addressed. And now we'd like to get some wider feedbacks from more hotspot experts. >> >> [1] https://github.com/openjdk/jdk/pull/3638 >> [2] https://sleef.org/ >> [3] https://packages.fedoraproject.org/pkgs/sleef/sleef/ >> [4] https://packages.debian.org/bookworm/libsleef3 >> [5] https://mail.openjdk.org/pipermail/panama-dev/2022-December/018172.html > > Xiaohong Gong has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: > > - Add a bundled native lib in jdk as a bridge to libsleef > - Merge 'jdk:master' into JDK-8312425 > - Disable sleef by default > - Merge 'jdk:master' into JDK-8312425 > - 8312425: [vectorapi] AArch64: Optimize vector math operations with SLEEF Agree that we using the external library as the first step, and then is adding the sleef sources in JDK if needed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16234#issuecomment-1824007585 From xgong at openjdk.org Thu Nov 23 08:57:23 2023 From: xgong at openjdk.org (Xiaohong Gong) Date: Thu, 23 Nov 2023 08:57:23 GMT Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations with SLEEF [v4] In-Reply-To: References: Message-ID: <3dscjw75an6_n3ko_2LjHdpdj08xsyjhfpStuZrS5-M=.f43592fe-036e-47b5-babc-67f126885839@github.com> > Currently the vector floating-point math APIs like `VectorOperators.SIN/COS/TAN...` are not intrinsified on AArch64 platform, which causes large performance gap on AArch64. Note that those APIs are optimized by C2 compiler on X86 platforms by calling Intel's SVML code [1]. To close the gap, we would like to optimize these APIs for AArch64 by calling a third-party vector library called libsleef [2], which are available in mainstream Linux distros (e.g. [3] [4]). > > SLEEF supports multiple accuracies. To match Vector API's requirement and implement the math ops on AArch64, we 1) call 1.0 ULP accuracy with FMA instructions used stubs in libsleef for most of the operations by default, and 2) add the vector calling convention to apply with the runtime calls to stub code in libsleef. Note that for those APIs that libsleef does not support 1.0 ULP, we choose 0.5 ULP instead. > > To help loading the expected libsleef library, this patch also adds an experimental JVM option (i.e. `-XX:UseSleefLib`) for AArch64 platforms. People can use it to denote the libsleef path/name explicitly. By default, it points to the system installed library. If the library does not exist or the dynamic loading of it in runtime fails, the math vector ops will fall-back to use the default scalar version without error. But a warning is printed out if people specifies a nonexistent library explicitly. > > Note that this is a part of the original proposed patch in panama-dev [5], just with some initial review comments addressed. And now we'd like to get some wider feedbacks from more hotspot experts. > > [1] https://github.com/openjdk/jdk/pull/3638 > [2] https://sleef.org/ > [3] https://packages.fedoraproject.org/pkgs/sleef/sleef/ > [4] https://packages.debian.org/bookworm/libsleef3 > [5] https://mail.openjdk.org/pipermail/panama-dev/2022-December/018172.html Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision: Address review comments in build system ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16234/files - new: https://git.openjdk.org/jdk/pull/16234/files/b29df846..2c3c4a64 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16234&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16234&range=02-03 Stats: 126 lines in 7 files changed: 72 ins; 22 del; 32 mod Patch: https://git.openjdk.org/jdk/pull/16234.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16234/head:pull/16234 PR: https://git.openjdk.org/jdk/pull/16234 From mbaesken at openjdk.org Thu Nov 23 09:02:05 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 23 Nov 2023 09:02:05 GMT Subject: RFR: 8320601: ProblemList java/lang/invoke/lambda/LambdaFileEncodingSerialization.java on linux-all In-Reply-To: References: Message-ID: On Wed, 22 Nov 2023 15:59:38 GMT, Christoph Langer wrote: > java/lang/invoke/lambda/LambdaFileEncodingSerialization.java is already problem listed on linux-x64. However, the issue is not processor specific. We see the failure on linux on other architectures as well. Makes sense to do it on all Linux CPU archs; however I wonder about the following - is there maybe some environment variable setting missing in the test that otherwise would make the test run successfully ? In the test java/lang/invoke/lambda/LambdaFileEncodingSerialization.java we set already https://github.com/openjdk/jdk/blob/8db7bad992a0f31de9c7e00c2657c18670539102/test/jdk/java/lang/invoke/lambda/LambdaFileEncodingSerialization.java#L83 ` env.put("LC_ALL", "en_US.UTF-8"); // Ensure locale supports the test requirements, lambda with a UTF char` is that maybe not sufficient on some systems and some other env var must be set ? ------------- Marked as reviewed by mbaesken (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16784#pullrequestreview-1745975621 PR Comment: https://git.openjdk.org/jdk/pull/16784#issuecomment-1824017867 From kevinw at openjdk.org Thu Nov 23 09:38:14 2023 From: kevinw at openjdk.org (Kevin Walls) Date: Thu, 23 Nov 2023 09:38:14 GMT Subject: RFR: 8316649: JMX connection timeout cannot be changed and uses the default of 0 (infinite) Message-ID: RMI Connections (in general) should use a timeout on the Socket connect call by default. JMX connections use RMI and some connection failures never terminate. The hang described in 8316649 is hard to reproduce manually: the description says it can be caused by a firewall that never returns a response. src/java.rmi/share/classes/sun/rmi/transport/tcp/TCPChannel.java has other timeouts but nothing to control the initial Socket connect. Defaulting to a 1 minute timeout on connect has no effect on existing tests for RMI and JMX, and should go unnoticed in applications unless there really is a significant connection delay. Specifying zero for the new System Property sun.rmi.transport.tcp.initialConnectTimeout uses the old code path of a connect with no timeout. I have a test, but it is not realistically usable: although specifying a 1 millisecond timeout will often fail (as expected/desired for the test), it will often pass as the connection happens immediately. ------------- Commit messages: - Ignore negative timeout values. - Make connect timeout static - 8316649: JMX connection timeout cannot be changed and uses the default of 0 (infinite) Changes: https://git.openjdk.org/jdk/pull/16771/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16771&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8316649 Stats: 21 lines in 1 file changed: 19 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/16771.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16771/head:pull/16771 PR: https://git.openjdk.org/jdk/pull/16771 From isipka at openjdk.org Thu Nov 23 10:34:16 2023 From: isipka at openjdk.org (Ivan =?UTF-8?B?xaBpcGth?=) Date: Thu, 23 Nov 2023 10:34:16 GMT Subject: Integrated: 8320586: update manual test/jdk/TEST.groups In-Reply-To: References: Message-ID: On Wed, 22 Nov 2023 11:32:53 GMT, Ivan ?ipka wrote: > @mahendrachhipa @bwhuang-us This pull request has now been integrated. Changeset: 99b9cb0a Author: Ivan ?ipka Committer: Mark Sheppard URL: https://git.openjdk.org/jdk/commit/99b9cb0a2eae1196f2127cd48e4085f19a90c4b4 Stats: 10 lines in 1 file changed: 5 ins; 2 del; 3 mod 8320586: update manual test/jdk/TEST.groups Reviewed-by: msheppar ------------- PR: https://git.openjdk.org/jdk/pull/16782 From prappo at openjdk.org Thu Nov 23 10:48:23 2023 From: prappo at openjdk.org (Pavel Rappo) Date: Thu, 23 Nov 2023 10:48:23 GMT Subject: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v32] In-Reply-To: <1-xpQnCScwxwkKoJgPybXoeI_U3LPuBvNcfHzI0vtqs=.c817ed49-2ed7-4b4c-9f19-75e6c5c6b5a6@github.com> References: <1-xpQnCScwxwkKoJgPybXoeI_U3LPuBvNcfHzI0vtqs=.c817ed49-2ed7-4b4c-9f19-75e6c5c6b5a6@github.com> Message-ID: On Wed, 22 Nov 2023 15:29:08 GMT, Jim Laskey wrote: >> Address changes from JEP 445 to JEP 463. >> >> - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. >> >> - Don't mark class on read. >> >> - Remove reflection and annotation processing related to unnamed classes. >> >> - Simplify main method search. > > Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: > > Handle javadoc on top level elements properly I've checked your recent commit [222e334](https://github.com/openjdk/jdk/pull/16461/commits/222e3346ac61a9116014791fac0ad60ef3950949) and can confirm that it fixes the issue with comments; thanks. Feel free to add a tests for it. Regardless of whether the compiler has such a test, javadoc will have its own test. So it will be covered. But javadoc test will be indirect. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16461#issuecomment-1824193504 From vklang at openjdk.org Thu Nov 23 10:59:10 2023 From: vklang at openjdk.org (Viktor Klang) Date: Thu, 23 Nov 2023 10:59:10 GMT Subject: RFR: JDK-8319662 ForkJoinPool trims worker threads too slowly [v3] In-Reply-To: References: Message-ID: On Tue, 21 Nov 2023 17:12:39 GMT, Doug Lea
    wrote: >> This update cascades timeouts to trim subsequent workers after the first keepAlive inactive period. > > 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 three additional commits since the last revision: > > - Merge branch 'openjdk:master' into JDK-8319662 > - tweak cascades; reinstate an @Contended; resolve JDK-8319498 > - Support cascading idle timeouts src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 2013: > 2011: else if ((e & SHUTDOWN) == 0) > 2012: return true; > 2013: else if (compareAndSetCtl(c, c) && casRunState(e, e | STOP)) { Is this `compareAndSetCtl(c, c)` really needed? Wouldn't a volatile get on `ctl` compared with `c` be enough? (Or are we relying on a store-barrier in the successful case? ? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16725#discussion_r1403218297 From eosterlund at openjdk.org Thu Nov 23 11:21:15 2023 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Thu, 23 Nov 2023 11:21:15 GMT Subject: RFR: 8310644: Make panama memory segment close use async handshakes Message-ID: The current logic for closing memory in panama today is susceptible to live lock if we have a closing thread that wants to close the memory in a loop that keeps failing, and a bunch of accessing threads that want to perform accesses as long as the memory is alive. They can both create impediments for the other. By using asynchronous handshakes to install an exception onto threads that are in @Scoped memory accesses, we can have close always succeed, and the accessing threads bail out. The idea is that we perform a synchronous handshake first to find threads that are in scoped methods. They might however be in the middle of throwing an exception or something wild like there, where an exception can't be delivered. We install an async handshake that will roll us forward to the first place where we can indeed install exceptions, then we reevaluate if we still need to do that, or if we have unwound out from the scoped method. If we are still inside of it, we ensure an exception is installed so we don't continue executing bytecodes that might access the memory that we have freed. Tested tier 1-5 as well as running test/jdk/java/foreign/TestHandshake.java hundreds of times, which tests this API pretty well. ------------- Commit messages: - 8310644: Make panama memory segment close use async handshakes Changes: https://git.openjdk.org/jdk/pull/16792/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16792&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8310644 Stats: 131 lines in 7 files changed: 59 ins; 25 del; 47 mod Patch: https://git.openjdk.org/jdk/pull/16792.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16792/head:pull/16792 PR: https://git.openjdk.org/jdk/pull/16792 From egahlin at openjdk.org Thu Nov 23 11:21:07 2023 From: egahlin at openjdk.org (Erik Gahlin) Date: Thu, 23 Nov 2023 11:21:07 GMT Subject: RFR: 8310994: Add JFR event for selection operations In-Reply-To: References: Message-ID: On Wed, 22 Nov 2023 12:25:45 GMT, Alan Bateman wrote: >> Added mirror event with static methods: jdk.internal.event.SelectionEvent that provides the duration of select calls and the count of how many keys are available. >> >> Emit the event from SelectorImpl::lockAndDoSelect >> >> Test at jdk.jfr.event.io.TestSelectionEvents > > src/jdk.jfr/share/classes/jdk/jfr/events/SelectionEvent.java line 43: > >> 41: >> 42: @Label("Selection Count") >> 43: @Description("Number of channels selected") > > I suspect you'll need to rename this event to something like "SelectorSelect" as "Selection" could be anything. > > We'll to find a better name for the field and the label too. There are two forms of selection operations. One form operates on a selected-key set where the select/selectNow methods returns the number of keys aded to the Selector's ready set. The other form performs an action on each selected key. I'll try to come up a suggestions for the names, I suspect a label "number of channels ready for I/O or added to ready set" would be the most accurate. It would also be good if the name reflect that it is related to channels so it won't clash with other events in the future. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16710#discussion_r1403242271 From msheppar at openjdk.org Thu Nov 23 11:40:05 2023 From: msheppar at openjdk.org (Mark Sheppard) Date: Thu, 23 Nov 2023 11:40:05 GMT Subject: RFR: 8316649: JMX connection timeout cannot be changed and uses the default of 0 (infinite) In-Reply-To: References: Message-ID: <19duWGlPAF6oED9N344lKIW9sssuEWQWCr9c-vI4MxE=.882aeec7-6ec0-47c0-b737-5f4e6300bf31@github.com> On Tue, 21 Nov 2023 17:57:32 GMT, Kevin Walls wrote: > RMI Connections (in general) should use a timeout on the Socket connect call by default. > > JMX connections use RMI and some connection failures never terminate. The hang described in 8316649 is hard to reproduce manually: the description says it can be caused by a firewall that never returns a response. > > src/java.rmi/share/classes/sun/rmi/transport/tcp/TCPChannel.java > has other timeouts but nothing to control the initial Socket connect. > > Defaulting to a 1 minute timeout on connect has no effect on existing tests for RMI and JMX, and should go unnoticed in applications unless there really is a significant connection delay. Specifying zero for the new System Property sun.rmi.transport.tcp.initialConnectTimeout uses the old code path of a connect with no timeout. > > I have a test, but it is not realistically usable: although specifying a 1 millisecond timeout will often fail (as expected/desired for the test), it will often pass as the connection happens immediately. The introduction of the system property is reasonable. I have questions over the veracity of the context described in the bug. I think it's a firewall configuration issue. If there is not listening end point for a TCP connect request, this will, result in a ConnectException being thrown in the RMI client. As such, for no response to happen, It means that a TCP connection has been established with the firewall (at the TCP level), from the RMI (JMX) client and that connection has not been accepted or passed through by the firewall application. Thus, it would appear that the shutdown of the target server has not been registered in the firewall. In any case the change looks fine. Do you have a test c.f. bug comment ------------- PR Comment: https://git.openjdk.org/jdk/pull/16771#issuecomment-1824272681 From dfuchs at openjdk.org Thu Nov 23 11:40:07 2023 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Thu, 23 Nov 2023 11:40:07 GMT Subject: RFR: 8316649: JMX connection timeout cannot be changed and uses the default of 0 (infinite) In-Reply-To: References: Message-ID: On Tue, 21 Nov 2023 17:57:32 GMT, Kevin Walls wrote: > RMI Connections (in general) should use a timeout on the Socket connect call by default. > > JMX connections use RMI and some connection failures never terminate. The hang described in 8316649 is hard to reproduce manually: the description says it can be caused by a firewall that never returns a response. > > src/java.rmi/share/classes/sun/rmi/transport/tcp/TCPChannel.java > has other timeouts but nothing to control the initial Socket connect. > > Defaulting to a 1 minute timeout on connect has no effect on existing tests for RMI and JMX, and should go unnoticed in applications unless there really is a significant connection delay. Specifying zero for the new System Property sun.rmi.transport.tcp.initialConnectTimeout uses the old code path of a connect with no timeout. > > I have a test, but it is not realistically usable: although specifying a 1 millisecond timeout will often fail (as expected/desired for the test), it will often pass as the connection happens immediately. src/java.rmi/share/classes/sun/rmi/transport/tcp/TCPDirectSocketFactory.java line 46: > 44: private static final int connectTimeout = // default 1 minute > 45: AccessController.doPrivileged((PrivilegedAction) () -> > 46: Integer.getInteger("sun.rmi.transport.tcp.initialConnectTimeout", 60 * 1000).intValue()); An exception here will prevent the class from being initialized, any subsequent attempts to use the class will then produce hard to diagnose error. If the class is not loaded by the main thread, such exception/error could be swallowed unless an uncaught exception handler was registered. I would suggest implementing the logic in a static block, catch any exception and revert to default behaviour (i.e. 0) if the value supplied for the property is not an integer, or not a valid integer, etc... ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16771#discussion_r1403258620 From dfuchs at openjdk.org Thu Nov 23 11:40:07 2023 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Thu, 23 Nov 2023 11:40:07 GMT Subject: RFR: 8316649: JMX connection timeout cannot be changed and uses the default of 0 (infinite) In-Reply-To: References: Message-ID: On Thu, 23 Nov 2023 11:35:11 GMT, Daniel Fuchs wrote: >> RMI Connections (in general) should use a timeout on the Socket connect call by default. >> >> JMX connections use RMI and some connection failures never terminate. The hang described in 8316649 is hard to reproduce manually: the description says it can be caused by a firewall that never returns a response. >> >> src/java.rmi/share/classes/sun/rmi/transport/tcp/TCPChannel.java >> has other timeouts but nothing to control the initial Socket connect. >> >> Defaulting to a 1 minute timeout on connect has no effect on existing tests for RMI and JMX, and should go unnoticed in applications unless there really is a significant connection delay. Specifying zero for the new System Property sun.rmi.transport.tcp.initialConnectTimeout uses the old code path of a connect with no timeout. >> >> I have a test, but it is not realistically usable: although specifying a 1 millisecond timeout will often fail (as expected/desired for the test), it will often pass as the connection happens immediately. > > src/java.rmi/share/classes/sun/rmi/transport/tcp/TCPDirectSocketFactory.java line 46: > >> 44: private static final int connectTimeout = // default 1 minute >> 45: AccessController.doPrivileged((PrivilegedAction) () -> >> 46: Integer.getInteger("sun.rmi.transport.tcp.initialConnectTimeout", 60 * 1000).intValue()); > > An exception here will prevent the class from being initialized, any subsequent attempts to use the class will then produce hard to diagnose error. If the class is not loaded by the main thread, such exception/error could be swallowed unless an uncaught exception handler was registered. I would suggest implementing the logic in a static block, catch any exception and revert to default behaviour (i.e. 0) if the value supplied for the property is not an integer, or not a valid integer, etc... IIRC, the default agent uses / may use its own socket factories - are we still coming here even with those factories? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16771#discussion_r1403260460 From asotona at openjdk.org Thu Nov 23 11:58:20 2023 From: asotona at openjdk.org (Adam Sotona) Date: Thu, 23 Nov 2023 11:58:20 GMT Subject: RFR: 8320618: NPE: Cannot invoke "java.lang.constant.ClassDesc.isArray()" because "this.sym" is null Message-ID: ClassFile API StackMapGenerator caused a NPE for a test case with invalid sequence of instructions. This fix simply avoids the NPE and adds StackMapsTest::testInvalidAALOADStack Please review. Thanks, Adam ------------- Commit messages: - 8320618: NPE: Cannot invoke "java.lang.constant.ClassDesc.isArray()" because "this.sym" is null Changes: https://git.openjdk.org/jdk/pull/16793/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16793&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8320618 Stats: 15 lines in 2 files changed: 12 ins; 1 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/16793.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16793/head:pull/16793 PR: https://git.openjdk.org/jdk/pull/16793 From dholmes at openjdk.org Thu Nov 23 12:09:27 2023 From: dholmes at openjdk.org (David Holmes) Date: Thu, 23 Nov 2023 12:09:27 GMT Subject: RFR: 8318776: Require supports_cx8 to always be true [v7] In-Reply-To: References: Message-ID: > As discussed in JBS all platforms (some tweaks to Zero are in progress) actually do support `cx8` i.e. 64-bit compare-and-exchange, so we can strip out the locked-based alternatives to using it and just add a guarantee that it is true at runtime. And all platforms except some ARM variants set `SUPPORTS_NATIVE_CX8`, so we can greatly simplify things. Summary of changes: > - `_supports_cx8` field is only needed when `SUPPORTS_NATIVE_CX8` is not defined > - Assertions for `supports_cx8()` are removed > - Compiler predicates requiring `supports_cx8()` are removed > - Access backend is greatly simplified without the need for lock-based alternative > - `java.util.concurrent.AtomicLongFieldUpdater` is simplified without the need for a lock-based alternative > > I did consider moving all the ARM `kuser_helper` related code to be only defined when `SUPPORTS_NATIVE_CX8` is not defined, but there was a theoretical risk this could change the behaviour if ARMv7 binaries were run on other ARM CPU's. I added a note to that effect in vm_version_linux_arm32.cpp so the ARM port maintainers could clean this up further if desired. > > Testing: > - All Oracle tiers 1-5 builds (which includes an ARMv7 build) > - GHA builds/tests > - Oracle tiers 1-3 sanity testing > > Zero changes coming in via [JDK-8319777](https://bugs.openjdk.org/browse/JDK-8319777) will be merged when they arrive. > > Thanks. David Holmes 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 - Fix typo - Merge with master and update Zero code accordingly - Merge branch 'master' into 8318776-supports_cx8 - Remove unnecessary includes of vm_version.hpp. Fix copyright years. - Remove cx8 comment as no longer relevant (the spinlock is used regardless of cx8) - Remove suports_cx8() checks from gtest - Remove test for VMSupportsCX8 - 8318776: Require supports_cx8 to always be true ------------- Changes: https://git.openjdk.org/jdk/pull/16625/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16625&range=06 Stats: 460 lines in 39 files changed: 16 ins; 429 del; 15 mod Patch: https://git.openjdk.org/jdk/pull/16625.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16625/head:pull/16625 PR: https://git.openjdk.org/jdk/pull/16625 From kevinw at openjdk.org Thu Nov 23 12:43:06 2023 From: kevinw at openjdk.org (Kevin Walls) Date: Thu, 23 Nov 2023 12:43:06 GMT Subject: RFR: 8316649: JMX connection timeout cannot be changed and uses the default of 0 (infinite) In-Reply-To: References: Message-ID: On Thu, 23 Nov 2023 11:37:12 GMT, Daniel Fuchs wrote: >> src/java.rmi/share/classes/sun/rmi/transport/tcp/TCPDirectSocketFactory.java line 46: >> >>> 44: private static final int connectTimeout = // default 1 minute >>> 45: AccessController.doPrivileged((PrivilegedAction) () -> >>> 46: Integer.getInteger("sun.rmi.transport.tcp.initialConnectTimeout", 60 * 1000).intValue()); >> >> An exception here will prevent the class from being initialized, any subsequent attempts to use the class will then produce hard to diagnose error. If the class is not loaded by the main thread, such exception/error could be swallowed unless an uncaught exception handler was registered. I would suggest implementing the logic in a static block, catch any exception and revert to default behaviour (i.e. 0) if the value supplied for the property is not an integer, or not a valid integer, etc... > > IIRC, the default agent uses / may use its own socket factories - are we still coming here even with those factories? > An exception here will prevent the class from being initialized... Maybe we can break it, but this new property is following the same pattern I think as the neighbouring file src/java.rmi/share/classes/sun/rmi/transport/tcp/TCPChannel.java when it reads the system props. I see Integer.getInteger handles the obvious Exceptions, so specifying a strange value does not immediately break us. If there's more protection needed then we have various other places to apply it that might need separate follow-up if you think there's a case? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16771#discussion_r1403331157 From kevinw at openjdk.org Thu Nov 23 12:46:08 2023 From: kevinw at openjdk.org (Kevin Walls) Date: Thu, 23 Nov 2023 12:46:08 GMT Subject: RFR: 8316649: JMX connection timeout cannot be changed and uses the default of 0 (infinite) In-Reply-To: References: Message-ID: On Thu, 23 Nov 2023 12:40:18 GMT, Kevin Walls wrote: >> IIRC, the default agent uses / may use its own socket factories - are we still coming here even with those factories? > >> An exception here will prevent the class from being initialized... > > Maybe we can break it, but this new property is following the same pattern I think as the neighbouring file src/java.rmi/share/classes/sun/rmi/transport/tcp/TCPChannel.java when it reads the system props. I see Integer.getInteger handles the obvious Exceptions, so specifying a strange value does not immediately break us. > > If there's more protection needed then we have various other places to apply it that might need separate follow-up if you think there's a case? > IIRC, the default agent uses / may use its own socket factories - are we still coming here even with those factories? We do get here, yes (not saying you can't customise your way out of getting here). This is a stack from a test I was experimenting with, when it did see the timeout: ---------System.out:(4/132)---------- JMX URL = service:jmx:rmi://x expectTimeout = true sun.rmi.transport.tcp.initialConnectTimeout = 1 Test passed ----------System.err:(24/1791)---------- java.rmi.ConnectIOException: Exception creating connection to: x.x.x.x; nested exception is: java.net.SocketTimeoutException at java.rmi/sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:637) at java.rmi/sun.rmi.transport.tcp.TCPChannel.createConnection(TCPChannel.java:217) at java.rmi/sun.rmi.transport.tcp.TCPChannel.newConnection(TCPChannel.java:204) at java.rmi/sun.rmi.server.UnicastRef.invoke(UnicastRef.java:134) at java.management.rmi/javax.management.remote.rmi.RMIServerImpl_Stub.newClient(RMIServerImpl_Stub.java:85) at java.management.rmi/javax.management.remote.rmi.RMIConnector.getConnection(RMIConnector.java:2106) at java.management.rmi/javax.management.remote.rmi.RMIConnector.connect(RMIConnector.java:321) at java.management/javax.management.remote.JMXConnectorFactory.connect(JMXConnectorFactory.java:270) at java.management/javax.management.remote.JMXConnectorFactory.connect(JMXConnectorFactory.java:229) at RMIConnectionTimeoutTest.main(RMIConnectionTimeoutTest.java:65) 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) Caused by: java.net.SocketTimeoutException at java.base/java.net.SocksSocketImpl.remainingMillis(SocksSocketImpl.java:112) at java.base/java.net.SocksSocketImpl.connect(SocksSocketImpl.java:327) at java.base/java.net.Socket.connect(Socket.java:752) at java.rmi/sun.rmi.transport.tcp.TCPDirectSocketFactory.createSocket(TCPDirectSocketFactory.java:57) at java.rmi/sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:619) ... 13 more STATUS:Passed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16771#discussion_r1403334446 From jvernee at openjdk.org Thu Nov 23 12:46:12 2023 From: jvernee at openjdk.org (Jorn Vernee) Date: Thu, 23 Nov 2023 12:46:12 GMT Subject: RFR: 8310644: Make panama memory segment close use async handshakes In-Reply-To: References: Message-ID: On Thu, 23 Nov 2023 11:14:29 GMT, Erik ?sterlund wrote: > The current logic for closing memory in panama today is susceptible to live lock if we have a closing thread that wants to close the memory in a loop that keeps failing, and a bunch of accessing threads that want to perform accesses as long as the memory is alive. They can both create impediments for the other. > > By using asynchronous handshakes to install an exception onto threads that are in @Scoped memory accesses, we can have close always succeed, and the accessing threads bail out. The idea is that we perform a synchronous handshake first to find threads that are in scoped methods. They might however be in the middle of throwing an exception or something wild like there, where an exception can't be delivered. We install an async handshake that will roll us forward to the first place where we can indeed install exceptions, then we reevaluate if we still need to do that, or if we have unwound out from the scoped method. If we are still inside of it, we ensure an exception is installed so we don't continue executing bytecodes that might access the memory that we have freed. > > Tested tier 1-5 as well as running test/jdk/java/foreign/TestHandshake.java hundreds of times, which tests this API pretty well. src/hotspot/share/prims/scopedMemoryAccess.cpp line 151: > 149: ResourceMark rm; > 150: if (_session != nullptr && last_frame.is_compiled_frame() && last_frame.can_be_deoptimized()) { > 151: CloseScopedMemoryFindOopClosure cl(_session); Pre-existing, but this value (and class) is unused since we do an unconditional deopt. If you feel like it, you could remove the `CloseScopedMemoryFindOopClosure`. We can get it back from the git history later when that bug is fixed (https://bugs.openjdk.org/browse/JDK-8290892) src/java.base/share/classes/jdk/internal/foreign/SharedSession.java line 86: > 84: throw alreadyAcquired(prevState); > 85: } > 86: SCOPED_MEMORY_ACCESS.closeScope(this); ? src/java.base/share/classes/jdk/internal/misc/X-ScopedMemoryAccess.java.template line 87: > 85: > 86: public void closeScope(MemorySessionImpl session) { > 87: closeScope0(session, MemorySessionImpl.ALREADY_CLOSED); I suggest passing in the `ALREADY_CLOSED` instance as an argument to this method instead. Then we can avoid making the field in `MemorySessionImpl` public. test/jdk/java/foreign/TestHandshake.java line 107: > 105: if (!failed.get()) { > 106: // ignore - this means segment was alive, but was closed while we were accessing it > 107: // next isAlive test should fail If we see the exception, we should be able to test that the scope is not alive here as well Suggestion: // next isAlive test should fail assertFalse(segment.scope().isAlive()); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16792#discussion_r1403266514 PR Review Comment: https://git.openjdk.org/jdk/pull/16792#discussion_r1403255404 PR Review Comment: https://git.openjdk.org/jdk/pull/16792#discussion_r1403257610 PR Review Comment: https://git.openjdk.org/jdk/pull/16792#discussion_r1403330411 From kevinw at openjdk.org Thu Nov 23 12:49:06 2023 From: kevinw at openjdk.org (Kevin Walls) Date: Thu, 23 Nov 2023 12:49:06 GMT Subject: RFR: 8316649: JMX connection timeout cannot be changed and uses the default of 0 (infinite) In-Reply-To: <19duWGlPAF6oED9N344lKIW9sssuEWQWCr9c-vI4MxE=.882aeec7-6ec0-47c0-b737-5f4e6300bf31@github.com> References: <19duWGlPAF6oED9N344lKIW9sssuEWQWCr9c-vI4MxE=.882aeec7-6ec0-47c0-b737-5f4e6300bf31@github.com> Message-ID: On Thu, 23 Nov 2023 11:35:47 GMT, Mark Sheppard wrote: > In any case the change looks fine. Do you have a test c.f. bug comment Thanks @msheppar yes I agree with the comments. For testing I got as far as a test that often cannot see the timeout as we are too quick for a 1ms timeout. I was thinking that as the change is basic enough, getting a property and passing on a value, the usable test seems rather elaborate... We do have test/jdk/java/rmi/transport/handshakeTimeout/HandshakeTimeout.java which tests -Dsun.rmi.transport.tcp.handshakeTimeout=1 but that must reliably fail to handshake in 1ms. The basic connect is much faster. 8-) ------------- PR Comment: https://git.openjdk.org/jdk/pull/16771#issuecomment-1824372808 From ihse at openjdk.org Thu Nov 23 13:54:09 2023 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Thu, 23 Nov 2023 13:54:09 GMT Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations with SLEEF [v3] In-Reply-To: References: Message-ID: On Thu, 23 Nov 2023 08:40:57 GMT, Xiaohong Gong wrote: >> Thanks for the advice! I will take a consideration for it. > >> Thirdly, I do not like at all how you just come crashing in setting -march like that. The -march flag is handled by FLAGS_SETUP_ABI_PROFILE. > > `-march=armv8-a+sve` is just used in this new added module, which may not expect to be used for other libraries. Per my understanding, flags handled by `FLAGS_SETUP_ABI_PROFILE` is not used for a specified module? > >> Actually, now that I think of it, this is just completely wrong! You are checking on features on the build machine, to determine what target machine code to generate, with no way to override. > > Yes, that's be a risk, although the usage to the SVE functions are controlled by SVE feature as well in runtime. I need time to find a better solution. It does not matter if you set the -march on just part of the build. Actually, there is no point in doing so. Either the JDK is run on a machine with the matching architecture, or it isn't. I don't know the details of what the aarch64 SVE feature means, but unless this is a special instance, any attempt to execute the compiled code on a machine that does not support that architecture will fail. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16234#discussion_r1403416310 From ihse at openjdk.org Thu Nov 23 14:00:11 2023 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Thu, 23 Nov 2023 14:00:11 GMT Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations with SLEEF [v4] In-Reply-To: <3dscjw75an6_n3ko_2LjHdpdj08xsyjhfpStuZrS5-M=.f43592fe-036e-47b5-babc-67f126885839@github.com> References: <3dscjw75an6_n3ko_2LjHdpdj08xsyjhfpStuZrS5-M=.f43592fe-036e-47b5-babc-67f126885839@github.com> Message-ID: On Thu, 23 Nov 2023 08:57:23 GMT, Xiaohong Gong wrote: >> Currently the vector floating-point math APIs like `VectorOperators.SIN/COS/TAN...` are not intrinsified on AArch64 platform, which causes large performance gap on AArch64. Note that those APIs are optimized by C2 compiler on X86 platforms by calling Intel's SVML code [1]. To close the gap, we would like to optimize these APIs for AArch64 by calling a third-party vector library called libsleef [2], which are available in mainstream Linux distros (e.g. [3] [4]). >> >> SLEEF supports multiple accuracies. To match Vector API's requirement and implement the math ops on AArch64, we 1) call 1.0 ULP accuracy with FMA instructions used stubs in libsleef for most of the operations by default, and 2) add the vector calling convention to apply with the runtime calls to stub code in libsleef. Note that for those APIs that libsleef does not support 1.0 ULP, we choose 0.5 ULP instead. >> >> To help loading the expected libsleef library, this patch also adds an experimental JVM option (i.e. `-XX:UseSleefLib`) for AArch64 platforms. People can use it to denote the libsleef path/name explicitly. By default, it points to the system installed library. If the library does not exist or the dynamic loading of it in runtime fails, the math vector ops will fall-back to use the default scalar version without error. But a warning is printed out if people specifies a nonexistent library explicitly. >> >> Note that this is a part of the original proposed patch in panama-dev [5], just with some initial review comments addressed. And now we'd like to get some wider feedbacks from more hotspot experts. >> >> [1] https://github.com/openjdk/jdk/pull/3638 >> [2] https://sleef.org/ >> [3] https://packages.fedoraproject.org/pkgs/sleef/sleef/ >> [4] https://packages.debian.org/bookworm/libsleef3 >> [5] https://mail.openjdk.org/pipermail/panama-dev/2022-December/018172.html > > Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision: > > Address review comments in build system make/autoconf/spec.gmk.in line 894: > 892: ENABLE_LIBSLEEF:=@ENABLE_LIBSLEEF@ > 893: LIBVMATH_CFLAGS:=@LIBVMATH_CFLAGS@ > 894: LIBVMATH_LIBS:=@LIBVMATH_LIBS@ It's getting better, but you still need to handle the naming here. It should be SLEEF_LIBS and SLEEF_CFLAGS, named after the library you import -- not the library you build. What if some other lib wants to use libsleef? And you need to untangle the SVE flags (whatever we end doing with that) from LIBVMATH_CFLAGS. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16234#discussion_r1403423892 From ihse at openjdk.org Thu Nov 23 14:14:17 2023 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Thu, 23 Nov 2023 14:14:17 GMT Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations with SLEEF [v4] In-Reply-To: <3dscjw75an6_n3ko_2LjHdpdj08xsyjhfpStuZrS5-M=.f43592fe-036e-47b5-babc-67f126885839@github.com> References: <3dscjw75an6_n3ko_2LjHdpdj08xsyjhfpStuZrS5-M=.f43592fe-036e-47b5-babc-67f126885839@github.com> Message-ID: On Thu, 23 Nov 2023 08:57:23 GMT, Xiaohong Gong wrote: >> Currently the vector floating-point math APIs like `VectorOperators.SIN/COS/TAN...` are not intrinsified on AArch64 platform, which causes large performance gap on AArch64. Note that those APIs are optimized by C2 compiler on X86 platforms by calling Intel's SVML code [1]. To close the gap, we would like to optimize these APIs for AArch64 by calling a third-party vector library called libsleef [2], which are available in mainstream Linux distros (e.g. [3] [4]). >> >> SLEEF supports multiple accuracies. To match Vector API's requirement and implement the math ops on AArch64, we 1) call 1.0 ULP accuracy with FMA instructions used stubs in libsleef for most of the operations by default, and 2) add the vector calling convention to apply with the runtime calls to stub code in libsleef. Note that for those APIs that libsleef does not support 1.0 ULP, we choose 0.5 ULP instead. >> >> To help loading the expected libsleef library, this patch also adds an experimental JVM option (i.e. `-XX:UseSleefLib`) for AArch64 platforms. People can use it to denote the libsleef path/name explicitly. By default, it points to the system installed library. If the library does not exist or the dynamic loading of it in runtime fails, the math vector ops will fall-back to use the default scalar version without error. But a warning is printed out if people specifies a nonexistent library explicitly. >> >> Note that this is a part of the original proposed patch in panama-dev [5], just with some initial review comments addressed. And now we'd like to get some wider feedbacks from more hotspot experts. >> >> [1] https://github.com/openjdk/jdk/pull/3638 >> [2] https://sleef.org/ >> [3] https://packages.fedoraproject.org/pkgs/sleef/sleef/ >> [4] https://packages.debian.org/bookworm/libsleef3 >> [5] https://mail.openjdk.org/pipermail/panama-dev/2022-December/018172.html > > Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision: > > Address review comments in build system make/autoconf/lib-vmath.m4 line 58: > 56: test -e ${with_libsleef}/include/sleef.h; then > 57: LIBSLEEF_FOUND=yes > 58: LIBVMATH_LIBS="-L${with_libsleef}/lib" Suggestion: LIBVMATH_LIBS="-L${with_libsleef}/lib -lsleef" make/autoconf/lib-vmath.m4 line 70: > 68: if test "x$SYSROOT" = "x" && > 69: test "x${LIBSLEEF_FOUND}" = "xno"; then > 70: PKG_CHECK_MODULES([LIBSLEEF], [sleef], [LIBSLEEF_FOUND=yes], [LIBSLEEF_FOUND=no]) Suggestion: PKG_CHECK_MODULES([SLEEF], [sleef], [LIBSLEEF_FOUND=yes], [LIBSLEEF_FOUND=no]) Otherwise `PKG_CHECK_MODULES` will set the variables LIBSLEEF_CFLAGS and LIBSLEEF_LIBS. make/autoconf/lib-vmath.m4 line 74: > 72: if test "x${LIBSLEEF_FOUND}" = "xno"; then > 73: AC_CHECK_HEADERS([sleef.h], > 74: [LIBSLEEF_FOUND=yes], Suggestion: [ LIBSLEEF_FOUND=yes SLEEF_LIBS=-lsleef ], make/autoconf/lib-vmath.m4 line 89: > 87: if test "x${LIBSLEEF_FOUND}" = "xyes"; then > 88: ENABLE_LIBSLEEF=true > 89: LIBVMATH_LIBS="${LIBVMATH_LIBS} -lsleef" Remove this line. It would just add `-lsleef` twice if you go via `PKG_CHECK_MODULES`. You need to set -lsleef at the correct places. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16234#discussion_r1403436252 PR Review Comment: https://git.openjdk.org/jdk/pull/16234#discussion_r1403433087 PR Review Comment: https://git.openjdk.org/jdk/pull/16234#discussion_r1403438730 PR Review Comment: https://git.openjdk.org/jdk/pull/16234#discussion_r1403437474 From ihse at openjdk.org Thu Nov 23 14:14:18 2023 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Thu, 23 Nov 2023 14:14:18 GMT Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations with SLEEF [v3] In-Reply-To: <_CHm262chkVi3EMvai4A5T-dal0pdCySL8aF0kXj_uU=.9d49baad-9de9-45e0-915b-9525feb8d610@github.com> References: <_CHm262chkVi3EMvai4A5T-dal0pdCySL8aF0kXj_uU=.9d49baad-9de9-45e0-915b-9525feb8d610@github.com> Message-ID: <-XS17AVgOkuO6_JUId8P-XZxRlnfWXF0wz60w5B58L8=.e51cb13b-ec84-4943-a6b7-b09b4e8943d4@github.com> On Thu, 23 Nov 2023 01:41:46 GMT, Xiaohong Gong wrote: >> As I said above, you should not mix the two together. Keep the library handling for libsleef. Move the march setting to where it belongs. And rename the files, functions and variables after this. > > OK, I see. It makes sense that the suffix name should be choosed mainly based on the real module name that is searched/checked in configure. This still needs fixing. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16234#discussion_r1403428592 From isipka at openjdk.org Thu Nov 23 14:36:14 2023 From: isipka at openjdk.org (Ivan =?UTF-8?B?xaBpcGth?=) Date: Thu, 23 Nov 2023 14:36:14 GMT Subject: RFR: 8320665: update jdk_core at test/jdk/TEST.groups Message-ID: @bwhuang-us @mahendrachhipa ------------- Commit messages: - 8320665: update jdk_core at test/jdk/TEST.groups - 8316121: JDK22 ATR tasks job definition updates Changes: https://git.openjdk.org/jdk/pull/16796/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16796&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8320665 Stats: 16 lines in 1 file changed: 9 ins; 3 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/16796.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16796/head:pull/16796 PR: https://git.openjdk.org/jdk/pull/16796 From jlaskey at openjdk.org Thu Nov 23 14:45:51 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Thu, 23 Nov 2023 14:45:51 GMT Subject: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v33] In-Reply-To: References: Message-ID: > Address changes from JEP 445 to JEP 463. > > - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. > > - Don't mark class on read. > > - Remove reflection and annotation processing related to unnamed classes. > > - Simplify main method search. Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: Move findMainMethod to non-public access ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16461/files - new: https://git.openjdk.org/jdk/pull/16461/files/222e3346..420f6b42 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16461&range=32 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16461&range=31-32 Stats: 155 lines in 6 files changed: 77 ins; 72 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/16461.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16461/head:pull/16461 PR: https://git.openjdk.org/jdk/pull/16461 From aph at openjdk.org Thu Nov 23 15:46:16 2023 From: aph at openjdk.org (Andrew Haley) Date: Thu, 23 Nov 2023 15:46:16 GMT Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations with SLEEF [v4] In-Reply-To: <3dscjw75an6_n3ko_2LjHdpdj08xsyjhfpStuZrS5-M=.f43592fe-036e-47b5-babc-67f126885839@github.com> References: <3dscjw75an6_n3ko_2LjHdpdj08xsyjhfpStuZrS5-M=.f43592fe-036e-47b5-babc-67f126885839@github.com> Message-ID: On Thu, 23 Nov 2023 08:57:23 GMT, Xiaohong Gong wrote: >> Currently the vector floating-point math APIs like `VectorOperators.SIN/COS/TAN...` are not intrinsified on AArch64 platform, which causes large performance gap on AArch64. Note that those APIs are optimized by C2 compiler on X86 platforms by calling Intel's SVML code [1]. To close the gap, we would like to optimize these APIs for AArch64 by calling a third-party vector library called libsleef [2], which are available in mainstream Linux distros (e.g. [3] [4]). >> >> SLEEF supports multiple accuracies. To match Vector API's requirement and implement the math ops on AArch64, we 1) call 1.0 ULP accuracy with FMA instructions used stubs in libsleef for most of the operations by default, and 2) add the vector calling convention to apply with the runtime calls to stub code in libsleef. Note that for those APIs that libsleef does not support 1.0 ULP, we choose 0.5 ULP instead. >> >> To help loading the expected libsleef library, this patch also adds an experimental JVM option (i.e. `-XX:UseSleefLib`) for AArch64 platforms. People can use it to denote the libsleef path/name explicitly. By default, it points to the system installed library. If the library does not exist or the dynamic loading of it in runtime fails, the math vector ops will fall-back to use the default scalar version without error. But a warning is printed out if people specifies a nonexistent library explicitly. >> >> Note that this is a part of the original proposed patch in panama-dev [5], just with some initial review comments addressed. And now we'd like to get some wider feedbacks from more hotspot experts. >> >> [1] https://github.com/openjdk/jdk/pull/3638 >> [2] https://sleef.org/ >> [3] https://packages.fedoraproject.org/pkgs/sleef/sleef/ >> [4] https://packages.debian.org/bookworm/libsleef3 >> [5] https://mail.openjdk.org/pipermail/panama-dev/2022-December/018172.html > > Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision: > > Address review comments in build system make/autoconf/lib-vmath.m4 line 94: > 92: # Check the ARM SVE feature > 93: SVE_CFLAGS="-march=armv8-a+sve" > 94: What's this about? We're building a standard binary, and all SVE detection is to be deferred to runtime. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16234#discussion_r1403541835 From aph at openjdk.org Thu Nov 23 15:50:13 2023 From: aph at openjdk.org (Andrew Haley) Date: Thu, 23 Nov 2023 15:50:13 GMT Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations with SLEEF [v4] In-Reply-To: <3dscjw75an6_n3ko_2LjHdpdj08xsyjhfpStuZrS5-M=.f43592fe-036e-47b5-babc-67f126885839@github.com> References: <3dscjw75an6_n3ko_2LjHdpdj08xsyjhfpStuZrS5-M=.f43592fe-036e-47b5-babc-67f126885839@github.com> Message-ID: <7iScaIdG-XOySGAiFk7hOKkzdf8fDUosIP2NIfWy04g=.c5194b4f-0018-431f-8559-89ef72f104f2@github.com> On Thu, 23 Nov 2023 08:57:23 GMT, Xiaohong Gong wrote: >> Currently the vector floating-point math APIs like `VectorOperators.SIN/COS/TAN...` are not intrinsified on AArch64 platform, which causes large performance gap on AArch64. Note that those APIs are optimized by C2 compiler on X86 platforms by calling Intel's SVML code [1]. To close the gap, we would like to optimize these APIs for AArch64 by calling a third-party vector library called libsleef [2], which are available in mainstream Linux distros (e.g. [3] [4]). >> >> SLEEF supports multiple accuracies. To match Vector API's requirement and implement the math ops on AArch64, we 1) call 1.0 ULP accuracy with FMA instructions used stubs in libsleef for most of the operations by default, and 2) add the vector calling convention to apply with the runtime calls to stub code in libsleef. Note that for those APIs that libsleef does not support 1.0 ULP, we choose 0.5 ULP instead. >> >> To help loading the expected libsleef library, this patch also adds an experimental JVM option (i.e. `-XX:UseSleefLib`) for AArch64 platforms. People can use it to denote the libsleef path/name explicitly. By default, it points to the system installed library. If the library does not exist or the dynamic loading of it in runtime fails, the math vector ops will fall-back to use the default scalar version without error. But a warning is printed out if people specifies a nonexistent library explicitly. >> >> Note that this is a part of the original proposed patch in panama-dev [5], just with some initial review comments addressed. And now we'd like to get some wider feedbacks from more hotspot experts. >> >> [1] https://github.com/openjdk/jdk/pull/3638 >> [2] https://sleef.org/ >> [3] https://packages.fedoraproject.org/pkgs/sleef/sleef/ >> [4] https://packages.debian.org/bookworm/libsleef3 >> [5] https://mail.openjdk.org/pipermail/panama-dev/2022-December/018172.html > > Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision: > > Address review comments in build system src/jdk.incubator.vector/linux/native/libvmath/vect_math.c line 63: > 61: DEFINE_VECTOR_MATH_UNARY(expm1d2_u10, float64x2_t, advsimd) > 62: > 63: #ifdef __ARM_FEATURE_SVE No, we're building a standard binary that will use SVE if it's present on the machine it's running on. Such compile-time feature tests are inappropriate. You need to provide SVE entry points for the target machine, no matter how HotSpot is configured and built. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16234#discussion_r1403545717 From jlaskey at openjdk.org Thu Nov 23 15:55:42 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Thu, 23 Nov 2023 15:55:42 GMT Subject: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v34] In-Reply-To: References: Message-ID: > Address changes from JEP 445 to JEP 463. > > - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. > > - Don't mark class on read. > > - Remove reflection and annotation processing related to unnamed classes. > > - Simplify main method search. Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: Remove Test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16461/files - new: https://git.openjdk.org/jdk/pull/16461/files/420f6b42..690dac1d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16461&range=33 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16461&range=32-33 Stats: 131 lines in 1 file changed: 0 ins; 131 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/16461.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16461/head:pull/16461 PR: https://git.openjdk.org/jdk/pull/16461 From eosterlund at openjdk.org Thu Nov 23 16:23:20 2023 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Thu, 23 Nov 2023 16:23:20 GMT Subject: RFR: 8310644: Make panama memory segment close use async handshakes [v2] In-Reply-To: References: Message-ID: <-sZTbRUmxI9N4jDw8UsOwqwXk429wUxBvgVr_NVtd7g=.af4df37c-4dfd-4942-8d5b-150b8c91455f@github.com> > The current logic for closing memory in panama today is susceptible to live lock if we have a closing thread that wants to close the memory in a loop that keeps failing, and a bunch of accessing threads that want to perform accesses as long as the memory is alive. They can both create impediments for the other. > > By using asynchronous handshakes to install an exception onto threads that are in @Scoped memory accesses, we can have close always succeed, and the accessing threads bail out. The idea is that we perform a synchronous handshake first to find threads that are in scoped methods. They might however be in the middle of throwing an exception or something wild like there, where an exception can't be delivered. We install an async handshake that will roll us forward to the first place where we can indeed install exceptions, then we reevaluate if we still need to do that, or if we have unwound out from the scoped method. If we are still inside of it, we ensure an exception is installed so we don't continue executing bytecodes that might access the memory that we have freed. > > Tested tier 1-5 as well as running test/jdk/java/foreign/TestHandshake.java hundreds of times, which tests this API pretty well. Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision: Update test/jdk/java/foreign/TestHandshake.java Co-authored-by: Jorn Vernee ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16792/files - new: https://git.openjdk.org/jdk/pull/16792/files/aac442ae..d12fa908 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16792&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16792&range=00-01 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/16792.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16792/head:pull/16792 PR: https://git.openjdk.org/jdk/pull/16792 From eosterlund at openjdk.org Thu Nov 23 16:37:19 2023 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Thu, 23 Nov 2023 16:37:19 GMT Subject: RFR: 8310644: Make panama memory segment close use async handshakes [v3] In-Reply-To: References: Message-ID: > The current logic for closing memory in panama today is susceptible to live lock if we have a closing thread that wants to close the memory in a loop that keeps failing, and a bunch of accessing threads that want to perform accesses as long as the memory is alive. They can both create impediments for the other. > > By using asynchronous handshakes to install an exception onto threads that are in @Scoped memory accesses, we can have close always succeed, and the accessing threads bail out. The idea is that we perform a synchronous handshake first to find threads that are in scoped methods. They might however be in the middle of throwing an exception or something wild like there, where an exception can't be delivered. We install an async handshake that will roll us forward to the first place where we can indeed install exceptions, then we reevaluate if we still need to do that, or if we have unwound out from the scoped method. If we are still inside of it, we ensure an exception is installed so we don't continue executing bytecodes that might access the memory that we have freed. > > Tested tier 1-5 as well as running test/jdk/java/foreign/TestHandshake.java hundreds of times, which tests this API pretty well. Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision: Comments from Jorn ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16792/files - new: https://git.openjdk.org/jdk/pull/16792/files/d12fa908..5d34ddba Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16792&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16792&range=01-02 Stats: 47 lines in 4 files changed: 0 ins; 39 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/16792.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16792/head:pull/16792 PR: https://git.openjdk.org/jdk/pull/16792 From jvernee at openjdk.org Thu Nov 23 16:37:19 2023 From: jvernee at openjdk.org (Jorn Vernee) Date: Thu, 23 Nov 2023 16:37:19 GMT Subject: RFR: 8310644: Make panama memory segment close use async handshakes [v3] In-Reply-To: References: Message-ID: On Thu, 23 Nov 2023 16:34:23 GMT, Erik ?sterlund wrote: >> The current logic for closing memory in panama today is susceptible to live lock if we have a closing thread that wants to close the memory in a loop that keeps failing, and a bunch of accessing threads that want to perform accesses as long as the memory is alive. They can both create impediments for the other. >> >> By using asynchronous handshakes to install an exception onto threads that are in @Scoped memory accesses, we can have close always succeed, and the accessing threads bail out. The idea is that we perform a synchronous handshake first to find threads that are in scoped methods. They might however be in the middle of throwing an exception or something wild like there, where an exception can't be delivered. We install an async handshake that will roll us forward to the first place where we can indeed install exceptions, then we reevaluate if we still need to do that, or if we have unwound out from the scoped method. If we are still inside of it, we ensure an exception is installed so we don't continue executing bytecodes that might access the memory that we have freed. >> >> Tested tier 1-5 as well as running test/jdk/java/foreign/TestHandshake.java hundreds of times, which tests this API pretty well. > > Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision: > > Comments from Jorn LGTM ------------- Marked as reviewed by jvernee (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16792#pullrequestreview-1746784992 From eosterlund at openjdk.org Thu Nov 23 16:37:21 2023 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Thu, 23 Nov 2023 16:37:21 GMT Subject: RFR: 8310644: Make panama memory segment close use async handshakes [v2] In-Reply-To: <-sZTbRUmxI9N4jDw8UsOwqwXk429wUxBvgVr_NVtd7g=.af4df37c-4dfd-4942-8d5b-150b8c91455f@github.com> References: <-sZTbRUmxI9N4jDw8UsOwqwXk429wUxBvgVr_NVtd7g=.af4df37c-4dfd-4942-8d5b-150b8c91455f@github.com> Message-ID: On Thu, 23 Nov 2023 16:23:20 GMT, Erik ?sterlund wrote: >> The current logic for closing memory in panama today is susceptible to live lock if we have a closing thread that wants to close the memory in a loop that keeps failing, and a bunch of accessing threads that want to perform accesses as long as the memory is alive. They can both create impediments for the other. >> >> By using asynchronous handshakes to install an exception onto threads that are in @Scoped memory accesses, we can have close always succeed, and the accessing threads bail out. The idea is that we perform a synchronous handshake first to find threads that are in scoped methods. They might however be in the middle of throwing an exception or something wild like there, where an exception can't be delivered. We install an async handshake that will roll us forward to the first place where we can indeed install exceptions, then we reevaluate if we still need to do that, or if we have unwound out from the scoped method. If we are still inside of it, we ensure an exception is installed so we don't continue executing bytecodes that might access the memory that we have freed. >> >> Tested tier 1-5 as well as running test/jdk/java/foreign/TestHandshake.java hundreds of times, which tests this API pretty well. > > Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision: > > Update test/jdk/java/foreign/TestHandshake.java > > Co-authored-by: Jorn Vernee Thanks for the review @JornVernee! I applied the changes you wanted I think. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16792#issuecomment-1824698160 From asemenyuk at openjdk.org Thu Nov 23 16:47:29 2023 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Thu, 23 Nov 2023 16:47:29 GMT Subject: RFR: 8301856: Generated .spec file for RPM installers uninstalls desktop launcher on update In-Reply-To: References: Message-ID: On Thu, 23 Nov 2023 16:36:28 GMT, Alexey Semenyuk wrote: > Fix uninstallation scripts in Linux installers to take action on desktop files only if these desktop files are not owned by another package. This prevents `xdg-mime uninstall`, `xdg-desktop-menu uninstall` commands from execution in case of upgrades. > > Borrowed helper shell script function from "launchers as services" for the fix. Now on Linux there is shared code between "launchers as services" and "desktop integration" subsystems - "common_utils.sh". Added `ServiceAndDesktopTest.java` to test how they align. src/jdk.jpackage/linux/classes/jdk/jpackage/internal/resources/desktop_utils.sh line 1: > 1: # Added `desktop_` prefix for all desktop integration functions src/jdk.jpackage/linux/classes/jdk/jpackage/internal/resources/template.spec line 88: > 86: COMMON_SCRIPTS > 87: LAUNCHER_AS_SERVICE_SCRIPTS > 88: if [ "$1" -gt 1 ]; then The condition changed to comply with recommendations at https://docs.fedoraproject.org/en-US/packaging-guidelines/Scriptlets/#_syntax. 'true' replaced with "nop" (`:`) src/jdk.jpackage/unix/classes/jdk/jpackage/internal/UnixLaunchersAsServices.java line 94: > 92: } catch (IOException ex) { > 93: throw new RuntimeException(ex); > 94: } Redundant try/catch removed test/jdk/tools/jpackage/helpers/jdk/jpackage/test/LauncherAsServiceVerifier.java line 289: > 287: throw ex; > 288: } > 289: } Fixed an issue that made it impossible to run tests for the "launcher as service" feature without starting jtreg under `sudo`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16800#discussion_r1403590951 PR Review Comment: https://git.openjdk.org/jdk/pull/16800#discussion_r1403593932 PR Review Comment: https://git.openjdk.org/jdk/pull/16800#discussion_r1403594531 PR Review Comment: https://git.openjdk.org/jdk/pull/16800#discussion_r1403596448 From asemenyuk at openjdk.org Thu Nov 23 16:47:26 2023 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Thu, 23 Nov 2023 16:47:26 GMT Subject: RFR: 8301856: Generated .spec file for RPM installers uninstalls desktop launcher on update Message-ID: Fix uninstallation scripts in Linux installers to take action on desktop files only if these desktop files are not owned by another package. This prevents `xdg-mime uninstall`, `xdg-desktop-menu uninstall` commands from execution in case of upgrades. Borrowed helper shell script function from "launchers as services" for the fix. Now on Linux there is shared code between "launchers as services" and "desktop integration" subsystems - "common_utils.sh". Added `ServiceAndDesktopTest.java` to test how they align. ------------- Commit messages: - 8301856: Generated .spec file for RPM installers uninstalls desktop launcher on update Changes: https://git.openjdk.org/jdk/pull/16800/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16800&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8301856 Stats: 407 lines in 16 files changed: 333 ins; 30 del; 44 mod Patch: https://git.openjdk.org/jdk/pull/16800.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16800/head:pull/16800 PR: https://git.openjdk.org/jdk/pull/16800 From dfuchs at openjdk.org Thu Nov 23 17:17:03 2023 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Thu, 23 Nov 2023 17:17:03 GMT Subject: RFR: 8316649: JMX connection timeout cannot be changed and uses the default of 0 (infinite) In-Reply-To: References: Message-ID: <6R7B_a7VdF5Fg8B38rMhx0Fe1WT53KQw0yt596rzmS4=.9902a48f-f143-4d81-8940-d9c273e94812@github.com> On Thu, 23 Nov 2023 12:43:33 GMT, Kevin Walls wrote: >>> An exception here will prevent the class from being initialized... >> >> Maybe we can break it, but this new property is following the same pattern I think as the neighbouring file src/java.rmi/share/classes/sun/rmi/transport/tcp/TCPChannel.java when it reads the system props. I see Integer.getInteger handles the obvious Exceptions, so specifying a strange value does not immediately break us. >> >> If there's more protection needed then we have various other places to apply it that might need separate follow-up if you think there's a case? > >> IIRC, the default agent uses / may use its own socket factories - are we still coming here even with those factories? > > We do get here, yes (not saying you can't customise your way out of getting here). This is a stack from a test I was experimenting with, when it did see the timeout: > > > ---------System.out:(4/132)---------- > JMX URL = service:jmx:rmi://x > expectTimeout = true > sun.rmi.transport.tcp.initialConnectTimeout = 1 > Test passed > ----------System.err:(24/1791)---------- > java.rmi.ConnectIOException: Exception creating connection to: x.x.x.x; nested exception is: > java.net.SocketTimeoutException > at java.rmi/sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:637) > at java.rmi/sun.rmi.transport.tcp.TCPChannel.createConnection(TCPChannel.java:217) > at java.rmi/sun.rmi.transport.tcp.TCPChannel.newConnection(TCPChannel.java:204) > at java.rmi/sun.rmi.server.UnicastRef.invoke(UnicastRef.java:134) > at java.management.rmi/javax.management.remote.rmi.RMIServerImpl_Stub.newClient(RMIServerImpl_Stub.java:85) > at java.management.rmi/javax.management.remote.rmi.RMIConnector.getConnection(RMIConnector.java:2106) > at java.management.rmi/javax.management.remote.rmi.RMIConnector.connect(RMIConnector.java:321) > at java.management/javax.management.remote.JMXConnectorFactory.connect(JMXConnectorFactory.java:270) > at java.management/javax.management.remote.JMXConnectorFactory.connect(JMXConnectorFactory.java:229) > at RMIConnectionTimeoutTest.main(RMIConnectionTimeoutTest.java:65) > 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) > Caused by: java.net.SocketTimeoutException > at java.base/java.net.SocksSocketImpl.remainingMillis(SocksSocketImpl.java:112) > at java.base/java.net.SocksSocketImpl.connect(SocksSocketImpl.java:327) > at java.base/java.net.Socket.connect(Socket.java:752) > at java.rmi/sun.rmi.transport.tcp.TCPDirectSocketFactory.createSocket(TCPDirectSocketFactory.java:57) > at java.rmi/sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:619) > ... 13 more > STATUS:Passed. > I see Integer.getInteger handles the obvious Exceptions, so specifying a strange value does not immediately break us. Oh - right. It's `Integer.getInteger`, not `Integer.parseInt` Ok, then - I withdraw my first comment :-) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16771#discussion_r1403618437 From dfuchs at openjdk.org Thu Nov 23 17:20:05 2023 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Thu, 23 Nov 2023 17:20:05 GMT Subject: RFR: 8316649: JMX connection timeout cannot be changed and uses the default of 0 (infinite) In-Reply-To: <6R7B_a7VdF5Fg8B38rMhx0Fe1WT53KQw0yt596rzmS4=.9902a48f-f143-4d81-8940-d9c273e94812@github.com> References: <6R7B_a7VdF5Fg8B38rMhx0Fe1WT53KQw0yt596rzmS4=.9902a48f-f143-4d81-8940-d9c273e94812@github.com> Message-ID: On Thu, 23 Nov 2023 17:14:52 GMT, Daniel Fuchs wrote: >>> IIRC, the default agent uses / may use its own socket factories - are we still coming here even with those factories? >> >> We do get here, yes (not saying you can't customise your way out of getting here). This is a stack from a test I was experimenting with, when it did see the timeout: >> >> >> ---------System.out:(4/132)---------- >> JMX URL = service:jmx:rmi://x >> expectTimeout = true >> sun.rmi.transport.tcp.initialConnectTimeout = 1 >> Test passed >> ----------System.err:(24/1791)---------- >> java.rmi.ConnectIOException: Exception creating connection to: x.x.x.x; nested exception is: >> java.net.SocketTimeoutException >> at java.rmi/sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:637) >> at java.rmi/sun.rmi.transport.tcp.TCPChannel.createConnection(TCPChannel.java:217) >> at java.rmi/sun.rmi.transport.tcp.TCPChannel.newConnection(TCPChannel.java:204) >> at java.rmi/sun.rmi.server.UnicastRef.invoke(UnicastRef.java:134) >> at java.management.rmi/javax.management.remote.rmi.RMIServerImpl_Stub.newClient(RMIServerImpl_Stub.java:85) >> at java.management.rmi/javax.management.remote.rmi.RMIConnector.getConnection(RMIConnector.java:2106) >> at java.management.rmi/javax.management.remote.rmi.RMIConnector.connect(RMIConnector.java:321) >> at java.management/javax.management.remote.JMXConnectorFactory.connect(JMXConnectorFactory.java:270) >> at java.management/javax.management.remote.JMXConnectorFactory.connect(JMXConnectorFactory.java:229) >> at RMIConnectionTimeoutTest.main(RMIConnectionTimeoutTest.java:65) >> 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) >> Caused by: java.net.SocketTimeoutException >> at java.base/java.net.SocksSocketImpl.remainingMillis(SocksSocketImpl.java:112) >> at java.base/java.net.SocksSocketImpl.connect(SocksSocketImpl.java:327) >> at java.base/java.net.Socket.connect(Socket.java:752) >> at java.rmi/sun.rmi.transport.tcp.TCPDirectSocketFactory.createSocket(TCPDirectSocketFactory.java:57) >> at java.rmi/sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:619) >> ... 13 more >> STATUS:Passed. > >> I see Integer.getInteger handles the obvious Exceptions, so specifying a strange value does not immediately break us. > > Oh - right. It's `Integer.getInteger`, not `Integer.parseInt` Ok, then - I withdraw my first comment :-) > This is a stack from a test I was experimenting with, when it did see the timeout: Ah - that's for testing with a particular test. So the question now is: Should the RMISocketFactories provided / implemented in the JMX implementation - such as those used by the JMX default agent, also honour this system property? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16771#discussion_r1403620057 From dfuchs at openjdk.org Thu Nov 23 17:24:03 2023 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Thu, 23 Nov 2023 17:24:03 GMT Subject: RFR: 8316649: JMX connection timeout cannot be changed and uses the default of 0 (infinite) In-Reply-To: References: <6R7B_a7VdF5Fg8B38rMhx0Fe1WT53KQw0yt596rzmS4=.9902a48f-f143-4d81-8940-d9c273e94812@github.com> Message-ID: On Thu, 23 Nov 2023 17:17:34 GMT, Daniel Fuchs wrote: >>> I see Integer.getInteger handles the obvious Exceptions, so specifying a strange value does not immediately break us. >> >> Oh - right. It's `Integer.getInteger`, not `Integer.parseInt` Ok, then - I withdraw my first comment :-) > >> This is a stack from a test I was experimenting with, when it did see the timeout: > > Ah - that's for testing with a particular test. So the question now is: > > Should the RMISocketFactories provided / implemented in the JMX implementation - such as those used by the JMX default agent, also honour this system property? (Look for socket factories in the module `jdk.management.agent`) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16771#discussion_r1403622189 From aivanov at openjdk.org Thu Nov 23 17:27:17 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 23 Nov 2023 17:27:17 GMT Subject: RFR: 8320608: Many jtreg printing tests are missing the @printer keyword In-Reply-To: References: Message-ID: <-89UjGPFJWRn0hJIyT5n2YLJKNCyaSeDPjOgw3dmZrw=.613b5081-039a-42cc-8b8c-f48fc91b9abd@github.com> On Wed, 22 Nov 2023 19:26:40 GMT, Phil Race wrote: > Many printing tests do not have the @printer keyword. This adds them to those that need it. > I also found one test that has nothing to do with printing in the print folder and moved it out. Changes requested by aivanov (Reviewer). test/jdk/java/awt/PrintJob/EdgeTest/EdgeTest.java line 30: > 28: * @summary Verifies that (0, 0) is the upper-left corner of the page, not > 29: * the upper-left corner adjusted for the margins. > 30: * @author dpm Suggestion: Perhaps, remove the `@author` tag here too. test/jdk/java/awt/PrintJob/RoundedRectTest/RoundedRectTest.java line 29: > 27: * @bug 4061440 > 28: * @summary Checks that rounded rectangles print correctly. > 29: * @author dpm Suggestion: test/jdk/java/awt/print/PageFormat/SetOrient.java line 28: > 26: * @summary Confirm that the clip and transform of the Graphics2D is > 27: * affected by the landscape orientation of the PageFormat. > 28: */ Since this test calls `pjob.print();`, it requires a printer. Indeed, it fails without a printer: runner starting test: java/awt/print/PageFormat/SetOrient.html runner finished test: java/awt/print/PageFormat/SetOrient.html Failed. Execution failed: Applet thread threw exception: java.lang.RuntimeException: No print service found. Test results: failed: 1 test/jdk/java/awt/print/PageFormat/SmallPaperPrinting.java line 30: > 28: > 29: import java.awt.*; > 30: import java.awt.print.*; Could you expand the wildcard imports, please? I would appreciate if you would add the jtreg tags *after* the imports. test/jdk/java/awt/print/PageFormat/SmallPaperPrinting.java line 35: > 33: { > 34: public static void main(String args[]) > 35: { Suggestion: public class SmallPaperPrinting { public static void main(String[] args) { Since you're reformatting the test source, it's better to follow the Java code style? throughout the entire source file. test/jdk/java/awt/print/PageFormat/SmallPaperPrinting.java line 42: > 40: System.out.println("A passing test should catch a PrinterException"); > 41: System.out.println("and should display \"Print error: (exception msg)\"."); > 42: System.out.println("---------------------------------------------------\n"); According to these instructions, the test is to contain a set of `@test` tags: /* * @test * @key printer * @run main/othervm SmallPaperPrinting */ /* * @test * @key printer * @run main/othervm SmallPaperPrinting 1 */ /* * @test * @key printer * @run main/othervm SmallPaperPrinting 2 */ Otherwise, it won't run all the cases and no one will ever see these instructions. For me, the test with the added `@test` tags as above prints an error message in the first two cases: # id0.jtr Print error: Paper's imageable height is too small. # id1.jtr Print error: Paper's imageable width is too small. Yet it does not print any error message in the third case where `width=-1`, and **it does not fail**. If I run it on a system without a printer, the test also *passes successfully*. Perhaps, we can ignore it as the `@key printer` ensures there's a printer the system. Having said the above, this test requires its own bug to fix the test. test/jdk/java/awt/print/PageFormat/WrongPaperPrintingTest.java line 29: > 27: @key printer > 28: @run main/manual WrongPaperPrintingTest > 29: */ It's minor but still, in majority of tests, the `@key` tag follows the `@bug` tag, and you mostly follow the convention in this PR. Keeping the order consistent helps scanning the test description with eyes quickly. test/jdk/java/awt/print/PrinterJob/EmptyFill.java line 30: > 28: * @key printer > 29: * @run main EmptyFill > 30: */ This test does not need a printer, it prints into a byte array and analyses the output. The test passes successfully on a system without a printer. test/jdk/java/awt/print/PrinterJob/GetUserNameTest.java line 26: > 24: * @test > 25: * @bug 6197099 > 26: * @key printer The test works correctly without a printer, it prints the expected message: SecurityException thrown as user.name permission not given No other exceptions are thrown but the warnings that `SecurityManager` is deprecated. test/jdk/java/awt/print/PrinterJob/MultiMonPrintDlgTest.java line 40: > 38: * @test > 39: * @bug 8138749 > 40: * @key printer Suggestion: * @key printer multimon The test requires two monitors. test/jdk/java/awt/print/PrinterJob/PrintAllFonts.java line 26: > 24: /** > 25: * > 26: * @bug 4884389 7183516 Is it intentional that there's no `@test` tag? test/jdk/java/awt/print/PrinterJob/PrintTranslatedFont.java line 29: > 27: * @key printer > 28: * @summary Test that fonts with a translation print where they should. > 29: * @author prr Suggestion: test/jdk/java/awt/print/PrinterJob/PrinterDevice.java line 31: > 29: * @key printer > 30: * @run main/othervm PrinterDevice > 31: */ There's no `@test` tag, is it intentional? Probably, you should remove this test from this PR because you're modifying in #16773. test/jdk/java/awt/print/PrinterJob/PrinterDialogsModalityTest/PrinterDialogsModalityTest.html line 30: > 28: @key printer > 29: @summary check whether Print- and Page- dialogs are modal and correct window activated after their closing > 30: @author Your Name: area=PrinterJob.modality Suggestion: test/jdk/java/awt/print/PrinterJob/RemoveListener.java line 25: > 23: > 24: /* > 25: * @test 1.1 01/05/17 Suggestion: * @test ------------- PR Review: https://git.openjdk.org/jdk/pull/16785#pullrequestreview-1746215963 PR Review Comment: https://git.openjdk.org/jdk/pull/16785#discussion_r1403233563 PR Review Comment: https://git.openjdk.org/jdk/pull/16785#discussion_r1403232953 PR Review Comment: https://git.openjdk.org/jdk/pull/16785#discussion_r1403250610 PR Review Comment: https://git.openjdk.org/jdk/pull/16785#discussion_r1403257236 PR Review Comment: https://git.openjdk.org/jdk/pull/16785#discussion_r1403254342 PR Review Comment: https://git.openjdk.org/jdk/pull/16785#discussion_r1403283083 PR Review Comment: https://git.openjdk.org/jdk/pull/16785#discussion_r1403301368 PR Review Comment: https://git.openjdk.org/jdk/pull/16785#discussion_r1403332726 PR Review Comment: https://git.openjdk.org/jdk/pull/16785#discussion_r1403341309 PR Review Comment: https://git.openjdk.org/jdk/pull/16785#discussion_r1403576760 PR Review Comment: https://git.openjdk.org/jdk/pull/16785#discussion_r1403595968 PR Review Comment: https://git.openjdk.org/jdk/pull/16785#discussion_r1403608444 PR Review Comment: https://git.openjdk.org/jdk/pull/16785#discussion_r1403613621 PR Review Comment: https://git.openjdk.org/jdk/pull/16785#discussion_r1403613833 PR Review Comment: https://git.openjdk.org/jdk/pull/16785#discussion_r1403616874 From sgehwolf at openjdk.org Thu Nov 23 18:02:41 2023 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Thu, 23 Nov 2023 18:02:41 GMT Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged modules being present [v9] In-Reply-To: References: Message-ID: > Please review this patch which adds a "jmodless" jlink mode to the JDK. Fundamentally this patch adds an option to use `jlink` even though your JDK install might not come with the packaged modules (directory `jmods`). This is particularly useful to further reduce the size of a jlinked runtime. After the removal of the concept of a JRE, a common distribution mechanism is still the full JDK with all modules and packaged modules. However, packaged modules can incur an additional size tax. For example in a container scenario it could be useful to have a base JDK container including all modules, but without also delivering the packaged modules. This comes at a size advantage of `~25%`. Such a base JDK container could then be used to `jlink` application specific runtimes, further reducing the size of the application runtime image (App + JDK runtime; as a single image *or* separate bundles, depending on the app being modularized). > > The basic design of this approach is to add a jlink plugin for tracking non-class and non-resource files of a JDK install. I.e. files which aren't present in the jimage (`lib/modules`). This enables producing a `JmodLessArchive` class which has all the info of what constitutes the final jlinked runtime. > > Basic usage example: > > $ diff -u <(./bin/java --list-modules --limit-modules java.se) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules java.se) > $ diff -u <(./bin/java --list-modules --limit-modules java.se) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules jdk.jlink) > $ ls ../linux-x86_64-server-release/images/jdk/jmods > java.base.jmod java.net.http.jmod java.sql.rowset.jmod jdk.crypto.ec.jmod jdk.internal.opt.jmod jdk.jdi.jmod jdk.management.agent.jmod jdk.security.auth.jmod > java.compiler.jmod java.prefs.jmod java.transaction.xa.jmod jdk.dynalink.jmod jdk.internal.vm.ci.jmod jdk.jdwp.agent.jmod jdk.management.jfr.jmod jdk.security.jgss.jmod > java.datatransfer.jmod java.rmi.jmod java.xml.crypto.jmod jdk.editpad.jmod jdk.internal.vm.compiler.jmod jdk.jfr.jmod jdk.management.jmod jdk.unsupported.desktop.jmod > java.desktop.jmod java.scripting.jmod java.xml.jmod jdk.hotspot.agent.jmod jdk.internal.vm.compiler.management.jmod jdk.jlink.jmod jdk.naming.dns.jmod jdk.unsupported... Severin Gehwolf has updated the pull request incrementally with 10 additional commits since the last revision: - Typo fix. - Add a proper test for generate-jli-classes in run-image based link mode - Fix corner case of system modules not consistently being enabled - Remove work-arounds for AddOptions and SaveJlinkArgfiles Plugins We now filter the resources in the run-time-image link mode. Similar to what we do for system-modules and generate-jli-classes plugins. - Fix SystemModulesPlugin in run-time link mode - Fix GenerateJLIClassesPlugin in run-time link mode - Update some comments - Mark --unlock-run-image as a hidden option - Fix some comments in GenerateJLIClassesPlugin - Use internal package name for run-image resources They are now in the jdk.jlink module and have prefix: /jdk.jlink/jdk/tools/jlink/internal/runlink_ For example for java.base, the resource file is: /jdk.jlink/jdk/tools/jlink/internal/runlink_java.base_resources ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14787/files - new: https://git.openjdk.org/jdk/pull/14787/files/ac01194c..3539c6a5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14787&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14787&range=07-08 Stats: 490 lines in 13 files changed: 327 ins; 111 del; 52 mod Patch: https://git.openjdk.org/jdk/pull/14787.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14787/head:pull/14787 PR: https://git.openjdk.org/jdk/pull/14787 From aivanov at openjdk.org Thu Nov 23 18:26:04 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 23 Nov 2023 18:26:04 GMT Subject: RFR: 8320608: Many jtreg printing tests are missing the @printer keyword In-Reply-To: <-89UjGPFJWRn0hJIyT5n2YLJKNCyaSeDPjOgw3dmZrw=.613b5081-039a-42cc-8b8c-f48fc91b9abd@github.com> References: <-89UjGPFJWRn0hJIyT5n2YLJKNCyaSeDPjOgw3dmZrw=.613b5081-039a-42cc-8b8c-f48fc91b9abd@github.com> Message-ID: On Thu, 23 Nov 2023 11:53:08 GMT, Alexey Ivanov wrote: > Having said the above, this test requires its own bug to fix the test. I submitted [JDK-8320671](https://bugs.openjdk.org/browse/JDK-8320671): PageFormat/SmallPaperPrinting.java needs three sets of @test tags ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16785#discussion_r1403654780 From sgehwolf at openjdk.org Thu Nov 23 18:30:07 2023 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Thu, 23 Nov 2023 18:30:07 GMT Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged modules being present [v8] In-Reply-To: <3DpzMArCkz5ehvgoid5DPvhy6SQmw9mkKzOBqj6vItU=.54099d82-259c-48ca-8c61-e7b783640ed8@github.com> References: <3DpzMArCkz5ehvgoid5DPvhy6SQmw9mkKzOBqj6vItU=.54099d82-259c-48ca-8c61-e7b783640ed8@github.com> Message-ID: On Thu, 16 Nov 2023 19:00:57 GMT, Mandy Chung wrote: > It'd be helpful if you write down your proposed behavior for each plugin for discussion. Otherwise, we will have to find out from the code. Here it goes. This was a *very* useful exercise and uncovered some bugs. Fundamentally, each plugin's `Category` is what I was looking at. Unique categories (for pre-existing plug-ins): -------------------------------- - FILTER - TRANSFORMER - ADDER - METADATA_ADDER - SORTER - PROCESSOR - COMPRESSOR SORTER, PROCESSOR and COMPRESSOR. Those plugins affect the final image only so they work the same as when using packaged modules. There is nothing to leak from a previous link as the output directory will contain a new JDK image. Note that classes.jsa and classes_nocoops.jsa are not part of the jmod files, nor are they classes or resources in the jimage. Thus, they are not tracked with `add-run-image-resources` and don't end up in the final JDK image when performing a run-time based link. ADDER, METADATA_ADDER plugins add files to the final jimage and/or JDK image ('release' file), which aren't there without those plugins. They get appropriately filtered at link time, so there isn't any oberservable difference. Exception: save-jlink-arg-file. The arg files are processed too early so they carry forward for the link, but not into the final image of that link. Therefore I've marked them as equivalent. FILTER, TRANSFORMER. Those change class files or native resources or exclude specific resources. Since those changes are then in effect in the resulting runtime image, and the link is performed from such an image, they carry over to the derived image. Certain transformers can be overridden by the final run-time image based link (e.g. vendor-version plugin). Filters remove things from the image, so those changes carry forward. Exceptions: system-modules and generate-jli-classes. Both behave the same as in packaged-modules case. For each individual plug-in the planned behaviour is in the "Current behaviour in run-time image link mode" column. Plugin name | Description | Current behaviour in run-time | Notes | | image link mode | ------------------------------------------------------------------------------------------------------------------------------------------------------------- add-options |Prepend the specified string, which may | Same as with packaged-modules. | Category: ADDER |include whitespace, before any other options when | /java.base/jdk/internal/vm/ | |invoking the virtual machine in the resulting | options file is being filtered.| |image. | | Adds a file in jimage: | | | /java.base/jdk/internal/vm/options ------------------------------------------------------------------------------------------------------------------------------------------------------------- compress |Compression to use in compressing resources: | Same as with packaged-modules | Category: COMPRESSOR |Accepted values are: | | |zip-[0-9], where zip-0 provides no compression, | | Combination of 'zip' |and zip-9 provides the best compression. | | and 'compact-cp' |Default is zip-6. | | ------------------------------------------------------------------------------------------------------------------------------------------------------------- dedup-legal-notices |De-duplicate all legal notices. | Accumulate with base run-time | |If error-if-not-same-content is specified then | image (if any). |Category: TRANSFORMER |it will be an error if two files of the same | | |filename are different. | | ------------------------------------------------------------------------------------------------------------------------------------------------------------- exclude-files | | Accumulate with base run-time | Category: FILTER | Specify files to exclude. | image (if any). | | e.g.: **.java,glob:/java.base/lib/client/** | | ------------------------------------------------------------------------------------------------------------------------------------------------------------- exclude-jmod-section | | Accumulate with base run-time | Category: FILTER |Specify a JMOD section to exclude. | image (if any). | |Where is "man" or "headers". | | Excludes resources of type man/header ------------------------------------------------------------------------------------------------------------------------------------------------------------- exclude-resources |Specify resources to exclude. | Accumulate with base run-time | Category: FILTER |e.g.: **.jcov,glob:**/META-INF/** | image (if any). | ------------------------------------------------------------------------------------------------------------------------------------------------------------- generate-cds-archive |Generate CDS archive if the runtime image supports | Same as with packaged-modules | Category: PROCESSOR |the CDS feature. | | Generates classes.jsa classes_nocoops.jsa | | | in $JAVA_HOME ------------------------------------------------------------------------------------------------------------------------------------------------------------- generate-jli-classes |Specify a file listing the java.lang.invoke | Same as with packaged-modules | Category: TRANSFORMER |classes to pre-generate. By default, this plugin | | |may use a builtin list of classes to pre-generate. | Potential existing BMH.Species | |If this plugin runs on a different runtime version | classes are filtered to match | Generates BoundMethodHandle$Species* |than the image being created then code generation | java.base jmod | classes. |will be disabled by default to guarantee | | |correctness add ignore-version=true | | |to override this. | | ------------------------------------------------------------------------------------------------------------------------------------------------------------- include-locales |BCP 47 language tags separated by a comma, | Accumulate with base run-time | Category: FILTER |allowing | image (if any). | |locale matching defined in RFC 4647. | | Filters specific locales in the target |e.g.: en,ja,*-IN | | image. ------------------------------------------------------------------------------------------------------------------------------------------------------------- order-resources |Order resources. | Same as with packaged-modules | Category: SORTER |e.g.: **/module-info.class, at classlist, | | |/java.base/java/lang/** | | ------------------------------------------------------------------------------------------------------------------------------------------------------------- release-info | option is to load release properties from | Same as with packaged-modules | Category: METAINFO_ADDER |the supplied file. | | |add: is to add properties to the release file. | | Adds a file 'release' to the final image |Any number of = pairs can be passed. | | in the top folder. Since that file is not |del: is to delete the list of keys in release file. | | in packaged modules nor in the jimage, | | | it doesn't get carried forward ------------------------------------------------------------------------------------------------------------------------------------------------------------- save-jlink-argfiles |Save the specified argument files that contain | If specified, options in an | Category: ADDER |the arguments to be prepended to the execution of | existing file are replaced by | |jlink in the output image. is a | the new options. Otherwise, | Adds a file to the jdk.jlink module, |: (; on Windows) separated list of command-line | options from the base image | /jdk.jlink/jdk/tools/jlink/internal/options |argument files. | affect the run, but don't | | | carry forward. | ------------------------------------------------------------------------------------------------------------------------------------------------------------- strip-debug |Strip debug information from the output image | Accumulate with base run-time | Category: TRANSFORMER | | image (if any). | 'strip-java-debug-attributes' and | | | 'strip-native-debug-symbols' combined ------------------------------------------------------------------------------------------------------------------------------------------------------------- strip-java-debug-attributes |Strip Java debug attributes from | Accumulate with base run-time | Category: TRANSFORMER |classes in the output image | image (if any). | ------------------------------------------------------------------------------------------------------------------------------------------------------------- strip-native-commands |Exclude native commands (such as java/java.exe) | Accumulate with base run-time | Category: FILTER |from the image. | image (if any). | ------------------------------------------------------------------------------------------------------------------------------------------------------------- strip-native-debug-symbols |Strip debug symbols from native libraries (if any). | Accumulate with base run-time | Category: TRANSFORMER |This plugin requires at least one option: | image (if any). | | objcopy: The path to the objcopy binary. | | | Defaults to objcopy in PATH. | | | exclude-debuginfo-files: Exclude debug info | | | files. Defaults to true. | | | keep-debuginfo-files[=]: Keep debug info | | | files in .. | | | Defaults to .debuginfo | | |Examples: --strip-native-debug-symbols | | | keep-debuginfo-files:objcopy=OBJPATH | | | --strip-native-debug-symbols | | | exclude-debuginfo-files | | ------------------------------------------------------------------------------------------------------------------------------------------------------------- system-modules |The batch size specifies the maximum number of | Same as with packaged modules. | Category: TRANSFORMER |modules be handled in one method to workaround if | | |the generated bytecode exceeds the method size | Generated classes get filtered | Changes SystemModulesMap.class and adds |limit. The default batch size is 75. | so they don't populate. | SystemModules${,all,default}.class ------------------------------------------------------------------------------------------------------------------------------------------------------------- vendor-bug-url |Override the vendor bug URL baked into the build. | Accumulate with base run-time | Category: TRANSFORMER |The value of the system property | image (if any). | |"java.vendor.url.bug" will be . | | ------------------------------------------------------------------------------------------------------------------------------------------------------------- vendor-version |Override the vendor version string baked into the | Accumulate with base run-time | Category: TRANSFORMER |build,if any. The value of the system property | image (if any). | |"java.vendor.version" will be . | | ------------------------------------------------------------------------------------------------------------------------------------------------------------- vendor-vm-bug-url |Override the vendor VM bug URL baked | Accumulate with base run-time | Category: TRANSFORMER |into the build. The URL displayed in VM error | image (if any). | |logs will be . | | ------------------------------------------------------------------------------------------------------------------------------------------------------------- vm |Select the HotSpot VM in the output image. | Accumulate with base run-time | Category: FILTER |Default is all | image (if any). | ------------------------------------------------------------------------------------------------------------------------------------------------------------- > Regarding the name of the `runimage_resources` file, this file is only used by jlink and so it can be a resource file in `jdk.jlink` module like `jdk.jlink/jdk/tools/jlink/internal/runtime/$MODULE_resources` (e.g. `jdk.jlink/jdk/tools/jlink/internal/runtime/java.base_resources`) That's a good observation. Thanks. I've modified the patch and CSR to mention that. Those resource files now live in `/jdk.jlink/jdk/tools/jlink/internal/runlink_$MODULE_resources`. The option `--unlock-run-image` to get equivalence between a link using packaged modules and run-time based link is now hidden (similar to `--keep-packaged-modules`). This is really advanced usage and doesn't need a prominent place in `jlink --help`. Other things of note: ------------------ `jlink` orders plugin's by their `Category`. So in general, the processing pipeline is: `FILTER->ADDER->TRANSFORMER->MODULEINFO_TRANSFORMER->SORTER->METAINFO_ADDER->COMPRESSOR->VERIFIER->PROCESSOR->PACKAGER`. In this updated patch I've used this info in order to re-establish the invariant of certain classes and resources not being in packaged modules. Things like `SystemModules$*.class` and `BMH$Species_*.class`. Those are now being filtered (using `exclude-resource`) prior it being processed by the `TRANSFORMER` or `ADDER` phases. Furthermore, it prevents those classes to populate if plug-ins that generated them aren't used. This also removes the need to actually modify any of the existing plugins. More thoughts? ------------- PR Comment: https://git.openjdk.org/jdk/pull/14787#issuecomment-1824804506 From duke at openjdk.org Thu Nov 23 19:58:10 2023 From: duke at openjdk.org (Vladimir Yaroslavskiy) Date: Thu, 23 Nov 2023 19:58:10 GMT Subject: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort) [v11] In-Reply-To: References: <918oCEfFu2JweXfV-afD1l_AGDDuc7dJwAxip-Ze6ZI=.8d5e9692-23db-47e4-9586-99e53b9cfbb6@github.com> <5VlrwO4ABJC1fPxj7Y0TAWV4izuo4dEl_fzSM1dPD4A=.83909050-fb10-40a8-8cdd-9cf67fca0724@github.com> Message-ID: <9LEgVtG1ZaFDlbr0oodR0rTM37OGY7waixXFy7dCOgI=.471b2b09-e473-46cd-ad48-285679aa7a04@github.com> On Fri, 17 Nov 2023 23:14:18 GMT, Srinivas Vamsi Parasa wrote: >> Hello Vamsi (@vamsi-parasa), >> >> Thank you very much for benchmarking, I appreciate your efforts! >> >> I looked at non-parallel sorting when radix sort is switched off (DualPivotQuicksort_RadixForParallel) and cannot explain the following data for STAGGER where all speedup < 1: >> testSort STAGGER 7000 0.92 >> testSort STAGGER 50000 0.84 >> testSort STAGGER 300000 0.85 >> testSort STAGGER 2000000 0.83 >> In these cases both versions go directly to merging sort: no quicksort, no insertion sort, no radix sort at all >> and therefore, no intrinsic also, Java code only,merging sort only. >> It is expected that benchmarking without AVX512 should be the same, >> but my benchmarking on Windows shows speedup 1.0 .. 1.10. >> >> Vamsi, >> Could you please run benchmarking with derived classes from jdk and my version? >> https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_a01.java >> https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_a02.java >> https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_r01.java >> II hope i allows us to detect the root of such behaviour. >> >> Please check sequential sorting only (parallel sort is out of scope now). >> I see you used not the latest ArraysSort, I pointed to https://github.com/iaroslavski/sorting/blob/master/radixsort/ArraysSort.java >> >> It is not critical, but it will be better to be in the same environment, see >> increased warmup, specified parameters for run and updated data sets >> @Warmup(iterations = 2, time = 3, timeUnit = TimeUnit.SECONDS) >> @Measurement(iterations = 4, time = 3, timeUnit = TimeUnit.SECONDS) >> @Fork(value=1, jvmArgsAppend={"-XX:CompileThreshold=1", "-XX:-TieredCompilation"}) >> >> Could you please spare some time and provide the performance data? > > Hello Vladimir (@iaroslavski), > > You're welcome! > Will provide the performance data (for the next set of experiments) within few days. > > Thanks, > Vamsi Hello Vamsi (@vamsi-parasa), Do you have the new results? ------------- PR Comment: https://git.openjdk.org/jdk/pull/13568#issuecomment-1824860775 From aivanov at openjdk.org Thu Nov 23 20:42:04 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 23 Nov 2023 20:42:04 GMT Subject: RFR: 8320608: Many jtreg printing tests are missing the @printer keyword In-Reply-To: <-89UjGPFJWRn0hJIyT5n2YLJKNCyaSeDPjOgw3dmZrw=.613b5081-039a-42cc-8b8c-f48fc91b9abd@github.com> References: <-89UjGPFJWRn0hJIyT5n2YLJKNCyaSeDPjOgw3dmZrw=.613b5081-039a-42cc-8b8c-f48fc91b9abd@github.com> Message-ID: <96ngNnlrygkt0Ni0W2xyr9STyYoQEALdDXtNu_jIQUg=.8969504d-ac54-4dc6-a271-08154523db94@github.com> On Thu, 23 Nov 2023 11:27:08 GMT, Alexey Ivanov wrote: >> Many printing tests do not have the @printer keyword. This adds them to those that need it. >> I also found one test that has nothing to do with printing in the print folder and moved it out. > > test/jdk/java/awt/print/PageFormat/SetOrient.java line 28: > >> 26: * @summary Confirm that the clip and transform of the Graphics2D is >> 27: * affected by the landscape orientation of the PageFormat. >> 28: */ > > Since this test calls `pjob.print();`, it requires a printer. Indeed, it fails without a printer: > > > runner starting test: java/awt/print/PageFormat/SetOrient.html > runner finished test: java/awt/print/PageFormat/SetOrient.html > Failed. Execution failed: Applet thread threw exception: > java.lang.RuntimeException: No print service found. > Test results: failed: 1 I see `SetOrient.java` has its sibling `SetOrient.html` where you added `@key printer`. Since both files contain all the tags except for `@test` in the .java file, you should not remove the `@run` tag from the .java file and add `@key printer` to it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16785#discussion_r1403712328 From aivanov at openjdk.org Thu Nov 23 21:24:05 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 23 Nov 2023 21:24:05 GMT Subject: RFR: 8320608: Many jtreg printing tests are missing the @printer keyword In-Reply-To: References: Message-ID: <8Z9CPTdY9H-cW3OOeiUbOTcx80o08oKXnJEk8_OHfDI=.c55d95af-05d2-4981-8271-25204c271feb@github.com> On Wed, 22 Nov 2023 19:26:40 GMT, Phil Race wrote: > Many printing tests do not have the @printer keyword. This adds them to those that need it. > I also found one test that has nothing to do with printing in the print folder and moved it out. test/jdk/java/awt/print/PrinterJob/PrintAllFonts.java line 29: > 27: * @key printer > 28: * @summary Font specified with face name loses style on printing > 29: * @run main/manual PrintRotatedText Is it intentional that this test presumably runs another test ? `PrintRotatedText` ? instead? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16785#discussion_r1403735222 From dholmes at openjdk.org Thu Nov 23 22:26:20 2023 From: dholmes at openjdk.org (David Holmes) Date: Thu, 23 Nov 2023 22:26:20 GMT Subject: RFR: 8318776: Require supports_cx8 to always be true [v7] In-Reply-To: References: Message-ID: On Thu, 23 Nov 2023 12:09:27 GMT, David Holmes wrote: >> As discussed in JBS all platforms (some tweaks to Zero are in progress) actually do support `cx8` i.e. 64-bit compare-and-exchange, so we can strip out the locked-based alternatives to using it and just add a guarantee that it is true at runtime. And all platforms except some ARM variants set `SUPPORTS_NATIVE_CX8`, so we can greatly simplify things. Summary of changes: >> - `_supports_cx8` field is only needed when `SUPPORTS_NATIVE_CX8` is not defined >> - Assertions for `supports_cx8()` are removed >> - Compiler predicates requiring `supports_cx8()` are removed >> - Access backend is greatly simplified without the need for lock-based alternative >> - `java.util.concurrent.AtomicLongFieldUpdater` is simplified without the need for a lock-based alternative >> >> I did consider moving all the ARM `kuser_helper` related code to be only defined when `SUPPORTS_NATIVE_CX8` is not defined, but there was a theoretical risk this could change the behaviour if ARMv7 binaries were run on other ARM CPU's. I added a note to that effect in vm_version_linux_arm32.cpp so the ARM port maintainers could clean this up further if desired. >> >> Testing: >> - All Oracle tiers 1-5 builds (which includes an ARMv7 build) >> - GHA builds/tests >> - Oracle tiers 1-3 sanity testing >> >> Zero changes coming in via [JDK-8319777](https://bugs.openjdk.org/browse/JDK-8319777) will be merged when they arrive. >> >> Thanks. > > David Holmes 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 > - Fix typo > - Merge with master and update Zero code accordingly > - Merge branch 'master' into 8318776-supports_cx8 > - Remove unnecessary includes of vm_version.hpp. > Fix copyright years. > - Remove cx8 comment as no longer relevant (the spinlock is used regardless of cx8) > - Remove suports_cx8() checks from gtest > - Remove test for VMSupportsCX8 > - 8318776: Require supports_cx8 to always be true Thanks for all the reviews. Integrating now. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16625#issuecomment-1824966904 From dholmes at openjdk.org Thu Nov 23 22:26:22 2023 From: dholmes at openjdk.org (David Holmes) Date: Thu, 23 Nov 2023 22:26:22 GMT Subject: Integrated: 8318776: Require supports_cx8 to always be true In-Reply-To: References: Message-ID: On Mon, 13 Nov 2023 04:38:35 GMT, David Holmes wrote: > As discussed in JBS all platforms (some tweaks to Zero are in progress) actually do support `cx8` i.e. 64-bit compare-and-exchange, so we can strip out the locked-based alternatives to using it and just add a guarantee that it is true at runtime. And all platforms except some ARM variants set `SUPPORTS_NATIVE_CX8`, so we can greatly simplify things. Summary of changes: > - `_supports_cx8` field is only needed when `SUPPORTS_NATIVE_CX8` is not defined > - Assertions for `supports_cx8()` are removed > - Compiler predicates requiring `supports_cx8()` are removed > - Access backend is greatly simplified without the need for lock-based alternative > - `java.util.concurrent.AtomicLongFieldUpdater` is simplified without the need for a lock-based alternative > > I did consider moving all the ARM `kuser_helper` related code to be only defined when `SUPPORTS_NATIVE_CX8` is not defined, but there was a theoretical risk this could change the behaviour if ARMv7 binaries were run on other ARM CPU's. I added a note to that effect in vm_version_linux_arm32.cpp so the ARM port maintainers could clean this up further if desired. > > Testing: > - All Oracle tiers 1-5 builds (which includes an ARMv7 build) > - GHA builds/tests > - Oracle tiers 1-3 sanity testing > > Zero changes coming in via [JDK-8319777](https://bugs.openjdk.org/browse/JDK-8319777) will be merged when they arrive. > > Thanks. This pull request has now been integrated. Changeset: c75c3887 Author: David Holmes URL: https://git.openjdk.org/jdk/commit/c75c38871ee7b5c9f7f0c195d649c16967f786bb Stats: 460 lines in 39 files changed: 16 ins; 429 del; 15 mod 8318776: Require supports_cx8 to always be true Reviewed-by: eosterlund, shade, dcubed ------------- PR: https://git.openjdk.org/jdk/pull/16625 From alanb at openjdk.org Fri Nov 24 08:00:06 2023 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 24 Nov 2023 08:00:06 GMT Subject: RFR: 8320665: update jdk_core at test/jdk/TEST.groups In-Reply-To: References: Message-ID: On Thu, 23 Nov 2023 14:31:40 GMT, Ivan ?ipka wrote: > @bwhuang-us @mahendrachhipa As a user of the jdk_core test group, would it be possible to explain why you are doing this? There is nothing in the JBS issue or PR to explain. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16796#issuecomment-1825275884 From djelinski at openjdk.org Fri Nov 24 08:53:13 2023 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Fri, 24 Nov 2023 08:53:13 GMT Subject: RFR: 8320691: Timeout handler on Windows takes 2 hours to complete Message-ID: The recent cdb versions do not support `.dump /f`: ***************************************************************************** * .dump /f is not supported on a user mode process. * * * * .dump /ma creates a complete memory dump of a user mode process. * ***************************************************************************** and after printing that message, cdb ignores the rest of the command line and never quits. This PR updates the dump command to use the recommended `/ma` parameter. This allows the command to produce a dump and complete in a timely manner. ------------- Commit messages: - Update timeout handler for newer cdb Changes: https://git.openjdk.org/jdk/pull/16806/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16806&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8320691 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/16806.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16806/head:pull/16806 PR: https://git.openjdk.org/jdk/pull/16806 From stuefe at openjdk.org Fri Nov 24 08:59:05 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Fri, 24 Nov 2023 08:59:05 GMT Subject: RFR: 8320691: Timeout handler on Windows takes 2 hours to complete In-Reply-To: References: Message-ID: On Fri, 24 Nov 2023 07:58:18 GMT, Daniel Jeli?ski wrote: > The recent cdb versions do not support `.dump /f`: > > ***************************************************************************** > * .dump /f is not supported on a user mode process. * > * * > * .dump /ma creates a complete memory dump of a user mode process. * > ***************************************************************************** > > and after printing that message, cdb ignores the rest of the command line and never quits. > > This PR updates the dump command to use the recommended `/ma` parameter. This allows the command to produce a dump and complete in a timely manner. Good. ------------- Marked as reviewed by stuefe (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16806#pullrequestreview-1747548753 From jpai at openjdk.org Fri Nov 24 09:08:07 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 24 Nov 2023 09:08:07 GMT Subject: RFR: 8320691: Timeout handler on Windows takes 2 hours to complete In-Reply-To: References: Message-ID: On Fri, 24 Nov 2023 07:58:18 GMT, Daniel Jeli?ski wrote: > The recent cdb versions do not support `.dump /f`: > > ***************************************************************************** > * .dump /f is not supported on a user mode process. * > * * > * .dump /ma creates a complete memory dump of a user mode process. * > ***************************************************************************** > > and after printing that message, cdb ignores the rest of the command line and never quits. > > This PR updates the dump command to use the recommended `/ma` parameter. This allows the command to produce a dump and complete in a timely manner. test/failure_handler/src/share/conf/windows.properties line 61: > 59: native.core.app=cdb > 60: native.core.args=-c ".dump /ma core.%p;qd" -p %p > 61: native.core.params.timeout=3600000 Hello Daniel, I found it surprising that this takes 2 hours to complete. The failure handler infrastructure has timeout handling built in, after which it kills the failure handler action (the process). Looking at the value specified here it translates to a timeout of 60 minutes (which is too high by the way). So I looked around in some other files and I think there might be a bug here. In other files (linux.properties and mac.properties), I notice the timeout is specified as: native.core.timeout=600000 Notice the absence of "params" part in that key. I wonder if that is playing a role here and whether we should fix this key. While at it, perhaps we should also reduce this timeout to may be something lesser (1 hour seems to high). Linux and macosx use a value of `600000` which is 10 minutes. If Windows requires a few more minutes then that's understandable but perhaps we should set it to a maximum of 30 minutes maybe? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16806#discussion_r1404106460 From jlahoda at openjdk.org Fri Nov 24 09:08:19 2023 From: jlahoda at openjdk.org (Jan Lahoda) Date: Fri, 24 Nov 2023 09:08:19 GMT Subject: Integrated: 8319220: Pattern matching switch with a lot of cases is unduly slow In-Reply-To: References: Message-ID: On Fri, 3 Nov 2023 08:41:12 GMT, Jan Lahoda wrote: > Consider code like: > > void test(Object o) { > switch (o) { > case X1 -> {} > case X2 -> {} > ...(about 100 cases) > ``` > > javac will compile the switch into a switch whose selector is an indy invocation to `SwitchBootstraps.typeSwitch`, with static arguments being the types in the cases. > > `SwitchBootstraps.typeSwitch` will then create a chain of `MethodHandle`s performing `instanceof` checks between the switch's selector and the given case type. The problem is that when the number of cases is high enough, (more than ~40-50), the chain gets too long, and the tests won't inline anymore. This then leads to a very bad performance, when compared to manually written if-instanceof-else-if-instanceof- chain. > > The proposal herein is to use bytecode (written using the ClassFile API/library) instead of the `MethodHandle`s chain. The overall performance of this seems to be similar to the manually written if-instanceof-else-if-instanceof- chain. > > Using the benchmark from the bug, and this patch, I am getting: > > MyBenchmark.testIfElse100 thrpt 5 521826.326 ? 7510.042 ops/s > MyBenchmark.testSwitch100 thrpt 5 505440.170 ? 3757.178 ops/s > > > The most tricky part of this new way to generate the tests is handling of non-type case labels, and in particular cases with enum constant labels. The resolution of enum constants is deferred as much as possible, by using an indirection through the `ResolvedEnumLabels`. > > Further improvements may be possible, esp. for some specific cases (like all cases having a type, and the type being a final class). This pull request has now been integrated. Changeset: 0c9a61c1 Author: Jan Lahoda URL: https://git.openjdk.org/jdk/commit/0c9a61c18545c7bd48e54e6b4e523b9ad8d0507d Stats: 361 lines in 2 files changed: 241 ins; 94 del; 26 mod 8319220: Pattern matching switch with a lot of cases is unduly slow Reviewed-by: asotona, vromero ------------- PR: https://git.openjdk.org/jdk/pull/16489 From alanb at openjdk.org Fri Nov 24 09:12:07 2023 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 24 Nov 2023 09:12:07 GMT Subject: RFR: 8320691: Timeout handler on Windows takes 2 hours to complete In-Reply-To: References: Message-ID: On Fri, 24 Nov 2023 07:58:18 GMT, Daniel Jeli?ski wrote: > The recent cdb versions do not support `.dump /f`: > > ***************************************************************************** > * .dump /f is not supported on a user mode process. * > * * > * .dump /ma creates a complete memory dump of a user mode process. * > ***************************************************************************** > > and after printing that message, cdb ignores the rest of the command line and never quits. > > This PR updates the dump command to use the recommended `/ma` parameter. This allows the command to produce a dump and complete in a timely manner. test/failure_handler/src/share/conf/windows.properties line 60: > 58: > 59: native.core.app=cdb > 60: native.core.args=-c ".dump /ma core.%p;qd" -p %p Just to double check that this is the right option. `/ma` terminates if there is "inaccessable memory" where `/mA` seems to be continue. The `/f` option says all "accessible" memory which I assume it means skips/ignored inaccessible, is that right? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16806#discussion_r1404110118 From jpai at openjdk.org Fri Nov 24 09:20:11 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 24 Nov 2023 09:20:11 GMT Subject: RFR: 8320691: Timeout handler on Windows takes 2 hours to complete In-Reply-To: References: Message-ID: On Fri, 24 Nov 2023 09:05:15 GMT, Jaikiran Pai wrote: > Notice the absence of "params" part in that key. I wonder if that is playing a role here and whether we should fix this key. Actually ignore that part. I had a look at the internal logs that you referenced. It appears that this form of specifying the timeout (through the use of `params` key) seems to work too. The reason why it took 2 hours is because it ran that command against 2 separate processes and each one timed out after one hour: [2023-11-23 21:45:40] [cdb.exe, -c, ".dump, /f, core.12345;qd", -p, 12345] timeout=3600000 ... 0:001> WARNING: tool timed out: killed process after 3600000 ms ---------------------------------------- [2023-11-23 22:45:40] exit code: -2 time: 3600006 ms ---------------------------------------- ---------------------------------------- [2023-11-23 22:47:36] [cdb.exe, -c, ".dump, /f, core.6789;qd", -p, 6789] timeout=3600000 ---------------------------------------- ... 0:063> WARNING: tool timed out: killed process after 3600000 ms ---------------------------------------- [2023-11-23 23:47:36] exit code: -2 time: 3599996 ms ---------------------------------------- ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16806#discussion_r1404118909 From djelinski at openjdk.org Fri Nov 24 09:43:06 2023 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Fri, 24 Nov 2023 09:43:06 GMT Subject: RFR: 8320691: Timeout handler on Windows takes 2 hours to complete In-Reply-To: References: Message-ID: On Fri, 24 Nov 2023 09:17:47 GMT, Jaikiran Pai wrote: >> test/failure_handler/src/share/conf/windows.properties line 61: >> >>> 59: native.core.app=cdb >>> 60: native.core.args=-c ".dump /ma core.%p;qd" -p %p >>> 61: native.core.params.timeout=3600000 >> >> Hello Daniel, I found it surprising that this takes 2 hours to complete. The failure handler infrastructure has timeout handling built in, after which it kills the failure handler action (the process). Looking at the value specified here it translates to a timeout of 60 minutes (which is too high by the way). So I looked around in some other files and I think there might be a bug here. In other files (linux.properties and mac.properties), I notice the timeout is specified as: >> >> >> native.core.timeout=600000 >> >> Notice the absence of "params" part in that key. I wonder if that is playing a role here and whether we should fix this key. While at it, perhaps we should also reduce this timeout to may be something lesser (1 hour seems to high). Linux and macosx use a value of `600000` which is 10 minutes. If Windows requires a few more minutes then that's understandable but perhaps we should set it to a maximum of 30 minutes maybe? > >> Notice the absence of "params" part in that key. I wonder if that is playing a role here and whether we should fix this key. > > Actually ignore that part. I had a look at the internal logs that you referenced. It appears that this form of specifying the timeout (through the use of `params` key) seems to work too. The reason why it took 2 hours is because it ran that command against 2 separate processes and each one timed out after one hour: > > > [2023-11-23 21:45:40] [cdb.exe, -c, ".dump, /f, core.12345;qd", -p, 12345] timeout=3600000 > ... > 0:001> WARNING: tool timed out: killed process after 3600000 ms > ---------------------------------------- > [2023-11-23 22:45:40] exit code: -2 time: 3600006 ms > ---------------------------------------- > > > ---------------------------------------- > [2023-11-23 22:47:36] [cdb.exe, -c, ".dump, /f, core.6789;qd", -p, 6789] timeout=3600000 > ---------------------------------------- > > ... > 0:063> WARNING: tool timed out: killed process after 3600000 ms > ---------------------------------------- > [2023-11-23 23:47:36] exit code: -2 time: 3599996 ms > ---------------------------------------- > > > Edit: ... and you did mention about this in the description of the JBS issue. I just overlooked it :) good point, 10 minutes should be more than enough. I'll update. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16806#discussion_r1404142975 From djelinski at openjdk.org Fri Nov 24 09:58:19 2023 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Fri, 24 Nov 2023 09:58:19 GMT Subject: RFR: 8320691: Timeout handler on Windows takes 2 hours to complete [v2] In-Reply-To: References: Message-ID: On Fri, 24 Nov 2023 09:09:03 GMT, Alan Bateman wrote: >> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision: >> >> Address review comments > > test/failure_handler/src/share/conf/windows.properties line 60: > >> 58: >> 59: native.core.app=cdb >> 60: native.core.args=-c ".dump /ma core.%p;qd" -p %p > > Just to double check that this is the right option. `/ma` terminates if there is "inaccessable memory" where `/mA` seems to be continue. The `/f` option says all "accessible" memory which I assume it means skips/ignored inaccessible, is that right? `/ma` was the option suggested by `.dump`; looking at the documentation, `/mA` indeed seems to be a better choice. I'll update. `/f` used to create a [full user-mode dump](https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/user-mode-dump-files#full-user-mode-dumps). I couldn't find any information about the behavior on inaccessible memory. None of the options specify dumping inaccessible memory; I assume the failures only happen if some memory becomes inaccessible while producing the dump. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16806#discussion_r1404155352 From stuefe at openjdk.org Fri Nov 24 09:58:20 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Fri, 24 Nov 2023 09:58:20 GMT Subject: RFR: 8320691: Timeout handler on Windows takes 2 hours to complete [v2] In-Reply-To: References: Message-ID: On Fri, 24 Nov 2023 09:51:07 GMT, Daniel Jeli?ski wrote: >> test/failure_handler/src/share/conf/windows.properties line 60: >> >>> 58: >>> 59: native.core.app=cdb >>> 60: native.core.args=-c ".dump /ma core.%p;qd" -p %p >> >> Just to double check that this is the right option. `/ma` terminates if there is "inaccessable memory" where `/mA` seems to be continue. The `/f` option says all "accessible" memory which I assume it means skips/ignored inaccessible, is that right? > > `/ma` was the option suggested by `.dump`; looking at the documentation, `/mA` indeed seems to be a better choice. I'll update. > > `/f` used to create a [full user-mode dump](https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/user-mode-dump-files#full-user-mode-dumps). I couldn't find any information about the behavior on inaccessible memory. > None of the options specify dumping inaccessible memory; I assume the failures only happen if some memory becomes inaccessible while producing the dump. Oh, I overlooked this. I think that is right, the old /f minidump generation worked around inaccessible memory. They were just "holes". ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16806#discussion_r1404160596 From djelinski at openjdk.org Fri Nov 24 09:58:17 2023 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Fri, 24 Nov 2023 09:58:17 GMT Subject: RFR: 8320691: Timeout handler on Windows takes 2 hours to complete [v2] In-Reply-To: References: Message-ID: > The recent cdb versions do not support `.dump /f`: > > ***************************************************************************** > * .dump /f is not supported on a user mode process. * > * * > * .dump /ma creates a complete memory dump of a user mode process. * > ***************************************************************************** > > and after printing that message, cdb ignores the rest of the command line and never quits. > > This PR updates the dump command to use the recommended `/ma` parameter. This allows the command to produce a dump and complete in a timely manner. Daniel Jeli?ski 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/16806/files - new: https://git.openjdk.org/jdk/pull/16806/files/7e6bd035..20ef5acb Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16806&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16806&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/16806.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16806/head:pull/16806 PR: https://git.openjdk.org/jdk/pull/16806 From alanb at openjdk.org Fri Nov 24 10:31:07 2023 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 24 Nov 2023 10:31:07 GMT Subject: RFR: 8320691: Timeout handler on Windows takes 2 hours to complete [v2] In-Reply-To: References: Message-ID: On Fri, 24 Nov 2023 09:40:16 GMT, Daniel Jeli?ski wrote: >>> Notice the absence of "params" part in that key. I wonder if that is playing a role here and whether we should fix this key. >> >> Actually ignore that part. I had a look at the internal logs that you referenced. It appears that this form of specifying the timeout (through the use of `params` key) seems to work too. The reason why it took 2 hours is because it ran that command against 2 separate processes and each one timed out after one hour: >> >> >> [2023-11-23 21:45:40] [cdb.exe, -c, ".dump, /f, core.12345;qd", -p, 12345] timeout=3600000 >> ... >> 0:001> WARNING: tool timed out: killed process after 3600000 ms >> ---------------------------------------- >> [2023-11-23 22:45:40] exit code: -2 time: 3600006 ms >> ---------------------------------------- >> >> >> ---------------------------------------- >> [2023-11-23 22:47:36] [cdb.exe, -c, ".dump, /f, core.6789;qd", -p, 6789] timeout=3600000 >> ---------------------------------------- >> >> ... >> 0:063> WARNING: tool timed out: killed process after 3600000 ms >> ---------------------------------------- >> [2023-11-23 23:47:36] exit code: -2 time: 3599996 ms >> ---------------------------------------- >> >> >> Edit: ... and you did mention about this in the description of the JBS issue. I just overlooked it :) > > good point, 10 minutes should be more than enough. I'll update. Out of curiosity, do we know why it takes more than an hour? Is it attempting to connect to the Microsoft symbol server? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16806#discussion_r1404194681 From alanb at openjdk.org Fri Nov 24 10:35:28 2023 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 24 Nov 2023 10:35:28 GMT Subject: RFR: 8320532: Remove Thread/ThreadGroup suspend/resume Message-ID: The deadlock prone Thread/ThreadGroup suspend/resume were deprecated since JDK 1.2, deprecated for removal in Java 14, and re-specified/degraded to throw UnsupportedOperationException unconditionally in Java 19/20. Early in Java 23 seems a fine time to finally remove these methods. Corpus analysis of 176 million classes in 485k artifacts found no remaining usages of ThreadGroup.suspend/resume beyond the artifacts that include a copy of java.lang.ThreadGroup (!). It found 87 remaining uses of Thread.suspend and 86 remaining usages of Thread.resume, some of these are tests. Thread.suspend/resume have always linked to the "Java Thread Primitive Deprecation" page. This originally explained the reasons why suspend/resume were deprecated. When these methods were degraded to throw UOE we changed the text to explain why the ability to suspend or resume a thread was removed. Now we must change it again. One choice is to re-word to explain why the Java APIs were removed or why the Java APIs don't define a way to suspend/resume threads, the other choice (which I prefer) is to remove the text. The method description of java.lang.management.ThreadInfo.isSuspended is tweaked to link to JVMTI SuspendThread instead of Thread.suspend ------------- Commit messages: - Clarify ThreadInfo.isSuspended - Initial commit Changes: https://git.openjdk.org/jdk/pull/16789/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16789&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8320532 Stats: 552 lines in 9 files changed: 116 ins; 430 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/16789.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16789/head:pull/16789 PR: https://git.openjdk.org/jdk/pull/16789 From alanb at openjdk.org Fri Nov 24 10:37:16 2023 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 24 Nov 2023 10:37:16 GMT Subject: RFR: 8320440: Implementation of Structured Concurrency (Second Preview) Message-ID: <4t6NzmCd-0w-y7iT51fEttO7gEArgRuCeEl4yeNIzd0=.cd7bbed3-1117-4fc1-9241-255e6e10e2f1@github.com> This API is sitting out JDK 22, meaning no API/implementation changes in this PR. We expect this API to do a third preview in JDK 23 with some API changes. So for now, we just need to bump JEP number/title that shows up in the preview section of the javadoc. ------------- Commit messages: - Initial commit Changes: https://git.openjdk.org/jdk/pull/16748/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16748&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8320440 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/16748.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16748/head:pull/16748 PR: https://git.openjdk.org/jdk/pull/16748 From stefank at openjdk.org Fri Nov 24 10:39:13 2023 From: stefank at openjdk.org (Stefan Karlsson) Date: Fri, 24 Nov 2023 10:39:13 GMT Subject: RFR: 8320699: Add parameter to skip progress logging of OutputAnalyzer Message-ID: Tests using ProcessTools.executeProcess gets the following output written to stdout: [2023-11-24T09:58:16.797540608Z] Gathering output for process 2517117 [2023-11-24T09:58:23.070781345Z] Waiting for completion for process 2517117 [2023-11-24T09:58:23.071045055Z] Waiting for completion finished for process 2517117 This might be good for some use cases and debugging, but some tests spawns a large number of processes and for those this output fills up the log files. I propose that we add a way to turn of this output for tests where we find this output to be too noisy. ------------- Commit messages: - 8320699: Add parameter to skip progress logging of OutputAnalyzer Changes: https://git.openjdk.org/jdk/pull/16807/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16807&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8320699 Stats: 24 lines in 2 files changed: 21 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/16807.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16807/head:pull/16807 PR: https://git.openjdk.org/jdk/pull/16807 From stefank at openjdk.org Fri Nov 24 10:39:14 2023 From: stefank at openjdk.org (Stefan Karlsson) Date: Fri, 24 Nov 2023 10:39:14 GMT Subject: RFR: 8320699: Add parameter to skip progress logging of OutputAnalyzer In-Reply-To: References: Message-ID: <-3DJY-XzhGn6x1QKWKrRy7QBCnCL1JoLsIxWNDL9_ks=.21ceb8bd-b7eb-47bf-9241-d45ac832ea6f@github.com> On Fri, 24 Nov 2023 10:34:02 GMT, Stefan Karlsson wrote: > Tests using ProcessTools.executeProcess gets the following output written to stdout: > [2023-11-24T09:58:16.797540608Z] Gathering output for process 2517117 > [2023-11-24T09:58:23.070781345Z] Waiting for completion for process 2517117 > [2023-11-24T09:58:23.071045055Z] Waiting for completion finished for process 2517117 > > This might be good for some use cases and debugging, but some tests spawns a large number of processes and for those this output fills up the log files. > > I propose that we add a way to turn of this output for tests where we find this output to be too noisy. This has been tested with an Oracle-internal stress tests. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16807#issuecomment-1825466825 From msheppar at openjdk.org Fri Nov 24 10:41:04 2023 From: msheppar at openjdk.org (Mark Sheppard) Date: Fri, 24 Nov 2023 10:41:04 GMT Subject: RFR: 8320665: update jdk_core at test/jdk/TEST.groups In-Reply-To: References: Message-ID: On Thu, 23 Nov 2023 14:31:40 GMT, Ivan ?ipka wrote: > @bwhuang-us @mahendrachhipa Marked as reviewed by msheppar (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/16796#pullrequestreview-1747718538 From alanb at openjdk.org Fri Nov 24 11:03:25 2023 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 24 Nov 2023 11:03:25 GMT Subject: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v34] In-Reply-To: References: Message-ID: On Thu, 23 Nov 2023 15:55:42 GMT, Jim Laskey wrote: >> Address changes from JEP 445 to JEP 463. >> >> - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. >> >> - Don't mark class on read. >> >> - Remove reflection and annotation processing related to unnamed classes. >> >> - Simplify main method search. > > Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: > > Remove Test src/java.base/share/classes/java/lang/Class.java line 4797: > 4795: PublicMethods.MethodList res = getMethodsRecursive(name, parameterTypes, true, publicOnly); > 4796: return res == null ? null : getReflectionFactory().copyMethod(res.getMostSpecific()); > 4797: } Would you mind moving this up to follow getDeclaredPublicMethods, as these are the two are the method finders exposed via JavaLangAccess. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16461#discussion_r1404226792 From isipka at openjdk.org Fri Nov 24 11:31:04 2023 From: isipka at openjdk.org (Ivan =?UTF-8?B?xaBpcGth?=) Date: Fri, 24 Nov 2023 11:31:04 GMT Subject: RFR: 8320665: update jdk_core at test/jdk/TEST.groups In-Reply-To: References: Message-ID: On Fri, 24 Nov 2023 07:57:41 GMT, Alan Bateman wrote: > I use the jdk_core test group. I know the split doesn't impact users of this test group but it's not clear why the change is being done. Would it be possible to explain why you are doing this? There is nothing in the JBS issue or PR to explain. explained in private communication: refactoring of internally used files to enable ergonomic result analysis for internal processes ------------- PR Comment: https://git.openjdk.org/jdk/pull/16796#issuecomment-1825537257 From alanb at openjdk.org Fri Nov 24 11:32:23 2023 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 24 Nov 2023 11:32:23 GMT Subject: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v34] In-Reply-To: References: Message-ID: On Thu, 23 Nov 2023 15:55:42 GMT, Jim Laskey wrote: >> Address changes from JEP 445 to JEP 463. >> >> - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. >> >> - Don't mark class on read. >> >> - Remove reflection and annotation processing related to unnamed classes. >> >> - Simplify main method search. > > Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: > > Remove Test src/java.base/share/classes/jdk/internal/misc/MethodFinder.java line 40: > 38: } > 39: > 40: private static final JavaLangAccess JLA = SharedSecrets.getJavaLangAccess(); The new shared secret and usage looks fine. It would be good to add a short class description and method description and make it clear it's for launcher usage, we don't want this used for anything else. Personally I would move JLA to to the top rather than after the constructor. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16461#discussion_r1404252179 From jpai at openjdk.org Fri Nov 24 11:33:05 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 24 Nov 2023 11:33:05 GMT Subject: RFR: 8320691: Timeout handler on Windows takes 2 hours to complete [v2] In-Reply-To: References: Message-ID: On Fri, 24 Nov 2023 09:58:17 GMT, Daniel Jeli?ski wrote: >> The recent cdb versions do not support `.dump /f`: >> >> ***************************************************************************** >> * .dump /f is not supported on a user mode process. * >> * * >> * .dump /ma creates a complete memory dump of a user mode process. * >> ***************************************************************************** >> >> and after printing that message, cdb ignores the rest of the command line and never quits. >> >> This PR updates the dump command to use the recommended `/ma` parameter. This allows the command to produce a dump and complete in a timely manner. > > Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision: > > Address review comments The timeout change looks good to me. ------------- Marked as reviewed by jpai (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16806#pullrequestreview-1747793376 From djelinski at openjdk.org Fri Nov 24 11:39:05 2023 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Fri, 24 Nov 2023 11:39:05 GMT Subject: RFR: 8320691: Timeout handler on Windows takes 2 hours to complete [v2] In-Reply-To: References: Message-ID: On Fri, 24 Nov 2023 10:28:30 GMT, Alan Bateman wrote: >> good point, 10 minutes should be more than enough. I'll update. > > Out of curiosity, do we know why it takes more than an hour? Is it attempting to connect to the Microsoft symbol server? It's ignoring the rest of the command line after `/f`, which means it ignores the `;qd` (quit and detach) part and enters the interactive mode. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16806#discussion_r1404256329 From alanb at openjdk.org Fri Nov 24 11:39:05 2023 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 24 Nov 2023 11:39:05 GMT Subject: RFR: 8320691: Timeout handler on Windows takes 2 hours to complete [v2] In-Reply-To: References: Message-ID: On Fri, 24 Nov 2023 11:33:57 GMT, Daniel Jeli?ski wrote: > It's ignoring the rest of the command line after `/f`, which means it ignores the `;qd` (quit and detach) part and enters the interactive mode. Wonderful :-) Does switching to `/mA` change that? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16806#discussion_r1404258410 From djelinski at openjdk.org Fri Nov 24 12:07:06 2023 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Fri, 24 Nov 2023 12:07:06 GMT Subject: RFR: 8320691: Timeout handler on Windows takes 2 hours to complete [v2] In-Reply-To: References: Message-ID: <5-N34uZKMMWpO-7Eyav7YRX3wWxXUOzxQ2sqTApqZls=.99967fa6-8fe0-4d67-b3a7-515313463ddf@github.com> On Fri, 24 Nov 2023 11:36:27 GMT, Alan Bateman wrote: >> It's ignoring the rest of the command line after `/f`, which means it ignores the `;qd` (quit and detach) part and enters the interactive mode. > >> It's ignoring the rest of the command line after `/f`, which means it ignores the `;qd` (quit and detach) part and enters the interactive mode. > > Wonderful :-) Does switching to `/mA` change that? Yes, with `/mA` the command exits as soon as the dump is completed. I couldn't find a way to make `cdb` not enter interactive mode on unrecognized parameter, so I left that part as is. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16806#discussion_r1404282038 From kevinw at openjdk.org Fri Nov 24 12:16:08 2023 From: kevinw at openjdk.org (Kevin Walls) Date: Fri, 24 Nov 2023 12:16:08 GMT Subject: RFR: 8316649: JMX connection timeout cannot be changed and uses the default of 0 (infinite) In-Reply-To: References: <6R7B_a7VdF5Fg8B38rMhx0Fe1WT53KQw0yt596rzmS4=.9902a48f-f143-4d81-8940-d9c273e94812@github.com> Message-ID: On Thu, 23 Nov 2023 17:21:02 GMT, Daniel Fuchs wrote: >>> This is a stack from a test I was experimenting with, when it did see the timeout: >> >> Ah - that's for testing with a particular test. So the question now is: >> >> Should the RMISocketFactories provided / implemented in the JMX implementation - such as those used by the JMX default agent, also honour this system property? > > (Look for socket factories in the module `jdk.management.agent`) OK yes, we also have: java.rmi/share/classes/javax/rmi/ssl/SslRMIClientSocketFactory.java with its own createSocket(String host, int port) method. This is used if we use JMX over SSL. So SslRMIClientSocketFactory could specifically implement the connect timeout. Next q, should it? 8-) The reported hang and those I have seen in testing have only been in: sun.rmi.transport.tcp.TCPDirectSocketFactory.createSocket calling Socket.init. javax/rmi/ssl/SslRMIClientSocketFactory.java reads some properties named "javax.rmi.ssl.client...." so it would be odd for it to read "sun.rmi.transport.tcp.initialConnectTimeout" I was proposing here. It could implement "javax.rmi.ssl.client.initialConnectTimeout", or we could leave SSL alone for now, possibly handling it in a separate issue if it's wanted. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16771#discussion_r1404290257 From ihse at openjdk.org Fri Nov 24 12:29:07 2023 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 24 Nov 2023 12:29:07 GMT Subject: RFR: 8320691: Timeout handler on Windows takes 2 hours to complete [v2] In-Reply-To: References: Message-ID: On Fri, 24 Nov 2023 09:58:17 GMT, Daniel Jeli?ski wrote: >> The recent cdb versions do not support `.dump /f`: >> >> ***************************************************************************** >> * .dump /f is not supported on a user mode process. * >> * * >> * .dump /ma creates a complete memory dump of a user mode process. * >> ***************************************************************************** >> >> and after printing that message, cdb ignores the rest of the command line and never quits. >> >> This PR updates the dump command to use the recommended `/ma` parameter. This allows the command to produce a dump and complete in a timely manner. > > Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision: > > Address review comments LGTM ------------- Marked as reviewed by ihse (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16806#pullrequestreview-1747867935 From jlaskey at openjdk.org Fri Nov 24 12:56:42 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Fri, 24 Nov 2023 12:56:42 GMT Subject: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v34] In-Reply-To: References: Message-ID: On Fri, 24 Nov 2023 11:00:18 GMT, Alan Bateman wrote: >> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove Test > > src/java.base/share/classes/java/lang/Class.java line 4797: > >> 4795: PublicMethods.MethodList res = getMethodsRecursive(name, parameterTypes, true, publicOnly); >> 4796: return res == null ? null : getReflectionFactory().copyMethod(res.getMostSpecific()); >> 4797: } > > Would you mind moving this up to follow getDeclaredPublicMethods, as these are the two method finders exposed via JavaLangAccess. Updated > src/java.base/share/classes/jdk/internal/misc/MethodFinder.java line 40: > >> 38: } >> 39: >> 40: private static final JavaLangAccess JLA = SharedSecrets.getJavaLangAccess(); > > The new shared secret and usage looks fine. It would be good to add a short class description and method description and make it clear it's for launcher usage, we don't want this used for anything else. Personally I would move JLA to to the top rather than after the constructor. Updated ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16461#discussion_r1404324242 PR Review Comment: https://git.openjdk.org/jdk/pull/16461#discussion_r1404324338 From jlaskey at openjdk.org Fri Nov 24 12:56:40 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Fri, 24 Nov 2023 12:56:40 GMT Subject: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v35] In-Reply-To: References: Message-ID: > Address changes from JEP 445 to JEP 463. > > - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. > > - Don't mark class on read. > > - Remove reflection and annotation processing related to unnamed classes. > > - Simplify main method search. Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: Requested changes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16461/files - new: https://git.openjdk.org/jdk/pull/16461/files/690dac1d..d7895da7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16461&range=34 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16461&range=33-34 Stats: 68 lines in 2 files changed: 57 ins; 9 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/16461.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16461/head:pull/16461 PR: https://git.openjdk.org/jdk/pull/16461 From dholmes at openjdk.org Fri Nov 24 13:01:12 2023 From: dholmes at openjdk.org (David Holmes) Date: Fri, 24 Nov 2023 13:01:12 GMT Subject: RFR: 8320532: Remove Thread/ThreadGroup suspend/resume In-Reply-To: References: Message-ID: On Thu, 23 Nov 2023 09:18:44 GMT, Alan Bateman wrote: > The deadlock prone Thread/ThreadGroup suspend/resume were deprecated since JDK 1.2, deprecated for removal in Java 14, and re-specified/degraded to throw UnsupportedOperationException unconditionally in Java 19/20. Early in Java 23 seems a fine time to finally remove these methods. > > Corpus analysis of 176 million classes in 485k artifacts found no remaining usages of ThreadGroup.suspend/resume beyond the artifacts that include a copy of java.lang.ThreadGroup (!). It found 87 remaining uses of Thread.suspend and 86 remaining usages of Thread.resume, some of these are tests. > > Thread.suspend/resume have always linked to the "Java Thread Primitive Deprecation" page. This originally explained the reasons why suspend/resume were deprecated. When these methods were degraded to throw UOE we changed the text to explain why the ability to suspend or resume a thread was removed. Now we must change it again. One choice is to re-word to explain why the Java APIs were removed or why the Java APIs don't define a way to suspend/resume threads, the other choice (which I prefer) is to remove the text. > > The method description of java.lang.management.ThreadInfo.isSuspended is tweaked to link to JVMTI SuspendThread instead of Thread.suspend Looks good to me. I'm okay with removing the suspend/resume text from the deprecation page - no point trying to explain a 25+ year history. Couple of queries on the test changes, but still approved. Thanks test/jdk/java/lang/Thread/ThreadStopTest.java line 27: > (failed to retrieve contents of file, check the PR for context) You didn't really need to rename the test even though there is now only one degraded method left. test/jdk/java/nio/channels/SocketChannel/SendUrgentData.java line 67: > 65: if (args.length > 0 && args[0].equals("-server")) { > 66: System.out.println(serverThread.getAddress()); > 67: Thread.currentThread().suspend(); If suspend throws then surely this test can't be functioning correctly! ??? ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16789#pullrequestreview-1747907612 PR Review Comment: https://git.openjdk.org/jdk/pull/16789#discussion_r1404325923 PR Review Comment: https://git.openjdk.org/jdk/pull/16789#discussion_r1404327680 From dfuchs at openjdk.org Fri Nov 24 13:05:05 2023 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Fri, 24 Nov 2023 13:05:05 GMT Subject: RFR: 8316649: JMX connection timeout cannot be changed and uses the default of 0 (infinite) In-Reply-To: References: <6R7B_a7VdF5Fg8B38rMhx0Fe1WT53KQw0yt596rzmS4=.9902a48f-f143-4d81-8940-d9c273e94812@github.com> Message-ID: On Fri, 24 Nov 2023 12:13:56 GMT, Kevin Walls wrote: >> (Look for socket factories in the module `jdk.management.agent`) > > OK yes, we also have: java.rmi/share/classes/javax/rmi/ssl/SslRMIClientSocketFactory.java > with its own createSocket(String host, int port) method. This is used if we use JMX over SSL. > > So SslRMIClientSocketFactory could specifically implement the connect timeout. > > Next q, should it? 8-) > > The reported hang and those I have seen in testing have only been in: > sun.rmi.transport.tcp.TCPDirectSocketFactory.createSocket calling Socket.init. > > javax/rmi/ssl/SslRMIClientSocketFactory.java reads some properties named "javax.rmi.ssl.client...." > so it would be odd for it to read "sun.rmi.transport.tcp.initialConnectTimeout" I was proposing here. > > It could implement "javax.rmi.ssl.client.initialConnectTimeout", or we could leave SSL alone for now, possibly handling it in a separate issue if it's wanted. OK - sounds good. Meanwhile I had a look at the custom RMI Socket Factories used by the JMX Agent, and these are actually RMIServerSocketFactories, so having a timeout for connect there probably makes no sense. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16771#discussion_r1404331875 From dholmes at openjdk.org Fri Nov 24 13:09:05 2023 From: dholmes at openjdk.org (David Holmes) Date: Fri, 24 Nov 2023 13:09:05 GMT Subject: RFR: 8320699: Add parameter to skip progress logging of OutputAnalyzer In-Reply-To: References: Message-ID: On Fri, 24 Nov 2023 10:34:02 GMT, Stefan Karlsson wrote: > Tests using ProcessTools.executeProcess gets the following output written to stdout: > [2023-11-24T09:58:16.797540608Z] Gathering output for process 2517117 > [2023-11-24T09:58:23.070781345Z] Waiting for completion for process 2517117 > [2023-11-24T09:58:23.071045055Z] Waiting for completion finished for process 2517117 > > This might be good for some use cases and debugging, but some tests spawns a large number of processes and for those this output fills up the log files. > > I propose that we add a way to turn of this output for tests where we find this output to be too noisy. I can't help but feel that if you disable this output then you are going to be missing it in the cases that you need it! Something will go wrong and there won't be enough info in the log to know what it was. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16807#issuecomment-1825651785 From alanb at openjdk.org Fri Nov 24 13:09:11 2023 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 24 Nov 2023 13:09:11 GMT Subject: RFR: 8320532: Remove Thread/ThreadGroup suspend/resume In-Reply-To: References: Message-ID: <4vSN6RIDxq2-Xeto5GijGKd4HcTVoFR4VkQ-ppbNOwo=.4649b7fd-e556-43ee-904c-5b268a998bc3@github.com> On Fri, 24 Nov 2023 12:55:26 GMT, David Holmes wrote: > You didn't really need to rename the test even though there is now only one degraded method left. True but it's wasn't good name for a test that only exercises one method. > test/jdk/java/nio/channels/SocketChannel/SendUrgentData.java line 67: > >> 65: if (args.length > 0 && args[0].equals("-server")) { >> 66: System.out.println(serverThread.getAddress()); >> 67: Thread.currentThread().suspend(); > > If suspend throws then surely this test can't be functioning correctly! ??? The test has two modes. The automated (and default) runs a client+server in the same VM. The other mode is for local/interactive testing where the client and server are different commands, it's the interactive server run in this mode that was doing the self-suspend. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16789#discussion_r1404336055 PR Review Comment: https://git.openjdk.org/jdk/pull/16789#discussion_r1404335282 From alanb at openjdk.org Fri Nov 24 13:13:08 2023 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 24 Nov 2023 13:13:08 GMT Subject: RFR: 8320532: Remove Thread/ThreadGroup suspend/resume In-Reply-To: References: Message-ID: On Fri, 24 Nov 2023 12:58:50 GMT, David Holmes wrote: > Looks good to me. I'm okay with removing the suspend/resume text from the deprecation page - no point trying to explain a 25+ year history. Thanks, would you mind reviewing the CSR too? (The fixVersion is set to 23 so the skara bots aren't going to link the issues until we after the fork and the sync up of this branch). ------------- PR Comment: https://git.openjdk.org/jdk/pull/16789#issuecomment-1825656830 From alanb at openjdk.org Fri Nov 24 13:19:06 2023 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 24 Nov 2023 13:19:06 GMT Subject: RFR: 8320691: Timeout handler on Windows takes 2 hours to complete [v2] In-Reply-To: References: Message-ID: On Fri, 24 Nov 2023 09:58:17 GMT, Daniel Jeli?ski wrote: >> The recent cdb versions do not support `.dump /f`: >> >> ***************************************************************************** >> * .dump /f is not supported on a user mode process. * >> * * >> * .dump /ma creates a complete memory dump of a user mode process. * >> ***************************************************************************** >> >> and after printing that message, cdb ignores the rest of the command line and never quits. >> >> This PR updates the dump command to use the recommended `/ma` parameter. This allows the command to produce a dump and complete in a timely manner. > > Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision: > > Address review comments Marked as reviewed by alanb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/16806#pullrequestreview-1747936722 From alanb at openjdk.org Fri Nov 24 13:19:09 2023 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 24 Nov 2023 13:19:09 GMT Subject: RFR: 8320691: Timeout handler on Windows takes 2 hours to complete [v2] In-Reply-To: <5-N34uZKMMWpO-7Eyav7YRX3wWxXUOzxQ2sqTApqZls=.99967fa6-8fe0-4d67-b3a7-515313463ddf@github.com> References: <5-N34uZKMMWpO-7Eyav7YRX3wWxXUOzxQ2sqTApqZls=.99967fa6-8fe0-4d67-b3a7-515313463ddf@github.com> Message-ID: On Fri, 24 Nov 2023 12:04:01 GMT, Daniel Jeli?ski wrote: > Yes, with `/mA` the command exits as soon as the dump is completed. I couldn't find a way to make `cdb` not enter interactive mode on unrecognized parameter, so I left that part as is. Okay, maybe it can be figured out another time. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16806#discussion_r1404343895 From kevinw at openjdk.org Fri Nov 24 13:25:06 2023 From: kevinw at openjdk.org (Kevin Walls) Date: Fri, 24 Nov 2023 13:25:06 GMT Subject: RFR: 8316649: JMX connection timeout cannot be changed and uses the default of 0 (infinite) In-Reply-To: References: <6R7B_a7VdF5Fg8B38rMhx0Fe1WT53KQw0yt596rzmS4=.9902a48f-f143-4d81-8940-d9c273e94812@github.com> Message-ID: On Fri, 24 Nov 2023 13:01:59 GMT, Daniel Fuchs wrote: >> OK yes, we also have: java.rmi/share/classes/javax/rmi/ssl/SslRMIClientSocketFactory.java >> with its own createSocket(String host, int port) method. This is used if we use JMX over SSL. >> >> So SslRMIClientSocketFactory could specifically implement the connect timeout. >> >> Next q, should it? 8-) >> >> The reported hang and those I have seen in testing have only been in: >> sun.rmi.transport.tcp.TCPDirectSocketFactory.createSocket calling Socket.init. >> >> javax/rmi/ssl/SslRMIClientSocketFactory.java reads some properties named "javax.rmi.ssl.client...." >> so it would be odd for it to read "sun.rmi.transport.tcp.initialConnectTimeout" I was proposing here. >> >> It could implement "javax.rmi.ssl.client.initialConnectTimeout", or we could leave SSL alone for now, possibly handling it in a separate issue if it's wanted. > > OK - sounds good. Meanwhile I had a look at the custom RMI Socket Factories used by the JMX Agent, and these are actually RMIServerSocketFactories, so having a timeout for connect there probably makes no sense. Thanks, yes so JMX SSL clients are without socket connect timeout, good to have that documented. I logged a parallel RFE for SslRMIClientSocketFactory, which should wait for now as it seems wrong to go changing that right now without knowing if it's ever been an issue for anybody: [JDK-8320703](https://bugs.openjdk.org/browse/JDK-8320703): JMX SSL RMI Socket connection timeout cannot be changed ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16771#discussion_r1404349662 From sgehwolf at openjdk.org Fri Nov 24 13:25:35 2023 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Fri, 24 Nov 2023 13:25:35 GMT Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged modules being present [v10] In-Reply-To: References: Message-ID: > Please review this patch which adds a "jmodless" jlink mode to the JDK. Fundamentally this patch adds an option to use `jlink` even though your JDK install might not come with the packaged modules (directory `jmods`). This is particularly useful to further reduce the size of a jlinked runtime. After the removal of the concept of a JRE, a common distribution mechanism is still the full JDK with all modules and packaged modules. However, packaged modules can incur an additional size tax. For example in a container scenario it could be useful to have a base JDK container including all modules, but without also delivering the packaged modules. This comes at a size advantage of `~25%`. Such a base JDK container could then be used to `jlink` application specific runtimes, further reducing the size of the application runtime image (App + JDK runtime; as a single image *or* separate bundles, depending on the app being modularized). > > The basic design of this approach is to add a jlink plugin for tracking non-class and non-resource files of a JDK install. I.e. files which aren't present in the jimage (`lib/modules`). This enables producing a `JmodLessArchive` class which has all the info of what constitutes the final jlinked runtime. > > Basic usage example: > > $ diff -u <(./bin/java --list-modules --limit-modules java.se) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules java.se) > $ diff -u <(./bin/java --list-modules --limit-modules java.se) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules jdk.jlink) > $ ls ../linux-x86_64-server-release/images/jdk/jmods > java.base.jmod java.net.http.jmod java.sql.rowset.jmod jdk.crypto.ec.jmod jdk.internal.opt.jmod jdk.jdi.jmod jdk.management.agent.jmod jdk.security.auth.jmod > java.compiler.jmod java.prefs.jmod java.transaction.xa.jmod jdk.dynalink.jmod jdk.internal.vm.ci.jmod jdk.jdwp.agent.jmod jdk.management.jfr.jmod jdk.security.jgss.jmod > java.datatransfer.jmod java.rmi.jmod java.xml.crypto.jmod jdk.editpad.jmod jdk.internal.vm.compiler.jmod jdk.jfr.jmod jdk.management.jmod jdk.unsupported.desktop.jmod > java.desktop.jmod java.scripting.jmod java.xml.jmod jdk.hotspot.agent.jmod jdk.internal.vm.compiler.management.jmod jdk.jlink.jmod jdk.naming.dns.jmod jdk.unsupported... Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision: Tighten ModifiedFilesExitTest Ensure the error message is reasonable and doesn't include Exceptions presented to the user. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14787/files - new: https://git.openjdk.org/jdk/pull/14787/files/3539c6a5..f1130d1c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14787&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14787&range=08-09 Stats: 32 lines in 3 files changed: 9 ins; 18 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/14787.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14787/head:pull/14787 PR: https://git.openjdk.org/jdk/pull/14787 From eosterlund at openjdk.org Fri Nov 24 14:19:21 2023 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Fri, 24 Nov 2023 14:19:21 GMT Subject: RFR: 8310644: Make panama memory segment close use async handshakes [v4] In-Reply-To: References: Message-ID: > The current logic for closing memory in panama today is susceptible to live lock if we have a closing thread that wants to close the memory in a loop that keeps failing, and a bunch of accessing threads that want to perform accesses as long as the memory is alive. They can both create impediments for the other. > > By using asynchronous handshakes to install an exception onto threads that are in @Scoped memory accesses, we can have close always succeed, and the accessing threads bail out. The idea is that we perform a synchronous handshake first to find threads that are in scoped methods. They might however be in the middle of throwing an exception or something wild like there, where an exception can't be delivered. We install an async handshake that will roll us forward to the first place where we can indeed install exceptions, then we reevaluate if we still need to do that, or if we have unwound out from the scoped method. If we are still inside of it, we ensure an exception is installed so we don't continue executing bytecodes that might access the memory that we have freed. > > Tested tier 1-5 as well as running test/jdk/java/foreign/TestHandshake.java hundreds of times, which tests this API pretty well. Erik ?sterlund has updated the pull request incrementally with five additional commits since the last revision: - Merge pull request #2 from JornVernee/PR_async_close+ASYNC_EXCEPTION_CHECK - Add swappy copy cast to TestHandShake.java - Polish: use special UNSAFE_ENTRY_SCOPED - work around NoSafepointVerifier check in CopySwapMemory - use more fine grained exception check ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16792/files - new: https://git.openjdk.org/jdk/pull/16792/files/5d34ddba..0b91ac9a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16792&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16792&range=02-03 Stats: 84 lines in 3 files changed: 44 ins; 18 del; 22 mod Patch: https://git.openjdk.org/jdk/pull/16792.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16792/head:pull/16792 PR: https://git.openjdk.org/jdk/pull/16792 From djelinski at openjdk.org Fri Nov 24 15:00:19 2023 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Fri, 24 Nov 2023 15:00:19 GMT Subject: RFR: 8320691: Timeout handler on Windows takes 2 hours to complete [v2] In-Reply-To: References: Message-ID: <80DURK7yfr4ux-LAVHJzSD5H8cqzDyuUL_XZWu9uoU4=.3c9fd436-2be6-493b-85af-c974f31b9a6d@github.com> On Fri, 24 Nov 2023 09:58:17 GMT, Daniel Jeli?ski wrote: >> The recent cdb versions do not support `.dump /f`: >> >> ***************************************************************************** >> * .dump /f is not supported on a user mode process. * >> * * >> * .dump /ma creates a complete memory dump of a user mode process. * >> ***************************************************************************** >> >> and after printing that message, cdb ignores the rest of the command line and never quits. >> >> This PR updates the dump command to use the recommended `/ma` parameter. This allows the command to produce a dump and complete in a timely manner. > > Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision: > > Address review comments Thanks for the reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/16806#issuecomment-1825783600 From djelinski at openjdk.org Fri Nov 24 15:00:20 2023 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Fri, 24 Nov 2023 15:00:20 GMT Subject: Integrated: 8320691: Timeout handler on Windows takes 2 hours to complete In-Reply-To: References: Message-ID: On Fri, 24 Nov 2023 07:58:18 GMT, Daniel Jeli?ski wrote: > The recent cdb versions do not support `.dump /f`: > > ***************************************************************************** > * .dump /f is not supported on a user mode process. * > * * > * .dump /ma creates a complete memory dump of a user mode process. * > ***************************************************************************** > > and after printing that message, cdb ignores the rest of the command line and never quits. > > This PR updates the dump command to use the recommended `/ma` parameter. This allows the command to produce a dump and complete in a timely manner. This pull request has now been integrated. Changeset: 4d50df63 Author: Daniel Jeli?ski URL: https://git.openjdk.org/jdk/commit/4d50df63b6ea76fd6a6c387593c3d6bc9429007b Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8320691: Timeout handler on Windows takes 2 hours to complete Reviewed-by: stuefe, jpai, ihse, alanb ------------- PR: https://git.openjdk.org/jdk/pull/16806 From msheppar at openjdk.org Fri Nov 24 16:31:05 2023 From: msheppar at openjdk.org (Mark Sheppard) Date: Fri, 24 Nov 2023 16:31:05 GMT Subject: RFR: 8316649: JMX connection timeout cannot be changed and uses the default of 0 (infinite) In-Reply-To: References: <6R7B_a7VdF5Fg8B38rMhx0Fe1WT53KQw0yt596rzmS4=.9902a48f-f143-4d81-8940-d9c273e94812@github.com> Message-ID: On Fri, 24 Nov 2023 13:22:07 GMT, Kevin Walls wrote: >> OK - sounds good. Meanwhile I had a look at the custom RMI Socket Factories used by the JMX Agent, and these are actually RMIServerSocketFactories, so having a timeout for connect there probably makes no sense. > > Thanks, yes so JMX SSL clients are without socket connect timeout, good to have that documented. I logged a parallel RFE for SslRMIClientSocketFactory, which should wait for now as it seems wrong to go changing that right now without knowing if it's ever been an issue for anybody: > [JDK-8320703](https://bugs.openjdk.org/browse/JDK-8320703): JMX SSL RMI Socket connection timeout cannot be changed wrt to the property name initialConnectTimeout might infer that it is an initial value which can be subsequentually modified, but that is not possible. As such, would sun.rmi.transport.tcp.connectTimeout be more appropriate -- dropping the initial ? If the connectTimeout initialization code was placed in a static method, it could directly unit testable :-) (if such a test was desirable for coverage completeness) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16771#discussion_r1404513377 From stefank at openjdk.org Fri Nov 24 16:34:05 2023 From: stefank at openjdk.org (Stefan Karlsson) Date: Fri, 24 Nov 2023 16:34:05 GMT Subject: RFR: 8320699: Add parameter to skip progress logging of OutputAnalyzer In-Reply-To: References: Message-ID: On Fri, 24 Nov 2023 13:06:05 GMT, David Holmes wrote: > I can't help but feel that if you disable this output then you are going to be missing it in the cases that you need it! Something will go wrong and there won't be enough info in the log to know what it was. My experience is that I won't need it. I've been able to identify numerous hangs, deadlocks, timeouts in the stress tests where I want to use this. Right now I much more annoyed by the log files filling up with thousands upon thousands lines of noise, making it harder to actually find the status of the test. An alternative to this could be to redirect the output to another file. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16807#issuecomment-1825888462 From asemenyuk at openjdk.org Fri Nov 24 16:39:13 2023 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Fri, 24 Nov 2023 16:39:13 GMT Subject: RFR: 8320706: RuntimePackageTest.testUsrInstallDir test fails on Linux Message-ID: 8320706: RuntimePackageTest.testUsrInstallDir test fails on Linux ------------- Commit messages: - 8320706: RuntimePackageTest.testUsrInstallDir test fails on Linux Changes: https://git.openjdk.org/jdk/pull/16810/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16810&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8320706 Stats: 11 lines in 1 file changed: 7 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/16810.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16810/head:pull/16810 PR: https://git.openjdk.org/jdk/pull/16810 From alanb at openjdk.org Fri Nov 24 16:49:06 2023 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 24 Nov 2023 16:49:06 GMT Subject: RFR: 8319668: Fixup of jar filename typo in BadFactoryTest.sh [v2] In-Reply-To: References: <6mykWP1swWPnVEyhG-sEgEHc4kIMoCdi8_jfXYxDj78=.b4d2c29a-47e6-43c8-82e7-54091b77b3c5@github.com> Message-ID: On Wed, 22 Nov 2023 18:28:30 GMT, Eirik Bjorsnos wrote: > Reviewer time is a scarce resource. It would be wasteful to spend review cycles on getting a fix of this `.sh` test integrated now and then immediately follow up with a delete in the rewrite PR. > > I think we should handle this change in one PR, not two. If you prefer to keep the history of your `.sh` fix documented, we can repurpose this PR, otherwise we start fresh with a new PR for the rewrite. The change here is trivial, it's okay to integrate and use a separate issue/PR to replace the shell test. I can't tell from the bug report if this was just noticed in passing or it actually failed (maybe on an IBM port). ------------- PR Comment: https://git.openjdk.org/jdk/pull/16585#issuecomment-1825910051 From stuefe at openjdk.org Fri Nov 24 16:50:03 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Fri, 24 Nov 2023 16:50:03 GMT Subject: RFR: 8320699: Add parameter to skip progress logging of OutputAnalyzer In-Reply-To: References: Message-ID: On Fri, 24 Nov 2023 10:34:02 GMT, Stefan Karlsson wrote: > Tests using ProcessTools.executeProcess gets the following output written to stdout: > [2023-11-24T09:58:16.797540608Z] Gathering output for process 2517117 > [2023-11-24T09:58:23.070781345Z] Waiting for completion for process 2517117 > [2023-11-24T09:58:23.071045055Z] Waiting for completion finished for process 2517117 > > This might be good for some use cases and debugging, but some tests spawns a large number of processes and for those this output fills up the log files. > > I propose that we add a way to turn of this output for tests where we find this output to be too noisy. I'm fine with this, but would prefer a global switch instead of hard-coding the value per test and handing it down. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16807#issuecomment-1825910975 From jpai at openjdk.org Fri Nov 24 17:04:05 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 24 Nov 2023 17:04:05 GMT Subject: RFR: 8320699: Add parameter to skip progress logging of OutputAnalyzer In-Reply-To: References: Message-ID: <0y4i9H_d10gNIKdCC1deBDjfHtOZQW7GzxPlbDemfU4=.07ad77ad-01cb-4326-b097-51970458d6f9@github.com> On Fri, 24 Nov 2023 10:34:02 GMT, Stefan Karlsson wrote: > Tests using ProcessTools.executeProcess gets the following output written to stdout: > [2023-11-24T09:58:16.797540608Z] Gathering output for process 2517117 > [2023-11-24T09:58:23.070781345Z] Waiting for completion for process 2517117 > [2023-11-24T09:58:23.071045055Z] Waiting for completion finished for process 2517117 > > This might be good for some use cases and debugging, but some tests spawns a large number of processes and for those this output fills up the log files. > > I propose that we add a way to turn of this output for tests where we find this output to be too noisy. Hello Stefan, I agree with David that I have found these logs to be useful - it shows that process launched by the test hasn't yet finished and is being waited upon. The log message when written will have a timestamp and can then also help to quickly understand how long it could have taken for this process to complete. > Right now I much more annoyed by the log files filling up with thousands upon thousands lines of noise, making it harder to actually find the status of the test. This I agree with. It's a co-incidence that just this week when I was looking at some test logs I happened to see such large amount of unexpected logging (not thousands, but large enough). For example: [2023-11-24T11:47:54.557561Z] Waiting for completion for process 24909 [2023-11-24T11:47:54.557873Z] Waiting for completion finished for process 24909 [2023-11-24T11:47:54.612609Z] Waiting for completion for process 24909 [2023-11-24T11:47:54.612682Z] Waiting for completion finished for process 24909 [2023-11-24T11:47:54.614500Z] Waiting for completion for process 24909 [2023-11-24T11:47:54.614542Z] Waiting for completion finished for process 24909 [2023-11-24T11:47:54.640945Z] Waiting for completion for process 24909 [2023-11-24T11:47:54.641115Z] Waiting for completion finished for process 24909 I wonder if something else is going on here, because looking at these logs messages it says that it has finished waiting for a process 24909, yet it keeps repeating those messages. I would have expected it to stop logging after the first: Waiting for completion finished for process 24909 I haven't yet had a chance to look at the code to see if there's some bug which is contributing to this extensive logging. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16807#issuecomment-1825923223 From jpai at openjdk.org Fri Nov 24 17:16:04 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 24 Nov 2023 17:16:04 GMT Subject: RFR: 8320699: Add parameter to skip progress logging of OutputAnalyzer In-Reply-To: References: Message-ID: On Fri, 24 Nov 2023 10:34:02 GMT, Stefan Karlsson wrote: > Tests using ProcessTools.executeProcess gets the following output written to stdout: > [2023-11-24T09:58:16.797540608Z] Gathering output for process 2517117 > [2023-11-24T09:58:23.070781345Z] Waiting for completion for process 2517117 > [2023-11-24T09:58:23.071045055Z] Waiting for completion finished for process 2517117 > > This might be good for some use cases and debugging, but some tests spawns a large number of processes and for those this output fills up the log files. > > I propose that we add a way to turn of this output for tests where we find this output to be too noisy. Perhaps this would help improve/fix the log flooding: diff --git a/test/lib/jdk/test/lib/process/OutputBuffer.java b/test/lib/jdk/test/lib/process/OutputBuffer.java index 3741ccbe2ff..02aedf29f6a 100644 --- a/test/lib/jdk/test/lib/process/OutputBuffer.java +++ b/test/lib/jdk/test/lib/process/OutputBuffer.java @@ -120,6 +120,7 @@ public String get() { private final StreamTask outTask; private final StreamTask errTask; private final Process p; + private volatile Integer processExitCode; // null represents process hasn't yet exited private final void logProgress(String state) { System.out.println("[" + Instant.now().toString() + "] " + state @@ -146,14 +147,18 @@ public String getStderr() { @Override public int getExitValue() { + Integer exitCode = this.processExitCode; + if (exitCode != null) { + return exitCode; + } try { logProgress("Waiting for completion"); boolean aborted = true; try { - int result = p.waitFor(); + processExitCode = exitCode = p.waitFor(); logProgress("Waiting for completion finished"); aborted = false; - return result; + return exitCode; } finally { if (aborted) { logProgress("Waiting for completion FAILED"); Other than a quick local test run, I haven't tested it for anything else. It did improve the situation in one of my test and it now only logs it once. In the setup that you are seeing this large amount of logging, would you be able to see if this change helps there too? ------------- PR Comment: https://git.openjdk.org/jdk/pull/16807#issuecomment-1825932899 From eosterlund at openjdk.org Fri Nov 24 18:30:17 2023 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Fri, 24 Nov 2023 18:30:17 GMT Subject: RFR: 8310644: Make panama memory segment close use async handshakes [v5] In-Reply-To: References: Message-ID: > The current logic for closing memory in panama today is susceptible to live lock if we have a closing thread that wants to close the memory in a loop that keeps failing, and a bunch of accessing threads that want to perform accesses as long as the memory is alive. They can both create impediments for the other. > > By using asynchronous handshakes to install an exception onto threads that are in @Scoped memory accesses, we can have close always succeed, and the accessing threads bail out. The idea is that we perform a synchronous handshake first to find threads that are in scoped methods. They might however be in the middle of throwing an exception or something wild like there, where an exception can't be delivered. We install an async handshake that will roll us forward to the first place where we can indeed install exceptions, then we reevaluate if we still need to do that, or if we have unwound out from the scoped method. If we are still inside of it, we ensure an exception is installed so we don't continue executing bytecodes that might access the memory that we have freed. > > Tested tier 1-5 as well as running test/jdk/java/foreign/TestHandshake.java hundreds of times, which tests this API pretty well. Erik ?sterlund has updated the pull request incrementally with two additional commits since the last revision: - Merge pull request #3 from JornVernee/PR_async_close+NoToNativeTrans - don't transition to native state on Unsafe_CopySwapMemory0 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16792/files - new: https://git.openjdk.org/jdk/pull/16792/files/0b91ac9a..83cef378 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16792&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16792&range=03-04 Stats: 35 lines in 1 file changed: 9 ins; 18 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/16792.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16792/head:pull/16792 PR: https://git.openjdk.org/jdk/pull/16792 From svein.otto.solem at gmail.com Fri Nov 24 19:31:39 2023 From: svein.otto.solem at gmail.com (Svein Otto Solem) Date: Fri, 24 Nov 2023 19:31:39 +0000 Subject: RFR: 8319123: Implement JEP 461: Stream Gatherers (Preview) [v13] Message-ID: Tested the Gatherer implementation, and it is a very nice work. I have always wanted a way of writing my own stream operations and also have incomplete composable pipelines which could be combined in different ways. Very interesting. The four Gatherer functions - initializer/integrator/combiner/finisher - all return function objects. In the javadoc for these Gatherer functions, no requirements are described for these functions. (though API note on class level says "Each invocation of initializer(), integrator(), combiner(), and finisher() must return a semantically identical result.") It would be nice to have the requirements stated on the function level also. Looking at the class level javadoc is not always done. How often and in which sequence these functions are called are of interest, especially for stateful Gatherers. I created a simple gatherer which prints some trace info for these functions (see below). It is tested using branch "pr/16420" of the jdk pr. 21.nov. - The "initializer()" function are in some cases called twice from the library. - The "initializer().get()" function is called only once in the tested scenarios. This is expected since the method is called "initializer", but this behaviour could have been documented. - The sequence these functions are called varies from use case to use case, sometimes the "integrator()" is called before "initializer()". Sometimes the "finisher()" are called before first call to "integrator()", sometimes after. I've marked the unexpected/unneccesary/repeated calls with ? marks. All this may be correct, but is it ? ------------------- Trace -------------------- Using andThen Using separate gathers Using separate gathers with map(identity) Creates WithIndex(A) Creates WithIndex(A) Creates WithIndex(A) Creates WithIndex(B) Creates Integrator(A) Creates Integrator(A) Creates WithIndex(C) Creates WithIndex(B) Creates WithIndex(B) Creates Initializer(A) Creates Initializer(A) Creates Integrator(B) Creates Integrator(A) ?Creates Integrator(A) Creates WithIndex(C) Creates Finisher(A) Creates Finisher(A) Creates Integrator(C) Creates Initializer(B) Creates Initializer(B) Calls Collectors.toList Creates Integrator(B) Creates Integrator(B) Finished Collectors.toList Creates Finisher(B) Creates Finisher(B) ?Creates Integrator(C) Creates Initializer(C) Creates WithIndex(C) ?Creates Integrator(B) Creates Integrator(C) ?Creates Initializer(A) ?Creates Integrator(A) Creates Finisher(C) ?Creates Integrator(A) Creates Initializer(A) Calls Collectors.toList ?Creates Finisher(A) Invokes Initializer(A) Finished Collectors.toList ?Creates Initializer(B) Creates Initializer(B) Invokes Initializer(A) ?Creates Integrator(B) Invokes Initializer(B) Invokes Initializer(B) ?Creates Finisher(B) Creates Initializer(C) Invokes Initializer(C) Creates Initializer(C) Invokes Initializer(C) Invokes Integrator(A) Creates Integrator(C) Invokes Integrator(A) Invokes Integrator(B) Creates Finisher(C) Invokes Integrator(B) Invokes Integrator(C) Calls Collectors.toList Invokes Integrator(C) Invokes Integrator(A) Finished Collectors.toList Invokes Integrator(A) Invokes Integrator(B) Invokes Initializer(A) Invokes Integrator(B) Invokes Integrator(C) Invokes Initializer(B) Invokes Integrator(C) Invokes Integrator(A) Invokes Initializer(C) Invokes Integrator(A) Invokes Integrator(B) Invokes Integrator(A) Invokes Integrator(B) Invokes Integrator(C) Invokes Integrator(B) Invokes Integrator(C) Invokes Finisher(A) Invokes Integrator(C) Creates Finisher(A) Invokes Finisher(B) Invokes Integrator(A) Invokes Finisher(A) Invokes Finisher(C) Invokes Integrator(B) Creates Finisher(B) Invokes Integrator(C) Invokes Finisher(B) Invokes Integrator(A) Creates Finisher(C) Invokes Integrator(B) Invokes Finisher(C) Invokes Integrator(C) Invokes Finisher(A) Invokes Finisher(B) Invokes Finisher(C) ----- Java code -------------------- package org.example; import java.util.List; import java.util.concurrent.atomic.AtomicInteger; import java.util.function.BiConsumer; import java.util.function.Supplier; import java.util.stream.Collector; import java.util.stream.Collectors; import java.util.stream.Gatherer; import java.util.stream.Stream; import static java.lang.StringTemplate.STR; import static java.util.function.Function.identity; public class GatherEx { static Gatherer> withIndex(String name) { return new WithIndexGatherer<>(name); } static class WithIndexGatherer implements Gatherer> { final String name; public WithIndexGatherer(String name) { System.out.println(STR. "Creates WithIndex(\{ name })" ); this.name = name; } @Override public Supplier initializer() { System.out.println(STR. "Creates Initializer(\{ name })" ); return () -> { System.out.println(STR. "Invokes Initializer(\{ name })" ); return new AtomicInteger(0); }; } @Override public Integrator> integrator() { System.out.println(STR. "Creates Integrator(\{ name })" ); return (state, element, downstream) -> { System.out.println(STR. "Invokes Integrator(\{ name })" ); return downstream.push(new Indexed<>(state.getAndIncrement(), element)); }; } @Override public BiConsumer>> finisher() { System.out.println(STR. "Creates Finisher(\{ name })" ); return (_, _) -> { System.out.println(STR. "Invokes Finisher(\{ name })" ); Gatherer.super.finisher(); }; } } record Indexed(int i, T data) { } public static void main(String[] args) { System.out.println("Using andThen"); System.out.println(Stream.of(1, 2, 3) .gather(withIndex("A") .andThen(withIndex("B")) .andThen(withIndex("C"))) .collect(createCollector())); System.out.println("Using separate gathers"); System.out.println(Stream.of(1, 2, 3) .gather(withIndex("A")) .gather(withIndex("B")) .gather(withIndex("C")) .collect(createCollector())); System.out.println("Using separate gathers with map(identity)"); System.out.println(Stream.of(1, 2, 3) .map(identity()) .gather(withIndex("A")) .map(identity()) .gather(withIndex("B")) .map(identity()) .gather(withIndex("C")) .map(identity()) .collect(createCollector())); } private static Collector, ?, List>> createCollector() { System.out.println("Calls Collectors.toList"); try { return Collectors.toList(); } finally { System.out.println("Finished Collectors.toList"); } } } -------------- next part -------------- An HTML attachment was scrubbed... URL: From viktor.klang at oracle.com Fri Nov 24 20:10:33 2023 From: viktor.klang at oracle.com (Viktor Klang) Date: Fri, 24 Nov 2023 20:10:33 +0000 Subject: RFR: 8319123: Implement JEP 461: Stream Gatherers (Preview) [v13] In-Reply-To: References: Message-ID: Thanks for the feedback, Svein -- it is much appreciated! In my mind, the default expectation on Java interfaces is that there is no specified order of invocation around the exposed methods, and unless explicitly stated otherwise it has to be presumed that any order is fine. Given that, and (as you noted) the specified behavior that repeated invocations must return semantically equivalent results, an implementation of an evaluator of a Gatherer must be able to call the Gatherer's initializer(), integrator(), combiner(), and finisher()-methods in any order and 1..N times. That being said, there's an established order upon which the returned functions are to be invoked -- starting with the initializer (presuming initializer != defaultInitializer()), via the integrator, then potentially the combiner, (presuming combiner != defaultCombiner() && we want parallel evaluation), then the finisher (presuming finisher != defaultFinisher()). Getting back to your example output, there's a lot of different things at play, such as (but not limited to) composition (both explicit and implicit), runtime information gathering, hoisting/caching, and more. If you're interested in diving even deeper, having a look at GathererOp is recommended! ? Cheers, ? Viktor Klang Software Architect, Java Platform Group Oracle ________________________________ From: core-libs-dev on behalf of Svein Otto Solem Sent: Friday, 24 November 2023 20:31 To: core-libs-dev at openjdk.org Subject: RFR: 8319123: Implement JEP 461: Stream Gatherers (Preview) [v13] Tested the Gatherer implementation, and it is a very nice work. I have always wanted a way of writing my own stream operations and also have incomplete composable pipelines which could be combined in different ways. Very interesting. The four Gatherer functions - initializer/integrator/combiner/finisher - all return function objects. In the javadoc for these Gatherer functions, no requirements are described for these functions. (though API note on class level says "Each invocation of initializer(), integrator(), combiner(), and finisher() must return a semantically identical result.") It would be nice to have the requirements stated on the function level also. Looking at the class level javadoc is not always done. How often and in which sequence these functions are called are of interest, especially for stateful Gatherers. I created a simple gatherer which prints some trace info for these functions (see below). It is tested using branch "pr/16420" of the jdk pr. 21.nov. - The "initializer()" function are in some cases called twice from the library. - The "initializer().get()" function is called only once in the tested scenarios. This is expected since the method is called "initializer", but this behaviour could have been documented. - The sequence these functions are called varies from use case to use case, sometimes the "integrator()" is called before "initializer()". Sometimes the "finisher()" are called before first call to "integrator()", sometimes after. I've marked the unexpected/unneccesary/repeated calls with ? marks. All this may be correct, but is it ? ------------------- Trace -------------------- Using andThen Using separate gathers Using separate gathers with map(identity) Creates WithIndex(A) Creates WithIndex(A) Creates WithIndex(A) Creates WithIndex(B) Creates Integrator(A) Creates Integrator(A) Creates WithIndex(C) Creates WithIndex(B) Creates WithIndex(B) Creates Initializer(A) Creates Initializer(A) Creates Integrator(B) Creates Integrator(A) ?Creates Integrator(A) Creates WithIndex(C) Creates Finisher(A) Creates Finisher(A) Creates Integrator(C) Creates Initializer(B) Creates Initializer(B) Calls Collectors.toList Creates Integrator(B) Creates Integrator(B) Finished Collectors.toList Creates Finisher(B) Creates Finisher(B) ?Creates Integrator(C) Creates Initializer(C) Creates WithIndex(C) ?Creates Integrator(B) Creates Integrator(C) ?Creates Initializer(A) ?Creates Integrator(A) Creates Finisher(C) ?Creates Integrator(A) Creates Initializer(A) Calls Collectors.toList ?Creates Finisher(A) Invokes Initializer(A) Finished Collectors.toList ?Creates Initializer(B) Creates Initializer(B) Invokes Initializer(A) ?Creates Integrator(B) Invokes Initializer(B) Invokes Initializer(B) ?Creates Finisher(B) Creates Initializer(C) Invokes Initializer(C) Creates Initializer(C) Invokes Initializer(C) Invokes Integrator(A) Creates Integrator(C) Invokes Integrator(A) Invokes Integrator(B) Creates Finisher(C) Invokes Integrator(B) Invokes Integrator(C) Calls Collectors.toList Invokes Integrator(C) Invokes Integrator(A) Finished Collectors.toList Invokes Integrator(A) Invokes Integrator(B) Invokes Initializer(A) Invokes Integrator(B) Invokes Integrator(C) Invokes Initializer(B) Invokes Integrator(C) Invokes Integrator(A) Invokes Initializer(C) Invokes Integrator(A) Invokes Integrator(B) Invokes Integrator(A) Invokes Integrator(B) Invokes Integrator(C) Invokes Integrator(B) Invokes Integrator(C) Invokes Finisher(A) Invokes Integrator(C) Creates Finisher(A) Invokes Finisher(B) Invokes Integrator(A) Invokes Finisher(A) Invokes Finisher(C) Invokes Integrator(B) Creates Finisher(B) Invokes Integrator(C) Invokes Finisher(B) Invokes Integrator(A) Creates Finisher(C) Invokes Integrator(B) Invokes Finisher(C) Invokes Integrator(C) Invokes Finisher(A) Invokes Finisher(B) Invokes Finisher(C) ----- Java code -------------------- package org.example; import java.util.List; import java.util.concurrent.atomic.AtomicInteger; import java.util.function.BiConsumer; import java.util.function.Supplier; import java.util.stream.Collector; import java.util.stream.Collectors; import java.util.stream.Gatherer; import java.util.stream.Stream; import static java.lang.StringTemplate.STR; import static java.util.function.Function.identity; public class GatherEx { static Gatherer> withIndex(String name) { return new WithIndexGatherer<>(name); } static class WithIndexGatherer implements Gatherer> { final String name; public WithIndexGatherer(String name) { System.out.println(STR. "Creates WithIndex(\{ name })" ); this.name = name; } @Override public Supplier initializer() { System.out.println(STR. "Creates Initializer(\{ name })" ); return () -> { System.out.println(STR. "Invokes Initializer(\{ name })" ); return new AtomicInteger(0); }; } @Override public Integrator> integrator() { System.out.println(STR. "Creates Integrator(\{ name })" ); return (state, element, downstream) -> { System.out.println(STR. "Invokes Integrator(\{ name })" ); return downstream.push(new Indexed<>(state.getAndIncrement(), element)); }; } @Override public BiConsumer>> finisher() { System.out.println(STR. "Creates Finisher(\{ name })" ); return (_, _) -> { System.out.println(STR. "Invokes Finisher(\{ name })" ); Gatherer.super.finisher(); }; } } record Indexed(int i, T data) { } public static void main(String[] args) { System.out.println("Using andThen"); System.out.println(Stream.of(1, 2, 3) .gather(withIndex("A") .andThen(withIndex("B")) .andThen(withIndex("C"))) .collect(createCollector())); System.out.println("Using separate gathers"); System.out.println(Stream.of(1, 2, 3) .gather(withIndex("A")) .gather(withIndex("B")) .gather(withIndex("C")) .collect(createCollector())); System.out.println("Using separate gathers with map(identity)"); System.out.println(Stream.of(1, 2, 3) .map(identity()) .gather(withIndex("A")) .map(identity()) .gather(withIndex("B")) .map(identity()) .gather(withIndex("C")) .map(identity()) .collect(createCollector())); } private static Collector, ?, List>> createCollector() { System.out.println("Calls Collectors.toList"); try { return Collectors.toList(); } finally { System.out.println("Finished Collectors.toList"); } } } -------------- next part -------------- An HTML attachment was scrubbed... URL: From iris at openjdk.org Fri Nov 24 20:21:04 2023 From: iris at openjdk.org (Iris Clark) Date: Fri, 24 Nov 2023 20:21:04 GMT Subject: RFR: 8320440: Implementation of Structured Concurrency (Second Preview) In-Reply-To: <4t6NzmCd-0w-y7iT51fEttO7gEArgRuCeEl4yeNIzd0=.cd7bbed3-1117-4fc1-9241-255e6e10e2f1@github.com> References: <4t6NzmCd-0w-y7iT51fEttO7gEArgRuCeEl4yeNIzd0=.cd7bbed3-1117-4fc1-9241-255e6e10e2f1@github.com> Message-ID: On Mon, 20 Nov 2023 19:48:20 GMT, Alan Bateman wrote: > This API is sitting out JDK 22, meaning no API/implementation changes in this PR. We expect this API to do a third preview in JDK 23 with some API changes. > > So for now, we just need to bump JEP number/title that shows up in the preview section of the javadoc. Marked as reviewed by iris (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/16748#pullrequestreview-1748399014 From asemenyuk at openjdk.org Fri Nov 24 22:27:21 2023 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Fri, 24 Nov 2023 22:27:21 GMT Subject: RFR: 8320249: tools/jpackage/share/AddLauncherTest.java#id1 fails intermittently on Windows in verifyDescription Message-ID: 8320249: tools/jpackage/share/AddLauncherTest.java#id1 fails intermittently on Windows in verifyDescription ------------- Commit messages: - 8320249: tools/jpackage/share/AddLauncherTest.java#id1 fails intermittently on Windows in verifyDescription Changes: https://git.openjdk.org/jdk/pull/16814/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16814&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8320249 Stats: 60 lines in 8 files changed: 31 ins; 0 del; 29 mod Patch: https://git.openjdk.org/jdk/pull/16814.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16814/head:pull/16814 PR: https://git.openjdk.org/jdk/pull/16814 From asemenyuk at openjdk.org Fri Nov 24 22:31:18 2023 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Fri, 24 Nov 2023 22:31:18 GMT Subject: RFR: 8320249: tools/jpackage/share/AddLauncherTest.java#id1 fails intermittently on Windows in verifyDescription [v2] In-Reply-To: References: Message-ID: > 8320249: tools/jpackage/share/AddLauncherTest.java#id1 fails intermittently on Windows in verifyDescription Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision: fix utf8 representation ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16814/files - new: https://git.openjdk.org/jdk/pull/16814/files/50d81036..7b803bce Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16814&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16814&range=00-01 Stats: 17 lines in 1 file changed: 0 ins; 0 del; 17 mod Patch: https://git.openjdk.org/jdk/pull/16814.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16814/head:pull/16814 PR: https://git.openjdk.org/jdk/pull/16814 From dholmes at openjdk.org Sat Nov 25 00:08:04 2023 From: dholmes at openjdk.org (David Holmes) Date: Sat, 25 Nov 2023 00:08:04 GMT Subject: RFR: 8320699: Add parameter to skip progress logging of OutputAnalyzer In-Reply-To: References: Message-ID: On Fri, 24 Nov 2023 17:13:30 GMT, Jaikiran Pai wrote: >> Tests using ProcessTools.executeProcess gets the following output written to stdout: >> [2023-11-24T09:58:16.797540608Z] Gathering output for process 2517117 >> [2023-11-24T09:58:23.070781345Z] Waiting for completion for process 2517117 >> [2023-11-24T09:58:23.071045055Z] Waiting for completion finished for process 2517117 >> >> This might be good for some use cases and debugging, but some tests spawns a large number of processes and for those this output fills up the log files. >> >> I propose that we add a way to turn of this output for tests where we find this output to be too noisy. > > Perhaps this would help improve/fix the log flooding: > > > diff --git a/test/lib/jdk/test/lib/process/OutputBuffer.java b/test/lib/jdk/test/lib/process/OutputBuffer.java > index 3741ccbe2ff..02aedf29f6a 100644 > --- a/test/lib/jdk/test/lib/process/OutputBuffer.java > +++ b/test/lib/jdk/test/lib/process/OutputBuffer.java > @@ -120,6 +120,7 @@ public String get() { > private final StreamTask outTask; > private final StreamTask errTask; > private final Process p; > + private volatile Integer processExitCode; // null represents process hasn't yet exited > > private final void logProgress(String state) { > System.out.println("[" + Instant.now().toString() + "] " + state > @@ -146,14 +147,18 @@ public String getStderr() { > > @Override > public int getExitValue() { > + Integer exitCode = this.processExitCode; > + if (exitCode != null) { > + return exitCode; > + } > try { > logProgress("Waiting for completion"); > boolean aborted = true; > try { > - int result = p.waitFor(); > + processExitCode = exitCode = p.waitFor(); > logProgress("Waiting for completion finished"); > aborted = false; > - return result; > + return exitCode; > } finally { > if (aborted) { > logProgress("Waiting for completion FAILED"); > > > Other than a quick local test run, I haven't tested it for anything else. It did improve the situation in one of my test and it now only logs it once. In the setup that you are seeing this large amount of logging, would you be able to see if this change helps there too? @jaikiran that looks like a good fix to me. It doesn't make sense to keep repeating the logging on every `getExitValue` call. Good find! ------------- PR Comment: https://git.openjdk.org/jdk/pull/16807#issuecomment-1826150703 From jpai at openjdk.org Sat Nov 25 06:31:03 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Sat, 25 Nov 2023 06:31:03 GMT Subject: RFR: 8320440: Implementation of Structured Concurrency (Second Preview) In-Reply-To: <4t6NzmCd-0w-y7iT51fEttO7gEArgRuCeEl4yeNIzd0=.cd7bbed3-1117-4fc1-9241-255e6e10e2f1@github.com> References: <4t6NzmCd-0w-y7iT51fEttO7gEArgRuCeEl4yeNIzd0=.cd7bbed3-1117-4fc1-9241-255e6e10e2f1@github.com> Message-ID: On Mon, 20 Nov 2023 19:48:20 GMT, Alan Bateman wrote: > This API is sitting out JDK 22, meaning no API/implementation changes in this PR. We expect this API to do a third preview in JDK 23 with some API changes. > > So for now, we just need to bump JEP number/title that shows up in the preview section of the javadoc. Looks OK to me. ------------- Marked as reviewed by jpai (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16748#pullrequestreview-1748785199 From jpai at openjdk.org Sat Nov 25 06:46:10 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Sat, 25 Nov 2023 06:46:10 GMT Subject: RFR: 8320532: Remove Thread/ThreadGroup suspend/resume In-Reply-To: References: Message-ID: On Thu, 23 Nov 2023 09:18:44 GMT, Alan Bateman wrote: > The deadlock prone Thread/ThreadGroup suspend/resume were deprecated since JDK 1.2, deprecated for removal in Java 14, and re-specified/degraded to throw UnsupportedOperationException unconditionally in Java 19/20. Early in Java 23 seems a fine time to finally remove these methods. > > Corpus analysis of 176 million classes in 485k artifacts found no remaining usages of ThreadGroup.suspend/resume beyond the artifacts that include a copy of java.lang.ThreadGroup (!). It found 87 remaining uses of Thread.suspend and 86 remaining usages of Thread.resume, some of these are tests. > > Thread.suspend/resume have always linked to the "Java Thread Primitive Deprecation" page. This originally explained the reasons why suspend/resume were deprecated. When these methods were degraded to throw UOE we changed the text to explain why the ability to suspend or resume a thread was removed. Now we must change it again. One choice is to re-word to explain why the Java APIs were removed or why the Java APIs don't define a way to suspend/resume threads, the other choice (which I prefer) is to remove the text. > > The method description of java.lang.management.ThreadInfo.isSuspended is tweaked to link to JVMTI SuspendThread instead of Thread.suspend The changes look fine to me. `SendUrgentData` is missing a copyright year update. ------------- Marked as reviewed by jpai (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16789#pullrequestreview-1748786335 From duke at openjdk.org Sat Nov 25 16:48:07 2023 From: duke at openjdk.org (Eirik Bjorsnos) Date: Sat, 25 Nov 2023 16:48:07 GMT Subject: RFR: 8319668: Fixup of jar filename typo in BadFactoryTest.sh [v2] In-Reply-To: References: <6mykWP1swWPnVEyhG-sEgEHc4kIMoCdi8_jfXYxDj78=.b4d2c29a-47e6-43c8-82e7-54091b77b3c5@github.com> Message-ID: <6o2bpFznW1fNEdjAcVI92nkENfhm1t8Vn2o1gtEJwl8=.b7fced34-9827-4c42-a267-2cf182dd926e@github.com> On Fri, 24 Nov 2023 16:46:05 GMT, Alan Bateman wrote: > The change here is trivial, it's okay to integrate and use a separate issue/PR to replace the shell test. Fair point, I filed https://bugs.openjdk.org/browse/JDK-8320712 to track the rewrite. @Deigue, would you like to contribute a PR for the rewrite as well? If not, I'll be happy to take on this task. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16585#issuecomment-1826374488 From xgong at openjdk.org Mon Nov 27 00:59:10 2023 From: xgong at openjdk.org (Xiaohong Gong) Date: Mon, 27 Nov 2023 00:59:10 GMT Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations with SLEEF [v4] In-Reply-To: References: <3dscjw75an6_n3ko_2LjHdpdj08xsyjhfpStuZrS5-M=.f43592fe-036e-47b5-babc-67f126885839@github.com> Message-ID: On Thu, 23 Nov 2023 14:10:02 GMT, Magnus Ihse Bursie wrote: >> Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision: >> >> Address review comments in build system > > make/autoconf/lib-vmath.m4 line 89: > >> 87: if test "x${LIBSLEEF_FOUND}" = "xyes"; then >> 88: ENABLE_LIBSLEEF=true >> 89: LIBVMATH_LIBS="${LIBVMATH_LIBS} -lsleef" > > Remove this line. It would just add `-lsleef` twice if you go via `PKG_CHECK_MODULES`. You need to set -lsleef at the correct places. Correct. Thanks! I will adjust all the relative names/cflags once the sve cflags is removed in the m4 file. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16234#discussion_r1405526805 From xgong at openjdk.org Mon Nov 27 00:59:12 2023 From: xgong at openjdk.org (Xiaohong Gong) Date: Mon, 27 Nov 2023 00:59:12 GMT Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations with SLEEF [v3] In-Reply-To: <-XS17AVgOkuO6_JUId8P-XZxRlnfWXF0wz60w5B58L8=.e51cb13b-ec84-4943-a6b7-b09b4e8943d4@github.com> References: <_CHm262chkVi3EMvai4A5T-dal0pdCySL8aF0kXj_uU=.9d49baad-9de9-45e0-915b-9525feb8d610@github.com> <-XS17AVgOkuO6_JUId8P-XZxRlnfWXF0wz60w5B58L8=.e51cb13b-ec84-4943-a6b7-b09b4e8943d4@github.com> Message-ID: On Thu, 23 Nov 2023 14:01:48 GMT, Magnus Ihse Bursie wrote: >> OK, I see. It makes sense that the suffix name should be choosed mainly based on the real module name that is searched/checked in configure. > > This still needs fixing. Yes, I will fix this together with removing the SVE cflags which I need more time to handle it with a better way. Thanks! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16234#discussion_r1405526236 From xgong at openjdk.org Mon Nov 27 01:09:11 2023 From: xgong at openjdk.org (Xiaohong Gong) Date: Mon, 27 Nov 2023 01:09:11 GMT Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations with SLEEF [v4] In-Reply-To: References: <3dscjw75an6_n3ko_2LjHdpdj08xsyjhfpStuZrS5-M=.f43592fe-036e-47b5-babc-67f126885839@github.com> Message-ID: <17T7DXMTf1rFVeQY_FWJx0DETVYlBWceJO4lltWZyw0=.847b02a3-ef40-464a-80b7-d62bd9dbc2b5@github.com> On Thu, 23 Nov 2023 15:43:34 GMT, Andrew Haley wrote: >> Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision: >> >> Address review comments in build system > > make/autoconf/lib-vmath.m4 line 94: > >> 92: # Check the ARM SVE feature >> 93: SVE_CFLAGS="-march=armv8-a+sve" >> 94: > > What's this about? We're building a standard binary, and all SVE detection is to be deferred to runtime. We have to use this c-compiler option to build out the SVE ABIs (e.g. `svfloat32_t sinfx_u10sve(svfloat32_t input)`) in `libvmath.so`. Without this option, at build time, all the sve related featues like `arm_sve.h / __ARM_FEATURE_SVE` are missing, together with the sve symbols in `libvmath.so` we needed at runtime. That means at runtime, hotspot cannot find out the sve symbols and the vector operations will fall back to the default java implementation. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16234#discussion_r1405529521 From thartmann at openjdk.org Mon Nov 27 07:44:08 2023 From: thartmann at openjdk.org (Tobias Hartmann) Date: Mon, 27 Nov 2023 07:44:08 GMT Subject: RFR: 8310159: Bulk copy with Unsafe::arrayCopy is slower compared to memcpy [v6] In-Reply-To: References: Message-ID: On Tue, 21 Nov 2023 21:03:20 GMT, Steve Dohrmann wrote: >> Update: the XorTest::xor results shown in this message used test code from PR commit 7cc272e862791 which was based on Maurizio Cimadamore's commit a788f066af17. The XorTest has since been updated and XorTest::copy is no longer needed and has been removed from this pull request. See comment [here](https://github.com/openjdk/jdk/pull/16575#issuecomment-1820006548) for updated performance data. >> >> Below is baseline data collected using a modified version of the java.lang.foreign.xor micro benchmark referenced by @mcimadamore in the bug report. I collected data on an Ubuntu 22.04 laptop with a Tigerlake i7-1185G7, which does support AVX512. >> >> Baseline data >> Benchmark (arrayKind) (sizeKind) Mode Cnt Score Error Units >> -------------------------------------------------------------------------------------- >> XorTest.copy ELEMENTS SMALL avgt 30 584737355.767 ? 60414308.540 ns/op >> XorTest.copy ELEMENTS MEDIUM avgt 30 272248995.683 ? 2924954.498 ns/op >> XorTest.copy ELEMENTS LARGE avgt 30 1019200210.900 ? 28334453.652 ns/op >> XorTest.copy REGION SMALL avgt 30 7399944.164 ? 216821.819 ns/op >> XorTest.copy REGION MEDIUM avgt 30 20591454.558 ? 147398.572 ns/op >> XorTest.copy REGION LARGE avgt 30 21649266.051 ? 179263.875 ns/op >> XorTest.copy CRITICAL SMALL avgt 30 51079.357 ? 542.482 ns/op >> XorTest.copy CRITICAL MEDIUM avgt 30 2496.961 ? 11.375 ns/op >> XorTest.copy CRITICAL LARGE avgt 30 515.454 ? 5.831 ns/op >> XorTest.copy FOREIGN SMALL avgt 30 7558432.075 ? 79489.276 ns/op >> XorTest.copy FOREIGN MEDIUM avgt 30 19730666.341 ? 500505.099 ns/op >> XorTest.copy FOREIGN LARGE avgt 30 34616758.085 ? 340300.726 ns/op >> XorTest.xor ELEMENTS SMALL avgt 30 219832692.489 ? 2329417.319 ns/op >> XorTest.xor ELEMENTS MEDIUM avgt 30 505138197.167 ? 3818334.424 ns/op >> XorTest.xor ELEMENTS LARGE avgt 30 1189608474.667 ? 5877981.900 ns/op >> XorTest.xor REGION SMALL avgt 30 64093872.804 ? 599704.491 ns/op >> XorTest.xor REGION MEDIUM avgt 30 81544576.454 ? 1406342.118 ns/op >> XorTest.xor REGION LARGE avgt 30 90091424.883 ? 775577.613 ns/op >> XorTest.xor CRITICAL SMALL avgt ... > > Steve Dohrmann has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits: > > - Merge branch 'master' into memcpy > - Updates based on reviewer (sviswa7) comments including > - use asserts instead of conditionals in two logically unreachable blocks > - remove unused function parmeters > - use 64-byte vector path in pre-loop masked write > - Merge branch 'master' into memcpy > - Update full name > Previous commit (fcbbc0d7880) added org.openjdk.bench.java.lang.ArrayCopyAlignedLarge benchmark > - - remerge upstream master > - remove ::copy test from XorTest > - Merge branch 'master' into memcpy > - - fix whitespace error > - Merge branch 'master' of https://git.openjdk.org/jdk into memcpy > - - bug fix: only generate / use large copy code if MaxVectorSize == 64 > - - fix whitespace issues > - fix xor test foreign impl constructor signature > - ... and 1 more: https://git.openjdk.org/jdk/compare/e47cf611...02ad27fa Correctness and performance testing passed. ------------- Marked as reviewed by thartmann (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16575#pullrequestreview-1749803030 From alanb at openjdk.org Mon Nov 27 07:57:05 2023 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 27 Nov 2023 07:57:05 GMT Subject: RFR: 8320618: NPE: Cannot invoke "java.lang.constant.ClassDesc.isArray()" because "this.sym" is null In-Reply-To: References: Message-ID: <0n2TyznlvEA0-xRKRPZFWg26xOgtv6w7Fpb3NEuesk4=.dd1c5088-475c-4aab-acbd-5b56287a2c3a@github.com> On Thu, 23 Nov 2023 11:52:05 GMT, Adam Sotona wrote: > ClassFile API StackMapGenerator caused a NPE for a test case with invalid sequence of instructions. > This fix simply avoids the NPE and adds StackMapsTest::testInvalidAALOADStack > > Please review. > > Thanks, > Adam Marked as reviewed by alanb (Reviewer). Good find. ------------- PR Review: https://git.openjdk.org/jdk/pull/16793#pullrequestreview-1749823985 Marked as reviewed by alanb (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16793#pullrequestreview-1749825267 From alanb at openjdk.org Mon Nov 27 08:07:06 2023 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 27 Nov 2023 08:07:06 GMT Subject: RFR: 8320665: update jdk_core at test/jdk/TEST.groups In-Reply-To: References: Message-ID: <_bGb6mv5_Y4kgakm0VSvtwC1QMzY2zWY9pwaZXnSSDc=.1ee3e6ca-c069-4711-bfe1-ce0d309e21ac@github.com> On Fri, 24 Nov 2023 11:28:23 GMT, Ivan ?ipka wrote: > > I use the jdk_core test group. I know the split doesn't impact users of this test group but it's not clear why the change is being done. Would it be possible to explain why you are doing this? There is nothing in the JBS issue or PR to explain. > > explained in private communication: refactoring of internally used files to enable ergonomic result analysis for internal processes My concern with changes like this is that it's just adding to the complexity of the definitions of important test groups. I think we need a new section/heading at the end of the file as the place to put these special test runs (esp. the manual tests). For jdk_core_no_security then my strong preference is not to hack the existing test group configurations, instead add this to the special runs section at the end: jdk_core_no_security = \ :jdk_core \ -:jdk_security ------------- PR Comment: https://git.openjdk.org/jdk/pull/16796#issuecomment-1827322376 From clanger at openjdk.org Mon Nov 27 08:25:18 2023 From: clanger at openjdk.org (Christoph Langer) Date: Mon, 27 Nov 2023 08:25:18 GMT Subject: Integrated: 8320601: ProblemList java/lang/invoke/lambda/LambdaFileEncodingSerialization.java on linux-all In-Reply-To: References: Message-ID: On Wed, 22 Nov 2023 15:59:38 GMT, Christoph Langer wrote: > java/lang/invoke/lambda/LambdaFileEncodingSerialization.java is already problem listed on linux-x64. However, the issue is not processor specific. We see the failure on linux on other architectures as well. This pull request has now been integrated. Changeset: f6e5559a Author: Christoph Langer URL: https://git.openjdk.org/jdk/commit/f6e5559ae9d1c8b84b31af5d36e93b43e7731ba5 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8320601: ProblemList java/lang/invoke/lambda/LambdaFileEncodingSerialization.java on linux-all Reviewed-by: mbaesken ------------- PR: https://git.openjdk.org/jdk/pull/16784 From asotona at openjdk.org Mon Nov 27 08:28:18 2023 From: asotona at openjdk.org (Adam Sotona) Date: Mon, 27 Nov 2023 08:28:18 GMT Subject: Integrated: 8320618: NPE: Cannot invoke "java.lang.constant.ClassDesc.isArray()" because "this.sym" is null In-Reply-To: References: Message-ID: On Thu, 23 Nov 2023 11:52:05 GMT, Adam Sotona wrote: > ClassFile API StackMapGenerator caused a NPE for a test case with invalid sequence of instructions. > This fix simply avoids the NPE and adds StackMapsTest::testInvalidAALOADStack > > Please review. > > Thanks, > Adam This pull request has now been integrated. Changeset: 28d3762b Author: Adam Sotona URL: https://git.openjdk.org/jdk/commit/28d3762bd30a31623f2ed97a1870313d3a2b9acb Stats: 15 lines in 2 files changed: 12 ins; 1 del; 2 mod 8320618: NPE: Cannot invoke "java.lang.constant.ClassDesc.isArray()" because "this.sym" is null Reviewed-by: alanb ------------- PR: https://git.openjdk.org/jdk/pull/16793 From stefank at openjdk.org Mon Nov 27 08:30:07 2023 From: stefank at openjdk.org (Stefan Karlsson) Date: Mon, 27 Nov 2023 08:30:07 GMT Subject: RFR: 8320699: Add parameter to skip progress logging of OutputAnalyzer In-Reply-To: References: Message-ID: On Fri, 24 Nov 2023 17:13:30 GMT, Jaikiran Pai wrote: > Other than a quick local test run, I haven't tested it for anything else. It did improve the situation in one of my test and it now only logs it once. In the setup that you are seeing this large amount of logging, would you be able to see if this change helps there too? The place where I would like to use it we repeatedly spawn a number of different processes to inspect the JVM and the OS. So, I think you have found a separate issue. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16807#issuecomment-1827352788 From stefank at openjdk.org Mon Nov 27 09:09:06 2023 From: stefank at openjdk.org (Stefan Karlsson) Date: Mon, 27 Nov 2023 09:09:06 GMT Subject: RFR: 8320699: Add parameter to skip progress logging of OutputAnalyzer In-Reply-To: <0y4i9H_d10gNIKdCC1deBDjfHtOZQW7GzxPlbDemfU4=.07ad77ad-01cb-4326-b097-51970458d6f9@github.com> References: <0y4i9H_d10gNIKdCC1deBDjfHtOZQW7GzxPlbDemfU4=.07ad77ad-01cb-4326-b097-51970458d6f9@github.com> Message-ID: On Fri, 24 Nov 2023 17:01:29 GMT, Jaikiran Pai wrote: > Hello Stefan, I agree with David that I have found these logs to be useful - it shows that process launched by the test hasn't yet finished and is being waited upon. The log message when written will have a timestamp and can then also help to quickly understand how long it could have taken for this process to complete. The test were I want to use this is a long-running stress test that is known to be good at shaking out JVM hangs. It has been written to provide its own output about spawned processes and what they are doing, and have that info written to appropriate files. For me, the OutputAnalyzer logging just adds redundant output to the streams where I don't want the information. When we do have JVM hangs in these larger tests it's usually is easier to look at the output generated from [test/failure_handler](https://github.com/openjdk/jdk/tree/master/test/failure_handler). ------------- PR Comment: https://git.openjdk.org/jdk/pull/16807#issuecomment-1827410018 From asotona at openjdk.org Mon Nov 27 09:20:34 2023 From: asotona at openjdk.org (Adam Sotona) Date: Mon, 27 Nov 2023 09:20:34 GMT Subject: RFR: 8308753: Class-File API transition to Preview [v31] In-Reply-To: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com> References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com> Message-ID: <96gFYL2iQI4xJubLzYNfxYbB2_D7xXqrR9FSWd4zN0s=.f11bc6d0-4c67-44be-820a-3e1f76fd9a49@github.com> > Classfile API is an internal library under package `jdk.internal.classfile`?in JDK 21. > This pull request turns the Classfile API into a preview feature and moves it into `java.lang.classfile`. > It repackages all uses across JDK and tests and adds lots of missing Javadoc. > > This PR goes in sync with?[JDK-8308754](https://bugs.openjdk.org/browse/JDK-8308754): Class-File API (Preview) (CSR) > and?[JDK-8280389](https://bugs.openjdk.org/browse/JDK-8280389): Class-File API (Preview) (JEP). > > Online javadoc is available at:? > https://cr.openjdk.org/~asotona/JDK-8308753-preview/api/java.base/java/lang/classfile/package-summary.html > > In addition to the primary transition to preview, this pull request also includes: > - All?Classfile*?classes ranamed to?ClassFile*?(based on JEP discussion). > - A new preview feature, `CLASSFILE_API`, has been added. > - Buildsystem tool required a little patch to support annotated modules. > - All JDK modules using the Classfile API are newly participating in the preview. > - All tests that use the Classfile API now have preview enabled. > - A few Javac tests not allowing preview have been partially reverted; their conversion can be re-applied when the Classfile API leaves preview mode. > > Despite the number of affected files, this pull request is relatively straight-forward. The preview version of the Classfile API is based on the internal version of the library from the JDK master branch, and there are no API features added. > > Please review this pull request to help the Classfile API turn into a preview. > > Any comments are welcome. > > Thanks, > Adam Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 369 commits: - fixed SwitchBootstrap and StackMapsTest - fixed SwtichBootstrapTest and ModuleVersionTest - Merge branch 'master' into JDK-8308753-preview - Merge branch 'master' into JDK-8308753-preview # Conflicts: # test/jdk/jdk/classfile/StackMapsTest.java - Merge branch 'master' into JDK-8308753-preview # Conflicts: # test/langtools/tools/javac/7199823/InnerClassCannotBeVerified.java - added new package-info snippets and fixed ClassFile::parse throws javadoc description - fixed lambda tests - Merge branch 'master' into JDK-8308753-preview - fixed SignaturesTest - fixed condy tests - ... and 359 more: https://git.openjdk.org/jdk/compare/28d3762b...deb064fc ------------- Changes: https://git.openjdk.org/jdk/pull/15706/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15706&range=30 Stats: 32361 lines in 787 files changed: 14660 ins; 14113 del; 3588 mod Patch: https://git.openjdk.org/jdk/pull/15706.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15706/head:pull/15706 PR: https://git.openjdk.org/jdk/pull/15706 From asotona at openjdk.org Mon Nov 27 10:01:50 2023 From: asotona at openjdk.org (Adam Sotona) Date: Mon, 27 Nov 2023 10:01:50 GMT Subject: RFR: 8308753: Class-File API transition to Preview [v32] In-Reply-To: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com> References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com> Message-ID: <9-Fm-UXpDT0FLAxTw9xve00qurpqv01xw1uJwG0IXKQ=.06a9e0da-7a8c-462b-9b7a-b1be1b9bff5f@github.com> > Classfile API is an internal library under package `jdk.internal.classfile`?in JDK 21. > This pull request turns the Classfile API into a preview feature and moves it into `java.lang.classfile`. > It repackages all uses across JDK and tests and adds lots of missing Javadoc. > > This PR goes in sync with?[JDK-8308754](https://bugs.openjdk.org/browse/JDK-8308754): Class-File API (Preview) (CSR) > and?[JDK-8280389](https://bugs.openjdk.org/browse/JDK-8280389): Class-File API (Preview) (JEP). > > Online javadoc is available at:? > https://cr.openjdk.org/~asotona/JDK-8308753-preview/api/java.base/java/lang/classfile/package-summary.html > > In addition to the primary transition to preview, this pull request also includes: > - All?Classfile*?classes ranamed to?ClassFile*?(based on JEP discussion). > - A new preview feature, `CLASSFILE_API`, has been added. > - Buildsystem tool required a little patch to support annotated modules. > - All JDK modules using the Classfile API are newly participating in the preview. > - All tests that use the Classfile API now have preview enabled. > - A few Javac tests not allowing preview have been partially reverted; their conversion can be re-applied when the Classfile API leaves preview mode. > > Despite the number of affected files, this pull request is relatively straight-forward. The preview version of the Classfile API is based on the internal version of the library from the JDK master branch, and there are no API features added. > > Please review this pull request to help the Classfile API turn into a preview. > > Any comments are welcome. > > Thanks, > Adam Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: fixed SwitchBootstrapTest ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15706/files - new: https://git.openjdk.org/jdk/pull/15706/files/deb064fc..dd9a4aa7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15706&range=31 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15706&range=30-31 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 aph at openjdk.org Mon Nov 27 10:31:13 2023 From: aph at openjdk.org (Andrew Haley) Date: Mon, 27 Nov 2023 10:31:13 GMT Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations with SLEEF [v4] In-Reply-To: <17T7DXMTf1rFVeQY_FWJx0DETVYlBWceJO4lltWZyw0=.847b02a3-ef40-464a-80b7-d62bd9dbc2b5@github.com> References: <3dscjw75an6_n3ko_2LjHdpdj08xsyjhfpStuZrS5-M=.f43592fe-036e-47b5-babc-67f126885839@github.com> <17T7DXMTf1rFVeQY_FWJx0DETVYlBWceJO4lltWZyw0=.847b02a3-ef40-464a-80b7-d62bd9dbc2b5@github.com> Message-ID: On Mon, 27 Nov 2023 01:06:21 GMT, Xiaohong Gong wrote: >> make/autoconf/lib-vmath.m4 line 94: >> >>> 92: # Check the ARM SVE feature >>> 93: SVE_CFLAGS="-march=armv8-a+sve" >>> 94: >> >> What's this about? We're building a standard binary, and all SVE detection is to be deferred to runtime. > > We have to use this c-compiler option to build out the SVE ABIs (e.g. `svfloat32_t sinfx_u10sve(svfloat32_t input)`) in `libvmath.so`. Without this option, at build time, all the sve related featues like `arm_sve.h / __ARM_FEATURE_SVE` are missing, together with the sve symbols in `libvmath.so` we needed at runtime. That means at runtime, hotspot cannot find out the sve symbols and the vector operations will fall back to the default java implementation. That's fine, but we must make sure that SVE is not used by the compiler in any other places. If you've already built on non-SVE and tested the result on both SVE and non-SVE, I'm happy. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16234#discussion_r1405950723 From mcimadamore at openjdk.org Mon Nov 27 11:39:10 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 27 Nov 2023 11:39:10 GMT Subject: RFR: 8310644: Make panama memory segment close use async handshakes [v5] In-Reply-To: References: Message-ID: On Fri, 24 Nov 2023 18:30:17 GMT, Erik ?sterlund wrote: >> The current logic for closing memory in panama today is susceptible to live lock if we have a closing thread that wants to close the memory in a loop that keeps failing, and a bunch of accessing threads that want to perform accesses as long as the memory is alive. They can both create impediments for the other. >> >> By using asynchronous handshakes to install an exception onto threads that are in @Scoped memory accesses, we can have close always succeed, and the accessing threads bail out. The idea is that we perform a synchronous handshake first to find threads that are in scoped methods. They might however be in the middle of throwing an exception or something wild like there, where an exception can't be delivered. We install an async handshake that will roll us forward to the first place where we can indeed install exceptions, then we reevaluate if we still need to do that, or if we have unwound out from the scoped method. If we are still inside of it, we ensure an exception is installed so we don't continue executing bytecodes that might access the memory that we have freed. >> >> Tested tier 1-5 as well as running test/jdk/java/foreign/TestHandshake.java hundreds of times, which tests this API pretty well. > > Erik ?sterlund has updated the pull request incrementally with two additional commits since the last revision: > > - Merge pull request #3 from JornVernee/PR_async_close+NoToNativeTrans > > - don't transition to native state on Unsafe_CopySwapMemory0 The new logic looks good. Good catch on the array copy with swap! ------------- Marked as reviewed by mcimadamore (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16792#pullrequestreview-1750232220 From core-libs-dev at io7m.com Mon Nov 27 11:44:11 2023 From: core-libs-dev at io7m.com (Mark Raynsford) Date: Mon, 27 Nov 2023 11:44:11 +0000 Subject: Automatic modules and jpackage Message-ID: I'm not entirely convinced that discussion on this list doesn't get lost in the endless sea of "RFR: " messages. :) For reference, here are the adventures I undertook that got me stuck on jpackage's hard requirements for named modules: https://blog.io7m.com/2023/11/10/batch-files-are-your-only-option.xhtml I'd love to use jpackage, but it seems that only classpath applications or 100% named module applications can work. I'm about 95% named modules, and some of the modules will almost certainly never be fully named. I've mentored a lot of open source projects through fully modularizing, but some projects just don't have the resources to do the work. -- Mark Raynsford | https://www.io7m.com From sspitsyn at openjdk.org Mon Nov 27 12:27:09 2023 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Mon, 27 Nov 2023 12:27:09 GMT Subject: RFR: 8320532: Remove Thread/ThreadGroup suspend/resume In-Reply-To: References: Message-ID: On Thu, 23 Nov 2023 09:18:44 GMT, Alan Bateman wrote: > The deadlock prone Thread/ThreadGroup suspend/resume were deprecated since JDK 1.2, deprecated for removal in Java 14, and re-specified/degraded to throw UnsupportedOperationException unconditionally in Java 19/20. Early in Java 23 seems a fine time to finally remove these methods. > > Corpus analysis of 176 million classes in 485k artifacts found no remaining usages of ThreadGroup.suspend/resume beyond the artifacts that include a copy of java.lang.ThreadGroup (!). It found 87 remaining uses of Thread.suspend and 86 remaining usages of Thread.resume, some of these are tests. > > Thread.suspend/resume have always linked to the "Java Thread Primitive Deprecation" page. This originally explained the reasons why suspend/resume were deprecated. When these methods were degraded to throw UOE we changed the text to explain why the ability to suspend or resume a thread was removed. Now we must change it again. One choice is to re-word to explain why the Java APIs were removed or why the Java APIs don't define a way to suspend/resume threads, the other choice (which I prefer) is to remove the text. > > The method description of java.lang.management.ThreadInfo.isSuspended is tweaked to link to JVMTI SuspendThread instead of Thread.suspend Looks okay in general. Will make one more pass tomorrow. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16789#issuecomment-1827737068 From alanb at openjdk.org Mon Nov 27 14:31:17 2023 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 27 Nov 2023 14:31:17 GMT Subject: RFR: 8320716: ResolvedModule::reads includes self when configuration contains two or more automatic modules Message-ID: This is update to the specification of the j.l.module.ResolvedModule.reads method to clarify that the set of resolved modules returned does not include itself. There is a small implementation change to align with the specification and fix an anomaly that arises with configurations that contain two or more automatic modules. Every module reads itself but the intent with ResolvedModule.reads is that it returns a set that doesn't include self. As things stand right now, the returned set does not include self when all modules in the configuration are explicit modules. However, if the configuration contains two or more automatic modules then the set includes self, a side effect of augmenting the readability graph due to implied readability. The specification of the "reads" method is updated. The implementation is also changed to skip automatic modules when augmenting the graph due to implied readability. It is skipped as each automatic module already reads all other modules. Note that it is not goal here to change the algorithm for handling implied readability, this may be a topic for a follow on PR. The existing ConfigurationTest already includes several tests for configurations consisting solely of explicit modules, no updates are needed. For configurations that include automatic modules, the existing AutomaticModulesTest is updated to add new asserts to each of the testConfigurationXXX methods. I decided to migrate this test to JUnit while visiting, most of it is just migrating the TestNG data providers to be parameterized tests. If needed then we could separate this but it's a simple migration so I left it in. ------------- Commit messages: - Reorder asserts - Initial commit Changes: https://git.openjdk.org/jdk/pull/16818/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16818&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8320716 Stats: 233 lines in 3 files changed: 45 ins; 51 del; 137 mod Patch: https://git.openjdk.org/jdk/pull/16818.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16818/head:pull/16818 PR: https://git.openjdk.org/jdk/pull/16818 From kevinw at openjdk.org Mon Nov 27 14:38:08 2023 From: kevinw at openjdk.org (Kevin Walls) Date: Mon, 27 Nov 2023 14:38:08 GMT Subject: RFR: 8316649: JMX connection timeout cannot be changed and uses the default of 0 (infinite) In-Reply-To: References: <6R7B_a7VdF5Fg8B38rMhx0Fe1WT53KQw0yt596rzmS4=.9902a48f-f143-4d81-8940-d9c273e94812@github.com> Message-ID: On Fri, 24 Nov 2023 16:28:38 GMT, Mark Sheppard wrote: >> Thanks, yes so JMX SSL clients are without socket connect timeout, good to have that documented. I logged a parallel RFE for SslRMIClientSocketFactory, which should wait for now as it seems wrong to go changing that right now without knowing if it's ever been an issue for anybody: >> [JDK-8320703](https://bugs.openjdk.org/browse/JDK-8320703): JMX SSL RMI Socket connection timeout cannot be changed > > wrt to the property name initialConnectTimeout might infer that it is an initial value which can be subsequentually modified, but that is not possible. As such, would sun.rmi.transport.tcp.connectTimeout be more appropriate -- dropping the initial ? > > If the connectTimeout initialization code was placed in a static method, it could be directly unit testable :-) (if such a test was desirable for coverage completeness) On the Property name: there is an existing System Property "sun.rmi.transport.connectionTimeout" which is a 15-second idle timeout. Having a "connectionTimeout" and this new one as "connectTimeout" could be confusing, even in different but very similar package names, hence naming this "initialConnectTimeout". (So "initial" to signal that it's the initial connect of a socket, different to the existing "connectionTimeout".) It does not seem like the kind of system property a user would expect to be read again on every usage, I think, let me know if you see that as a problem. I am hoping that as we already have various properties fetched in the same manner, we don't see the need to pursue a test that the value is fetched and passed on. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16771#discussion_r1406256156 From Alan.Bateman at oracle.com Mon Nov 27 14:42:51 2023 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 27 Nov 2023 14:42:51 +0000 Subject: Automatic modules and jpackage In-Reply-To: References: Message-ID: On 27/11/2023 11:44, Mark Raynsford wrote: > I'm not entirely convinced that discussion on this list doesn't get > lost in the endless sea of "RFR: " messages. :) It was originally sent to jigsaw-dev, then Alan Synder sent it here. As you know, automatic modules are to support migration without waiting for everything you transitively depend on to migrate first. In addition to allowing you to write "requires xxx" before xxx becomes an explicit module, they also support bridging to the class path so you can leave second and third level dependences on the class path. The intention was for automatic modules to be used when early in the migration journey. The jlink tool, on the other hand, is the other end of the journey where everything is an explicit module. As jlink produces a run-time image then it can't be in the business of having dangling references to classes on the class path that may or may not exist. It's unfortunate that some of the libraries you are using are slow or resistant to being linking into a run-time image. As you've found, jpackage supports applications where everything is an explicit module on the module path or applications where everything is on the class path. I don't know if it has been explored so support a hybrid configuration when it runs jlink to create a run-time image for a closed subset of the modules and produces an application image that has the rest of the modules in a directory. One thing that would help the discussion is to prototype your idea, see what it means for an application image and work through the additional complexity of the command line options. The possible command line options to jpackage is already very length and complications so one concern is that another mode would put it over the edge when it comes to usability. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From duke at openjdk.org Mon Nov 27 14:57:19 2023 From: duke at openjdk.org (fabioromano1) Date: Mon, 27 Nov 2023 14:57:19 GMT Subject: RFR: 8320759: Creation of random BigIntegers can be made faster Message-ID: A faster and simpler way to generate random BigIntegers, avoiding eventually trimming of leading zeros in magnitude array. ------------- Commit messages: - Optimized randomBits(int, Random) - Removed trailing whitespaces - Correct randomBits(int, Random) - Update BigInteger.java - Merge branch 'openjdk:master' into patch-4 - Merge branch 'patch-4' of https://github.com/fabioromano1/jdk into patch-4 - Merge branch 'openjdk:master' into patch-4 - An optimization - Correct BigInteger(int , Random) - Made random generation of BigIntegers faster Changes: https://git.openjdk.org/jdk/pull/16817/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16817&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8320759 Stats: 39 lines in 1 file changed: 16 ins; 8 del; 15 mod Patch: https://git.openjdk.org/jdk/pull/16817.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16817/head:pull/16817 PR: https://git.openjdk.org/jdk/pull/16817 From ihse at openjdk.org Mon Nov 27 15:02:13 2023 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 27 Nov 2023 15:02:13 GMT Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations with SLEEF [v4] In-Reply-To: References: <3dscjw75an6_n3ko_2LjHdpdj08xsyjhfpStuZrS5-M=.f43592fe-036e-47b5-babc-67f126885839@github.com> <17T7DXMTf1rFVeQY_FWJx0DETVYlBWceJO4lltWZyw0=.847b02a3-ef40-464a-80b7-d62bd9dbc2b5@github.com> Message-ID: <3g_PCAyCoS9IB9PIulE0sXzT8KqvxeNbzdgfbElT72E=.60fa3790-4894-463a-b192-1b75ff42d24b@github.com> On Mon, 27 Nov 2023 10:28:45 GMT, Andrew Haley wrote: >> We have to use this c-compiler option to build out the SVE ABIs (e.g. `svfloat32_t sinfx_u10sve(svfloat32_t input)`) in `libvmath.so`. Without this option, at build time, all the sve related featues like `arm_sve.h / __ARM_FEATURE_SVE` are missing, together with the sve symbols in `libvmath.so` we needed at runtime. That means at runtime, hotspot cannot find out the sve symbols and the vector operations will fall back to the default java implementation. > > That's fine, but we must make sure that SVE is not used by the compiler in any other places. If you've already built on non-SVE and tested the result on both SVE and non-SVE, I'm happy. You still need to separate out the SVE detection from the libsleef code, and provide a way to enable/disable it from the configure command line. It is not okay to auto-detect if features should be turned on or off by default, but it should always be possible to override. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16234#discussion_r1406291471 From dfuchs at openjdk.org Mon Nov 27 15:04:08 2023 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Mon, 27 Nov 2023 15:04:08 GMT Subject: RFR: 8316649: JMX connection timeout cannot be changed and uses the default of 0 (infinite) In-Reply-To: References: <6R7B_a7VdF5Fg8B38rMhx0Fe1WT53KQw0yt596rzmS4=.9902a48f-f143-4d81-8940-d9c273e94812@github.com> Message-ID: On Mon, 27 Nov 2023 14:35:07 GMT, Kevin Walls wrote: >> wrt to the property name initialConnectTimeout might infer that it is an initial value which can be subsequentually modified, but that is not possible. As such, would sun.rmi.transport.tcp.connectTimeout be more appropriate -- dropping the initial ? >> >> If the connectTimeout initialization code was placed in a static method, it could be directly unit testable :-) (if such a test was desirable for coverage completeness) > > On the Property name: there is an existing System Property "sun.rmi.transport.connectionTimeout" which is a 15-second idle timeout. Having a "connectionTimeout" and this new one as "connectTimeout" could be confusing, even in different but very similar package names, hence naming this "initialConnectTimeout". > (So "initial" to signal that it's the initial connect of a socket, different to the existing "connectionTimeout".) > It does not seem like the kind of system property a user would expect to be read again on every usage, I think, let me know if you see that as a problem. > > I am hoping that as we already have various properties fetched in the same manner, we don't see the need to pursue a test that the value is fetched and passed on. Have you considered naming it "socketConnectTimeout" instead? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16771#discussion_r1406293632 From dfuchs at openjdk.org Mon Nov 27 15:14:09 2023 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Mon, 27 Nov 2023 15:14:09 GMT Subject: RFR: 8316649: JMX connection timeout cannot be changed and uses the default of 0 (infinite) In-Reply-To: References: <6R7B_a7VdF5Fg8B38rMhx0Fe1WT53KQw0yt596rzmS4=.9902a48f-f143-4d81-8940-d9c273e94812@github.com> Message-ID: On Mon, 27 Nov 2023 15:00:54 GMT, Daniel Fuchs wrote: >> On the Property name: there is an existing System Property "sun.rmi.transport.connectionTimeout" which is a 15-second idle timeout. Having a "connectionTimeout" and this new one as "connectTimeout" could be confusing, even in different but very similar package names, hence naming this "initialConnectTimeout". >> (So "initial" to signal that it's the initial connect of a socket, different to the existing "connectionTimeout".) >> It does not seem like the kind of system property a user would expect to be read again on every usage, I think, let me know if you see that as a problem. >> >> I am hoping that as we already have various properties fetched in the same manner, we don't see the need to pursue a test that the value is fetched and passed on. > > Have you considered naming it "socketConnectTimeout" instead? Or possibly "tcpConnectTimeout"? If you named it "tcpConnectTimeout" then you could name the (future) property for [JDK-8320703](https://bugs.openjdk.org/browse/JDK-8320703: JMX SSL RMI Socket connection timeout cannot be changed) "tlsConnectTimeout"... ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16771#discussion_r1406309820 From aph at openjdk.org Mon Nov 27 15:14:15 2023 From: aph at openjdk.org (Andrew Haley) Date: Mon, 27 Nov 2023 15:14:15 GMT Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations with SLEEF [v4] In-Reply-To: <3g_PCAyCoS9IB9PIulE0sXzT8KqvxeNbzdgfbElT72E=.60fa3790-4894-463a-b192-1b75ff42d24b@github.com> References: <3dscjw75an6_n3ko_2LjHdpdj08xsyjhfpStuZrS5-M=.f43592fe-036e-47b5-babc-67f126885839@github.com> <17T7DXMTf1rFVeQY_FWJx0DETVYlBWceJO4lltWZyw0=.847b02a3-ef40-464a-80b7-d62bd9dbc2b5@github.com> <3g_PCAyCoS9IB9PIulE0sXzT8KqvxeNbzdgfbElT72E=.60fa3790-4894-463a-b192-1b75ff42d24b@github.com> Message-ID: <3mhEtXP50-Lkn4iKkMGyCY4RJEcFbaTXyCUN3eoOH7M=.54337aac-d295-4fd8-884b-8dba5c4a68f6@github.com> On Mon, 27 Nov 2023 14:59:23 GMT, Magnus Ihse Bursie wrote: > You still need to separate out the SVE detection from the libsleef code, and provide a way to enable/disable it from the configure command line. Why? I don't think this should be a build-time option at all, because it puts the people who build binaries in an impossible position. Can't this all be built unconditionally, with run-time feature detection? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16234#discussion_r1406310998 From ihse at openjdk.org Mon Nov 27 15:25:12 2023 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 27 Nov 2023 15:25:12 GMT Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations with SLEEF [v4] In-Reply-To: <3mhEtXP50-Lkn4iKkMGyCY4RJEcFbaTXyCUN3eoOH7M=.54337aac-d295-4fd8-884b-8dba5c4a68f6@github.com> References: <3dscjw75an6_n3ko_2LjHdpdj08xsyjhfpStuZrS5-M=.f43592fe-036e-47b5-babc-67f126885839@github.com> <17T7DXMTf1rFVeQY_FWJx0DETVYlBWceJO4lltWZyw0=.847b02a3-ef40-464a-80b7-d62bd9dbc2b5@github.com> <3g_PCAyCoS9IB9PIulE0sXzT8KqvxeNbzdgfbElT72E=.60fa3790-4894-463a-b192-1b75ff42d24b@github.com> <3mhEtXP50-Lkn4iKkMGyCY4RJEcFbaTXyCUN3eoOH7M=.54337aac-d295-4fd8-884b-8dba5c4a68f6@github.com> Message-ID: On Mon, 27 Nov 2023 15:11:32 GMT, Andrew Haley wrote: >> You still need to separate out the SVE detection from the libsleef code, and provide a way to enable/disable it from the configure command line. It is not okay to auto-detect if features should be turned on or off by default, but it should always be possible to override. > >> You still need to separate out the SVE detection from the libsleef code, and provide a way to enable/disable it from the configure command line. > > Why? I don't think this should be a build-time option at all, because it puts the people who build binaries in an impossible position. Can't this all be built unconditionally, with run-time feature detection? Apparently the situation is this: If your build machine happens to have SVE, then you will get SVE support in the vmath library. The SVE support will be used during runtime if the machine you run on has SVE support. If your build host happens to to not have SVE, then the vmath library will be built without SVE support, and no matter if your runtime machine has SVE or not, it will not provide SVE support in the vmath library. Now, if your CI farm has an arbitrarily selection of aarch64 machines with and without SVE, then you have no idea what you are going to get in your build. We have been very careful in staying clear of this kind of "random" build system behavior. The system you build on should not affect the output -- at least, not without a chance to override the default value. In fact, I am not even sure why it seems to the PR author to be a good idea to let the default be dependent on the build machine at all. My personal opinion is that it would be better to select either "SVE enabled" or "SVE disabled" as the default, and then let the user override this on the configure command line, if they target a platform with different SVE availability. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16234#discussion_r1406326711 From kevinw at openjdk.org Mon Nov 27 15:52:06 2023 From: kevinw at openjdk.org (Kevin Walls) Date: Mon, 27 Nov 2023 15:52:06 GMT Subject: RFR: 8316649: JMX connection timeout cannot be changed and uses the default of 0 (infinite) In-Reply-To: References: <6R7B_a7VdF5Fg8B38rMhx0Fe1WT53KQw0yt596rzmS4=.9902a48f-f143-4d81-8940-d9c273e94812@github.com> Message-ID: <4ISsCpwQr-iv5JDoTNRrgBiDOJQeZDTYznNFDJVem8A=.e9d4ed79-72e8-40b5-a4e4-6cfdddbe68db@github.com> On Mon, 27 Nov 2023 15:10:52 GMT, Daniel Fuchs wrote: >> Have you considered naming it "socketConnectTimeout" instead? Or possibly "tcpConnectTimeout"? > > If you named it "tcpConnectTimeout" then you could name the (future) property for [JDK-8320703](https://bugs.openjdk.org/browse/JDK-8320703: JMX SSL RMI Socket connection timeout cannot be changed) "tlsConnectTimeout"... Yes, that could work 8-) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16771#discussion_r1406372110 From core-libs-dev at io7m.com Mon Nov 27 16:09:17 2023 From: core-libs-dev at io7m.com (Mark Raynsford) Date: Mon, 27 Nov 2023 16:09:17 +0000 Subject: Automatic modules and jpackage In-Reply-To: References: Message-ID: <98e8caaef50f36e49315a7c3beacc9cbebaea444.camel@io7m.com> On Mon, 2023-11-27 at 14:42 +0000, Alan Bateman wrote: > On 27/11/2023 11:44, Mark Raynsford wrote: > > I'm not entirely convinced that discussion on this list doesn't get > > lost in the endless sea of "RFR: " messages. :) > > It was originally sent to jigsaw-dev, then Alan Synder sent it here. Yep. :) > > As you know, automatic modules are to support migration without > waiting > for everything you transitively depend on to migrate first. In > addition > to allowing you to write "requires xxx" before xxx becomes an > explicit > module, they also support bridging to the class path so you can leave > second and third level dependences on the class path. The intention > was > for automatic modules to be used when early in the migration journey. Unfortunately, for some projects, they seem to have become the end of the migration journey. "We've added an Automatic-Module-Name, we're done!". > It's unfortunate > that some of the libraries you are using are slow or resistant to > being > linking into a run-time image. Sometimes it's just that their transitive dependencies haven't been modularized and so they don't see the benefit in doing it themselves. Others are also paranoid about keeping builds working on Java 8, even though modern JDKs build Java 8 code better than JDK 8 ever did. :) > As you've found, jpackage supports applications where everything is > an > explicit module on the module path or applications where everything > is > on the class path. I don't know if it has been explored so support a > hybrid configuration when it runs jlink to create a run-time image > for a > closed subset of the modules and produces an application image that > has > the rest of the modules in a directory. One thing that would help the > discussion is to prototype your idea, see what it means for an > application image and work through the additional complexity of the > command line options. That might be something I can take on! I'm taking a look at what my schedule is like for 2024. What I had in mind was something simpler than your description implied: I'd actually aim for jlink to do no analysis whatsoever and simply leave all of the JDK modules as they were. I'm not sure if jlink or jpackage is responsible for branding the resulting executable (adding a nice icon, and all that), but it might be that the resulting app image is just a branded runtime with all of the normal JDK modules untouched, and the extra application modules included in a directory. As I mentioned in the blog, I feel like almost all of the functionality might already be there (minus a way to get the runtime to use -p instead of -cp internally), it's just that there doesn't appear to be a way to get jpackage to skip one of the steps that causes the failure. -- Mark Raynsford | https://www.io7m.com From duke at openjdk.org Mon Nov 27 16:23:18 2023 From: duke at openjdk.org (Eirik Bjorsnos) Date: Mon, 27 Nov 2023 16:23:18 GMT Subject: RFR: 8320781: Fix whitespace in j.l.Double and j.u.z.ZipInputStream @snippets Message-ID: Please review this trivial, formatting and documentation-only change which adds missing whitespace around a few `if` statements, `while` statements and assigments in `@snippet` code in `j.l.Double` and `j.u.z.ZipInputStream`. While there are many similar issues in the OpenJDK code base, these were the only instances found in `@snippet` code in the API of `java.base`, so it could be worthwhile fixing. While updating the snippet in `ZipInputStream`, I took the liberty to also add `lang = "java"` since this seems more commonly included around the code base. ------------- Commit messages: - Correct whitespace around if, while and assignments in @snippet code in java.base Changes: https://git.openjdk.org/jdk/pull/16827/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16827&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8320781 Stats: 5 lines in 2 files changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/16827.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16827/head:pull/16827 PR: https://git.openjdk.org/jdk/pull/16827 From vklang at openjdk.org Mon Nov 27 16:35:33 2023 From: vklang at openjdk.org (Viktor Klang) Date: Mon, 27 Nov 2023 16:35:33 GMT Subject: RFR: 8319123: Implement JEP 461: Stream Gatherers (Preview) [v13] In-Reply-To: References: Message-ID: On Tue, 21 Nov 2023 10:11:28 GMT, Viktor Klang wrote: >> This Pull-Request implements [JEP-461](https://openjdk.org/jeps/461) > > Viktor Klang has updated the pull request incrementally with one additional commit since the last revision: > > Javadoc clarifications for Gatherer type parameters, > correcting descriptions of Integrator type parameters, > and more consistently use "initializer function" instead > of "supplier function". src/java.base/share/classes/java/util/stream/Gatherer.java line 314: > 312: * @see Gatherer#finisher() > 313: * @return the instance of the default finisher > 314: * @param the type of the state of the returned finisher @AlanBateman @PaulSandoz Making the following changes following conversation on core-libs ML, plus I noted that some of the descriptions of the Integrator type parameters were mis-targeted. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1400345490 From lancea at openjdk.org Mon Nov 27 16:36:12 2023 From: lancea at openjdk.org (Lance Andersen) Date: Mon, 27 Nov 2023 16:36:12 GMT Subject: RFR: 8320781: Fix whitespace in j.l.Double and j.u.z.ZipInputStream @snippets In-Reply-To: References: Message-ID: On Mon, 27 Nov 2023 16:17:14 GMT, Eirik Bjorsnos wrote: > Please review this trivial, formatting and documentation-only change which adds missing whitespace around a few `if` statements, `while` statements and assigments in `@snippet` code in `j.l.Double` and `j.u.z.ZipInputStream`. > > While there are many similar issues in the OpenJDK code base, these were the only instances found in `@snippet` code in the API of `java.base`, so it could be worthwhile fixing. > > While updating the snippet in `ZipInputStream`, I took the liberty to also add `lang = "java"` since this seems more commonly included around the code base. Marked as reviewed by lancea (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/16827#pullrequestreview-1750875671 From aph at openjdk.org Mon Nov 27 16:46:16 2023 From: aph at openjdk.org (Andrew Haley) Date: Mon, 27 Nov 2023 16:46:16 GMT Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations with SLEEF [v4] In-Reply-To: References: <3dscjw75an6_n3ko_2LjHdpdj08xsyjhfpStuZrS5-M=.f43592fe-036e-47b5-babc-67f126885839@github.com> <17T7DXMTf1rFVeQY_FWJx0DETVYlBWceJO4lltWZyw0=.847b02a3-ef40-464a-80b7-d62bd9dbc2b5@github.com> <3g_PCAyCoS9IB9PIulE0sXzT8KqvxeNbzdgfbElT72E=.60fa3790-4894-463a-b192-1b75ff42d24b@github.com> <3mhEtXP50-Lkn4iKkMGyCY4RJEcFbaTXyCUN3eoOH7M=.54337aac-d295-4fd8-884b-8dba5c4a68f6@github.com> Message-ID: On Mon, 27 Nov 2023 15:22:32 GMT, Magnus Ihse Bursie wrote: > In fact, I am not even sure why it seems to the PR author to be a good idea to let the default be dependent on the build machine at all. My personal opinion is that it would be better to select either "SVE enabled" or "SVE disabled" as the default, and then let the user override this on the configure command line, if they target a platform with different SVE availability. SVE support should be enabled regardless of the build machine. The same binary must run on both SVE and non-SVE machines, using SVE if it is advantageous. I suppose some ancient C++ compilers without SVE support still exist, but I see no very good reason to support them building JDK 22+. Making a configure option to disable SVE support for vector math is a mistake, but IMO mostly harmless because no-one will ever turn it off. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16234#discussion_r1406450888 From duke at openjdk.org Mon Nov 27 16:48:06 2023 From: duke at openjdk.org (Gaurav Chaudhari) Date: Mon, 27 Nov 2023 16:48:06 GMT Subject: RFR: 8319668: Fixup of jar filename typo in BadFactoryTest.sh [v2] In-Reply-To: <6o2bpFznW1fNEdjAcVI92nkENfhm1t8Vn2o1gtEJwl8=.b7fced34-9827-4c42-a267-2cf182dd926e@github.com> References: <6mykWP1swWPnVEyhG-sEgEHc4kIMoCdi8_jfXYxDj78=.b4d2c29a-47e6-43c8-82e7-54091b77b3c5@github.com> <6o2bpFznW1fNEdjAcVI92nkENfhm1t8Vn2o1gtEJwl8=.b7fced34-9827-4c42-a267-2cf182dd926e@github.com> Message-ID: On Sat, 25 Nov 2023 16:45:07 GMT, Eirik Bjorsnos wrote: >>> Reviewer time is a scarce resource. It would be wasteful to spend review cycles on getting a fix of this `.sh` test integrated now and then immediately follow up with a delete in the rewrite PR. >>> >>> I think we should handle this change in one PR, not two. If you prefer to keep the history of your `.sh` fix documented, we can repurpose this PR, otherwise we start fresh with a new PR for the rewrite. >> >> The change here is trivial, it's okay to integrate and use a separate issue/PR to replace the shell test. I can't tell from the bug report if this was just noticed in passing or it actually failed (maybe on an IBM port). > >> The change here is trivial, it's okay to integrate and use a separate issue/PR to replace the shell test. > > Fair point, I filed https://bugs.openjdk.org/browse/JDK-8320712 to track the rewrite. > > @Deigue, would you like to contribute a PR for the rewrite as well? If not, I'll be happy to take on this task. Thanks @eirbjo, I dont directly have committer status for creating openjdk bugs myself. You can go ahead and contribute the PR in that case. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16585#issuecomment-1828215999 From dfenacci at openjdk.org Mon Nov 27 16:49:17 2023 From: dfenacci at openjdk.org (Damon Fenacci) Date: Mon, 27 Nov 2023 16:49:17 GMT Subject: RFR: 8311906: Improve robustness of String constructors with mutable array inputs [v12] In-Reply-To: References: <6SKlGLh5MmxoEx07wHCCUc8KWbbhcspLJmcc1uxQ_FI=.ca33bfb4-fa5c-45f0-b49f-ee6c5c6b68b4@github.com> Message-ID: On Wed, 22 Nov 2023 05:03:41 GMT, Roger Riggs wrote: >> Strings, after construction, are immutable but may be constructed from mutable arrays of bytes, characters, or integers. >> The string constructors should guard against the effects of mutating the arrays during construction that might invalidate internal invariants for the correct behavior of operations on the resulting strings. In particular, a number of operations have optimizations for operations on pairs of latin1 strings and pairs of non-latin1 strings, while operations between latin1 and non-latin1 strings use a more general implementation. >> >> The changes include: >> >> - Adding a warning to each constructor with an array as an argument to indicate that the results are indeterminate >> if the input array is modified before the constructor returns. >> The resulting string may contain any combination of characters sampled from the input array. >> >> - Ensure that strings that are represented as non-latin1 contain at least one non-latin1 character. >> For latin1 inputs, whether the arrays contain ASCII, ISO-8859-1, UTF8, or another encoding decoded to latin1 the scanning and compression is unchanged. >> If a non-latin1 character is found, the string is represented as non-latin1 with the added verification that a non-latin1 character is present at the same index. >> If that character is found to be latin1, then the input array has been modified and the result of the scan may be incorrect. >> Though a ConcurrentModificationException could be thrown, the risk to an existing application of an unexpected exception should be avoided. >> Instead, the non-latin1 copy of the input is re-scanned and compressed; that scan determines whether the latin1 or the non-latin1 representation is returned. >> >> - The methods that scan for non-latin1 characters and their intrinsic implementations are updated to return the index of the non-latin1 character. >> >> - String construction from StringBuilder and CharSequence must also be guarded as their contents may be modified during construction. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Apply StringUTF16.coderFromArrayLen src/hotspot/cpu/x86/macroAssembler_x86.cpp line 8538: > 8536: > 8537: testl(len, -64); > 8538: jcc(Assembler::zero, post_alignment); @cl4es since some of the `jcc` instructions have been changed into `jccb` in the rest of the intrinsic, I was wondering if it would make sense do the same for the rest of them (where the jump is short): Suggestion: jccb(Assembler::zero, post_alignment); src/hotspot/cpu/x86/macroAssembler_x86.cpp line 8547: > 8545: // bail out when there is nothing to be done > 8546: testl(tmp5, 0xFFFFFFFF); > 8547: jcc(Assembler::zero, post_alignment); Suggestion: jccb(Assembler::zero, post_alignment); and here: https://github.com/openjdk/jdk/blob/d201344b631bf2cc9fb1990874fc7d42d523eeab/src/hotspot/cpu/x86/macroAssembler_x86.cpp#L8574 src/hotspot/cpu/x86/macroAssembler_x86.cpp line 8584: > 8582: evpcmpuw(mask1, tmp1Reg, tmp2Reg, Assembler::le, Assembler::AVX_512bit); > 8583: kortestdl(mask1, mask1); > 8584: jcc(Assembler::carryClear, reset_for_copy_tail); Suggestion: jccb(Assembler::carryClear, reset_for_copy_tail); and here: https://github.com/openjdk/jdk/blob/d201344b631bf2cc9fb1990874fc7d42d523eeab/src/hotspot/cpu/x86/macroAssembler_x86.cpp#L8590 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16425#discussion_r1406147105 PR Review Comment: https://git.openjdk.org/jdk/pull/16425#discussion_r1406147739 PR Review Comment: https://git.openjdk.org/jdk/pull/16425#discussion_r1406178794 From core-libs-dev at io7m.com Mon Nov 27 17:15:55 2023 From: core-libs-dev at io7m.com (Mark Raynsford) Date: Mon, 27 Nov 2023 17:15:55 +0000 Subject: Automatic modules and jpackage In-Reply-To: <98e8caaef50f36e49315a7c3beacc9cbebaea444.camel@io7m.com> References: <98e8caaef50f36e49315a7c3beacc9cbebaea444.camel@io7m.com> Message-ID: <843040014f7f7d3bbbf5f050cb50d9d67ce0e0d2.camel@io7m.com> On Mon, 2023-11-27 at 16:09 +0000, Mark Raynsford wrote: > > As I mentioned in the blog, I feel like almost all of the > functionality might already be there (minus a way to get the runtime > to use -p instead of -cp internally), it's just that there doesn't > appear to be a way to get jpackage to skip one of the steps that > causes the failure. > Well, I feel silly. It turns out that it _is_ possible. The key part is the --runtime-image option. If there's a normal JDK/JRE image in "jre", and the application's modules are in "jars", then: jpackage \ --runtime-image jre \ -t app-image \ --module com.io7m.demo.m3 \ --module-path jars \ --name jpackagetest This will result in an application image where jpackage/lib/app/mods is a directory containing the untouched application jars. Additionally: $ cat jpackagetest/lib/app/jpackagetest.cfg [Application] app.mainmodule=com.io7m.demo.m3/com.io7m.demo.m3.M3 [JavaOptions] java-options=-Djpackage.app-version=20231111 java-options=--module-path java-options=$APPDIR/mods Running the application shows that it's definitely running in module path mode. I've no idea why I spent all day failing to combine the arguments in this particular way. Maybe my work in 2024 is to submit a documentation PR that adds this as an example to the jpackage manual page. -- Mark Raynsford | https://www.io7m.com From joehw at openjdk.org Mon Nov 27 17:30:21 2023 From: joehw at openjdk.org (Joe Wang) Date: Mon, 27 Nov 2023 17:30:21 GMT Subject: RFR: 8320602: Lock contention in SchemaDVFactory.getInstance() Message-ID: Applying an update from the upstream source, quote: "Removing synchronized from the getInstance() methods". As the reporter noted, this change was made 16 years ago. Tests: SQE & unit tests passed ------------- Commit messages: - 8320602: Lock contention in SchemaDVFactory.getInstance() Changes: https://git.openjdk.org/jdk/pull/16829/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16829&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8320602 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/16829.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16829/head:pull/16829 PR: https://git.openjdk.org/jdk/pull/16829 From rriggs at openjdk.org Mon Nov 27 17:31:22 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Mon, 27 Nov 2023 17:31:22 GMT Subject: RFR: 8311906: Improve robustness of String constructors with mutable array inputs [v12] In-Reply-To: References: <6SKlGLh5MmxoEx07wHCCUc8KWbbhcspLJmcc1uxQ_FI=.ca33bfb4-fa5c-45f0-b49f-ee6c5c6b68b4@github.com> Message-ID: <4aeW-4xV_Fwl9bvrdDtW-TwRzDZ41JWiLQRXwkrwWP4=.4e426206-6912-4360-a37a-c2abc17bcc32@github.com> On Mon, 27 Nov 2023 13:43:52 GMT, Damon Fenacci wrote: >> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: >> >> Apply StringUTF16.coderFromArrayLen > > src/hotspot/cpu/x86/macroAssembler_x86.cpp line 8584: > >> 8582: evpcmpuw(mask1, tmp1Reg, tmp2Reg, Assembler::le, Assembler::AVX_512bit); >> 8583: kortestdl(mask1, mask1); >> 8584: jcc(Assembler::carryClear, reset_for_copy_tail); > > Suggestion: > > jccb(Assembler::carryClear, reset_for_copy_tail); > > > and here: > > https://github.com/openjdk/jdk/blob/d201344b631bf2cc9fb1990874fc7d42d523eeab/src/hotspot/cpu/x86/macroAssembler_x86.cpp#L8590 Thanks for the suggestions to use byte offset branches. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16425#discussion_r1406506896 From duke at openjdk.org Mon Nov 27 17:38:23 2023 From: duke at openjdk.org (Steve Dohrmann) Date: Mon, 27 Nov 2023 17:38:23 GMT Subject: Integrated: 8310159: Bulk copy with Unsafe::arrayCopy is slower compared to memcpy In-Reply-To: References: Message-ID: On Wed, 8 Nov 2023 23:23:48 GMT, Steve Dohrmann wrote: > Update: the XorTest::xor results shown in this message used test code from PR commit 7cc272e862791 which was based on Maurizio Cimadamore's commit a788f066af17. The XorTest has since been updated and XorTest::copy is no longer needed and has been removed from this pull request. See comment [here](https://github.com/openjdk/jdk/pull/16575#issuecomment-1820006548) for updated performance data. > > Below is baseline data collected using a modified version of the java.lang.foreign.xor micro benchmark referenced by @mcimadamore in the bug report. I collected data on an Ubuntu 22.04 laptop with a Tigerlake i7-1185G7, which does support AVX512. > > Baseline data > Benchmark (arrayKind) (sizeKind) Mode Cnt Score Error Units > -------------------------------------------------------------------------------------- > XorTest.copy ELEMENTS SMALL avgt 30 584737355.767 ? 60414308.540 ns/op > XorTest.copy ELEMENTS MEDIUM avgt 30 272248995.683 ? 2924954.498 ns/op > XorTest.copy ELEMENTS LARGE avgt 30 1019200210.900 ? 28334453.652 ns/op > XorTest.copy REGION SMALL avgt 30 7399944.164 ? 216821.819 ns/op > XorTest.copy REGION MEDIUM avgt 30 20591454.558 ? 147398.572 ns/op > XorTest.copy REGION LARGE avgt 30 21649266.051 ? 179263.875 ns/op > XorTest.copy CRITICAL SMALL avgt 30 51079.357 ? 542.482 ns/op > XorTest.copy CRITICAL MEDIUM avgt 30 2496.961 ? 11.375 ns/op > XorTest.copy CRITICAL LARGE avgt 30 515.454 ? 5.831 ns/op > XorTest.copy FOREIGN SMALL avgt 30 7558432.075 ? 79489.276 ns/op > XorTest.copy FOREIGN MEDIUM avgt 30 19730666.341 ? 500505.099 ns/op > XorTest.copy FOREIGN LARGE avgt 30 34616758.085 ? 340300.726 ns/op > XorTest.xor ELEMENTS SMALL avgt 30 219832692.489 ? 2329417.319 ns/op > XorTest.xor ELEMENTS MEDIUM avgt 30 505138197.167 ? 3818334.424 ns/op > XorTest.xor ELEMENTS LARGE avgt 30 1189608474.667 ? 5877981.900 ns/op > XorTest.xor REGION SMALL avgt 30 64093872.804 ? 599704.491 ns/op > XorTest.xor REGION MEDIUM avgt 30 81544576.454 ? 1406342.118 ns/op > XorTest.xor REGION LARGE avgt 30 90091424.883 ? 775577.613 ns/op > XorTest.xor CRITICAL SMALL avgt 30 57231375.744 ? 438223.342 ns/op > XorTest.x... This pull request has now been integrated. Changeset: 82967f45 Author: steveatgh Committer: Sandhya Viswanathan URL: https://git.openjdk.org/jdk/commit/82967f45db3b9555be03fcabdba380852ea21e2c Stats: 259 lines in 5 files changed: 259 ins; 0 del; 0 mod 8310159: Bulk copy with Unsafe::arrayCopy is slower compared to memcpy Co-authored-by: Maurizio Cimadamore Reviewed-by: thartmann, jbhateja, sviswanathan ------------- PR: https://git.openjdk.org/jdk/pull/16575 From redestad at openjdk.org Mon Nov 27 18:08:19 2023 From: redestad at openjdk.org (Claes Redestad) Date: Mon, 27 Nov 2023 18:08:19 GMT Subject: RFR: 8311906: Improve robustness of String constructors with mutable array inputs [v12] In-Reply-To: <4aeW-4xV_Fwl9bvrdDtW-TwRzDZ41JWiLQRXwkrwWP4=.4e426206-6912-4360-a37a-c2abc17bcc32@github.com> References: <6SKlGLh5MmxoEx07wHCCUc8KWbbhcspLJmcc1uxQ_FI=.ca33bfb4-fa5c-45f0-b49f-ee6c5c6b68b4@github.com> <4aeW-4xV_Fwl9bvrdDtW-TwRzDZ41JWiLQRXwkrwWP4=.4e426206-6912-4360-a37a-c2abc17bcc32@github.com> Message-ID: On Mon, 27 Nov 2023 17:28:34 GMT, Roger Riggs wrote: >> src/hotspot/cpu/x86/macroAssembler_x86.cpp line 8584: >> >>> 8582: evpcmpuw(mask1, tmp1Reg, tmp2Reg, Assembler::le, Assembler::AVX_512bit); >>> 8583: kortestdl(mask1, mask1); >>> 8584: jcc(Assembler::carryClear, reset_for_copy_tail); >> >> Suggestion: >> >> jccb(Assembler::carryClear, reset_for_copy_tail); >> >> >> and here: >> >> https://github.com/openjdk/jdk/blob/d201344b631bf2cc9fb1990874fc7d42d523eeab/src/hotspot/cpu/x86/macroAssembler_x86.cpp#L8590 > > Thanks for the suggestions to use byte offset branches. Seems reasonable. AFAICT these suggestions are all in the AVX-512-code that is soft disabled by the need to supply `-XX:AVX3Threshold=0`. We don't do any systematic performance testing of those (maybe we should?), so some manual verification is necessary. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16425#discussion_r1406554229 From bpb at openjdk.org Mon Nov 27 18:09:08 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Mon, 27 Nov 2023 18:09:08 GMT Subject: RFR: 8320781: Fix whitespace in j.l.Double and j.u.z.ZipInputStream @snippets In-Reply-To: References: Message-ID: On Mon, 27 Nov 2023 16:17:14 GMT, Eirik Bjorsnos wrote: > Please review this trivial, formatting and documentation-only change which adds missing whitespace around a few `if` statements, `while` statements and assigments in `@snippet` code in `j.l.Double` and `j.u.z.ZipInputStream`. > > While there are many similar issues in the OpenJDK code base, these were the only instances found in `@snippet` code in the API of `java.base`, so it could be worthwhile fixing. > > While updating the snippet in `ZipInputStream`, I took the liberty to also add `lang = "java"` since this seems more commonly included around the code base. Marked as reviewed by bpb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/16827#pullrequestreview-1751057799 From darcy at openjdk.org Mon Nov 27 18:09:09 2023 From: darcy at openjdk.org (Joe Darcy) Date: Mon, 27 Nov 2023 18:09:09 GMT Subject: RFR: 8320781: Fix whitespace in j.l.Double and j.u.z.ZipInputStream @snippets In-Reply-To: References: Message-ID: <-mFvjK5LzJ6o10u_3D0GGCeVgCiHLp2PnT2eIp3DdKk=.9b6c35c3-9d24-48f1-95e4-6175f7a9e4a6@github.com> On Mon, 27 Nov 2023 16:17:14 GMT, Eirik Bjorsnos wrote: > Please review this trivial, formatting and documentation-only change which adds missing whitespace around a few `if` statements, `while` statements and assigments in `@snippet` code in `j.l.Double` and `j.u.z.ZipInputStream`. > > While there are many similar issues in the OpenJDK code base, these were the only instances found in `@snippet` code in the API of `java.base`, so it could be worthwhile fixing. > > While updating the snippet in `ZipInputStream`, I took the liberty to also add `lang = "java"` since this seems more commonly included around the code base. Marked as reviewed by darcy (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/16827#pullrequestreview-1751060034 From iris at openjdk.org Mon Nov 27 18:17:02 2023 From: iris at openjdk.org (Iris Clark) Date: Mon, 27 Nov 2023 18:17:02 GMT Subject: RFR: 8320602: Lock contention in SchemaDVFactory.getInstance() In-Reply-To: References: Message-ID: On Mon, 27 Nov 2023 17:24:35 GMT, Joe Wang wrote: > Applying an update from the upstream source, quote: "Removing synchronized from the getInstance() methods". As the reporter noted, this change was made 16 years ago. > > Tests: SQE & unit tests passed Verified `synchronized` keyword removed from method declaration as in upstream source. ------------- Marked as reviewed by iris (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16829#pullrequestreview-1751076242 From lancea at openjdk.org Mon Nov 27 18:20:06 2023 From: lancea at openjdk.org (Lance Andersen) Date: Mon, 27 Nov 2023 18:20:06 GMT Subject: RFR: 8320602: Lock contention in SchemaDVFactory.getInstance() In-Reply-To: References: Message-ID: On Mon, 27 Nov 2023 17:24:35 GMT, Joe Wang wrote: > Applying an update from the upstream source, quote: "Removing synchronized from the getInstance() methods". As the reporter noted, this change was made 16 years ago. > > Tests: SQE & unit tests passed This looks OK. Please add a the appropriate label given there is no test included with this change so that you do not get asked later where is the test ;-) ------------- Marked as reviewed by lancea (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16829#pullrequestreview-1751080653 From darcy at openjdk.org Mon Nov 27 18:45:24 2023 From: darcy at openjdk.org (Joe Darcy) Date: Mon, 27 Nov 2023 18:45:24 GMT Subject: RFR: JDK-8319413: Start of release updates for JDK 23 Message-ID: Time to start making preparations for JDK 23. ------------- Commit messages: - Add symbol files for JDK 22 build 25. - Merge branch 'master' into JDK-8319413 - Merge branch 'master' into JDK-8319413 - Adjust expected release date. - Fix omission in Classfile.java - JDK-8319413: Start of release updates for JDK 23 Changes: https://git.openjdk.org/jdk/pull/16505/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16505&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8319413 Stats: 7694 lines in 70 files changed: 7656 ins; 0 del; 38 mod Patch: https://git.openjdk.org/jdk/pull/16505.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16505/head:pull/16505 PR: https://git.openjdk.org/jdk/pull/16505 From liach at openjdk.org Mon Nov 27 18:45:26 2023 From: liach at openjdk.org (Chen Liang) Date: Mon, 27 Nov 2023 18:45:26 GMT Subject: RFR: JDK-8319413: Start of release updates for JDK 23 In-Reply-To: References: Message-ID: <5vvx35OFQByttXi78XninlFdmr7NAc-ryvxSz1Uz-cM=.d5acd0ff-996d-4bee-8673-00489253122b@github.com> On Fri, 3 Nov 2023 23:42:03 GMT, Joe Darcy wrote: > Time to start making preparations for JDK 23. Changes requested by liach (Author). src/java.base/share/classes/jdk/internal/classfile/Classfile.java line 1: > 1: /* `latestMajorVersion` below should be updated to return `JAVA_23_VERSION` as well. ------------- PR Review: https://git.openjdk.org/jdk/pull/16505#pullrequestreview-1713657511 PR Review Comment: https://git.openjdk.org/jdk/pull/16505#discussion_r1382292651 From darcy at openjdk.org Mon Nov 27 18:45:26 2023 From: darcy at openjdk.org (Joe Darcy) Date: Mon, 27 Nov 2023 18:45:26 GMT Subject: RFR: JDK-8319413: Start of release updates for JDK 23 In-Reply-To: References: Message-ID: On Fri, 3 Nov 2023 23:42:03 GMT, Joe Darcy wrote: > Time to start making preparations for JDK 23. Nothing exception in this batch of start-of-release updates. Clean local testing results on tier 1. The symbol files correspond to JDK 22 build 25 and will be updated with subsequent builds as usual. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16505#issuecomment-1828413515 From darcy at openjdk.org Mon Nov 27 18:45:30 2023 From: darcy at openjdk.org (Joe Darcy) Date: Mon, 27 Nov 2023 18:45:30 GMT Subject: RFR: JDK-8319413: Start of release updates for JDK 23 In-Reply-To: <5vvx35OFQByttXi78XninlFdmr7NAc-ryvxSz1Uz-cM=.d5acd0ff-996d-4bee-8673-00489253122b@github.com> References: <5vvx35OFQByttXi78XninlFdmr7NAc-ryvxSz1Uz-cM=.d5acd0ff-996d-4bee-8673-00489253122b@github.com> Message-ID: On Fri, 3 Nov 2023 23:52:45 GMT, Chen Liang wrote: >> Time to start making preparations for JDK 23. > > src/java.base/share/classes/jdk/internal/classfile/Classfile.java line 1: > >> 1: /* > > `latestMajorVersion` below should be updated to return `JAVA_23_VERSION` as well. Good catch; fixed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16505#discussion_r1382295414 From joehw at openjdk.org Mon Nov 27 19:04:04 2023 From: joehw at openjdk.org (Joe Wang) Date: Mon, 27 Nov 2023 19:04:04 GMT Subject: RFR: 8320602: Lock contention in SchemaDVFactory.getInstance() In-Reply-To: References: Message-ID: On Mon, 27 Nov 2023 18:14:53 GMT, Iris Clark wrote: > Verified `synchronized` keyword removed from method declaration as in upstream source. Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/16829#issuecomment-1828441202 From joehw at openjdk.org Mon Nov 27 19:04:06 2023 From: joehw at openjdk.org (Joe Wang) Date: Mon, 27 Nov 2023 19:04:06 GMT Subject: RFR: 8320602: Lock contention in SchemaDVFactory.getInstance() In-Reply-To: References: Message-ID: On Mon, 27 Nov 2023 18:17:50 GMT, Lance Andersen wrote: > This looks OK. > > Please add a the appropriate label given there is no test included with this change so that you do not get asked later where is the test ;-) Added a label and note. Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/16829#issuecomment-1828442696 From rriggs at openjdk.org Mon Nov 27 19:09:40 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Mon, 27 Nov 2023 19:09:40 GMT Subject: RFR: 8311906: Improve robustness of String constructors with mutable array inputs [v13] In-Reply-To: <6SKlGLh5MmxoEx07wHCCUc8KWbbhcspLJmcc1uxQ_FI=.ca33bfb4-fa5c-45f0-b49f-ee6c5c6b68b4@github.com> References: <6SKlGLh5MmxoEx07wHCCUc8KWbbhcspLJmcc1uxQ_FI=.ca33bfb4-fa5c-45f0-b49f-ee6c5c6b68b4@github.com> Message-ID: > Strings, after construction, are immutable but may be constructed from mutable arrays of bytes, characters, or integers. > The string constructors should guard against the effects of mutating the arrays during construction that might invalidate internal invariants for the correct behavior of operations on the resulting strings. In particular, a number of operations have optimizations for operations on pairs of latin1 strings and pairs of non-latin1 strings, while operations between latin1 and non-latin1 strings use a more general implementation. > > The changes include: > > - Adding a warning to each constructor with an array as an argument to indicate that the results are indeterminate > if the input array is modified before the constructor returns. > The resulting string may contain any combination of characters sampled from the input array. > > - Ensure that strings that are represented as non-latin1 contain at least one non-latin1 character. > For latin1 inputs, whether the arrays contain ASCII, ISO-8859-1, UTF8, or another encoding decoded to latin1 the scanning and compression is unchanged. > If a non-latin1 character is found, the string is represented as non-latin1 with the added verification that a non-latin1 character is present at the same index. > If that character is found to be latin1, then the input array has been modified and the result of the scan may be incorrect. > Though a ConcurrentModificationException could be thrown, the risk to an existing application of an unexpected exception should be avoided. > Instead, the non-latin1 copy of the input is re-scanned and compressed; that scan determines whether the latin1 or the non-latin1 representation is returned. > > - The methods that scan for non-latin1 characters and their intrinsic implementations are updated to return the index of the non-latin1 character. > > - String construction from StringBuilder and CharSequence must also be guarded as their contents may be modified during construction. Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: Use byte off branches in char_array_compress Verified by manual tests with "-XX:AVX3Threshold=0" And test in the PR test/hotspot/jtreg/compiler/intrinsics/string/TestStringConstructionIntrinsics.java ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16425/files - new: https://git.openjdk.org/jdk/pull/16425/files/d201344b..5299c43b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16425&range=12 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16425&range=11-12 Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/16425.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16425/head:pull/16425 PR: https://git.openjdk.org/jdk/pull/16425 From mchung at openjdk.org Mon Nov 27 19:12:05 2023 From: mchung at openjdk.org (Mandy Chung) Date: Mon, 27 Nov 2023 19:12:05 GMT Subject: RFR: 8320440: Implementation of Structured Concurrency (Second Preview) In-Reply-To: <4t6NzmCd-0w-y7iT51fEttO7gEArgRuCeEl4yeNIzd0=.cd7bbed3-1117-4fc1-9241-255e6e10e2f1@github.com> References: <4t6NzmCd-0w-y7iT51fEttO7gEArgRuCeEl4yeNIzd0=.cd7bbed3-1117-4fc1-9241-255e6e10e2f1@github.com> Message-ID: On Mon, 20 Nov 2023 19:48:20 GMT, Alan Bateman wrote: > This API is sitting out JDK 22, meaning no API/implementation changes in this PR. We expect this API to do a third preview in JDK 23 with some API changes. > > So for now, we just need to bump JEP number/title that shows up in the preview section of the javadoc. Marked as reviewed by mchung (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/16748#pullrequestreview-1751175380 From prr at openjdk.org Mon Nov 27 19:29:06 2023 From: prr at openjdk.org (Phil Race) Date: Mon, 27 Nov 2023 19:29:06 GMT Subject: RFR: 8320608: Many jtreg printing tests are missing the @printer keyword In-Reply-To: <-qqvX2JKzr3-eQ_FNsovChX5aJjqQaqbewiVgvCamM0=.644272b2-55b3-4d32-8e57-7de1f9ec5590@github.com> References: <-qqvX2JKzr3-eQ_FNsovChX5aJjqQaqbewiVgvCamM0=.644272b2-55b3-4d32-8e57-7de1f9ec5590@github.com> Message-ID: On Thu, 23 Nov 2023 07:02:54 GMT, Alan Bateman wrote: >> Many printing tests do not have the @printer keyword. This adds them to those that need it. >> I also found one test that has nothing to do with printing in the print folder and moved it out. > > test/jdk/TEST.ROOT line 15: > >> 13: # >> 14: # Notes on "client" keywords : headful sound printer 2d dnd multimon >> 15: # ================================================================== > > The note reads well but there aren't any notes for "2d" and "dnd". The heading hints that there will be information on these keywords. That's because I wasn't sure what we use them for :-) I've grepped and they are never used. I'm not sure we need either of them so I think I'll just remove them. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16785#discussion_r1406590062 From prr at openjdk.org Mon Nov 27 19:29:20 2023 From: prr at openjdk.org (Phil Race) Date: Mon, 27 Nov 2023 19:29:20 GMT Subject: RFR: 8320608: Many jtreg printing tests are missing the @printer keyword In-Reply-To: <-89UjGPFJWRn0hJIyT5n2YLJKNCyaSeDPjOgw3dmZrw=.613b5081-039a-42cc-8b8c-f48fc91b9abd@github.com> References: <-89UjGPFJWRn0hJIyT5n2YLJKNCyaSeDPjOgw3dmZrw=.613b5081-039a-42cc-8b8c-f48fc91b9abd@github.com> Message-ID: On Thu, 23 Nov 2023 11:10:35 GMT, Alexey Ivanov wrote: >> Many printing tests do not have the @printer keyword. This adds them to those that need it. >> I also found one test that has nothing to do with printing in the print folder and moved it out. > > test/jdk/java/awt/PrintJob/EdgeTest/EdgeTest.java line 30: > >> 28: * @summary Verifies that (0, 0) is the upper-left corner of the page, not >> 29: * the upper-left corner adjusted for the margins. >> 30: * @author dpm > > Suggestion: > > > Perhaps, remove the `@author` tag here too. will do, although removing author tags was just something I was doing as I went along and happened to spot them .. > test/jdk/java/awt/PrintJob/RoundedRectTest/RoundedRectTest.java line 29: > >> 27: * @bug 4061440 >> 28: * @summary Checks that rounded rectangles print correctly. >> 29: * @author dpm > > Suggestion: will do > test/jdk/java/awt/print/PageFormat/SmallPaperPrinting.java line 30: > >> 28: >> 29: import java.awt.*; >> 30: import java.awt.print.*; > > Could you expand the wildcard imports, please? > > I would appreciate if you would add the jtreg tags *after* the imports. I can .. but I am not aware of even a convention to do that ordering. I'll update the imports in this file since I touched it more than any other case > test/jdk/java/awt/print/PageFormat/SmallPaperPrinting.java line 35: > >> 33: { >> 34: public static void main(String args[]) >> 35: { > > Suggestion: > > public class SmallPaperPrinting { > public static void main(String[] args) { > > Since you're reformatting the test source, it's better to follow the Java code style? throughout the entire source file. ok. > test/jdk/java/awt/print/PageFormat/WrongPaperPrintingTest.java line 29: > >> 27: @key printer >> 28: @run main/manual WrongPaperPrintingTest >> 29: */ > > It's minor but still, in majority of tests, the `@key` tag follows the `@bug` tag, and you mostly follow the convention in this PR. Keeping the order consistent helps scanning the test description with eyes quickly. updated > test/jdk/java/awt/print/PrinterJob/EmptyFill.java line 30: > >> 28: * @key printer >> 29: * @run main EmptyFill >> 30: */ > > This test does not need a printer, it prints into a byte array and analyses the output. The test passes successfully on a system without a printer. You are right, I mis-read this PrinterJob pj = PrinterJob.getPrinterJob(); if (svc == null) { return; } that test bails if there's no service but that's if it failed to create the output stream service Not sure why the code is ordered that way round since we can check for null first. > test/jdk/java/awt/print/PrinterJob/GetUserNameTest.java line 26: > >> 24: * @test >> 25: * @bug 6197099 >> 26: * @key printer > > The test works correctly without a printer, it prints the expected message: > > SecurityException thrown as user.name permission not given > > > No other exceptions are thrown but the warnings that `SecurityManager` is deprecated. fixed > test/jdk/java/awt/print/PrinterJob/MultiMonPrintDlgTest.java line 40: > >> 38: * @test >> 39: * @bug 8138749 >> 40: * @key printer > > Suggestion: > > * @key printer multimon > > The test requires two monitors. fixed. I meant to add this but forgot. > test/jdk/java/awt/print/PrinterJob/PrintAllFonts.java line 26: > >> 24: /** >> 25: * >> 26: * @bug 4884389 7183516 > > Is it intentional that there's no `@test` tag? I think this is another test that needs some work. It doesn't wait to see if the user gave it a pass. I'll add "test" but not "@test". > test/jdk/java/awt/print/PrinterJob/PrintAllFonts.java line 29: > >> 27: * @key printer >> 28: * @summary Font specified with face name loses style on printing >> 29: * @run main/manual PrintRotatedText > > Is it intentional that this test presumably runs another test ? `PrintRotatedText` ? instead? that looks wrong. will fix > test/jdk/java/awt/print/PrinterJob/PrintTranslatedFont.java line 29: > >> 27: * @key printer >> 28: * @summary Test that fonts with a translation print where they should. >> 29: * @author prr > > Suggestion: fixed > test/jdk/java/awt/print/PrinterJob/PrinterDevice.java line 31: > >> 29: * @key printer >> 30: * @run main/othervm PrinterDevice >> 31: */ > > There's no `@test` tag, is it intentional? > > Probably, you should remove this test from this PR because you're modifying in #16773. agreed > test/jdk/java/awt/print/PrinterJob/PrinterDialogsModalityTest/PrinterDialogsModalityTest.html line 30: > >> 28: @key printer >> 29: @summary check whether Print- and Page- dialogs are modal and correct window activated after their closing >> 30: @author Your Name: area=PrinterJob.modality > > Suggestion: fixed > test/jdk/java/awt/print/PrinterJob/RemoveListener.java line 25: > >> 23: >> 24: /* >> 25: * @test 1.1 01/05/17 > > Suggestion: > > * @test fixed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16785#discussion_r1406595049 PR Review Comment: https://git.openjdk.org/jdk/pull/16785#discussion_r1406595720 PR Review Comment: https://git.openjdk.org/jdk/pull/16785#discussion_r1406610431 PR Review Comment: https://git.openjdk.org/jdk/pull/16785#discussion_r1406621800 PR Review Comment: https://git.openjdk.org/jdk/pull/16785#discussion_r1406627499 PR Review Comment: https://git.openjdk.org/jdk/pull/16785#discussion_r1406630862 PR Review Comment: https://git.openjdk.org/jdk/pull/16785#discussion_r1406631860 PR Review Comment: https://git.openjdk.org/jdk/pull/16785#discussion_r1406633247 PR Review Comment: https://git.openjdk.org/jdk/pull/16785#discussion_r1406639812 PR Review Comment: https://git.openjdk.org/jdk/pull/16785#discussion_r1406638321 PR Review Comment: https://git.openjdk.org/jdk/pull/16785#discussion_r1406640707 PR Review Comment: https://git.openjdk.org/jdk/pull/16785#discussion_r1406642687 PR Review Comment: https://git.openjdk.org/jdk/pull/16785#discussion_r1406643230 PR Review Comment: https://git.openjdk.org/jdk/pull/16785#discussion_r1406643654 From prr at openjdk.org Mon Nov 27 19:29:23 2023 From: prr at openjdk.org (Phil Race) Date: Mon, 27 Nov 2023 19:29:23 GMT Subject: RFR: 8320608: Many jtreg printing tests are missing the @printer keyword In-Reply-To: <96ngNnlrygkt0Ni0W2xyr9STyYoQEALdDXtNu_jIQUg=.8969504d-ac54-4dc6-a271-08154523db94@github.com> References: <-89UjGPFJWRn0hJIyT5n2YLJKNCyaSeDPjOgw3dmZrw=.613b5081-039a-42cc-8b8c-f48fc91b9abd@github.com> <96ngNnlrygkt0Ni0W2xyr9STyYoQEALdDXtNu_jIQUg=.8969504d-ac54-4dc6-a271-08154523db94@github.com> Message-ID: On Thu, 23 Nov 2023 20:39:50 GMT, Alexey Ivanov wrote: >> test/jdk/java/awt/print/PageFormat/SetOrient.java line 28: >> >>> 26: * @summary Confirm that the clip and transform of the Graphics2D is >>> 27: * affected by the landscape orientation of the PageFormat. >>> 28: */ >> >> Since this test calls `pjob.print();`, it requires a printer. Indeed, it fails without a printer: >> >> >> runner starting test: java/awt/print/PageFormat/SetOrient.html >> runner finished test: java/awt/print/PageFormat/SetOrient.html >> Failed. Execution failed: Applet thread threw exception: >> java.lang.RuntimeException: No print service found. >> Test results: failed: 1 > > I see `SetOrient.java` has its sibling `SetOrient.html` where you added `@key printer`. > > Since both files contain all the tags except for `@test` in the .java file, you should not remove the `@run` tag from the .java file and add `@key printer` to it. "Should not" is strong. Why ? There's no requirement do to this even though you can. https://openjdk.org/jtreg/faq.html#can-i-use-the-author-run-etc.-tags-in-other-files >> test/jdk/java/awt/print/PageFormat/SmallPaperPrinting.java line 42: >> >>> 40: System.out.println("A passing test should catch a PrinterException"); >>> 41: System.out.println("and should display \"Print error: (exception msg)\"."); >>> 42: System.out.println("---------------------------------------------------\n"); >> >> According to these instructions, the test is to contain a set of `@test` tags: >> >> >> /* >> * @test >> * @key printer >> * @run main/othervm SmallPaperPrinting >> */ >> >> /* >> * @test >> * @key printer >> * @run main/othervm SmallPaperPrinting 1 >> */ >> >> /* >> * @test >> * @key printer >> * @run main/othervm SmallPaperPrinting 2 >> */ >> >> >> Otherwise, it won't run all the cases and no one will ever see these instructions. >> >> For me, the test with the added `@test` tags as above prints an error message in the first two cases: >> >> # id0.jtr >> Print error: >> Paper's imageable height is too small. >> # id1.jtr >> Print error: >> Paper's imageable width is too small. >> >> >> Yet it does not print any error message in the third case where `width=-1`, and **it does not fail**. >> >> If I run it on a system without a printer, the test also *passes successfully*. Perhaps, we can ignore it as the `@key printer` ensures there's a printer the system. >> >> Having said the above, this test requires its own bug to fix the test. > >> Having said the above, this test requires its own bug to fix the test. > > I submitted [JDK-8320671](https://bugs.openjdk.org/browse/JDK-8320671): PageFormat/SmallPaperPrinting.java needs three sets of @test tags I saw that, and it didn't fail at all on mac for any case. Not sure how much I want to get dragged into fixing the test, and there's no bug id to refer back to. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16785#discussion_r1406605795 PR Review Comment: https://git.openjdk.org/jdk/pull/16785#discussion_r1406627015 From jlu at openjdk.org Mon Nov 27 19:43:12 2023 From: jlu at openjdk.org (Justin Lu) Date: Mon, 27 Nov 2023 19:43:12 GMT Subject: RFR: JDK-8320714: java/util/Locale/LocaleProvidersRun.java and java/util/ResourceBundle/modules/visibility/VisibilityTest.java timeout after passing Message-ID: Please review this PR which fixes timeouts for the two tests: _java/util/Locale/LocaleProvidersRun.java_ and _java/util/ResourceBundle/modules/visibility/VisibilityTest.java_. These tests were updated to accept VM flags in [JDK-8319569](https://bugs.openjdk.org/browse/JDK-8319569), which is now causing timeouts in tiers 6 and 8. One set of VM flags causes _VisibilityTest.java_ to timeout with a duration of over 2 hours in tier6. Both have been updated to run without VM flags and marked as `vm.flagless`. ------------- Commit messages: - init Changes: https://git.openjdk.org/jdk/pull/16831/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16831&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8320714 Stats: 4 lines in 2 files changed: 2 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/16831.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16831/head:pull/16831 PR: https://git.openjdk.org/jdk/pull/16831 From prr at openjdk.org Mon Nov 27 20:20:38 2023 From: prr at openjdk.org (Phil Race) Date: Mon, 27 Nov 2023 20:20:38 GMT Subject: RFR: 8320608: Many jtreg printing tests are missing the @printer keyword [v2] In-Reply-To: References: Message-ID: > Many printing tests do not have the @printer keyword. This adds them to those that need it. > I also found one test that has nothing to do with printing in the print folder and moved it out. Phil Race has updated the pull request incrementally with one additional commit since the last revision: 8320608 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16785/files - new: https://git.openjdk.org/jdk/pull/16785/files/cea88f00..5fbc06d1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16785&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16785&range=00-01 Stats: 52 lines in 13 files changed: 16 ins; 13 del; 23 mod Patch: https://git.openjdk.org/jdk/pull/16785.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16785/head:pull/16785 PR: https://git.openjdk.org/jdk/pull/16785 From dl at openjdk.org Mon Nov 27 20:25:25 2023 From: dl at openjdk.org (Doug Lea) Date: Mon, 27 Nov 2023 20:25:25 GMT Subject: RFR: JDK-8319662 ForkJoinPool trims worker threads too slowly [v4] In-Reply-To: References: Message-ID: <6Bx7Qvg6bKKGtxonMkVIdf0s4tLWNrWcTn3D7kZt33U=.8086bcc1-2498-4461-be2a-38e8d348b4c8@github.com> > This update cascades timeouts to trim subsequent workers after the first keepAlive inactive period. 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 five additional commits since the last revision: - Merge branch 'openjdk:master' into JDK-8319662 - Split up method awaitWork; other associated changes. - Merge branch 'openjdk:master' into JDK-8319662 - tweak cascades; reinstate an @Contended; resolve JDK-8319498 - Support cascading idle timeouts ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16725/files - new: https://git.openjdk.org/jdk/pull/16725/files/6d352608..149304e7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16725&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16725&range=02-03 Stats: 12836 lines in 504 files changed: 9127 ins; 2202 del; 1507 mod Patch: https://git.openjdk.org/jdk/pull/16725.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16725/head:pull/16725 PR: https://git.openjdk.org/jdk/pull/16725 From mchung at openjdk.org Mon Nov 27 20:33:06 2023 From: mchung at openjdk.org (Mandy Chung) Date: Mon, 27 Nov 2023 20:33:06 GMT Subject: RFR: 8319571: Update jni/nullCaller/NullCallerTest.java to accept flags or mark as flagless [v2] In-Reply-To: References: Message-ID: On Tue, 21 Nov 2023 17:30:20 GMT, Tim Prinzing wrote: >> Marked as flagless. > > Tim Prinzing has updated the pull request with a new target base 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: > > - use ProcessTools helper class to run test. > - Merge branch 'master' into JDK-8319571 > - Merge branch 'master' into JDK-8319571 > - 8319571: Update jni/nullCaller/NullCallerTest.java to accept flags or mark as flagless > > Marked as flagless. It'd help if the PR description reflects what this change is. It's no longer made VM flagless. ------------- Marked as reviewed by mchung (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16711#pullrequestreview-1751302106 From naoto at openjdk.org Mon Nov 27 20:35:04 2023 From: naoto at openjdk.org (Naoto Sato) Date: Mon, 27 Nov 2023 20:35:04 GMT Subject: RFR: JDK-8320714: java/util/Locale/LocaleProvidersRun.java and java/util/ResourceBundle/modules/visibility/VisibilityTest.java timeout after passing In-Reply-To: References: Message-ID: <6ikNc3VJOr7vqied3hhob7LEfZ6Sz1A_Csiqjr0fT_E=.7b69daed-f970-4b6d-aadd-8f77b699c38f@github.com> On Mon, 27 Nov 2023 19:32:04 GMT, Justin Lu wrote: > Please review this PR which fixes timeouts for the two tests: _java/util/Locale/LocaleProvidersRun.java_ and _java/util/ResourceBundle/modules/visibility/VisibilityTest.java_. > > These tests were updated to accept VM flags in [JDK-8319569](https://bugs.openjdk.org/browse/JDK-8319569), which is now causing timeouts in tiers 6 and 8. One set of VM flags causes _VisibilityTest.java_ to timeout with a duration of over 2 hours in tier6. > > Both have been updated to run without VM flags and marked as `vm.flagless`. Marked as reviewed by naoto (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/16831#pullrequestreview-1751305525 From alexey.semenyuk at oracle.com Mon Nov 27 20:51:12 2023 From: alexey.semenyuk at oracle.com (Alexey Semenyuk) Date: Mon, 27 Nov 2023 15:51:12 -0500 Subject: Automatic modules and jpackage In-Reply-To: <843040014f7f7d3bbbf5f050cb50d9d67ce0e0d2.camel@io7m.com> References: <98e8caaef50f36e49315a7c3beacc9cbebaea444.camel@io7m.com> <843040014f7f7d3bbbf5f050cb50d9d67ce0e0d2.camel@io7m.com> Message-ID: Hi Mark, Good to know you've sorted out the issue. I replied to your email last week, but didn't send it to the right recipients and it got lost. Resending once again just in case: If you want your app's modules in app directory, you can specify external runtime to jpackage with "--runtime-image" cli option. In this case jpackage will not run jlink and compile in your modules. Instead it will copy your modules in "app/mods" directory. You can run jlink before running jpackage and create a runtime you want. Or you can simply pass $JAVA_HOME as an argument to "--runtime-image" cli option. PS Would you mind updating https://blog.io7m.com/2023/11/10/batch-files-are-your-only-option.xhtml page with the solution? jpackage is not a dead end ? and it will support WiX v4. - Alexey On 11/27/2023 12:15 PM, Mark Raynsford wrote: > On Mon, 2023-11-27 at 16:09 +0000, Mark Raynsford wrote: >> As I mentioned in the blog, I feel like almost all of the >> functionality might already be there (minus a way to get the runtime >> to use -p instead of -cp internally), it's just that there doesn't >> appear to be a way to get jpackage to skip one of the steps that >> causes the failure. >> > Well, I feel silly. > > It turns out that it _is_ possible. The key part is the --runtime-image > option. If there's a normal JDK/JRE image in "jre", and the > application's modules are in "jars", then: > > jpackage \ > --runtime-image jre \ > -t app-image \ > --module com.io7m.demo.m3 \ > --module-path jars \ > --name jpackagetest > > This will result in an application image where jpackage/lib/app/mods is > a directory containing the untouched application jars. Additionally: > > $ cat jpackagetest/lib/app/jpackagetest.cfg > [Application] > app.mainmodule=com.io7m.demo.m3/com.io7m.demo.m3.M3 > > [JavaOptions] > java-options=-Djpackage.app-version=20231111 > java-options=--module-path > java-options=$APPDIR/mods > > Running the application shows that it's definitely running in module > path mode. > > I've no idea why I spent all day failing to combine the arguments in > this particular way. Maybe my work in 2024 is to submit a documentation > PR that adds this as an example to the jpackage manual page. > From bpb at openjdk.org Mon Nov 27 21:06:06 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Mon, 27 Nov 2023 21:06:06 GMT Subject: RFR: JDK-8320714: java/util/Locale/LocaleProvidersRun.java and java/util/ResourceBundle/modules/visibility/VisibilityTest.java timeout after passing In-Reply-To: References: Message-ID: On Mon, 27 Nov 2023 19:32:04 GMT, Justin Lu wrote: > Please review this PR which fixes timeouts for the two tests: _java/util/Locale/LocaleProvidersRun.java_ and _java/util/ResourceBundle/modules/visibility/VisibilityTest.java_. > > These tests were updated to accept VM flags in [JDK-8319569](https://bugs.openjdk.org/browse/JDK-8319569), which is now causing timeouts in tiers 6 and 8. One set of VM flags causes _VisibilityTest.java_ to timeout with a duration of over 2 hours in tier6. > > Both have been updated to run without VM flags and marked as `vm.flagless`. Marked as reviewed by bpb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/16831#pullrequestreview-1751354324 From jlu at openjdk.org Mon Nov 27 21:12:17 2023 From: jlu at openjdk.org (Justin Lu) Date: Mon, 27 Nov 2023 21:12:17 GMT Subject: RFR: JDK-8320714: java/util/Locale/LocaleProvidersRun.java and java/util/ResourceBundle/modules/visibility/VisibilityTest.java timeout after passing [v2] In-Reply-To: References: Message-ID: > Please review this PR which fixes timeouts for the two tests: _java/util/Locale/LocaleProvidersRun.java_ and _java/util/ResourceBundle/modules/visibility/VisibilityTest.java_. > > These tests were updated to accept VM flags in [JDK-8319569](https://bugs.openjdk.org/browse/JDK-8319569), which is now causing timeouts in tiers 6 and 8. One set of VM flags causes _VisibilityTest.java_ to timeout with a duration of over 2 hours in tier6. > > Both have been updated to run without VM flags and marked as `vm.flagless`. Justin Lu has updated the pull request incrementally with one additional commit since the last revision: clarify comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16831/files - new: https://git.openjdk.org/jdk/pull/16831/files/f58cb4b5..5ecf4285 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16831&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16831&range=00-01 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/16831.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16831/head:pull/16831 PR: https://git.openjdk.org/jdk/pull/16831 From lancea at openjdk.org Mon Nov 27 21:18:05 2023 From: lancea at openjdk.org (Lance Andersen) Date: Mon, 27 Nov 2023 21:18:05 GMT Subject: RFR: JDK-8320714: java/util/Locale/LocaleProvidersRun.java and java/util/ResourceBundle/modules/visibility/VisibilityTest.java timeout after passing [v2] In-Reply-To: References: Message-ID: <0zq6gbSlNZVhlzQtB5zZiigwQOjINBw-ywMtRoHMsGY=.5e219f63-65c4-4467-b8f8-5e4a9b7540a1@github.com> On Mon, 27 Nov 2023 21:12:17 GMT, Justin Lu wrote: >> Please review this PR which fixes timeouts for the two tests: _java/util/Locale/LocaleProvidersRun.java_ and _java/util/ResourceBundle/modules/visibility/VisibilityTest.java_. >> >> These tests were updated to accept VM flags in [JDK-8319569](https://bugs.openjdk.org/browse/JDK-8319569), which is now causing timeouts in tiers 6 and 8. One set of VM flags causes _VisibilityTest.java_ to timeout with a duration of over 2 hours in tier6. >> >> Both have been updated to run without VM flags and marked as `vm.flagless`. > > Justin Lu has updated the pull request incrementally with one additional commit since the last revision: > > clarify comments Marked as reviewed by lancea (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/16831#pullrequestreview-1751388560 From duke at openjdk.org Mon Nov 27 21:20:11 2023 From: duke at openjdk.org (Srinivas Vamsi Parasa) Date: Mon, 27 Nov 2023 21:20:11 GMT Subject: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort) [v11] In-Reply-To: References: <918oCEfFu2JweXfV-afD1l_AGDDuc7dJwAxip-Ze6ZI=.8d5e9692-23db-47e4-9586-99e53b9cfbb6@github.com> <5VlrwO4ABJC1fPxj7Y0TAWV4izuo4dEl_fzSM1dPD4A=.83909050-fb10-40a8-8cdd-9cf67fca0724@github.com> Message-ID: On Fri, 17 Nov 2023 23:14:18 GMT, Srinivas Vamsi Parasa wrote: >> Hello Vamsi (@vamsi-parasa), >> >> Thank you very much for benchmarking, I appreciate your efforts! >> >> I looked at non-parallel sorting when radix sort is switched off (DualPivotQuicksort_RadixForParallel) and cannot explain the following data for STAGGER where all speedup < 1: >> testSort STAGGER 7000 0.92 >> testSort STAGGER 50000 0.84 >> testSort STAGGER 300000 0.85 >> testSort STAGGER 2000000 0.83 >> In these cases both versions go directly to merging sort: no quicksort, no insertion sort, no radix sort at all >> and therefore, no intrinsic also, Java code only,merging sort only. >> It is expected that benchmarking without AVX512 should be the same, >> but my benchmarking on Windows shows speedup 1.0 .. 1.10. >> >> Vamsi, >> Could you please run benchmarking with derived classes from jdk and my version? >> https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_a01.java >> https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_a02.java >> https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_r01.java >> II hope i allows us to detect the root of such behaviour. >> >> Please check sequential sorting only (parallel sort is out of scope now). >> I see you used not the latest ArraysSort, I pointed to https://github.com/iaroslavski/sorting/blob/master/radixsort/ArraysSort.java >> >> It is not critical, but it will be better to be in the same environment, see >> increased warmup, specified parameters for run and updated data sets >> @Warmup(iterations = 2, time = 3, timeUnit = TimeUnit.SECONDS) >> @Measurement(iterations = 4, time = 3, timeUnit = TimeUnit.SECONDS) >> @Fork(value=1, jvmArgsAppend={"-XX:CompileThreshold=1", "-XX:-TieredCompilation"}) >> >> Could you please spare some time and provide the performance data? > > Hello Vladimir (@iaroslavski), > > You're welcome! > Will provide the performance data (for the next set of experiments) within few days. > > Thanks, > Vamsi > Hello Vamsi (@vamsi-parasa), > > Do you have the new results? Hi Vladimir (@iaroslavski), Sorry for the delay as I was on vacation the whole of last week. Will provide the data today by EOD (US pacific time). (Looks like, my reply comment posted last week was not delivered as it was mistakenly sent from my personal github account.) Thanks, Vamsi ------------- PR Comment: https://git.openjdk.org/jdk/pull/13568#issuecomment-1828629476 From almatvee at openjdk.org Mon Nov 27 21:21:05 2023 From: almatvee at openjdk.org (Alexander Matveev) Date: Mon, 27 Nov 2023 21:21:05 GMT Subject: RFR: 8320249: tools/jpackage/share/AddLauncherTest.java#id1 fails intermittently on Windows in verifyDescription [v2] In-Reply-To: References: Message-ID: On Fri, 24 Nov 2023 22:31:18 GMT, Alexey Semenyuk wrote: >> 8320249: tools/jpackage/share/AddLauncherTest.java#id1 fails intermittently on Windows in verifyDescription > > Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision: > > fix utf8 representation Looks good. ------------- Marked as reviewed by almatvee (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16814#pullrequestreview-1751393743 From asemenyuk at openjdk.org Mon Nov 27 21:21:06 2023 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Mon, 27 Nov 2023 21:21:06 GMT Subject: RFR: 8320249: tools/jpackage/share/AddLauncherTest.java#id1 fails intermittently on Windows in verifyDescription [v2] In-Reply-To: References: Message-ID: On Fri, 24 Nov 2023 22:31:18 GMT, Alexey Semenyuk wrote: >> 8320249: tools/jpackage/share/AddLauncherTest.java#id1 fails intermittently on Windows in verifyDescription > > Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision: > > fix utf8 representation @sashamatveev please review ------------- PR Comment: https://git.openjdk.org/jdk/pull/16814#issuecomment-1828513907 From duke at openjdk.org Mon Nov 27 21:28:12 2023 From: duke at openjdk.org (Vladimir Yaroslavskiy) Date: Mon, 27 Nov 2023 21:28:12 GMT Subject: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort) [v11] In-Reply-To: References: <918oCEfFu2JweXfV-afD1l_AGDDuc7dJwAxip-Ze6ZI=.8d5e9692-23db-47e4-9586-99e53b9cfbb6@github.com> <5VlrwO4ABJC1fPxj7Y0TAWV4izuo4dEl_fzSM1dPD4A=.83909050-fb10-40a8-8cdd-9cf67fca0724@github.com> Message-ID: On Mon, 27 Nov 2023 21:17:24 GMT, Srinivas Vamsi Parasa wrote: > > Hello Vamsi (@vamsi-parasa), > > Do you have the new results? > > Hi Vladimir (@iaroslavski), > > Sorry for the delay as I was on vacation the whole of last week. Will provide the data today by EOD (US pacific time). (Looks like, my reply comment posted last week was not delivered as it was mistakenly sent from my personal github account.) > > Thanks, Vamsi Hi Vams (@vamsi-parasa), Your comment is not here, but github notified me by email. Thank you for your support! ------------- PR Comment: https://git.openjdk.org/jdk/pull/13568#issuecomment-1828639617 From core-libs-dev at io7m.com Mon Nov 27 21:43:01 2023 From: core-libs-dev at io7m.com (Mark Raynsford) Date: Mon, 27 Nov 2023 21:43:01 +0000 Subject: Automatic modules and jpackage In-Reply-To: References: <98e8caaef50f36e49315a7c3beacc9cbebaea444.camel@io7m.com> <843040014f7f7d3bbbf5f050cb50d9d67ce0e0d2.camel@io7m.com> Message-ID: <16415986ac1d9dc047fdc08e50358c17682f04cf.camel@io7m.com> On Mon, 2023-11-27 at 15:51 -0500, Alexey Semenyuk wrote: > Hi Mark, > > Good to know you've sorted out the issue. I replied to your email > last > week, but didn't send it to the right recipients and it got lost. > Resending once again just in case: > > If you want your app's modules in app directory, you can specify > external runtime to jpackage with "--runtime-image" cli option. In > this > case jpackage will not run jlink and compile in your modules. Instead > it > will copy your modules in "app/mods" directory. > You can run jlink before running jpackage and create a runtime you > want. > Or you can simply pass $JAVA_HOME as an argument to "--runtime-image" > cli option. Thanks! > > PS Would you mind updating > https://blog.io7m.com/2023/11/10/batch-files-are-your-only-option.xhtml > ? > page with the solution? jpackage is not a dead end ? and it will > support WiX v4. Yep, way ahead of you... :) https://blog.io7m.com/2023/11/27/batch-files-are-not-your-only-option.xhtml I look forward to WiX v4 support. Setting up WiX v3 to work in a CI setting is a bit rough at the moment. v4 is far easier to set up, but obviously not supported yet (they've removed/renamed various executables, as you probably know). -- Mark Raynsford | https://www.io7m.com From asemenyuk at openjdk.org Mon Nov 27 21:46:13 2023 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Mon, 27 Nov 2023 21:46:13 GMT Subject: Integrated: 8320249: tools/jpackage/share/AddLauncherTest.java#id1 fails intermittently on Windows in verifyDescription In-Reply-To: References: Message-ID: On Fri, 24 Nov 2023 22:20:20 GMT, Alexey Semenyuk wrote: > 8320249: tools/jpackage/share/AddLauncherTest.java#id1 fails intermittently on Windows in verifyDescription This pull request has now been integrated. Changeset: 5f7f2c4e Author: Alexey Semenyuk URL: https://git.openjdk.org/jdk/commit/5f7f2c4ea07d41c2f280ca341b49c857c1436224 Stats: 43 lines in 8 files changed: 31 ins; 0 del; 12 mod 8320249: tools/jpackage/share/AddLauncherTest.java#id1 fails intermittently on Windows in verifyDescription Reviewed-by: almatvee ------------- PR: https://git.openjdk.org/jdk/pull/16814 From almatvee at openjdk.org Mon Nov 27 22:04:05 2023 From: almatvee at openjdk.org (Alexander Matveev) Date: Mon, 27 Nov 2023 22:04:05 GMT Subject: RFR: 8320706: RuntimePackageTest.testUsrInstallDir test fails on Linux In-Reply-To: References: Message-ID: On Fri, 24 Nov 2023 16:33:13 GMT, Alexey Semenyuk wrote: > 8320706: RuntimePackageTest.testUsrInstallDir test fails on Linux Looks good. ------------- Marked as reviewed by almatvee (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16810#pullrequestreview-1751469146 From asemenyuk at openjdk.org Mon Nov 27 22:04:05 2023 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Mon, 27 Nov 2023 22:04:05 GMT Subject: RFR: 8320706: RuntimePackageTest.testUsrInstallDir test fails on Linux In-Reply-To: References: Message-ID: On Fri, 24 Nov 2023 16:33:13 GMT, Alexey Semenyuk wrote: > 8320706: RuntimePackageTest.testUsrInstallDir test fails on Linux @sashamatveev please review ------------- PR Comment: https://git.openjdk.org/jdk/pull/16810#issuecomment-1828514026 From alexey.semenyuk at oracle.com Mon Nov 27 22:18:05 2023 From: alexey.semenyuk at oracle.com (Alexey Semenyuk) Date: Mon, 27 Nov 2023 17:18:05 -0500 Subject: [External] : Re: Automatic modules and jpackage In-Reply-To: <16415986ac1d9dc047fdc08e50358c17682f04cf.camel@io7m.com> References: <98e8caaef50f36e49315a7c3beacc9cbebaea444.camel@io7m.com> <843040014f7f7d3bbbf5f050cb50d9d67ce0e0d2.camel@io7m.com> <16415986ac1d9dc047fdc08e50358c17682f04cf.camel@io7m.com> Message-ID: On 11/27/2023 4:43 PM, Mark Raynsford wrote: > On Mon, 2023-11-27 at 15:51 -0500, Alexey Semenyuk wrote: >> Hi Mark, >> >> Good to know you've sorted out the issue. I replied to your email >> last >> week, but didn't send it to the right recipients and it got lost. >> Resending once again just in case: >> >> If you want your app's modules in app directory, you can specify >> external runtime to jpackage with "--runtime-image" cli option. In >> this >> case jpackage will not run jlink and compile in your modules. Instead >> it >> will copy your modules in "app/mods" directory. >> You can run jlink before running jpackage and create a runtime you >> want. >> Or you can simply pass $JAVA_HOME as an argument to "--runtime-image" >> cli option. > Thanks! > >> PS Would you mind updating >> https://urldefense.com/v3/__https://blog.io7m.com/2023/11/10/batch-files-are-your-only-option.xhtml__;!!ACWV5N9M2RV99hQ!I6pyEwewDHFRM2GBn_2IUZItmkR1_2iw0iGU8x1xS6cYXvZlrmgai8Px4y2RAsBNZinxW2cgpmCxGonPxzO9t2gmcDQz$ >> >> page with the solution? jpackage is not a dead end ? and it will >> support WiX v4. > Yep, way ahead of you... :) > > https://urldefense.com/v3/__https://blog.io7m.com/2023/11/27/batch-files-are-not-your-only-option.xhtml__;!!ACWV5N9M2RV99hQ!I6pyEwewDHFRM2GBn_2IUZItmkR1_2iw0iGU8x1xS6cYXvZlrmgai8Px4y2RAsBNZinxW2cgpmCxGonPxzO9t7YIFzjx$ Nice! > > I look forward to WiX v4 support. Setting up WiX v3 to work in a CI > setting is a bit rough at the moment. v4 is far easier to set up, but > obviously not supported yet (they've removed/renamed various > executables, as you probably know). Yeah, they merged all commands into single one and on top of that changed the format of? source files. Keep us entertained. - Alexey > From asemenyuk at openjdk.org Mon Nov 27 22:23:15 2023 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Mon, 27 Nov 2023 22:23:15 GMT Subject: Integrated: 8320706: RuntimePackageTest.testUsrInstallDir test fails on Linux In-Reply-To: References: Message-ID: On Fri, 24 Nov 2023 16:33:13 GMT, Alexey Semenyuk wrote: > 8320706: RuntimePackageTest.testUsrInstallDir test fails on Linux This pull request has now been integrated. Changeset: 726f854b Author: Alexey Semenyuk URL: https://git.openjdk.org/jdk/commit/726f854b141dc2f6474e81c7bcf12608bf6577ae Stats: 11 lines in 1 file changed: 7 ins; 0 del; 4 mod 8320706: RuntimePackageTest.testUsrInstallDir test fails on Linux Reviewed-by: almatvee ------------- PR: https://git.openjdk.org/jdk/pull/16810 From almatvee at openjdk.org Mon Nov 27 22:24:05 2023 From: almatvee at openjdk.org (Alexander Matveev) Date: Mon, 27 Nov 2023 22:24:05 GMT Subject: RFR: 8301856: Generated .spec file for RPM installers uninstalls desktop launcher on update In-Reply-To: References: Message-ID: On Thu, 23 Nov 2023 16:36:28 GMT, Alexey Semenyuk wrote: > Fix uninstallation scripts in Linux installers to take action on desktop files only if these desktop files are not owned by another package. This prevents `xdg-mime uninstall`, `xdg-desktop-menu uninstall` commands from execution in case of upgrades. > > Borrowed helper shell script function from "launchers as services" for the fix. Now on Linux there is shared code between "launchers as services" and "desktop integration" subsystems - "common_utils.sh". Added `ServiceAndDesktopTest.java` to test how they align. Looks good. ------------- Marked as reviewed by almatvee (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16800#pullrequestreview-1751505209 From asemenyuk at openjdk.org Mon Nov 27 22:24:06 2023 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Mon, 27 Nov 2023 22:24:06 GMT Subject: RFR: 8301856: Generated .spec file for RPM installers uninstalls desktop launcher on update In-Reply-To: References: Message-ID: On Thu, 23 Nov 2023 16:36:28 GMT, Alexey Semenyuk wrote: > Fix uninstallation scripts in Linux installers to take action on desktop files only if these desktop files are not owned by another package. This prevents `xdg-mime uninstall`, `xdg-desktop-menu uninstall` commands from execution in case of upgrades. > > Borrowed helper shell script function from "launchers as services" for the fix. Now on Linux there is shared code between "launchers as services" and "desktop integration" subsystems - "common_utils.sh". Added `ServiceAndDesktopTest.java` to test how they align. @sashamatveev please review ------------- PR Comment: https://git.openjdk.org/jdk/pull/16800#issuecomment-1828514315 From asemenyuk at openjdk.org Mon Nov 27 22:31:19 2023 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Mon, 27 Nov 2023 22:31:19 GMT Subject: Integrated: 8301856: Generated .spec file for RPM installers uninstalls desktop launcher on update In-Reply-To: References: Message-ID: <_rRN6FTQOru7Q9oB4wHr5LpR0YCasdqMx8vyCz1SsNE=.def0d600-8c71-4475-9be9-53380f36d572@github.com> On Thu, 23 Nov 2023 16:36:28 GMT, Alexey Semenyuk wrote: > Fix uninstallation scripts in Linux installers to take action on desktop files only if these desktop files are not owned by another package. This prevents `xdg-mime uninstall`, `xdg-desktop-menu uninstall` commands from execution in case of upgrades. > > Borrowed helper shell script function from "launchers as services" for the fix. Now on Linux there is shared code between "launchers as services" and "desktop integration" subsystems - "common_utils.sh". Added `ServiceAndDesktopTest.java` to test how they align. This pull request has now been integrated. Changeset: 7848ed77 Author: Alexey Semenyuk URL: https://git.openjdk.org/jdk/commit/7848ed779b8c292fe78b5e4c90a7504e034e1bf0 Stats: 407 lines in 16 files changed: 333 ins; 30 del; 44 mod 8301856: Generated .spec file for RPM installers uninstalls desktop launcher on update Reviewed-by: almatvee ------------- PR: https://git.openjdk.org/jdk/pull/16800 From duke at openjdk.org Mon Nov 27 22:36:06 2023 From: duke at openjdk.org (Hans Boehm) Date: Mon, 27 Nov 2023 22:36:06 GMT Subject: RFR: 8314480: Memory ordering spec updates in java.lang.ref In-Reply-To: References: Message-ID: On Mon, 13 Nov 2023 22:31:16 GMT, Brent Christian wrote: > Classes in the `java.lang.ref` package would benefit from an update to bring the spec in line with how the VM already behaves. The changes would focus on _happens-before_ edges at some key points during reference processing. > > A couple key things we want to be able to say are: > - `Reference.reachabilityFence(x)` _happens-before_ reference processing occurs for 'x'. > - `Cleaner.register()` _happens-before_ the Cleaner thread runs the registered cleaning action. > > This will bring Cleaner in line (or close) with the memory visibility guarantees made for finalizers in [JLS 17.4.5](https://docs.oracle.com/javase/specs/jls/se18/html/jls-17.html#jls-17.4.5): > _"There is a happens-before edge from the end of a constructor of an object to the start of a finalizer (?12.6) for that object."_ src/java.base/share/classes/java/lang/ref/Reference.java line 546: > 544: * strongly reachable, > 545: * regardless of any other actions of the program that might otherwise cause > 546: * the object to become unreachable; thus, the object is not Delete "regardless of any other actions of the program that might otherwise cause the object to become unreachable" ? I have no idea what actions would qualify there. And it's more misleading thann informative, since IMO the real concern here is compiler dead variable elimination. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16644#discussion_r1406844556 From duke at openjdk.org Mon Nov 27 22:36:09 2023 From: duke at openjdk.org (Hans Boehm) Date: Mon, 27 Nov 2023 22:36:09 GMT Subject: RFR: 8314480: Memory ordering spec updates in java.lang.ref In-Reply-To: References: Message-ID: On Tue, 21 Nov 2023 22:58:09 GMT, Roger Riggs wrote: >> Classes in the `java.lang.ref` package would benefit from an update to bring the spec in line with how the VM already behaves. The changes would focus on _happens-before_ edges at some key points during reference processing. >> >> A couple key things we want to be able to say are: >> - `Reference.reachabilityFence(x)` _happens-before_ reference processing occurs for 'x'. >> - `Cleaner.register()` _happens-before_ the Cleaner thread runs the registered cleaning action. >> >> This will bring Cleaner in line (or close) with the memory visibility guarantees made for finalizers in [JLS 17.4.5](https://docs.oracle.com/javase/specs/jls/se18/html/jls-17.html#jls-17.4.5): >> _"There is a happens-before edge from the end of a constructor of an object to the start of a finalizer (?12.6) for that object."_ > > src/java.base/share/classes/java/lang/ref/Reference.java line 552: > >> 550: * of this method. >> 551: * Invocation of this method does not itself initiate reference processing, >> 552: * garbage collection, or finalization. > > My understanding was that it is not the object instance that is being guarded, only that the reference holding the object is considered a strong root and is only used to delimit a range of bytecodes for which the reference is considered to be strong. > In particular, the invocation of the method itself has no semantics, only that a control flow could reach that statement and the reference was considered strong as long as the reference was in a scope that included the reachability fence. IMO, the core of the semantics here are that the reachabilityFence() call happens before clearing or enqueueing of any References to the argument. I think it's the call itself, not the end of the argument.s scope (which may not even make sense) that matters here. Perhaps reachabilityFence(x) should also happen before any objects that are definitely reachable from x (JLS 12.6.2) at that point are cleared or enqueued. That is not completely clear to me, since it impacts the legality of dead field elimination. And it would be nice to get rid of 12.6.2. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16644#discussion_r1406842978 From bpb at openjdk.org Mon Nov 27 22:37:07 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Mon, 27 Nov 2023 22:37:07 GMT Subject: RFR: 8320759: Creation of random BigIntegers can be made faster In-Reply-To: References: Message-ID: <4WB_FtpmH5qbqDU3zMoTCkGFRVaMmBSrRRjSVA33TKE=.698ad745-b5d7-4471-8c29-019dcaea988b@github.com> On Sun, 26 Nov 2023 16:52:40 GMT, fabioromano1 wrote: > A faster and simpler way to generate random BigIntegers, avoiding eventually trimming of leading zeros in magnitude array. src/java.base/share/classes/java/math/BigInteger.java line 732: > 730: */ > 731: public BigInteger(int numBits, Random rnd) { > 732: // randomBits() returns a zero length array if len == 0 Should this comment say "if numBits == 0"? src/java.base/share/classes/java/math/BigInteger.java line 754: > 752: // numInts >= 1, since numBits > 0 > 753: > 754: int firstInt = rnd.nextInt() & (-1 >>> -numBits); // Mask out any excess bits Instead of `numBits`, shouldn't this use something like `excessBits` similar to line 760 in the old version? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16817#discussion_r1406843451 PR Review Comment: https://git.openjdk.org/jdk/pull/16817#discussion_r1406847756 From duke at openjdk.org Mon Nov 27 22:44:10 2023 From: duke at openjdk.org (Hans Boehm) Date: Mon, 27 Nov 2023 22:44:10 GMT Subject: RFR: 8314480: Memory ordering spec updates in java.lang.ref In-Reply-To: References: Message-ID: On Mon, 13 Nov 2023 22:31:16 GMT, Brent Christian wrote: > Classes in the `java.lang.ref` package would benefit from an update to bring the spec in line with how the VM already behaves. The changes would focus on _happens-before_ edges at some key points during reference processing. > > A couple key things we want to be able to say are: > - `Reference.reachabilityFence(x)` _happens-before_ reference processing occurs for 'x'. > - `Cleaner.register()` _happens-before_ the Cleaner thread runs the registered cleaning action. > > This will bring Cleaner in line (or close) with the memory visibility guarantees made for finalizers in [JLS 17.4.5](https://docs.oracle.com/javase/specs/jls/se18/html/jls-17.html#jls-17.4.5): > _"There is a happens-before edge from the end of a constructor of an object to the start of a finalizer (?12.6) for that object."_ src/java.base/share/classes/java/lang/ref/Reference.java line 568: > 566: * > 567: * @apiNote > 568: * Reference processing or finalization may occur whenever the virtual machine detects that no How about "detects that all needed data from the object is available elsewhere, and no reference to that object will ever be stored ..." Otherwise this seems needlessly mysterious to me. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16644#discussion_r1406857727 From dl at openjdk.org Mon Nov 27 22:44:30 2023 From: dl at openjdk.org (Doug Lea) Date: Mon, 27 Nov 2023 22:44:30 GMT Subject: RFR: JDK-8319662 ForkJoinPool trims worker threads too slowly [v5] In-Reply-To: References: Message-ID: > This update cascades timeouts to trim subsequent workers after the first keepAlive inactive period. Doug Lea has updated the pull request incrementally with one additional commit since the last revision: Revert 2 lines in method scan ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16725/files - new: https://git.openjdk.org/jdk/pull/16725/files/149304e7..e111166f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16725&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16725&range=03-04 Stats: 5 lines in 1 file changed: 2 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/16725.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16725/head:pull/16725 PR: https://git.openjdk.org/jdk/pull/16725 From iris at openjdk.org Mon Nov 27 22:46:05 2023 From: iris at openjdk.org (Iris Clark) Date: Mon, 27 Nov 2023 22:46:05 GMT Subject: RFR: JDK-8319413: Start of release updates for JDK 23 In-Reply-To: References: Message-ID: On Fri, 3 Nov 2023 23:42:03 GMT, Joe Darcy wrote: > Time to start making preparations for JDK 23. Marked as reviewed by iris (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/16505#pullrequestreview-1751551968 From duke at openjdk.org Mon Nov 27 22:55:08 2023 From: duke at openjdk.org (fabioromano1) Date: Mon, 27 Nov 2023 22:55:08 GMT Subject: RFR: 8320759: Creation of random BigIntegers can be made faster In-Reply-To: <4WB_FtpmH5qbqDU3zMoTCkGFRVaMmBSrRRjSVA33TKE=.698ad745-b5d7-4471-8c29-019dcaea988b@github.com> References: <4WB_FtpmH5qbqDU3zMoTCkGFRVaMmBSrRRjSVA33TKE=.698ad745-b5d7-4471-8c29-019dcaea988b@github.com> Message-ID: <9linin03BjEwpwt9j1cCabK_AhfWjp7M9uxTY7MxAlQ=.6467a7a8-87d0-48dc-a05f-c6f3339f136e@github.com> On Mon, 27 Nov 2023 22:34:12 GMT, Brian Burkhalter wrote: >> A faster and simpler way to generate random BigIntegers, avoiding eventually trimming of leading zeros in magnitude array. > > src/java.base/share/classes/java/math/BigInteger.java line 754: > >> 752: // numInts >= 1, since numBits > 0 >> 753: >> 754: int firstInt = rnd.nextInt() & (-1 >>> -numBits); // Mask out any excess bits > > Instead of `numBits`, shouldn't this use something like `excessBits` similar to line 760 in the old version? It's equivalent. If you watch the implementations of other methods in the class where a mask out is made, this method is often used. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16817#discussion_r1406865830 From duke at openjdk.org Mon Nov 27 22:58:17 2023 From: duke at openjdk.org (fabioromano1) Date: Mon, 27 Nov 2023 22:58:17 GMT Subject: RFR: 8320759: Creation of random BigIntegers can be made faster [v2] In-Reply-To: References: Message-ID: > A faster and simpler way to generate random BigIntegers, avoiding eventually trimming of leading zeros in magnitude array. fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: Update BigInteger(int, Random) Update a comment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16817/files - new: https://git.openjdk.org/jdk/pull/16817/files/000261de..928a13a1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16817&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16817&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/16817.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16817/head:pull/16817 PR: https://git.openjdk.org/jdk/pull/16817 From darcy at openjdk.org Mon Nov 27 23:39:25 2023 From: darcy at openjdk.org (Joe Darcy) Date: Mon, 27 Nov 2023 23:39:25 GMT Subject: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v2] In-Reply-To: References: <3pl66yHVt5I61JBf_1hKObxaK7Tiutw6S5a6MFhiSqY=.7b4b525c-19a0-4a46-8ecb-d26a27c6427f@github.com> Message-ID: <-Tw35Sh8XjisOJEIbFFVf_xE7asoSucQDV97LsOkWdA=.5f97af1f-86b1-47b2-9d92-752f0b40f6fd@github.com> On Thu, 2 Nov 2023 17:42:48 GMT, Jim Laskey wrote: >> `UNNAMED_CLASSES` should probably be removed, as I think it is fully replaced with `IMPLICIT_CLASSES`, and I don't think there are bootstrap problems here (unlike in `jdk.internal.java.PreviewFeature`). I would say it would make sense to set the version to `JDK22`, although the difference is very small given the feature is a preview and requires `-source 22` anyway. (Although we keep the `@since` value for the duration of preview.) > > Changing I had the same question when reading over the changes if JDK21 or JDK22 should be used for IMPLICIT_CLASSES. I think it would help if the comment of the Feature enum documented what the expected protocol was for previewing features. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16461#discussion_r1406896429 From svein.otto.solem at gmail.com Mon Nov 27 23:46:58 2023 From: svein.otto.solem at gmail.com (Svein Otto Solem) Date: Mon, 27 Nov 2023 23:46:58 +0000 Subject: RFR: 8319123: Implement JEP 461: Stream Gatherers (Preview) [v13] Message-ID: I tried to understand the GathererOp class and came over a small detail concering Gatherer.Integrator. The two gatheres below are equivalent, both are greedy. Gatherer.Integrator.Greedy voidStringIntegerGreedy = (v, s, downStream) -> downStream.push(s.length()); var greedy1 = Gatherer.of(Gatherer.Integrator.ofGreedy(voidStringIntegerGreedy)); var greedy2 = Gatherer.of(Gatherer.Integrator.of(voidStringIntegerGreedy)); Inlining the lambda makes them different. var greedy = Gatherer.of(Gatherer.Integrator.ofGreedy((v, s, downStream) -> downStream.push(s.length()))); var nonGreedy = Gatherer.of(Gatherer.Integrator.of((v, s, downStream) -> downStream.push(s.length()))); If this can be a problem an introduction of an Integrator subtype like NonGreedy would have given a compiler error on the "var greedy2 =" line instead. interface Integrator { ??????..... ? static NonGreedy of(NonGreedy integrator) { return integrator; } static Greedy ofGreedy(Greedy greedy) { return greedy; } interface Greedy extends Integrator { } interface NonGreedy extends Integrator { } ?? } Svein Otto Solem Retired programmer Kantega -------------- next part -------------- An HTML attachment was scrubbed... URL: From sviswanathan at openjdk.org Mon Nov 27 23:47:07 2023 From: sviswanathan at openjdk.org (Sandhya Viswanathan) Date: Mon, 27 Nov 2023 23:47:07 GMT Subject: RFR: 8319577: x86_64 AVX2 intrinsics for Arrays.sort methods (int, float arrays) [v2] In-Reply-To: References: Message-ID: On Tue, 21 Nov 2023 15:14:28 GMT, Dalibor Topic wrote: >> src/java.base/linux/native/libsimdsort/avx2-32bit-qsort.hpp line 3: >> >>> 1: /* >>> 2: * Copyright (c) 2021, 2023, Intel Corporation. All rights reserved. >>> 3: * Copyright (c) 2021 Serge Sans Paille. All rights reserved. >> >> Is this person an OpenJDK Contributor? > > Not listed here: https://oca.opensource.oracle.com/?ojr=contributors Yes, Vamsi is part of Intel Java team. He also has the author status (https://openjdk.org/census#sparasa). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16534#discussion_r1406904710 From darcy at openjdk.org Mon Nov 27 23:49:26 2023 From: darcy at openjdk.org (Joe Darcy) Date: Mon, 27 Nov 2023 23:49:26 GMT Subject: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v35] In-Reply-To: References: Message-ID: On Fri, 24 Nov 2023 12:56:40 GMT, Jim Laskey wrote: >> Address changes from JEP 445 to JEP 463. >> >> - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. >> >> - Don't mark class on read. >> >> - Remove reflection and annotation processing related to unnamed classes. >> >> - Simplify main method search. > > Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: > > Requested changes test/langtools/tools/javac/ImplicitClass/TestImplicitClass.java line 35: > 33: import java.lang.reflect.Modifier; > 34: > 35: public class TestImplicitClass { The test looks to be testing core reflection behavior (i.e. runtime behavior) and not compile-time behavior via javax.lang.model. Core reflection tests should be done too, but done the core libraries tests, not langtools tests. I might have overlooked it, but if some other exercise of compile-time modeling is not being done, please restore and update accordingly the sort of tests previously done in the now-deleted test/langtools/tools/javac/processing/model/element/TestUnnamedClass.java ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16461#discussion_r1406905612 From duke at openjdk.org Tue Nov 28 00:11:10 2023 From: duke at openjdk.org (Srinivas Vamsi Parasa) Date: Tue, 28 Nov 2023 00:11:10 GMT Subject: RFR: 8319577: x86_64 AVX2 intrinsics for Arrays.sort methods (int, float arrays) [v2] In-Reply-To: References: <4XHLjTI5l8tGKCU8_iE53H7EY9-0EjR1gbbFWF57rfI=.8b7585bd-f829-4c3b-81ca-ddc8301c2179@github.com> Message-ID: On Tue, 28 Nov 2023 00:04:55 GMT, Sandhya Viswanathan wrote: >> Srinivas Vamsi Parasa has updated the pull request with a new target base 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: >> >> - Disable AVX2 sort for 64-bit types >> - Merge branch 'master' of https://git.openjdk.java.net/jdk into simdsort >> - fix jcheck failures due to windows encoding >> - fix carriage return and change insertion sort thresholds >> - fix formatting and white spaces >> - cleanup unused code >> - fix insertion sort thresholds >> - add insertion sort >> - fix headers >> - revert to xss-common-qsort >> - ... and 1 more: https://git.openjdk.org/jdk/compare/36991c25...08307b6a > > src/hotspot/share/opto/library_call.cpp line 5391: > >> 5389: BasicType bt = elem_type->basic_type(); >> 5390: // Disable the intrinsic for 64-bit types with AVX2 >> 5391: if ((bt == T_LONG || bt == T_DOUBLE) && UseAVX == 2) { > > UseAVX is platform specific and cannot be used in library_call.cpp. Thanks Sandhya, will fix this issue. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16534#discussion_r1406924860 From sviswanathan at openjdk.org Tue Nov 28 00:11:09 2023 From: sviswanathan at openjdk.org (Sandhya Viswanathan) Date: Tue, 28 Nov 2023 00:11:09 GMT Subject: RFR: 8319577: x86_64 AVX2 intrinsics for Arrays.sort methods (int, float arrays) [v2] In-Reply-To: <4XHLjTI5l8tGKCU8_iE53H7EY9-0EjR1gbbFWF57rfI=.8b7585bd-f829-4c3b-81ca-ddc8301c2179@github.com> References: <4XHLjTI5l8tGKCU8_iE53H7EY9-0EjR1gbbFWF57rfI=.8b7585bd-f829-4c3b-81ca-ddc8301c2179@github.com> Message-ID: On Sat, 18 Nov 2023 01:21:09 GMT, Srinivas Vamsi Parasa wrote: >> The goal is to develop faster sort routines for x86_64 CPUs by taking advantage of AVX2 instructions. This enhancement provides an order of magnitude speedup for Arrays.sort() using int, long, float and double arrays. >> >> For serial sort on random data, this PR shows upto ~7.5x improvement for 32-bit datatypes (int, float) on Intel TigerLake machine as shown in the performance data below. >> >> For parallel sort on random data, this PR shows upto ~3.4x for 32-bit datatypes (int, float) as shown below. >> >> **Note:** This PR also improves the performance of AVX512 sort by upto 35%. >> >> > xmlns:o="urn:schemas-microsoft-com:office:office" >> xmlns:x="urn:schemas-microsoft-com:office:excel" >> xmlns="http://www.w3.org/TR/REC-html40"> >> >> >> >> >> >> > href="file:///C:/Users/sparasa/AppData/Local/Temp/msohtmlclip1/01/clip.htm"> >> > href="file:///C:/Users/sparasa/AppData/Local/Temp/msohtmlclip1/01/clip_filelist.xml"> >> >> >> >> >> >> >> >> >> Benchmark (Serial Sort) | Size | Baseline (us/op) | AVX2 (us/op) | Speedup >> -- | -- | -- | -- | -- >> ArraysSort.intSort | 10 | 0.034 | 0.029 | 1.2 >> ArraysSort.intSort | 25 | 0.088 | 0.044 | 2.0 >> ArraysSort.intSort | 50 | 0.239 | 0.159 | 1.5 >> ArraysSort.intSort | 75 | 0.417 | 0.27 | 1.5 >> ArraysSort.intSort | 100 | 0.572 | 0.265 | 2.2 >> ArraysSort.intSort | 1000 | 10.098 | 4.282 | 2.4 >> ArraysSort.intSort | 10000 | 330.065 | 43.383 | 7.6 >> ArraysSort.intSort | 100000 | 4099.527 | 778.943 | 5.3 >> ArraysSort.intSort | 1000000 | 49150.16 | 9634.335 | 5.1 >> ArraysSort.floatSort | 10 | 0.045 | 0.043 | 1.0 >> ArraysSort.floatSort | 25 | 0.105 | 0.073 | 1.4 >> ArraysSort.floatSort | 50 | 0.278 | 0.216 | 1.3 >> ArraysSort.floatSort | 75 | 0.476 | 0.241 | 2.0 >> ArraysSort.floatSort | 100 | 0.583 | 0.313 | 1.9 >> ArraysSort.floatSort | 1000 | 10.182 | 4.329 | 2.4 >> ArraysSort.floatSort | 10000 | 323.136 | 57.175 | 5.7 >> ArraysSort.floatSort | 100000 | 4299.519 | 862.63 | 5.0 >> ArraysSort.floatSort | 1000000 | 50889.4 | 10972.19 | 4.6 >> >> >> >> >> >> > xmlns:o="urn:schemas-microsoft-com:office:office" >> xmlns:x="urn:schemas-microsoft-com:office:excel" >> xmlns="http://www.w3.org/TR/REC-html40"> >> >> >> >> > Srinivas Vamsi Parasa has updated the pull request with a new target base 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: > > - Disable AVX2 sort for 64-bit types > - Merge branch 'master' of https://git.openjdk.java.net/jdk into simdsort > - fix jcheck failures due to windows encoding > - fix carriage return and change insertion sort thresholds > - fix formatting and white spaces > - cleanup unused code > - fix insertion sort thresholds > - add insertion sort > - fix headers > - revert to xss-common-qsort > - ... and 1 more: https://git.openjdk.org/jdk/compare/36991c25...08307b6a src/hotspot/share/opto/library_call.cpp line 5391: > 5389: BasicType bt = elem_type->basic_type(); > 5390: // Disable the intrinsic for 64-bit types with AVX2 > 5391: if ((bt == T_LONG || bt == T_DOUBLE) && UseAVX == 2) { UseAVX is platform specific and cannot be used in library_call.cpp. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16534#discussion_r1406923009 From duke at openjdk.org Tue Nov 28 00:40:13 2023 From: duke at openjdk.org (Srinivas Vamsi Parasa) Date: Tue, 28 Nov 2023 00:40:13 GMT Subject: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort) [v11] In-Reply-To: References: <918oCEfFu2JweXfV-afD1l_AGDDuc7dJwAxip-Ze6ZI=.8d5e9692-23db-47e4-9586-99e53b9cfbb6@github.com> Message-ID: On Sun, 22 Oct 2023 17:26:52 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: > > add @SuppressWarnings (serial) > Vamsi, Could you please run benchmarking with derived classes from jdk and my version? https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_a01.java https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_a02.java https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_r01.java II hope i allows us to detect the root of such behaviour. > > I see you used not the latest ArraysSort, I pointed to https://github.com/iaroslavski/sorting/blob/master/radixsort/ArraysSort.java > > It is not critical, but it will be better to be in the same environment, see increased warmup, specified parameters for run and updated data sets @WarmUp(iterations = 2, time = 3, timeUnit = TimeUnit.SECONDS) @measurement(iterations = 4, time = 3, timeUnit = TimeUnit.SECONDS) @fork(value=1, jvmArgsAppend={"-XX:CompileThreshold=1", "-XX:-TieredCompilation"}) > Hello Vladimir (@iaroslavski), Please see the performance data below using the updated ArraysSort.java using the settings you suggested. Thank you for your understanding and patience! Thanks, Vamsi Benchmark (us/op) | Builder | (size) | Stock JDK (+ AVX512 sort) | DPQS_a01 (+ AVX512 sort) | Speedup -- | -- | -- | -- | -- | -- ArraysSort.Int.testSort | RANDOM | 600 | 2.256 | 2.069 | 1.09 ArraysSort.Int.testSort | RANDOM | 9000 | 41.457 | 42.359 | 0.98 ArraysSort.Int.testSort | RANDOM | 20000 | 98.448 | 99.709 | 0.99 ArraysSort.Int.testSort | RANDOM | 400000 | 2820.939 | 2867.054 | 0.98 ArraysSort.Int.testSort | RANDOM | 3000000 | 23426.411 | 23811.912 | 0.98 ArraysSort.Int.testSort | REPEATED | 600 | 1.032 | 1.309 | 0.79 ArraysSort.Int.testSort | REPEATED | 9000 | 5.114 | 5.026 | 1.02 ArraysSort.Int.testSort | REPEATED | 20000 | 10.3 | 12.02 | 0.86 ArraysSort.Int.testSort | REPEATED | 400000 | 210.742 | 234.39 | 0.90 ArraysSort.Int.testSort | REPEATED | 3000000 | 1948.589 | 1972.167 | 0.99 ArraysSort.Int.testSort | STAGGER | 600 | 2.125 | 2.077 | 1.02 ArraysSort.Int.testSort | STAGGER | 9000 | 29.86 | 28.353 | 1.05 ArraysSort.Int.testSort | STAGGER | 20000 | 67.096 | 80.237 | 0.84 ArraysSort.Int.testSort | STAGGER | 400000 | 1247.53 | 1241.979 | 1.00 ArraysSort.Int.testSort | STAGGER | 3000000 | 9435.404 | 9720.086 | 0.97 ArraysSort.Int.testSort | SHUFFLE | 600 | 2.701 | 2.653 | 1.02 ArraysSort.Int.testSort | SHUFFLE | 9000 | 38.976 | 40.214 | 0.97 ArraysSort.Int.testSort | SHUFFLE | 20000 | 96.399 | 94.587 | 1.02 ArraysSort.Int.testSort | SHUFFLE | 400000 | 2566.338 | 2571.189 | 1.00 ArraysSort.Int.testSort | SHUFFLE | 3000000 | 20835.935 | 21026.27 | 0.99 Benchmark (us/op) | Builder | (size) | Stock JDK (+ AVX512 sort) | DPQS_a02 (+ AVX512 sort) | Speedup -- | -- | -- | -- | -- | -- ArraysSort.Int.testSort | RANDOM | 600 | 2.256 | 2.248 | 1.00 ArraysSort.Int.testSort | RANDOM | 9000 | 41.457 | 41.284 | 1.00 ArraysSort.Int.testSort | RANDOM | 20000 | 98.448 | 97.855 | 1.01 ArraysSort.Int.testSort | RANDOM | 400000 | 2820.939 | 2814.225 | 1.00 ArraysSort.Int.testSort | RANDOM | 3000000 | 23426.411 | 23227.972 | 1.01 ArraysSort.Int.testSort | REPEATED | 600 | 1.032 | 1.063 | 0.97 ArraysSort.Int.testSort | REPEATED | 9000 | 5.114 | 5.094 | 1.00 ArraysSort.Int.testSort | REPEATED | 20000 | 10.3 | 10.409 | 0.99 ArraysSort.Int.testSort | REPEATED | 400000 | 210.742 | 215.049 | 0.98 ArraysSort.Int.testSort | REPEATED | 3000000 | 1948.589 | 1921.44 | 1.01 ArraysSort.Int.testSort | STAGGER | 600 | 2.125 | 1.857 | 1.14 ArraysSort.Int.testSort | STAGGER | 9000 | 29.86 | 29.712 | 1.00 ArraysSort.Int.testSort | STAGGER | 20000 | 67.096 | 66.779 | 1.00 ArraysSort.Int.testSort | STAGGER | 400000 | 1247.53 | 1227.183 | 1.02 ArraysSort.Int.testSort | STAGGER | 3000000 | 9435.404 | 9457.907 | 1.00 ArraysSort.Int.testSort | SHUFFLE | 600 | 2.701 | 2.676 | 1.01 ArraysSort.Int.testSort | SHUFFLE | 9000 | 38.976 | 39.283 | 0.99 ArraysSort.Int.testSort | SHUFFLE | 20000 | 96.399 | 94.128 | 1.02 ArraysSort.Int.testSort | SHUFFLE | 400000 | 2566.338 | 2551.235 | 1.01 ArraysSort.Int.testSort | SHUFFLE | 3000000 | 20835.935 | 20628.565 | 1.01 Benchmark (us/op) | Builder | (size) | Stock JDK (+ AVX512 sort) | DPQS_r01 (+ AVX512 sort) | Speedup -- | -- | -- | -- | -- | -- ArraysSort.Int.testSort | RANDOM | 600 | 2.256 | 1.713 | 1.32 ArraysSort.Int.testSort | RANDOM | 9000 | 41.457 | 38.316 | 1.08 ArraysSort.Int.testSort | RANDOM | 20000 | 98.448 | 86.376 | 1.14 ArraysSort.Int.testSort | RANDOM | 400000 | 2820.939 | 2792.333 | 1.01 ArraysSort.Int.testSort | RANDOM | 3000000 | 23426.411 | 23711.885 | 0.99 ArraysSort.Int.testSort | REPEATED | 600 | 1.032 | 0.859 | 1.20 ArraysSort.Int.testSort | REPEATED | 9000 | 5.114 | 5.014 | 1.02 ArraysSort.Int.testSort | REPEATED | 20000 | 10.3 | 9.532 | 1.08 ArraysSort.Int.testSort | REPEATED | 400000 | 210.742 | 235.281 | 0.90 ArraysSort.Int.testSort | REPEATED | 3000000 | 1948.589 | 1955.258 | 1.00 ArraysSort.Int.testSort | STAGGER | 600 | 2.125 | 2.157 | 0.99 ArraysSort.Int.testSort | STAGGER | 9000 | 29.86 | 29.931 | 1.00 ArraysSort.Int.testSort | STAGGER | 20000 | 67.096 | 66.543 | 1.01 ArraysSort.Int.testSort | STAGGER | 400000 | 1247.53 | 1224.999 | 1.02 ArraysSort.Int.testSort | STAGGER | 3000000 | 9435.404 | 9495.189 | 0.99 ArraysSort.Int.testSort | SHUFFLE | 600 | 2.701 | 1.64 | 1.65 ArraysSort.Int.testSort | SHUFFLE | 9000 | 38.976 | 34.201 | 1.14 ArraysSort.Int.testSort | SHUFFLE | 20000 | 96.399 | 79.616 | 1.21 ArraysSort.Int.testSort | SHUFFLE | 400000 | 2566.338 | 2436.271 | 1.05 ArraysSort.Int.testSort | SHUFFLE | 3000000 | 20835.935 | 20071.12 | 1.04 ------------- PR Comment: https://git.openjdk.org/jdk/pull/13568#issuecomment-1828868104 PR Comment: https://git.openjdk.org/jdk/pull/13568#issuecomment-1828869075 PR Comment: https://git.openjdk.org/jdk/pull/13568#issuecomment-1828869933 PR Comment: https://git.openjdk.org/jdk/pull/13568#issuecomment-1828870641 From bpb at openjdk.org Tue Nov 28 01:11:14 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 28 Nov 2023 01:11:14 GMT Subject: RFR: 8320759: Creation of random BigIntegers can be made faster [v2] In-Reply-To: <9linin03BjEwpwt9j1cCabK_AhfWjp7M9uxTY7MxAlQ=.6467a7a8-87d0-48dc-a05f-c6f3339f136e@github.com> References: <4WB_FtpmH5qbqDU3zMoTCkGFRVaMmBSrRRjSVA33TKE=.698ad745-b5d7-4471-8c29-019dcaea988b@github.com> <9linin03BjEwpwt9j1cCabK_AhfWjp7M9uxTY7MxAlQ=.6467a7a8-87d0-48dc-a05f-c6f3339f136e@github.com> Message-ID: On Mon, 27 Nov 2023 22:52:36 GMT, fabioromano1 wrote: >> src/java.base/share/classes/java/math/BigInteger.java line 754: >> >>> 752: // numInts >= 1, since numBits > 0 >>> 753: >>> 754: int firstInt = rnd.nextInt() & (-1 >>> -numBits); // Mask out any excess bits >> >> Instead of `numBits`, shouldn't this use something like `excessBits` similar to line 760 in the old version? > > It's equivalent. If you watch the implementations of other methods in the class where a mask out is made, this method is often used. Indeed it looks as if that is correct. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16817#discussion_r1406956445 From xgong at openjdk.org Tue Nov 28 01:40:08 2023 From: xgong at openjdk.org (Xiaohong Gong) Date: Tue, 28 Nov 2023 01:40:08 GMT Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations with SLEEF [v4] In-Reply-To: References: <3dscjw75an6_n3ko_2LjHdpdj08xsyjhfpStuZrS5-M=.f43592fe-036e-47b5-babc-67f126885839@github.com> <17T7DXMTf1rFVeQY_FWJx0DETVYlBWceJO4lltWZyw0=.847b02a3-ef40-464a-80b7-d62bd9dbc2b5@github.com> <3g_PCAyCoS9IB9PIulE0sXzT8KqvxeNbzdgfbElT72E=.60fa3790-4894-463a-b192-1b75ff42d24b@github.com> <3mhEtXP50-Lkn4iKkMGyCY4RJEcFbaTXyCUN3eoOH7M=.54337aac-d295-4fd8-884b-8dba5c4a68f6@github.com> Message-ID: On Mon, 27 Nov 2023 16:43:09 GMT, Andrew Haley wrote: >> Apparently the situation is this: If your build machine happens to have SVE, then you will get SVE support in the vmath library. The SVE support will be used during runtime if the machine you run on has SVE support. >> >> If your build host happens to to not have SVE, then the vmath library will be built without SVE support, and no matter if your runtime machine has SVE or not, it will not provide SVE support in the vmath library. >> >> Now, if your CI farm has an arbitrarily selection of aarch64 machines with and without SVE, then you have no idea what you are going to get in your build. >> >> We have been very careful in staying clear of this kind of "random" build system behavior. The system you build on should not affect the output -- at least, not without a chance to override the default value. >> >> In fact, I am not even sure why it seems to the PR author to be a good idea to let the default be dependent on the build machine at all. My personal opinion is that it would be better to select either "SVE enabled" or "SVE disabled" as the default, and then let the user override this on the configure command line, if they target a platform with different SVE availability. > >> In fact, I am not even sure why it seems to the PR author to be a good idea to let the default be dependent on the build machine at all. My personal opinion is that it would be better to select either "SVE enabled" or "SVE disabled" as the default, and then let the user override this on the configure command line, if they target a platform with different SVE availability. > > SVE support should be enabled regardless of the build machine. The same binary must run on both SVE and non-SVE machines, using SVE if it is advantageous. I suppose some ancient C++ compilers without SVE support still exist, but I see no very good reason to support them building JDK 22+. > > Making a configure option to disable SVE support for vector math is a mistake, but IMO mostly harmless because no-one will ever turn it off. > That's fine, but we must make sure that SVE is not used by the compiler in any other places. If you've already built on non-SVE and tested the result on both SVE and non-SVE, I'm happy. Agree. Since it contains both NEON and SVE functions in libvmath.so, we have to disable SVE feature when building those NEON functions. We want to separate NEON/SVE functions in two files, build them with different cflags (i.e. only build SVE sources with `-march=armv8-a+sve`), and then link to the single `libvmath.so`. Do we have such similar examples or functions in current jdk make system? I'm still struggling on finding out an effective way for it. > SVE support should be enabled regardless of the build machine. The same binary must run on both SVE and non-SVE machines, using SVE if it is advantageous. I suppose some ancient C++ compilers without SVE support still exist, but I see no very good reason to support them building JDK 22+. > > Making a configure option to disable SVE support for vector math is a mistake, but IMO mostly harmless because no-one will ever turn it off. Yes, SVE feature is also always enabled in jdk hotspot on SVE machines. If we add the option to give people disable SVE, it's weird that we disabling the SVE just in libvmath.so, and enabling it in hotspot. Besides, we choose the NEON stubs for smaller than 128-bit vector operations no matter whether the runtime machine supports SVE or not. So performance may not be an issue. Hence, I don't think people have reason disabling SVE features. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16234#discussion_r1406971807 From sspitsyn at openjdk.org Tue Nov 28 01:57:09 2023 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 28 Nov 2023 01:57:09 GMT Subject: RFR: 8320532: Remove Thread/ThreadGroup suspend/resume In-Reply-To: References: Message-ID: On Thu, 23 Nov 2023 09:18:44 GMT, Alan Bateman wrote: > The deadlock prone Thread/ThreadGroup suspend/resume were deprecated since JDK 1.2, deprecated for removal in Java 14, and re-specified/degraded to throw UnsupportedOperationException unconditionally in Java 19/20. Early in Java 23 seems a fine time to finally remove these methods. > > Corpus analysis of 176 million classes in 485k artifacts found no remaining usages of ThreadGroup.suspend/resume beyond the artifacts that include a copy of java.lang.ThreadGroup (!). It found 87 remaining uses of Thread.suspend and 86 remaining usages of Thread.resume, some of these are tests. > > Thread.suspend/resume have always linked to the "Java Thread Primitive Deprecation" page. This originally explained the reasons why suspend/resume were deprecated. When these methods were degraded to throw UOE we changed the text to explain why the ability to suspend or resume a thread was removed. Now we must change it again. One choice is to re-word to explain why the Java APIs were removed or why the Java APIs don't define a way to suspend/resume threads, the other choice (which I prefer) is to remove the text. > > The method description of java.lang.management.ThreadInfo.isSuspended is tweaked to link to JVMTI SuspendThread instead of Thread.suspend Marked as reviewed by sspitsyn (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/16789#pullrequestreview-1751737540 From almatvee at openjdk.org Tue Nov 28 02:30:16 2023 From: almatvee at openjdk.org (Alexander Matveev) Date: Tue, 28 Nov 2023 02:30:16 GMT Subject: RFR: 8320681: [macos] Test tools/jpackage/macosx/MacAppStoreJlinkOptionsTest.java timed out on macOS Message-ID: Looks like the test timed out due to slow/loaded host. Failure log similar to [JDK-8296489](https://bugs.openjdk.org/browse/JDK-8296489) and [JDK-8298735](https://bugs.openjdk.org/browse/JDK-8298735). Fixed by increasing test timeout. ------------- Commit messages: - 8320681: [macos] Test tools/jpackage/macosx/MacAppStoreJlinkOptionsTest.java timed out on macOS Changes: https://git.openjdk.org/jdk/pull/16838/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16838&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8320681 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/16838.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16838/head:pull/16838 PR: https://git.openjdk.org/jdk/pull/16838 From dholmes at openjdk.org Tue Nov 28 05:18:03 2023 From: dholmes at openjdk.org (David Holmes) Date: Tue, 28 Nov 2023 05:18:03 GMT Subject: RFR: 8319577: x86_64 AVX2 intrinsics for Arrays.sort methods (int, float arrays) [v2] In-Reply-To: References: Message-ID: On Mon, 27 Nov 2023 23:44:25 GMT, Sandhya Viswanathan wrote: >> Not listed here: https://oca.opensource.oracle.com/?ojr=contributors > > Yes, Vamsi is part of Intel Java team. He also has the author status (https://openjdk.org/census#sparasa). @sviswa7 I am asking about the copyright holder "Serge Sans Paille". ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16534#discussion_r1407189136 From dholmes at openjdk.org Tue Nov 28 06:36:05 2023 From: dholmes at openjdk.org (David Holmes) Date: Tue, 28 Nov 2023 06:36:05 GMT Subject: RFR: JDK-8319413: Start of release updates for JDK 23 In-Reply-To: References: Message-ID: On Fri, 3 Nov 2023 23:42:03 GMT, Joe Darcy wrote: > Time to start making preparations for JDK 23. Hotspot change is trivially fine, but too insignificant to hit the Approve button. Thanks ------------- PR Review: https://git.openjdk.org/jdk/pull/16505#pullrequestreview-1752152672 From joehw at openjdk.org Tue Nov 28 06:51:14 2023 From: joehw at openjdk.org (Joe Wang) Date: Tue, 28 Nov 2023 06:51:14 GMT Subject: Integrated: 8320602: Lock contention in SchemaDVFactory.getInstance() In-Reply-To: References: Message-ID: On Mon, 27 Nov 2023 17:24:35 GMT, Joe Wang wrote: > Applying an update from the upstream source, quote: "Removing synchronized from the getInstance() methods". As the reporter noted, this change was made 16 years ago. > > Tests: SQE & unit tests passed This pull request has now been integrated. Changeset: 0678253b Author: Joe Wang URL: https://git.openjdk.org/jdk/commit/0678253bffca91775d29d2942f48c806ab4d2cab Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod 8320602: Lock contention in SchemaDVFactory.getInstance() Reviewed-by: iris, lancea ------------- PR: https://git.openjdk.org/jdk/pull/16829 From prappo at openjdk.org Tue Nov 28 09:44:27 2023 From: prappo at openjdk.org (Pavel Rappo) Date: Tue, 28 Nov 2023 09:44:27 GMT Subject: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v35] In-Reply-To: References: Message-ID: On Fri, 24 Nov 2023 12:56:40 GMT, Jim Laskey wrote: >> Address changes from JEP 445 to JEP 463. >> >> - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. >> >> - Don't mark class on read. >> >> - Remove reflection and annotation processing related to unnamed classes. >> >> - Simplify main method search. > > Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: > > Requested changes Jim, consider merging this PR with master to catch up. This PR is almost 250 commits behind master. That is a month of work. Also, if you merge, we could use this PR as a [dependency](https://mail.openjdk.org/pipermail/jdk-dev/2021-March/005232.html) for other PRs. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16461#issuecomment-1829444791 From jpai at openjdk.org Tue Nov 28 10:03:06 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 28 Nov 2023 10:03:06 GMT Subject: RFR: 8320781: Fix whitespace in j.l.Double and j.u.z.ZipInputStream @snippets In-Reply-To: References: Message-ID: On Mon, 27 Nov 2023 16:17:14 GMT, Eirik Bjorsnos wrote: > Please review this trivial, formatting and documentation-only change which adds missing whitespace around a few `if` statements, `while` statements and assigments in `@snippet` code in `j.l.Double` and `j.u.z.ZipInputStream`. > > While there are many similar issues in the OpenJDK code base, these were the only instances found in `@snippet` code in the API of `java.base`, so it could be worthwhile fixing. > > While updating the snippet in `ZipInputStream`, I took the liberty to also add `lang = "java"` since this seems more commonly included around the code base. Looks good to me. Please add a "noreg-doc" label to the JDK-8320781 issue. ------------- Marked as reviewed by jpai (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16827#pullrequestreview-1752493644 From aph at openjdk.org Tue Nov 28 10:06:09 2023 From: aph at openjdk.org (Andrew Haley) Date: Tue, 28 Nov 2023 10:06:09 GMT Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations with SLEEF [v4] In-Reply-To: References: <3dscjw75an6_n3ko_2LjHdpdj08xsyjhfpStuZrS5-M=.f43592fe-036e-47b5-babc-67f126885839@github.com> <17T7DXMTf1rFVeQY_FWJx0DETVYlBWceJO4lltWZyw0=.847b02a3-ef40-464a-80b7-d62bd9dbc2b5@github.com> <3g_PCAyCoS9IB9PIulE0sXzT8KqvxeNbzdgfbElT72E=.60fa3790-4894-463a-b192-1b75ff42d24b@github.com> <3mhEtXP50-Lkn4iKkMGyCY4RJEcFbaTXyCUN3eoOH7M=.54337aac-d295-4fd8-884b-8dba5c4a68f6@github.com> Message-ID: <69BEw41MlNZ8k-6WG9JC5V-F-Z_WZVzouYVkNCxDNgw=.6f9e9219-538e-4e1b-ab0b-46ef6b932b79@github.com> On Tue, 28 Nov 2023 01:37:01 GMT, Xiaohong Gong wrote: >>> In fact, I am not even sure why it seems to the PR author to be a good idea to let the default be dependent on the build machine at all. My personal opinion is that it would be better to select either "SVE enabled" or "SVE disabled" as the default, and then let the user override this on the configure command line, if they target a platform with different SVE availability. >> >> SVE support should be enabled regardless of the build machine. The same binary must run on both SVE and non-SVE machines, using SVE if it is advantageous. I suppose some ancient C++ compilers without SVE support still exist, but I see no very good reason to support them building JDK 22+. >> >> Making a configure option to disable SVE support for vector math is a mistake, but IMO mostly harmless because no-one will ever turn it off. > >> That's fine, but we must make sure that SVE is not used by the compiler in any other places. If you've already built on non-SVE and tested the result on both SVE and non-SVE, I'm happy. > > Agree. > > Since it contains both NEON and SVE functions in libvmath.so, we have to disable SVE feature when building those NEON functions. We want to separate NEON/SVE functions in two files, build them with different cflags (i.e. only build SVE sources with `-march=armv8-a+sve`), and then link to the single `libvmath.so`. Do we have such similar examples or functions in current jdk make system? I'm still struggling on finding out an effective way for it. > >> SVE support should be enabled regardless of the build machine. The same binary must run on both SVE and non-SVE machines, using SVE if it is advantageous. I suppose some ancient C++ compilers without SVE support still exist, but I see no very good reason to support them building JDK 22+. >> >> Making a configure option to disable SVE support for vector math is a mistake, but IMO mostly harmless because no-one will ever turn it off. > > Yes, SVE feature is also always enabled in jdk hotspot on SVE machines. If we add the option to give people disable SVE, it's weird that we disabling the SVE just in libvmath.so, and enabling it in hotspot. Besides, we choose the NEON stubs for smaller than 128-bit vector operations no matter whether the runtime machine supports SVE or not. So performance may not be an issue. Hence, I don't think people have reason disabling SVE features. It makes no sense to configure any of this at build time. Postpone all of the decisions to runtime. Don't touch the make system.Instead, try to open the library at runtime with `os::dll_open()`, after (or inside) `VM_Version::initialize()`. If you're not running on an SVE system, none of the SVE routines will be called, so it doesn't matter, right? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16234#discussion_r1407511713 From duke at openjdk.org Tue Nov 28 10:13:05 2023 From: duke at openjdk.org (Eirik Bjorsnos) Date: Tue, 28 Nov 2023 10:13:05 GMT Subject: RFR: 8320781: Fix whitespace in j.l.Double and j.u.z.ZipInputStream @snippets In-Reply-To: References: Message-ID: <0AU8RRVbpy0_kwq2okrfkKUa6cW9RgTNi614XnFFKjM=.b58dfb1b-35e4-43ef-86ed-2e0f476820b1@github.com> On Tue, 28 Nov 2023 10:00:14 GMT, Jaikiran Pai wrote: > Looks good to me. Please add a "noreg-doc" label to the JDK-8320781 issue. Thanks, label added! I'll need a sponsor for the integration of this change. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16827#issuecomment-1829499864 From duke at openjdk.org Tue Nov 28 10:23:28 2023 From: duke at openjdk.org (Eirik Bjorsnos) Date: Tue, 28 Nov 2023 10:23:28 GMT Subject: Integrated: 8320781: Fix whitespace in j.l.Double and j.u.z.ZipInputStream @snippets In-Reply-To: References: Message-ID: On Mon, 27 Nov 2023 16:17:14 GMT, Eirik Bjorsnos wrote: > Please review this trivial, formatting and documentation-only change which adds missing whitespace around a few `if` statements, `while` statements and assigments in `@snippet` code in `j.l.Double` and `j.u.z.ZipInputStream`. > > While there are many similar issues in the OpenJDK code base, these were the only instances found in `@snippet` code in the API of `java.base`, so it could be worthwhile fixing. > > While updating the snippet in `ZipInputStream`, I took the liberty to also add `lang = "java"` since this seems more commonly included around the code base. This pull request has now been integrated. Changeset: 99f870c4 Author: Eirik Bjorsnos Committer: Jaikiran Pai URL: https://git.openjdk.org/jdk/commit/99f870c43fea4e31a63240733ab9a471469f282b Stats: 5 lines in 2 files changed: 0 ins; 0 del; 5 mod 8320781: Fix whitespace in j.l.Double and j.u.z.ZipInputStream @snippets Reviewed-by: lancea, bpb, darcy, jpai ------------- PR: https://git.openjdk.org/jdk/pull/16827 From pminborg at openjdk.org Tue Nov 28 10:24:39 2023 From: pminborg at openjdk.org (Per Minborg) Date: Tue, 28 Nov 2023 10:24:39 GMT Subject: RFR: 8308753: Class-File API transition to Preview [v32] In-Reply-To: <9-Fm-UXpDT0FLAxTw9xve00qurpqv01xw1uJwG0IXKQ=.06a9e0da-7a8c-462b-9b7a-b1be1b9bff5f@github.com> References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com> <9-Fm-UXpDT0FLAxTw9xve00qurpqv01xw1uJwG0IXKQ=.06a9e0da-7a8c-462b-9b7a-b1be1b9bff5f@github.com> Message-ID: <8aNWssZUAmka3xQNMbRvY8P8ruJ0-7Eo5NTLeQGPko4=.ac8f1a19-8f0a-42fc-85cf-2fb540d194a7@github.com> On Mon, 27 Nov 2023 10:01:50 GMT, Adam Sotona wrote: >> Classfile API is an internal library under package `jdk.internal.classfile`?in JDK 21. >> This pull request turns the Classfile API into a preview feature and moves it into `java.lang.classfile`. >> It repackages all uses across JDK and tests and adds lots of missing Javadoc. >> >> This PR goes in sync with?[JDK-8308754](https://bugs.openjdk.org/browse/JDK-8308754): Class-File API (Preview) (CSR) >> and?[JDK-8280389](https://bugs.openjdk.org/browse/JDK-8280389): Class-File API (Preview) (JEP). >> >> Online javadoc is available at:? >> https://cr.openjdk.org/~asotona/JDK-8308753-preview/api/java.base/java/lang/classfile/package-summary.html >> >> In addition to the primary transition to preview, this pull request also includes: >> - All?Classfile*?classes ranamed to?ClassFile*?(based on JEP discussion). >> - A new preview feature, `CLASSFILE_API`, has been added. >> - Buildsystem tool required a little patch to support annotated modules. >> - All JDK modules using the Classfile API are newly participating in the preview. >> - All tests that use the Classfile API now have preview enabled. >> - A few Javac tests not allowing preview have been partially reverted; their conversion can be re-applied when the Classfile API leaves preview mode. >> >> Despite the number of affected files, this pull request is relatively straight-forward. The preview version of the Classfile API is based on the internal version of the library from the JDK master branch, and there are no API features added. >> >> Please review this pull request to help the Classfile API turn into a preview. >> >> Any comments are welcome. >> >> Thanks, >> Adam > > Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: > > fixed SwitchBootstrapTest src/java.base/share/classes/java/lang/classfile/ClassFile.java line 1404: > (failed to retrieve contents of file, check the PR for context) Is there a more scalable way to express the major class version? The current approach means we have to add two fields per year. Maybe a lookup function would be better? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15706#discussion_r1407534887 From mcimadamore at openjdk.org Tue Nov 28 10:32:08 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Tue, 28 Nov 2023 10:32:08 GMT Subject: RFR: 8320440: Implementation of Structured Concurrency (Second Preview) In-Reply-To: <4t6NzmCd-0w-y7iT51fEttO7gEArgRuCeEl4yeNIzd0=.cd7bbed3-1117-4fc1-9241-255e6e10e2f1@github.com> References: <4t6NzmCd-0w-y7iT51fEttO7gEArgRuCeEl4yeNIzd0=.cd7bbed3-1117-4fc1-9241-255e6e10e2f1@github.com> Message-ID: On Mon, 20 Nov 2023 19:48:20 GMT, Alan Bateman wrote: > This API is sitting out JDK 22, meaning no API/implementation changes in this PR. We expect this API to do a third preview in JDK 23 with some API changes. > > So for now, we just need to bump JEP number/title that shows up in the preview section of the javadoc. Marked as reviewed by mcimadamore (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/16748#pullrequestreview-1752551278 From duke at openjdk.org Tue Nov 28 10:43:11 2023 From: duke at openjdk.org (Eirik Bjorsnos) Date: Tue, 28 Nov 2023 10:43:11 GMT Subject: RFR: 8319668: Fixup of jar filename typo in BadFactoryTest.sh [v2] In-Reply-To: References: <6mykWP1swWPnVEyhG-sEgEHc4kIMoCdi8_jfXYxDj78=.b4d2c29a-47e6-43c8-82e7-54091b77b3c5@github.com> <6o2bpFznW1fNEdjAcVI92nkENfhm1t8Vn2o1gtEJwl8=.b7fced34-9827-4c42-a267-2cf182dd926e@github.com> Message-ID: <9Za2jNyI8oZ4fO4Og7bPoIHy4BDKubnEF-o8Hrf63-c=.d47af8f6-f204-4ff1-b9d3-af41bc961619@github.com> On Mon, 27 Nov 2023 16:45:12 GMT, Gaurav Chaudhari wrote: > You can go ahead and contribute the PR in that case. Thanks! You'll need a sponsor to integrate this PR, then I'll go ahead and follow up with #16830 ------------- PR Comment: https://git.openjdk.org/jdk/pull/16585#issuecomment-1829551620 From jpai at openjdk.org Tue Nov 28 11:35:12 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 28 Nov 2023 11:35:12 GMT Subject: RFR: 8319668: Fixup of jar filename typo in BadFactoryTest.sh [v2] In-Reply-To: <_AwsuoLG-Y_sYz25yJodFyY4KYggZdZzrW6fSdKRh8I=.bd4fb6d6-4a84-4228-8c90-507c38066844@github.com> References: <_AwsuoLG-Y_sYz25yJodFyY4KYggZdZzrW6fSdKRh8I=.bd4fb6d6-4a84-4228-8c90-507c38066844@github.com> Message-ID: On Wed, 22 Nov 2023 17:57:22 GMT, Gaurav Chaudhari wrote: >> The file test/jdk/javax/script/JDK_8196959/BadFactoryTest.sh contains a typo. When running without security manager, the test references 'badfactoty.jar' instead of 'badfactory.jar'. This change addresses this by correcting the jar name. > > Gaurav Chaudhari 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: > > 8319668: Fixup of jar filename typo in BadFactoryTest.sh Hello Gaurav, the change looks good to me. I ran the test/jdk/javax/script tests with this change in our CI and they continue to pass. I'll go ahead and sponsor this. ------------- Marked as reviewed by jpai (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16585#pullrequestreview-1752668321 From duke at openjdk.org Tue Nov 28 11:38:22 2023 From: duke at openjdk.org (Gaurav Chaudhari) Date: Tue, 28 Nov 2023 11:38:22 GMT Subject: Integrated: 8319668: Fixup of jar filename typo in BadFactoryTest.sh In-Reply-To: References: Message-ID: On Thu, 9 Nov 2023 16:49:41 GMT, Gaurav Chaudhari wrote: > The file test/jdk/javax/script/JDK_8196959/BadFactoryTest.sh contains a typo. When running without security manager, the test references 'badfactoty.jar' instead of 'badfactory.jar'. This change addresses this by correcting the jar name. This pull request has now been integrated. Changeset: 63ad868e Author: Gaurav Chaudhari Committer: Jaikiran Pai URL: https://git.openjdk.org/jdk/commit/63ad868e182279eeef8b5d27a25453873039d22f Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8319668: Fixup of jar filename typo in BadFactoryTest.sh Reviewed-by: alanb, jpai ------------- PR: https://git.openjdk.org/jdk/pull/16585 From duke at openjdk.org Tue Nov 28 11:49:05 2023 From: duke at openjdk.org (fabioromano1) Date: Tue, 28 Nov 2023 11:49:05 GMT Subject: RFR: 8320759: Creation of random BigIntegers can be made faster [v2] In-Reply-To: References: <4WB_FtpmH5qbqDU3zMoTCkGFRVaMmBSrRRjSVA33TKE=.698ad745-b5d7-4471-8c29-019dcaea988b@github.com> <9linin03BjEwpwt9j1cCabK_AhfWjp7M9uxTY7MxAlQ=.6467a7a8-87d0-48dc-a05f-c6f3339f136e@github.com> Message-ID: <0naowVOuVFb0JGS7eT_IvAxiKowPnJGm4BnDXYHiRJA=.0131f810-05b4-43f3-bd6b-8f4579daf3e5@github.com> On Tue, 28 Nov 2023 01:08:43 GMT, Brian Burkhalter wrote: >> It's equivalent. If you watch the implementations of other methods in the class where a mask out is made, this method is often used. > > Indeed it looks as if that is correct. As specified in https://docs.oracle.com/javase/specs/jls/se21/html/jls-15.html#jls-15.19: "If the promoted type of the left-hand operand is int, then only the five lowest-order bits of the right-hand operand are used as the shift distance. It is as if the right-hand operand were subjected to a bitwise logical AND operator & ([?15.22.1](https://docs.oracle.com/javase/specs/jls/se21/html/jls-15.html#jls-15.22.1)) with the mask value 0x1f (0b11111). The shift distance actually used is therefore always in the range 0 to 31, inclusive. The value of n >>> s is n right-shifted s bit positions with zero-extension, where If n is negative and the type of the left-hand operand is int, then the result is equal to that of the expression (n >> s) + (2 << ~s). The added term (2 << ~s) cancels out the propagated sign bit. Note that, because of the implicit masking of the right-hand operand of a shift operator, ~s as a shift distance is equivalent to 31-s when shifting an int value and to 63-s when shifting a long value." So, since ~s == -s - 1, we have that -s as a shift distance is equivalent to 32-s. Since (excessBits == 32 * numInts - numBits), then (excessBits == (32 - (numBits & 0x1f)) & 0x1f), because (x & 0x1f == x mod 32). Since the five lowest-order bits of 32 are 0, then the five lowest-order bits of (32 - (numBits & 0x1f)) are the same of (-numBits), and so (excessBits == (-numBits) & 0x1f), therefore (-1 >>> excessBits == -1 >>> -numBits). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16817#discussion_r1407635417 From duke at openjdk.org Tue Nov 28 12:18:23 2023 From: duke at openjdk.org (Ryan Wallace) Date: Tue, 28 Nov 2023 12:18:23 GMT Subject: RFR: 8318971: Better Error Handling for Jar Tool Processing of "@File" [v5] In-Reply-To: References: Message-ID: > Hi all, > > Please review this fix for jar tool not producing an archive if there is a missing file supplied. > The current behaviour will recognise missing files as an error but continue processing, > creating a temporary archive and then deleting it without moving to the current directory. > The fix is to return false when a missing file is supplied and exit immediately without continuing with any wasted processing. > > Thanks, > Ryan. Ryan Wallace has updated the pull request with a new target base 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 8318971 - 8318971: Better Error Handling for Jar Tool Processing of "@File" - Merge branch 'master' into 8318971 - Merge branch 'master' into 8318971 - 8318971: jar v17 should either exit on error immediately or create archive as jar v1.8 did - 8318971: jar v17 should either exit on error immediately or create archive as jar v1.8 did - Merge branch 'master' into 8318971 - 8318971: jar v17 should either exit on error immediately or create archive as jar v1.8 did - 8318971: jar v17 should either exit on error immediately or create archive as jar v1.8 did ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16423/files - new: https://git.openjdk.org/jdk/pull/16423/files/cee20934..374e7bff Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16423&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16423&range=03-04 Stats: 14693 lines in 623 files changed: 10624 ins; 2285 del; 1784 mod Patch: https://git.openjdk.org/jdk/pull/16423.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16423/head:pull/16423 PR: https://git.openjdk.org/jdk/pull/16423 From asotona at openjdk.org Tue Nov 28 13:06:31 2023 From: asotona at openjdk.org (Adam Sotona) Date: Tue, 28 Nov 2023 13:06:31 GMT Subject: RFR: 8308753: Class-File API transition to Preview [v32] In-Reply-To: <8aNWssZUAmka3xQNMbRvY8P8ruJ0-7Eo5NTLeQGPko4=.ac8f1a19-8f0a-42fc-85cf-2fb540d194a7@github.com> References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com> <9-Fm-UXpDT0FLAxTw9xve00qurpqv01xw1uJwG0IXKQ=.06a9e0da-7a8c-462b-9b7a-b1be1b9bff5f@github.com> <8aNWssZUAmka3xQNMbRvY8P8ruJ0-7Eo5NTLeQGPko4=.ac8f1a19-8f0a-42fc-85cf-2fb540d194a7@github.com> Message-ID: On Tue, 28 Nov 2023 10:21:25 GMT, Per Minborg wrote: >> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: >> >> fixed SwitchBootstrapTest > > src/java.base/share/classes/java/lang/classfile/ClassFile.java line 1404: > >> (failed to retrieve contents of file, check the PR for context) > Is there a more scalable way to express the major class version? The current approach means we have to add two fields per year. Maybe a lookup function would be better? This is explicit list of supported class file versions, so I don't see any other way. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15706#discussion_r1407726710 From jbhateja at openjdk.org Tue Nov 28 13:14:13 2023 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Tue, 28 Nov 2023 13:14:13 GMT Subject: RFR: 8319577: x86_64 AVX2 intrinsics for Arrays.sort methods (int, float arrays) [v2] In-Reply-To: <4XHLjTI5l8tGKCU8_iE53H7EY9-0EjR1gbbFWF57rfI=.8b7585bd-f829-4c3b-81ca-ddc8301c2179@github.com> References: <4XHLjTI5l8tGKCU8_iE53H7EY9-0EjR1gbbFWF57rfI=.8b7585bd-f829-4c3b-81ca-ddc8301c2179@github.com> Message-ID: On Sat, 18 Nov 2023 01:21:09 GMT, Srinivas Vamsi Parasa wrote: >> The goal is to develop faster sort routines for x86_64 CPUs by taking advantage of AVX2 instructions. This enhancement provides an order of magnitude speedup for Arrays.sort() using int, long, float and double arrays. >> >> For serial sort on random data, this PR shows upto ~7.5x improvement for 32-bit datatypes (int, float) on Intel TigerLake machine as shown in the performance data below. >> >> For parallel sort on random data, this PR shows upto ~3.4x for 32-bit datatypes (int, float) as shown below. >> >> **Note:** This PR also improves the performance of AVX512 sort by upto 35%. >> >> > xmlns:o="urn:schemas-microsoft-com:office:office" >> xmlns:x="urn:schemas-microsoft-com:office:excel" >> xmlns="http://www.w3.org/TR/REC-html40"> >> >> >> >> >> >> > href="file:///C:/Users/sparasa/AppData/Local/Temp/msohtmlclip1/01/clip.htm"> >> > href="file:///C:/Users/sparasa/AppData/Local/Temp/msohtmlclip1/01/clip_filelist.xml"> >> >> >> >> >> >> >> >> >> Benchmark (Serial Sort) | Size | Baseline (us/op) | AVX2 (us/op) | Speedup >> -- | -- | -- | -- | -- >> ArraysSort.intSort | 10 | 0.034 | 0.029 | 1.2 >> ArraysSort.intSort | 25 | 0.088 | 0.044 | 2.0 >> ArraysSort.intSort | 50 | 0.239 | 0.159 | 1.5 >> ArraysSort.intSort | 75 | 0.417 | 0.27 | 1.5 >> ArraysSort.intSort | 100 | 0.572 | 0.265 | 2.2 >> ArraysSort.intSort | 1000 | 10.098 | 4.282 | 2.4 >> ArraysSort.intSort | 10000 | 330.065 | 43.383 | 7.6 >> ArraysSort.intSort | 100000 | 4099.527 | 778.943 | 5.3 >> ArraysSort.intSort | 1000000 | 49150.16 | 9634.335 | 5.1 >> ArraysSort.floatSort | 10 | 0.045 | 0.043 | 1.0 >> ArraysSort.floatSort | 25 | 0.105 | 0.073 | 1.4 >> ArraysSort.floatSort | 50 | 0.278 | 0.216 | 1.3 >> ArraysSort.floatSort | 75 | 0.476 | 0.241 | 2.0 >> ArraysSort.floatSort | 100 | 0.583 | 0.313 | 1.9 >> ArraysSort.floatSort | 1000 | 10.182 | 4.329 | 2.4 >> ArraysSort.floatSort | 10000 | 323.136 | 57.175 | 5.7 >> ArraysSort.floatSort | 100000 | 4299.519 | 862.63 | 5.0 >> ArraysSort.floatSort | 1000000 | 50889.4 | 10972.19 | 4.6 >> >> >> >> >> >> > xmlns:o="urn:schemas-microsoft-com:office:office" >> xmlns:x="urn:schemas-microsoft-com:office:excel" >> xmlns="http://www.w3.org/TR/REC-html40"> >> >> >> >> > Srinivas Vamsi Parasa has updated the pull request with a new target base 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: > > - Disable AVX2 sort for 64-bit types > - Merge branch 'master' of https://git.openjdk.java.net/jdk into simdsort > - fix jcheck failures due to windows encoding > - fix carriage return and change insertion sort thresholds > - fix formatting and white spaces > - cleanup unused code > - fix insertion sort thresholds > - add insertion sort > - fix headers > - revert to xss-common-qsort > - ... and 1 more: https://git.openjdk.org/jdk/compare/a21d12ff...08307b6a src/hotspot/share/opto/library_call.cpp line 5391: > 5389: BasicType bt = elem_type->basic_type(); > 5390: // Disable the intrinsic for 64-bit types with AVX2 > 5391: if ((bt == T_LONG || bt == T_DOUBLE) && UseAVX == 2) { You can directly use convenience routine _is_double_word_type_ src/hotspot/share/opto/library_call.cpp line 5448: > 5446: BasicType bt = elem_type->basic_type(); > 5447: // Disable the intrinsic for 64-bit types with AVX2 > 5448: if ((bt == T_LONG || bt == T_DOUBLE) && UseAVX == 2) { Same as above. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16534#discussion_r1407677897 PR Review Comment: https://git.openjdk.org/jdk/pull/16534#discussion_r1407678192 From jbhateja at openjdk.org Tue Nov 28 13:14:15 2023 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Tue, 28 Nov 2023 13:14:15 GMT Subject: RFR: 8319577: x86_64 AVX2 intrinsics for Arrays.sort methods (int, float arrays) [v2] In-Reply-To: References: <4XHLjTI5l8tGKCU8_iE53H7EY9-0EjR1gbbFWF57rfI=.8b7585bd-f829-4c3b-81ca-ddc8301c2179@github.com> Message-ID: On Tue, 28 Nov 2023 12:23:12 GMT, Jatin Bhateja wrote: >> Srinivas Vamsi Parasa has updated the pull request with a new target base 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: >> >> - Disable AVX2 sort for 64-bit types >> - Merge branch 'master' of https://git.openjdk.java.net/jdk into simdsort >> - fix jcheck failures due to windows encoding >> - fix carriage return and change insertion sort thresholds >> - fix formatting and white spaces >> - cleanup unused code >> - fix insertion sort thresholds >> - add insertion sort >> - fix headers >> - revert to xss-common-qsort >> - ... and 1 more: https://git.openjdk.org/jdk/compare/a21d12ff...08307b6a > > src/hotspot/share/opto/library_call.cpp line 5448: > >> 5446: BasicType bt = elem_type->basic_type(); >> 5447: // Disable the intrinsic for 64-bit types with AVX2 >> 5448: if ((bt == T_LONG || bt == T_DOUBLE) && UseAVX == 2) { > > Same as above. You can move this entire check to platform specific matcher file (matcher_x86.hpp) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16534#discussion_r1407681744 From jlaskey at openjdk.org Tue Nov 28 13:52:53 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Tue, 28 Nov 2023 13:52:53 GMT Subject: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v36] In-Reply-To: References: Message-ID: <_SVulYe3fr1XL_2ZWqB-pXawtOT9jGGc-SoCojpxW0k=.3cff67d9-4c04-4019-9889-62e98e6276c9@github.com> > Address changes from JEP 445 to JEP 463. > > - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. > > - Don't mark class on read. > > - Remove reflection and annotation processing related to unnamed classes. > > - Simplify main method search. Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 40 commits: - Merge remote-tracking branch 'upstream/master' into 8315458 - Requested changes - Remove Test - Move findMainMethod to non-public access - Handle javadoc on top level elements properly - Update Class.java - Update test - Update findMainMethod as requested - Add nested class test - Move Implicitly Declared Classes to single directory - ... and 30 more: https://git.openjdk.org/jdk/compare/2fae07f5...daacc0ba ------------- Changes: https://git.openjdk.org/jdk/pull/16461/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16461&range=35 Stats: 1294 lines in 51 files changed: 439 ins; 723 del; 132 mod Patch: https://git.openjdk.org/jdk/pull/16461.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16461/head:pull/16461 PR: https://git.openjdk.org/jdk/pull/16461 From alanb at openjdk.org Tue Nov 28 13:57:02 2023 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 28 Nov 2023 13:57:02 GMT Subject: RFR: 8320858: Move jpackage tests to tier3 Message-ID: Update the jtreg test group configuration in the jdk test tree so that the jpackage tests run in tier3 rather than tier2. At this time, the jpackage tests run in jdk:tier2, more specifically jdk:tier2_part2 as part of the core_tools test group. The jpackage tests take a significant amount of time on some platforms (on macOS and Windows in particular). The changes here remove tools/jpackage from core_tools (it's not a core tool anyway) and adds the tests to tier3. In the future then maybe tier3 can be split up if needed. ------------- Commit messages: - Initial commit Changes: https://git.openjdk.org/jdk/pull/16841/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16841&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8320858 Stats: 11 lines in 1 file changed: 6 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/16841.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16841/head:pull/16841 PR: https://git.openjdk.org/jdk/pull/16841 From alanb at openjdk.org Tue Nov 28 13:57:30 2023 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 28 Nov 2023 13:57:30 GMT Subject: RFR: 8320786: Remove ThreadGroup.stop Message-ID: ThreadGroup.stop was deprecated since JDK 1.2, deprecated for removal in Java 18, and re-specified/degraded to throw UnsupportedOperationException unconditionally in Java 20. Early in Java 23 seems a fine time to finally remove this method. Corpus analysis of 176 million classes in 485k artifacts found residual usages in 14 artifacts, so not many. It would be nice if we could remove Thread.stop at the same time. Sadly there are still quite a few artifacts containing code (and in some cases tests) that reference this method. We will have to come back to this in some future release. ------------- Commit messages: - Initial commit Changes: https://git.openjdk.org/jdk/pull/16828/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16828&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8320786 Stats: 18 lines in 2 files changed: 0 ins; 17 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/16828.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16828/head:pull/16828 PR: https://git.openjdk.org/jdk/pull/16828 From alanb at openjdk.org Tue Nov 28 14:07:10 2023 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 28 Nov 2023 14:07:10 GMT Subject: RFR: JDK-8319662 ForkJoinPool trims worker threads too slowly [v5] In-Reply-To: References: Message-ID: On Mon, 27 Nov 2023 22:44:30 GMT, Doug Lea
    wrote: >> This update cascades timeouts to trim subsequent workers after the first keepAlive inactive period. > > Doug Lea has updated the pull request incrementally with one additional commit since the last revision: > > Revert 2 lines in method scan src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 3123: > 3121: throw unchecked; > 3122: } catch (Exception checked) { > 3123: throw new RuntimeException(checked); We should probably a test that uses invoke(adaptInterruptible(callable)) to check that a checked exception is wrapped, just in case it breaks with some future change. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16725#discussion_r1407815979 From duke at openjdk.org Tue Nov 28 14:11:17 2023 From: duke at openjdk.org (Eirik Bjorsnos) Date: Tue, 28 Nov 2023 14:11:17 GMT Subject: RFR: 8320712: Rewrite BadFactoryTest in pure Java Message-ID: Please review this PR which rewrites the BadFactoryTest to pure Java/JUnit. The test is currently implemented using a mix of shell script and a Java main method. Reviewers may notice the following changes: - The shell script file `BadFactoryTest.sh` has been retired and jtreg tags moved over to `BadFactoryTest.java` - The main method has been replaced with a JUnit `@Test` method - The service definition file used to be packaged into a jar file, now the source directory is instead directly added to the classpath using `@library /javax/script/JDK_8196959` - The `@summary` tag was updated since the existing summary was slightly confusing - To make jtreg happy, the SecurityManager-enabled invocation now runs with `-Djava.security.manager=allow` instead of just `-Djava.security.manager` - A sanity check was added to verify that `ScriptEngineManager` can actually find and load `BadFactory`. Such a check would have detected the issue which inspired this rewrite, see #16585. Verified by running: % make test TEST="test/jdk/javax/script/JDK_8196959" [..] TEST TOTAL PASS FAIL ERROR jtreg:test/jdk/javax/script/JDK_8196959 1 1 0 0 Note that the original issue JDK-8196959 is not available in JBS, so my understanding of what the original test does is based on code inspection. ------------- Commit messages: - Add the Java rewrite issue to the @bug list - Merge branch 'master' into badfactory-java-rewritte - Move jtreg tags from before to after imports - Merge branch 'master' into badfactory-java-rewritte - Update the @summary to describe the purpose of the test, not the BadFactory - Add comment describing the initialization of ScriptEngineManager - Implement BadFactoryTest in pure Java Changes: https://git.openjdk.org/jdk/pull/16830/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16830&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8320712 Stats: 87 lines in 2 files changed: 25 ins; 60 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/16830.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16830/head:pull/16830 PR: https://git.openjdk.org/jdk/pull/16830 From alanb at openjdk.org Tue Nov 28 14:18:36 2023 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 28 Nov 2023 14:18:36 GMT Subject: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v36] In-Reply-To: <_SVulYe3fr1XL_2ZWqB-pXawtOT9jGGc-SoCojpxW0k=.3cff67d9-4c04-4019-9889-62e98e6276c9@github.com> References: <_SVulYe3fr1XL_2ZWqB-pXawtOT9jGGc-SoCojpxW0k=.3cff67d9-4c04-4019-9889-62e98e6276c9@github.com> Message-ID: <2FFWAcDn5vw9HOG1T-TVKU1N3wE1_hn_GCos6UUfjx8=.cab3fb18-4550-4190-8b65-78592e0d298e@github.com> On Tue, 28 Nov 2023 13:52:53 GMT, Jim Laskey wrote: >> Address changes from JEP 445 to JEP 463. >> >> - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. >> >> - Don't mark class on read. >> >> - Remove reflection and annotation processing related to unnamed classes. >> >> - Simplify main method search. > > Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 40 commits: > > - Merge remote-tracking branch 'upstream/master' into 8315458 > - Requested changes > - Remove Test > - Move findMainMethod to non-public access > - Handle javadoc on top level elements properly > - Update Class.java > - Update test > - Update findMainMethod as requested > - Add nested class test > - Move Implicitly Declared Classes to single directory > - ... and 30 more: https://git.openjdk.org/jdk/compare/2fae07f5...daacc0ba src/java.base/share/classes/java/lang/Class.java line 2896: > 2894: * @param parameterTypes the parameter array > 2895: * @return the list of {@code Method} objects for the public methods of > 2896: * this class matching the specified name and parameters The return description seems to be copied from getDeclaredPublicMethods, I think you can drop it as the method description is clear. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16461#discussion_r1407832086 From jlaskey at openjdk.org Tue Nov 28 14:35:08 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Tue, 28 Nov 2023 14:35:08 GMT Subject: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v36] In-Reply-To: <2FFWAcDn5vw9HOG1T-TVKU1N3wE1_hn_GCos6UUfjx8=.cab3fb18-4550-4190-8b65-78592e0d298e@github.com> References: <_SVulYe3fr1XL_2ZWqB-pXawtOT9jGGc-SoCojpxW0k=.3cff67d9-4c04-4019-9889-62e98e6276c9@github.com> <2FFWAcDn5vw9HOG1T-TVKU1N3wE1_hn_GCos6UUfjx8=.cab3fb18-4550-4190-8b65-78592e0d298e@github.com> Message-ID: On Tue, 28 Nov 2023 14:15:48 GMT, Alan Bateman wrote: >> Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 40 commits: >> >> - Merge remote-tracking branch 'upstream/master' into 8315458 >> - Requested changes >> - Remove Test >> - Move findMainMethod to non-public access >> - Handle javadoc on top level elements properly >> - Update Class.java >> - Update test >> - Update findMainMethod as requested >> - Add nested class test >> - Move Implicitly Declared Classes to single directory >> - ... and 30 more: https://git.openjdk.org/jdk/compare/2fae07f5...daacc0ba > > src/java.base/share/classes/java/lang/Class.java line 2896: > >> 2894: * @param parameterTypes the parameter array >> 2895: * @return the list of {@code Method} objects for the public methods of >> 2896: * this class matching the specified name and parameters > > The return description seems to be copied from getDeclaredPublicMethods, I think you can drop it as the method description is clear. * @return the {@code Method} object for the method found from this class matching * the specified name and parameters, or null if not found ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16461#discussion_r1407856392 From jlaskey at openjdk.org Tue Nov 28 14:47:39 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Tue, 28 Nov 2023 14:47:39 GMT Subject: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v37] In-Reply-To: References: Message-ID: > Address changes from JEP 445 to JEP 463. > > - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. > > - Don't mark class on read. > > - Remove reflection and annotation processing related to unnamed classes. > > - Simplify main method search. Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: Update Class.java comment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16461/files - new: https://git.openjdk.org/jdk/pull/16461/files/daacc0ba..f313cc96 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16461&range=36 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16461&range=35-36 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/16461.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16461/head:pull/16461 PR: https://git.openjdk.org/jdk/pull/16461 From alanb at openjdk.org Tue Nov 28 14:47:47 2023 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 28 Nov 2023 14:47:47 GMT Subject: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v36] In-Reply-To: <_SVulYe3fr1XL_2ZWqB-pXawtOT9jGGc-SoCojpxW0k=.3cff67d9-4c04-4019-9889-62e98e6276c9@github.com> References: <_SVulYe3fr1XL_2ZWqB-pXawtOT9jGGc-SoCojpxW0k=.3cff67d9-4c04-4019-9889-62e98e6276c9@github.com> Message-ID: On Tue, 28 Nov 2023 13:52:53 GMT, Jim Laskey wrote: >> Address changes from JEP 445 to JEP 463. >> >> - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. >> >> - Don't mark class on read. >> >> - Remove reflection and annotation processing related to unnamed classes. >> >> - Simplify main method search. > > Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 40 commits: > > - Merge remote-tracking branch 'upstream/master' into 8315458 > - Requested changes > - Remove Test > - Move findMainMethod to non-public access > - Handle javadoc on top level elements properly > - Update Class.java > - Update test > - Update findMainMethod as requested > - Add nested class test > - Move Implicitly Declared Classes to single directory > - ... and 30 more: https://git.openjdk.org/jdk/compare/2fae07f5...daacc0ba test/jdk/tools/launcher/modules/basic/LauncherErrors.java line 97: > 95: .shouldContain("Error: Unable to load main class " + MAIN_CLASS + " in module " + TEST_MODULE) > 96: .shouldContain("java.security.AccessControlException") > 97: .shouldNotHaveExitValue(0); The updates to the launcher tests look okay but I'm wondering if the "Caused by:" is the output now? I get it that the "Unable to ..." message has changed but has the format of the cause changed too? I assume you'll fix up the copyright date on Arrrrgs and LauncherErrors before integrating. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16461#discussion_r1407880682 From rgiulietti at openjdk.org Tue Nov 28 14:58:34 2023 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Tue, 28 Nov 2023 14:58:34 GMT Subject: RFR: 8311906: Improve robustness of String constructors with mutable array inputs [v13] In-Reply-To: References: <6SKlGLh5MmxoEx07wHCCUc8KWbbhcspLJmcc1uxQ_FI=.ca33bfb4-fa5c-45f0-b49f-ee6c5c6b68b4@github.com> Message-ID: On Mon, 27 Nov 2023 19:09:40 GMT, Roger Riggs wrote: >> Strings, after construction, are immutable but may be constructed from mutable arrays of bytes, characters, or integers. >> The string constructors should guard against the effects of mutating the arrays during construction that might invalidate internal invariants for the correct behavior of operations on the resulting strings. In particular, a number of operations have optimizations for operations on pairs of latin1 strings and pairs of non-latin1 strings, while operations between latin1 and non-latin1 strings use a more general implementation. >> >> The changes include: >> >> - Adding a warning to each constructor with an array as an argument to indicate that the results are indeterminate >> if the input array is modified before the constructor returns. >> The resulting string may contain any combination of characters sampled from the input array. >> >> - Ensure that strings that are represented as non-latin1 contain at least one non-latin1 character. >> For latin1 inputs, whether the arrays contain ASCII, ISO-8859-1, UTF8, or another encoding decoded to latin1 the scanning and compression is unchanged. >> If a non-latin1 character is found, the string is represented as non-latin1 with the added verification that a non-latin1 character is present at the same index. >> If that character is found to be latin1, then the input array has been modified and the result of the scan may be incorrect. >> Though a ConcurrentModificationException could be thrown, the risk to an existing application of an unexpected exception should be avoided. >> Instead, the non-latin1 copy of the input is re-scanned and compressed; that scan determines whether the latin1 or the non-latin1 representation is returned. >> >> - The methods that scan for non-latin1 characters and their intrinsic implementations are updated to return the index of the non-latin1 character. >> >> - String construction from StringBuilder and CharSequence must also be guarded as their contents may be modified during construction. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Use byte off branches in char_array_compress > Verified by manual tests with "-XX:AVX3Threshold=0" > And test in the PR test/hotspot/jtreg/compiler/intrinsics/string/TestStringConstructionIntrinsics.java The Java code, both src and test, looks good to me. ------------- Marked as reviewed by rgiulietti (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16425#pullrequestreview-1753111255 From pchilanomate at openjdk.org Tue Nov 28 15:01:37 2023 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Tue, 28 Nov 2023 15:01:37 GMT Subject: RFR: 8310644: Make panama memory segment close use async handshakes [v5] In-Reply-To: References: Message-ID: On Fri, 24 Nov 2023 18:30:17 GMT, Erik ?sterlund wrote: >> The current logic for closing memory in panama today is susceptible to live lock if we have a closing thread that wants to close the memory in a loop that keeps failing, and a bunch of accessing threads that want to perform accesses as long as the memory is alive. They can both create impediments for the other. >> >> By using asynchronous handshakes to install an exception onto threads that are in @Scoped memory accesses, we can have close always succeed, and the accessing threads bail out. The idea is that we perform a synchronous handshake first to find threads that are in scoped methods. They might however be in the middle of throwing an exception or something wild like there, where an exception can't be delivered. We install an async handshake that will roll us forward to the first place where we can indeed install exceptions, then we reevaluate if we still need to do that, or if we have unwound out from the scoped method. If we are still inside of it, we ensure an exception is installed so we don't continue executing bytecodes that might access the memory that we have freed. >> >> Tested tier 1-5 as well as running test/jdk/java/foreign/TestHandshake.java hundreds of times, which tests this API pretty well. > > Erik ?sterlund has updated the pull request incrementally with two additional commits since the last revision: > > - Merge pull request #3 from JornVernee/PR_async_close+NoToNativeTrans > > - don't transition to native state on Unsafe_CopySwapMemory0 I don't know about the Panama details but the asynchronous handshake usage looks good. ------------- Marked as reviewed by pchilanomate (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16792#pullrequestreview-1753119472 From jlaskey at openjdk.org Tue Nov 28 15:05:42 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Tue, 28 Nov 2023 15:05:42 GMT Subject: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v38] In-Reply-To: References: Message-ID: > Address changes from JEP 445 to JEP 463. > > - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. > > - Don't mark class on read. > > - Remove reflection and annotation processing related to unnamed classes. > > - Simplify main method search. Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: Create TestImplicitClass.java ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16461/files - new: https://git.openjdk.org/jdk/pull/16461/files/f313cc96..c4fc2f9c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16461&range=37 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16461&range=36-37 Stats: 217 lines in 1 file changed: 217 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/16461.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16461/head:pull/16461 PR: https://git.openjdk.org/jdk/pull/16461 From ihse at openjdk.org Tue Nov 28 15:05:57 2023 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 28 Nov 2023 15:05:57 GMT Subject: RFR: 8320786: Remove ThreadGroup.stop In-Reply-To: References: Message-ID: On Mon, 27 Nov 2023 16:58:29 GMT, Alan Bateman wrote: > It would be nice if we could remove Thread.stop at the same time. Sadly there are still quite a few artifacts containing code (and in some cases tests) that reference this method. We will have to come back to this in some future release. But we've started eating the elephant. I vote for free champagne to all JDK developers every time we can actually remove stuff that have been deprecated for removal! ------------- PR Comment: https://git.openjdk.org/jdk/pull/16828#issuecomment-1830028330 From jlaskey at openjdk.org Tue Nov 28 15:05:56 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Tue, 28 Nov 2023 15:05:56 GMT Subject: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v35] In-Reply-To: References: Message-ID: On Mon, 27 Nov 2023 23:46:00 GMT, Joe Darcy wrote: >> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: >> >> Requested changes > > test/langtools/tools/javac/ImplicitClass/TestImplicitClass.java line 35: > >> 33: import java.lang.reflect.Modifier; >> 34: >> 35: public class TestImplicitClass { > > The test looks to be testing core reflection behavior (i.e. runtime behavior) and not compile-time behavior via javax.lang.model. > > Core reflection tests should be done too, but done the core libraries tests, not langtools tests. > > I might have overlooked it, but if some other exercise of compile-time modeling is not being done, please restore and update accordingly the sort of tests previously done in the now-deleted > > test/langtools/tools/javac/processing/model/element/TestUnnamedClass.java Added ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16461#discussion_r1407907660 From alanb at openjdk.org Tue Nov 28 15:54:27 2023 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 28 Nov 2023 15:54:27 GMT Subject: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v36] In-Reply-To: <_SVulYe3fr1XL_2ZWqB-pXawtOT9jGGc-SoCojpxW0k=.3cff67d9-4c04-4019-9889-62e98e6276c9@github.com> References: <_SVulYe3fr1XL_2ZWqB-pXawtOT9jGGc-SoCojpxW0k=.3cff67d9-4c04-4019-9889-62e98e6276c9@github.com> Message-ID: On Tue, 28 Nov 2023 13:52:53 GMT, Jim Laskey wrote: >> Address changes from JEP 445 to JEP 463. >> >> - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. >> >> - Don't mark class on read. >> >> - Remove reflection and annotation processing related to unnamed classes. >> >> - Simplify main method search. > > Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 40 commits: > > - Merge remote-tracking branch 'upstream/master' into 8315458 > - Requested changes > - Remove Test > - Move findMainMethod to non-public access > - Handle javadoc on top level elements properly > - Update Class.java > - Update test > - Update findMainMethod as requested > - Add nested class test > - Move Implicitly Declared Classes to single directory > - ... and 30 more: https://git.openjdk.org/jdk/compare/2fae07f5...daacc0ba Marked as reviewed by alanb (Reviewer). src/java.base/share/native/libjli/java.c line 415: > 413: CHECK_EXCEPTION_FAIL(); > 414: (*env)->CallStaticVoidMethod(env, mainClass, mainID, mainArgs); > 415: return 1; I think we should add a comment to each of the 4 invokeXXXX functions to say that they return 1 if the main method completes successfully or it throws. Just trying to head off someone asking why there isn't a CHECK_XXX after the CallStaticVoidMethod/CallVoidMethod. ------------- PR Review: https://git.openjdk.org/jdk/pull/16461#pullrequestreview-1753261575 PR Review Comment: https://git.openjdk.org/jdk/pull/16461#discussion_r1407995550 From eirbjo at gmail.com Tue Nov 28 15:50:46 2023 From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=) Date: Tue, 28 Nov 2023 16:50:46 +0100 Subject: Revisiting JDK-4512189: ZipConstants leaking into public APIs Message-ID: Hi, JDK-4512189 [1] raised the issue that ZipFile, ZipEntry, ZipInputStream and ZipOutputStream all implement the non-public ZipConstants interface. While the interface itself is non-public, the constants defined unfortunately leak into the public API as constants of the mentioned classes. This means they show up in Javadoc, and maybe worse in code completions. JDK-4512189 was closed in 2001 because of concerns of binary compatibility: Unfortunately, whether or not a class implements an interface is part of > the classes public API and having those classes *not* implement > ZipConstants will break binary compatibility. Therefore, unfortunately, > this bug is being closed as will not fix. However, will this really break binary compatibility? Any reference to ZipFile.CENSIG or any other constant (which are all of type long and int) will be compiled into byte code in the referencing class, with or without a copy of the constant in the constant pool of the referencing class. Thus, any compiled reference should continue to work. There is of course a source compatibility issue, but these constants should generally not be of interest to anyone outside the implementation, and if anyone is accidentally using them, it's most probably a bug. In any case, they would get warned when trying to recompile their sources. The easy solution then will be to define their own constants or fix the bug. In light of this, I would like to revisit this issue, 22 years later: - Is my assessment that this change is actually not binary incompatible sound, or did I miss something? - Would it in any case make sense to mark ZipConstants as @Deprecated, maybe for removal to alert people we want to remove the constants? - Could we aim to make the mentioned classes *not* implement ZipConstants, following the regular deprecation process, CSR and release note etc? Thanks, Eirik. [1] https://bugs.openjdk.org/browse/JDK-4512189 -------------- next part -------------- An HTML attachment was scrubbed... URL: From rriggs at openjdk.org Tue Nov 28 16:10:58 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 28 Nov 2023 16:10:58 GMT Subject: RFR: 8320786: Remove ThreadGroup.stop In-Reply-To: References: Message-ID: On Mon, 27 Nov 2023 16:58:29 GMT, Alan Bateman wrote: > ThreadGroup.stop was deprecated since JDK 1.2, deprecated for removal in Java 18, and re-specified/degraded to throw UnsupportedOperationException unconditionally in Java 20. Early in Java 23 seems a fine time to finally remove this method. Corpus analysis of 176 million classes in 485k artifacts found residual usages in 14 artifacts, so not many. > > It would be nice if we could remove Thread.stop at the same time. Sadly there are still quite a few artifacts containing code (and in some cases tests) that reference this method. We will have to come back to this in some future release. Finally! ------------- Marked as reviewed by rriggs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16828#pullrequestreview-1753301310 From david.lloyd at redhat.com Tue Nov 28 16:28:13 2023 From: david.lloyd at redhat.com (David Lloyd) Date: Tue, 28 Nov 2023 10:28:13 -0600 Subject: Revisiting JDK-4512189: ZipConstants leaking into public APIs In-Reply-To: References: Message-ID: On Tue, Nov 28, 2023 at 10:01?AM Eirik Bj?rsn?s wrote: > Hi, > > JDK-4512189 [1] raised the issue that ZipFile, ZipEntry, ZipInputStream > and ZipOutputStream all implement the non-public ZipConstants interface. > While the interface itself is non-public, the constants defined > unfortunately leak into the public API as constants of the mentioned > classes. This means they show up in Javadoc, and maybe worse in code > completions. > > JDK-4512189 was closed in 2001 because of concerns of binary compatibility: > > Unfortunately, whether or not a class implements an interface is part of >> the classes public API and having those classes *not* implement >> ZipConstants will break binary compatibility. Therefore, unfortunately, >> this bug is being closed as will not fix. > > > However, will this really break binary compatibility? Any reference to > ZipFile.CENSIG or any other constant (which are all of type long and int) > will be compiled into byte code in the referencing class, with or without a > copy of the constant in the constant pool of the referencing class. Thus, > any compiled reference should continue to work. > > There is of course a source compatibility issue, but these constants > should generally not be of interest to anyone outside the implementation, > and if anyone is accidentally using them, it's most probably a bug. In any > case, they would get warned when trying to recompile their sources. The > easy solution then will be to define their own constants or fix the bug. > > In light of this, I would like to revisit this issue, 22 years later: > > - Is my assessment that this change is actually not binary incompatible > sound, or did I miss something? > - Would it in any case make sense to mark ZipConstants as @Deprecated, > maybe for removal to alert people we want to remove the constants? > - Could we aim to make the mentioned classes *not* implement ZipConstants, > following the regular deprecation process, CSR and release note etc? > I agree, I always thought that this was a bizarre thing to expose in a public API so it being accidental does explain things. But maybe the appropriate fix is even simpler now in these modern times: one could remove the `implements` and add a `static import` of `ZipConstants.*`, which at approximately one or two lines is a much more minimal (and conflict-resistant, for those who care about backporting subsequent fixes of this class) change IMO. -- - DML ? he/him -------------- next part -------------- An HTML attachment was scrubbed... URL: From eirbjo at gmail.com Tue Nov 28 16:37:45 2023 From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=) Date: Tue, 28 Nov 2023 17:37:45 +0100 Subject: Revisiting JDK-4512189: ZipConstants leaking into public APIs In-Reply-To: References: Message-ID: On Tue, Nov 28, 2023 at 5:28?PM David Lloyd wrote: > I agree, I always thought that this was a bizarre thing to expose in a > public API so it being accidental does explain things. But maybe the > appropriate fix is even simpler now in these modern times: one could remove > the `implements` and add a `static import` of `ZipConstants.*`, which at > approximately one or two lines is a much more minimal (and > conflict-resistant, for those who care about backporting subsequent fixes > of this class) change IMO. > Thanks David! Not entirely sure I understand what you suggest this as an alternative to. Removing "implements" and replacing that with static imports is surely where I would eventually see this going. But before we get there, I think we need to discuss the compatibility impact of such a change, and how to go about it with regards to the deprecation process etc. Eirik. -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.lloyd at redhat.com Tue Nov 28 16:52:54 2023 From: david.lloyd at redhat.com (David Lloyd) Date: Tue, 28 Nov 2023 10:52:54 -0600 Subject: Revisiting JDK-4512189: ZipConstants leaking into public APIs In-Reply-To: References: Message-ID: On Tue, Nov 28, 2023 at 10:38?AM Eirik Bj?rsn?s wrote: > > > On Tue, Nov 28, 2023 at 5:28?PM David Lloyd > wrote: > >> I agree, I always thought that this was a bizarre thing to expose in a >> public API so it being accidental does explain things. But maybe the >> appropriate fix is even simpler now in these modern times: one could remove >> the `implements` and add a `static import` of `ZipConstants.*`, which at >> approximately one or two lines is a much more minimal (and >> conflict-resistant, for those who care about backporting subsequent fixes >> of this class) change IMO. >> > > Thanks David! > > Not entirely sure I understand what you suggest this as an alternative to. > Removing "implements" and replacing that with static imports is surely > where I would eventually see this going. > I was "responding" to the (22-year-old?) suggested fix on the JIRA bug, perhaps unnecessarily; my apologies. > But before we get there, I think we need to discuss the compatibility > impact of such a change, and how to go about it with regards to the > deprecation process etc. > Makes sense to me. FWIW (maybe not much) I think your analysis of the source vs binary compatibility impact is correct. Peeking at `java.util.zip.ZipConstants` with `javap` reveals that the fields do indeed have the expected `ConstantValue` attribute which seems to support your conclusion per JLS ? 13.1 [1]. [1] https://docs.oracle.com/javase/specs/jls/se21/html/jls-13.html#jls-13.1 -- - DML ? he/him -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevinw at openjdk.org Tue Nov 28 17:07:06 2023 From: kevinw at openjdk.org (Kevin Walls) Date: Tue, 28 Nov 2023 17:07:06 GMT Subject: RFR: 8316649: JMX connection timeout cannot be changed and uses the default of 0 (infinite) In-Reply-To: References: Message-ID: On Tue, 21 Nov 2023 17:57:32 GMT, Kevin Walls wrote: > RMI Connections (in general) should use a timeout on the Socket connect call by default. > > JMX connections use RMI and some connection failures never terminate. The hang described in 8316649 is hard to reproduce manually: the description says it can be caused by a firewall that never returns a response. > > src/java.rmi/share/classes/sun/rmi/transport/tcp/TCPChannel.java > has other timeouts but nothing to control the initial Socket connect. > > Defaulting to a 1 minute timeout on connect has no effect on existing tests for RMI and JMX, and should go unnoticed in applications unless there really is a significant connection delay. Specifying zero for the new System Property sun.rmi.transport.tcp.initialConnectTimeout uses the old code path of a connect with no timeout. > > I have a test, but it is not realistically usable: although specifying a 1 millisecond timeout will often fail (as expected/desired for the test), it will often pass as the connection happens immediately. It may be that changing the base RMI implementation isn't desirable. I am bringing up a different implementation, using a new ClientSocketFactory for JMX which implements the connect timeout. So a new JMX-specific property, not a general RMI property, and we limit the impact of the change, so it won't affect any other RMI apps. I'm putting this in https://github.com/openjdk/jdk/pull/16856 it's in draft right now, I'll complete the details and see if it is a better way forward (will close this PR if the new one is better). ------------- PR Comment: https://git.openjdk.org/jdk/pull/16771#issuecomment-1830309421 From ihse at openjdk.org Tue Nov 28 17:07:20 2023 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 28 Nov 2023 17:07:20 GMT Subject: RFR: 8320915: Update copyright year in build files Message-ID: <-4RrV3-LPfsh3BT-qwj3WtF1szg-_6Tt3RxnysPpNeo=.f2b0fee1-7d0c-4c43-bc4f-39ad9fec1150@github.com> Over the year, even though we have tried to be diligent, there have been commits that modify files without updating the copyright year. Here is a mass update of the copyright years in the build system (`make/**`, `.github/**`). Feel free to verify that these files have indeed been modified in 2023 :-), or trust my tools + manual verification. Also, as far as I (and my tools) can tell, this is the only files modified in 2023 that have not had their header updated. ------------- Commit messages: - 8320915: Update copyright year in build files Changes: https://git.openjdk.org/jdk/pull/16858/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16858&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8320915 Stats: 69 lines in 69 files changed: 0 ins; 0 del; 69 mod Patch: https://git.openjdk.org/jdk/pull/16858.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16858/head:pull/16858 PR: https://git.openjdk.org/jdk/pull/16858 From Alan.Bateman at oracle.com Tue Nov 28 17:15:52 2023 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 28 Nov 2023 17:15:52 +0000 Subject: Revisiting JDK-4512189: ZipConstants leaking into public APIs In-Reply-To: References: Message-ID: <128ad702-d589-4365-a62f-baea1ec9e73a@oracle.com> On 28/11/2023 15:50, Eirik Bj?rsn?s wrote: > : > > In light of this, I would like to revisit this issue, 22 years later: > > - Is my assessment that this change is actually not binary > incompatible sound, or did I miss something? > - Would it in any case make sense to mark ZipConstants as?@Deprecated, > maybe for removal to alert people we want to remove the constants? > - Could we aim to make the mentioned classes *not* implement > ZipConstants, following the regular deprecation process, CSR and > release note etc? > This is a JDK 1.1 era mistake. It would a source incompatible change to "remove" the constants. It would require corpus searches to gauge the impact. I think the question is whether it's worth the disruption, is your motivation to cleanup this area or something stronger? -Alan From jlu at openjdk.org Tue Nov 28 17:26:13 2023 From: jlu at openjdk.org (Justin Lu) Date: Tue, 28 Nov 2023 17:26:13 GMT Subject: Integrated: JDK-8320714: java/util/Locale/LocaleProvidersRun.java and java/util/ResourceBundle/modules/visibility/VisibilityTest.java timeout after passing In-Reply-To: References: Message-ID: On Mon, 27 Nov 2023 19:32:04 GMT, Justin Lu wrote: > Please review this PR which fixes timeouts for the two tests: _java/util/Locale/LocaleProvidersRun.java_ and _java/util/ResourceBundle/modules/visibility/VisibilityTest.java_. > > These tests were updated to accept VM flags in [JDK-8319569](https://bugs.openjdk.org/browse/JDK-8319569), which is now causing timeouts in tiers 6 and 8. One set of VM flags causes _VisibilityTest.java_ to timeout with a duration of over 2 hours in tier6. > > Both have been updated to run without VM flags and marked as `vm.flagless`. This pull request has now been integrated. Changeset: 69c0b243 Author: Justin Lu URL: https://git.openjdk.org/jdk/commit/69c0b24386d0bcf2f2d623ccef0192a54753f916 Stats: 6 lines in 2 files changed: 2 ins; 0 del; 4 mod 8320714: java/util/Locale/LocaleProvidersRun.java and java/util/ResourceBundle/modules/visibility/VisibilityTest.java timeout after passing Reviewed-by: naoto, bpb, lancea ------------- PR: https://git.openjdk.org/jdk/pull/16831 From mchung at openjdk.org Tue Nov 28 17:42:08 2023 From: mchung at openjdk.org (Mandy Chung) Date: Tue, 28 Nov 2023 17:42:08 GMT Subject: RFR: 8320858: Move jpackage tests to tier3 In-Reply-To: References: Message-ID: On Tue, 28 Nov 2023 08:51:17 GMT, Alan Bateman wrote: > Update the jtreg test group configuration in the jdk test tree so that the jpackage tests run in tier3 rather than tier2. > > At this time, the jpackage tests run in jdk:tier2, more specifically jdk:tier2_part2 as part of the core_tools test group. The jpackage tests take a significant amount of time on some platforms (on macOS and Windows in particular). The changes here remove tools/jpackage from core_tools (it's not a core tool anyway) and adds the tests to tier3. In the future then maybe tier3 can be split up if needed. This PR looks fine. Per our offline discussion, need to revisit the CI configurations to ensure these tests are covered. ------------- Marked as reviewed by mchung (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16841#pullrequestreview-1753504621 From lance.andersen at oracle.com Tue Nov 28 17:45:40 2023 From: lance.andersen at oracle.com (Lance Andersen) Date: Tue, 28 Nov 2023 17:45:40 +0000 Subject: Revisiting JDK-4512189: ZipConstants leaking into public APIs In-Reply-To: <128ad702-d589-4365-a62f-baea1ec9e73a@oracle.com> References: <128ad702-d589-4365-a62f-baea1ec9e73a@oracle.com> Message-ID: <7EC1FE64-4A8F-45D6-977E-6BF029891F95@oracle.com> I agree, I am not sure there is a large benefit to changing this at this time. Seems a lot of effort for minimal gain at best. On Nov 28, 2023, at 12:15 PM, Alan Bateman > wrote: On 28/11/2023 15:50, Eirik Bj?rsn?s wrote: : In light of this, I would like to revisit this issue, 22 years later: - Is my assessment that this change is actually not binary incompatible sound, or did I miss something? - Would it in any case make sense to mark ZipConstants as @Deprecated, maybe for removal to alert people we want to remove the constants? - Could we aim to make the mentioned classes *not* implement ZipConstants, following the regular deprecation process, CSR and release note etc? This is a JDK 1.1 era mistake. It would a source incompatible change to "remove" the constants. It would require corpus searches to gauge the impact. I think the question is whether it's worth the disruption, is your motivation to cleanup this area or something stronger? -Alan [cid:E1C4E2F0-ECD0-4C9D-ADB4-B16CA7BCB7FC at home] Lance Andersen | Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: oracle_sig_logo.gif Type: image/gif Size: 658 bytes Desc: oracle_sig_logo.gif URL: From bpb at openjdk.org Tue Nov 28 17:59:08 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 28 Nov 2023 17:59:08 GMT Subject: RFR: 8320759: Creation of random BigIntegers can be made faster [v2] In-Reply-To: <0naowVOuVFb0JGS7eT_IvAxiKowPnJGm4BnDXYHiRJA=.0131f810-05b4-43f3-bd6b-8f4579daf3e5@github.com> References: <4WB_FtpmH5qbqDU3zMoTCkGFRVaMmBSrRRjSVA33TKE=.698ad745-b5d7-4471-8c29-019dcaea988b@github.com> <9linin03BjEwpwt9j1cCabK_AhfWjp7M9uxTY7MxAlQ=.6467a7a8-87d0-48dc-a05f-c6f3339f136e@github.com> <0naowVOuVFb0JGS7eT_IvAxiKowPnJGm4BnDXYHiRJA=.0131f810-05b4-43f3-bd6b-8f4579daf3e5@github.com> Message-ID: On Tue, 28 Nov 2023 11:46:10 GMT, fabioromano1 wrote: >> Indeed it looks as if that is correct. > > As specified in https://docs.oracle.com/javase/specs/jls/se21/html/jls-15.html#jls-15.19: > "If the promoted type of the left-hand operand is int, then only the five lowest-order bits of the right-hand operand are used as the shift distance. It is as if the right-hand operand were subjected to a bitwise logical AND operator & ([?15.22.1](https://docs.oracle.com/javase/specs/jls/se21/html/jls-15.html#jls-15.22.1)) with the mask value 0x1f (0b11111). The shift distance actually used is therefore always in the range 0 to 31, inclusive. > The value of n >>> s is n right-shifted s bit positions with zero-extension, where If n is negative and the type of the left-hand operand is int, then the result is equal to that of the expression (n >> s) + (2 << ~s). The added term (2 << ~s) cancels out the propagated sign bit." > Since (excessBits == 32 * numInts - numBits), then (excessBits == (32 - (numBits & 0x1f)) & 0x1f), because (n & 0x1f == n mod 32). Since the five lowest-order bits of 32 are 0, then the five lowest-order bits of (32 - (numBits & 0x1f)) are the same of (-numBits), and so (excessBits == (-numBits) & 0x1f), therefore (-1 >>> excessBits == -1 >>> -numBits). Thanks for the proof. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16817#discussion_r1408164544 From bpb at openjdk.org Tue Nov 28 18:14:06 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 28 Nov 2023 18:14:06 GMT Subject: RFR: 8320759: Creation of random BigIntegers can be made faster [v2] In-Reply-To: References: Message-ID: On Mon, 27 Nov 2023 22:58:17 GMT, fabioromano1 wrote: >> A faster and simpler way to generate random BigIntegers, avoiding eventually trimming of leading zeros in magnitude array. > > fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: > > Update BigInteger(int, Random) > > Update a comment Do you have any actual benchmark measurements that you could share? ------------- PR Comment: https://git.openjdk.org/jdk/pull/16817#issuecomment-1830416016 From mgronlun at openjdk.org Tue Nov 28 18:24:10 2023 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Tue, 28 Nov 2023 18:24:10 GMT Subject: RFR: 8310994: Add JFR event for selection operations In-Reply-To: References: Message-ID: On Fri, 17 Nov 2023 16:22:55 GMT, Tim Prinzing wrote: > Added mirror event with static methods: jdk.internal.event.SelectionEvent that provides the duration of select calls and the count of how many keys are available. > > Emit the event from SelectorImpl::lockAndDoSelect > > Test at jdk.jfr.event.io.TestSelectionEvents It would be good to integrate this quite soon because it would release the reliance on ASM and let us only use the new ClassFile API. Now, we need to load both implementations, leading to startup regression. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16710#issuecomment-1830431950 From eirbjo at gmail.com Tue Nov 28 18:24:18 2023 From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=) Date: Tue, 28 Nov 2023 19:24:18 +0100 Subject: Revisiting JDK-4512189: ZipConstants leaking into public APIs In-Reply-To: <128ad702-d589-4365-a62f-baea1ec9e73a@oracle.com> References: <128ad702-d589-4365-a62f-baea1ec9e73a@oracle.com> Message-ID: On Tue, Nov 28, 2023 at 6:16?PM Alan Bateman wrote: > > In light of this, I would like to revisit this issue, 22 years later: > [...] > > This is a JDK 1.1 era mistake. It would a source incompatible change to > "remove" the constants. It would require corpus searches to gauge the > impact. I think the question is whether it's worth the disruption, is > your motivation to cleanup this area or something stronger? > Alan, Lance Yes, removing anything always incurs a cost. There is the cost for the OpenJDK team to assess, plan, implement and communicate the change. This is a fixed, one time, implementation and review cost for a few of us to take on. Then there is also a cost paid by any project recompiling source files referencing these constants and discovering that they have been removed. Each such project will experience a fixed, one time cost to replace references with their own constants. This replacement should be relatively straightforward, given that values are readily available in Java API docs [1]. A corpus search may help us assess the magnitude of this cost. We can reduce (or at least ease) this cost by deprecating the constants for a few releases first, giving projects more time to detect and react to a forthcoming removal. But keeping this "peculiarity" afloat does not come for free either. This cost is perhaps harder to assess, because it is a small cost potentially affecting many people. There are millions of Java developers out there. A good chunk of them will through their career eventually need to study the APIs of ZipFile, ZipEntry, ZipInputStream or ZipOutputStream, either by reading Javadocs, or by using code completion in their IDE. Most of them will stumble upon these constants. Some will simply scroll past them, finding what they looked for. Others will stop, wonder how these constants are supposed to be used, what part of the API allows them to be used. Most will soon think "it's probably there for a reason", and continue their work. But some will be curious, search for an explanation, ask on forums, study the source code, perhaps stumble upon JDK-4512189. It's hard to say whether the cumulative cost over years of all these small distractions is larger than the fixed, one-time cost of the removal. My gut feeling says yes. In any case, could it perhaps be worth at least deprecating these constants? This would signal to API readers that they were a mistake and should not be given focus. And it would give a compile warning to projects accidentally referencing the constants. Then we can spend a few releases deciding whether a removal is warranted. Eirik. [1] -------------- next part -------------- An HTML attachment was scrubbed... URL: From isipka at openjdk.org Tue Nov 28 18:26:37 2023 From: isipka at openjdk.org (Ivan =?UTF-8?B?xaBpcGth?=) Date: Tue, 28 Nov 2023 18:26:37 GMT Subject: RFR: 8320665: update jdk_core at test/jdk/TEST.groups [v2] In-Reply-To: References: Message-ID: > @bwhuang-us @mahendrachhipa Ivan ?ipka has updated the pull request incrementally with one additional commit since the last revision: added jdk_core_no_security as additional group defintion, reverting old base definition ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16796/files - new: https://git.openjdk.org/jdk/pull/16796/files/e311f3e0..6615915b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16796&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16796&range=00-01 Stats: 10 lines in 1 file changed: 5 ins; 4 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/16796.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16796/head:pull/16796 PR: https://git.openjdk.org/jdk/pull/16796 From jlu at openjdk.org Tue Nov 28 18:28:37 2023 From: jlu at openjdk.org (Justin Lu) Date: Tue, 28 Nov 2023 18:28:37 GMT Subject: RFR: JDK-8210410: Refactor java.util.Currency:i18n shell tests to plain java tests [v2] In-Reply-To: References: Message-ID: > Please review this PR which converts the shell test, _java/util/currency/PropertiesTest.sh_ to a normal java test. > > This test is a test runner that launches test methods from _PropertiesTest.java_. It tests both the ways to supersede the default currencies, that is, either using a custom properties file under the lib directory, or setting the path to a custom properties file via the system property. Justin Lu has updated the pull request incrementally with one additional commit since the last revision: cleanup + naming ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16787/files - new: https://git.openjdk.org/jdk/pull/16787/files/780c6fd1..efc6da98 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16787&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16787&range=00-01 Stats: 40 lines in 1 file changed: 8 ins; 10 del; 22 mod Patch: https://git.openjdk.org/jdk/pull/16787.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16787/head:pull/16787 PR: https://git.openjdk.org/jdk/pull/16787 From lancea at openjdk.org Tue Nov 28 18:29:13 2023 From: lancea at openjdk.org (Lance Andersen) Date: Tue, 28 Nov 2023 18:29:13 GMT Subject: RFR: 8303866: Allow ZipInputStream.readEnd to parse small Zip64 ZIP files [v8] In-Reply-To: References: Message-ID: On Wed, 15 Nov 2023 20:10:53 GMT, Eirik Bjorsnos wrote: >> ZipInputStream.readEnd currently assumes a Zip64 data descriptor if the number of compressed or uncompressed bytes read from the inflater is larger than the Zip64 magic value. >> >> While the ZIP format mandates that the data descriptor `SHOULD be stored in ZIP64 format (as 8 byte values) when a file's size exceeds 0xFFFFFFFF`, it also states that `ZIP64 format MAY be used regardless of the size of a file`. For such small entries, the above assumption does not hold. >> >> This PR augments ZipInputStream.readEnd to also assume 8-byte sizes if the ZipEntry includes a Zip64 extra information field. This brings ZipInputStream into alignment with the APPNOTE format spec: >> >> >> When extracting, if the zip64 extended information extra >> field is present for the file the compressed and >> uncompressed sizes will be 8 byte values. >> >> >> While small Zip64 files with 8-byte data descriptors are not commonly found in the wild, it is possible to create one using the Info-ZIP command line `-fd` flag: >> >> `echo hello | zip -fd > hello.zip` >> >> The PR also adds a test verifying that such a small Zip64 file can be parsed by ZipInputStream. > > Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision: > > Extract ZIP64_BLOCK_SIZE_OFFSET as a constant Thank you for your efforts here Eirik. I am OK with the proposed changes. We have completed internally our Mach5 runs and thanks to Jai, we have been able to exercise a build against a large internal repository of jars I would like to suggest that we hold off until we fork for JDK 23 to push this (as we are going to do for my outstanding CEN validation checks) so that we are allowing for more time to catch the unexpected hiccup ------------- Marked as reviewed by lancea (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/12524#pullrequestreview-1753604135 From isipka at openjdk.org Tue Nov 28 18:33:02 2023 From: isipka at openjdk.org (Ivan =?UTF-8?B?xaBpcGth?=) Date: Tue, 28 Nov 2023 18:33:02 GMT Subject: RFR: 8320665: update jdk_core at test/jdk/TEST.groups In-Reply-To: <_bGb6mv5_Y4kgakm0VSvtwC1QMzY2zWY9pwaZXnSSDc=.1ee3e6ca-c069-4711-bfe1-ce0d309e21ac@github.com> References: <_bGb6mv5_Y4kgakm0VSvtwC1QMzY2zWY9pwaZXnSSDc=.1ee3e6ca-c069-4711-bfe1-ce0d309e21ac@github.com> Message-ID: On Mon, 27 Nov 2023 08:03:04 GMT, Alan Bateman wrote: > > > I use the jdk_core test group. I know the split doesn't impact users of this test group but it's not clear why the change is being done. Would it be possible to explain why you are doing this? There is nothing in the JBS issue or PR to explain. > > > > > > explained in private communication: refactoring of internally used files to enable ergonomic result analysis for internal processes > > My concern with changes like this is that it's just adding to the complexity of the definitions of important test groups. I think we need a new section/heading at the end of the file as the place to put these special test runs (esp. the manual tests). For jdk_core_no_security then my strong preference is not to hack the existing test group configurations, instead add this to the special runs section at the end: > > ``` > jdk_core_no_security = \ > :jdk_core \ > -:jdk_security > ``` Code updated as per your suggestion, thank you. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16796#issuecomment-1830446899 From smarks at openjdk.org Tue Nov 28 18:38:12 2023 From: smarks at openjdk.org (Stuart Marks) Date: Tue, 28 Nov 2023 18:38:12 GMT Subject: RFR: 8320532: Remove Thread/ThreadGroup suspend/resume In-Reply-To: References: Message-ID: On Thu, 23 Nov 2023 09:18:44 GMT, Alan Bateman wrote: > The deadlock prone Thread/ThreadGroup suspend/resume were deprecated since JDK 1.2, deprecated for removal in Java 14, and re-specified/degraded to throw UnsupportedOperationException unconditionally in Java 19/20. Early in Java 23 seems a fine time to finally remove these methods. > > Corpus analysis of 176 million classes in 485k artifacts found no remaining usages of ThreadGroup.suspend/resume beyond the artifacts that include a copy of java.lang.ThreadGroup (!). It found 87 remaining uses of Thread.suspend and 86 remaining usages of Thread.resume, some of these are tests. > > Thread.suspend/resume have always linked to the "Java Thread Primitive Deprecation" page. This originally explained the reasons why suspend/resume were deprecated. When these methods were degraded to throw UOE we changed the text to explain why the ability to suspend or resume a thread was removed. Now we must change it again. One choice is to re-word to explain why the Java APIs were removed or why the Java APIs don't define a way to suspend/resume threads, the other choice (which I prefer) is to remove the text. > > The method description of java.lang.management.ThreadInfo.isSuspended is tweaked to link to JVMTI SuspendThread instead of Thread.suspend Marked as reviewed by smarks (Reviewer). Yeah, removing the text from the deprecation is reasonable. I expect that eventually the deprecation page will simply vanish when this is all over (I guess, after Thread.stop is finally removed). Eventually somebody should write the definitive history of the Thread API. ------------- PR Review: https://git.openjdk.org/jdk/pull/16789#pullrequestreview-1753630611 PR Comment: https://git.openjdk.org/jdk/pull/16789#issuecomment-1830456956 From eirbjo at gmail.com Tue Nov 28 18:59:02 2023 From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=) Date: Tue, 28 Nov 2023 19:59:02 +0100 Subject: Revisiting JDK-4512189: ZipConstants leaking into public APIs In-Reply-To: References: <128ad702-d589-4365-a62f-baea1ec9e73a@oracle.com> Message-ID: > > But keeping this "peculiarity" afloat does not come for free either. > Let me add that keeping the constants also incurs a maintenance cost: The fact that these constants are "effectively and accidentally public" is unusual, but needs to be understood and enforced by maintainers. Their names, values and location need to stay constant, regardless of needs to improve and evolve our code base. Eirik. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jlaskey at openjdk.org Tue Nov 28 19:10:45 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Tue, 28 Nov 2023 19:10:45 GMT Subject: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v39] In-Reply-To: References: Message-ID: > Address changes from JEP 445 to JEP 463. > > - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. > > - Don't mark class on read. > > - Remove reflection and annotation processing related to unnamed classes. > > - Simplify main method search. Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 43 commits: - Merge remote-tracking branch 'upstream/master' into 8315458 - Create TestImplicitClass.java - Update Class.java comment - Merge remote-tracking branch 'upstream/master' into 8315458 - Requested changes - Remove Test - Move findMainMethod to non-public access - Handle javadoc on top level elements properly - Update Class.java - Update test - ... and 33 more: https://git.openjdk.org/jdk/compare/dc256fbc...6ce7c84a ------------- Changes: https://git.openjdk.org/jdk/pull/16461/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16461&range=38 Stats: 1511 lines in 52 files changed: 656 ins; 723 del; 132 mod Patch: https://git.openjdk.org/jdk/pull/16461.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16461/head:pull/16461 PR: https://git.openjdk.org/jdk/pull/16461 From naoto at openjdk.org Tue Nov 28 19:18:13 2023 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 28 Nov 2023 19:18:13 GMT Subject: RFR: 8320798: Console read line with zero out should zero out underlying buffer Message-ID: It is best practice to zero out the underlying buffer after use. ------------- Commit messages: - copyright year - fill zero to position - initial commit Changes: https://git.openjdk.org/jdk/pull/16861/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16861&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8320798 Stats: 31 lines in 2 files changed: 30 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/16861.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16861/head:pull/16861 PR: https://git.openjdk.org/jdk/pull/16861 From asemenyuk at openjdk.org Tue Nov 28 19:25:08 2023 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Tue, 28 Nov 2023 19:25:08 GMT Subject: RFR: 8320858: Move jpackage tests to tier3 In-Reply-To: References: Message-ID: On Tue, 28 Nov 2023 08:51:17 GMT, Alan Bateman wrote: > Update the jtreg test group configuration in the jdk test tree so that the jpackage tests run in tier3 rather than tier2. > > At this time, the jpackage tests run in jdk:tier2, more specifically jdk:tier2_part2 as part of the core_tools test group. The jpackage tests take a significant amount of time on some platforms (on macOS and Windows in particular). The changes here remove tools/jpackage from core_tools (it's not a core tool anyway) and adds the tests to tier3. In the future then maybe tier3 can be split up if needed. Marked as reviewed by asemenyuk (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/16841#pullrequestreview-1753718659 From mchung at openjdk.org Tue Nov 28 19:25:10 2023 From: mchung at openjdk.org (Mandy Chung) Date: Tue, 28 Nov 2023 19:25:10 GMT Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged modules being present [v8] In-Reply-To: References: <3DpzMArCkz5ehvgoid5DPvhy6SQmw9mkKzOBqj6vItU=.54099d82-259c-48ca-8c61-e7b783640ed8@github.com> Message-ID: On Thu, 23 Nov 2023 18:26:58 GMT, Severin Gehwolf wrote: > Those are now being filtered (using exclude-resource) prior it being processed by the TRANSFORMER or ADDER phases. Furthermore, it prevents those classes to populate if plug-ins that generated them aren't used. This also removes the need to actually modify any of the existing plugins. This is a clever idea. I think we can express this via Plugin API as each plugin knows what contents it adds. Instead of hardcoding the `exclude-resources` pattern in `TaskHelper::getPluginsConfig`, it can construct the list from `Plugin::excludeResourcesPattern`. > The option --unlock-run-image to get equivalence between a link using packaged modules and run-time based link is now hidden (similar to --keep-packaged-modules). This is really advanced usage and doesn't need a prominent place in jlink --help. I would suggest to keep this as an internal/unsupported option for now. Give some time to get customer feedback and reevaluate this if needed. i.e. `--unlock-run-image` won't show in the help output and the error message won't mention this option like this: Error: /path/to/jdk/conf/net.properties has been modified. Comments on the CSR: 1. `Plugin` is an internal API and so no need to document `Plugin::isHidden` in the CSR. 2. If we agree to keep `--unlock-run-image` option as internal/unsupported option, it can be dropped from the CSR. 3. About the message 'jmods' folder not present, performing a run-time image based link. Instead of saying "performing a run-time image based link", it may be helpful for the users to know what plugins are applied in the resulting image. Also we can say "The default module path: `jmods` not present". For example: The default module path: `$java.home/jmods` not present. Use --verbose to show the full list of plugin options applied. The `--verbose` option can include the options for the plugins accumulated with the run-time image (such as `--strip-debug --vendor-bug-url xxx`) 4. Suggested error message for recursive linking: $ ./bin/jlink --add-modules java.base --output ./build/second-stage-link-java.base Error: Module path to the JDK package modules must be specified. Run-time image based linking is not supported as $java.home was created from a run-time image but not packaged modules. or something like that. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14787#issuecomment-1830528390 From bpb at openjdk.org Tue Nov 28 19:26:08 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 28 Nov 2023 19:26:08 GMT Subject: RFR: 8320798: Console read line with zero out should zero out underlying buffer In-Reply-To: References: Message-ID: On Tue, 28 Nov 2023 19:12:50 GMT, Naoto Sato wrote: > It is best practice to zero out the underlying buffer after use. src/java.base/share/classes/sun/nio/cs/StreamDecoder.java line 294: > 292: private void lockedFillZeroToPosition() throws IOException { > 293: ensureOpen(); > 294: Arrays.fill(bb.array(), 0, bb.arrayOffset() + bb.position(), (byte)0); Should the `from` parameter be zero or `bb.arrayOffset()`? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16861#discussion_r1408281785 From naoto at openjdk.org Tue Nov 28 19:30:34 2023 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 28 Nov 2023 19:30:34 GMT Subject: RFR: 8320798: Console read line with zero out should zero out underlying buffer [v2] In-Reply-To: References: Message-ID: > It is best practice to zero out the underlying buffer after use. Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: corrected fromIndex ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16861/files - new: https://git.openjdk.org/jdk/pull/16861/files/3d2351b5..90c4dece Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16861&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16861&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/16861.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16861/head:pull/16861 PR: https://git.openjdk.org/jdk/pull/16861 From naoto at openjdk.org Tue Nov 28 19:30:36 2023 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 28 Nov 2023 19:30:36 GMT Subject: RFR: 8320798: Console read line with zero out should zero out underlying buffer [v2] In-Reply-To: References: Message-ID: On Tue, 28 Nov 2023 19:23:45 GMT, Brian Burkhalter wrote: >> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: >> >> corrected fromIndex > > src/java.base/share/classes/sun/nio/cs/StreamDecoder.java line 294: > >> 292: private void lockedFillZeroToPosition() throws IOException { >> 293: ensureOpen(); >> 294: Arrays.fill(bb.array(), 0, bb.arrayOffset() + bb.position(), (byte)0); > > Should the `from` parameter be zero or `bb.arrayOffset()`? Right. Fixed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16861#discussion_r1408285735 From duke at openjdk.org Tue Nov 28 19:31:09 2023 From: duke at openjdk.org (fabioromano1) Date: Tue, 28 Nov 2023 19:31:09 GMT Subject: RFR: 8320759: Creation of random BigIntegers can be made faster [v2] In-Reply-To: References: Message-ID: On Mon, 27 Nov 2023 22:58:17 GMT, fabioromano1 wrote: >> A faster and simpler way to generate random BigIntegers, avoiding eventually trimming of leading zeros in magnitude array. > > fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: > > Update BigInteger(int, Random) > > Update a comment @bplb I have not yet made benchmark measurements, but I can produce them. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16817#issuecomment-1830536035 From bpb at openjdk.org Tue Nov 28 19:34:12 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 28 Nov 2023 19:34:12 GMT Subject: RFR: 8320759: Creation of random BigIntegers can be made faster [v2] In-Reply-To: References: Message-ID: On Tue, 28 Nov 2023 18:11:25 GMT, Brian Burkhalter wrote: >> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: >> >> Update BigInteger(int, Random) >> >> Update a comment > > Do you have any actual benchmark measurements that you could share? > @bplb I have not yet made benchmark measurements, but I can produce them. @fabioromano1 I think it would be good to measure and report the benefit, if you don't mind. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16817#issuecomment-1830540230 From bpb at openjdk.org Tue Nov 28 19:36:06 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 28 Nov 2023 19:36:06 GMT Subject: RFR: 8320798: Console read line with zero out should zero out underlying buffer [v2] In-Reply-To: References: Message-ID: On Tue, 28 Nov 2023 19:30:34 GMT, Naoto Sato wrote: >> It is best practice to zero out the underlying buffer after use. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > corrected fromIndex Looks good now. ------------- Marked as reviewed by bpb (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16861#pullrequestreview-1753736289 From lancea at openjdk.org Tue Nov 28 19:47:08 2023 From: lancea at openjdk.org (Lance Andersen) Date: Tue, 28 Nov 2023 19:47:08 GMT Subject: RFR: 8320798: Console read line with zero out should zero out underlying buffer [v2] In-Reply-To: References: Message-ID: On Tue, 28 Nov 2023 19:30:34 GMT, Naoto Sato wrote: >> It is best practice to zero out the underlying buffer after use. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > corrected fromIndex Marked as reviewed by lancea (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/16861#pullrequestreview-1753782100 From mchung at openjdk.org Tue Nov 28 19:49:09 2023 From: mchung at openjdk.org (Mandy Chung) Date: Tue, 28 Nov 2023 19:49:09 GMT Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged modules being present [v8] In-Reply-To: References: <3DpzMArCkz5ehvgoid5DPvhy6SQmw9mkKzOBqj6vItU=.54099d82-259c-48ca-8c61-e7b783640ed8@github.com> Message-ID: On Tue, 28 Nov 2023 19:22:44 GMT, Mandy Chung wrote: > The --verbose option can include the options for the plugins accumulated with the run-time image (such as --strip-debug --vendor-bug-url xxx) I considered how to document the behavior of linking with packaged modules vs from run-time image. For example (1) document in `--list-plugins` output, (2) via Plugin API to indicate whether accumulate with base run-time image or not. Ultimately, we want to know the jlink command-line options if it's linked with packaged modules. So I think `--verbose` output would serve as a good documentation. I'd like to hear other opinions. This probably need to extend Plugin API to indicate if this plugin will carry forward in linking from the run-time image. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14787#issuecomment-1830596088 From sgehwolf at openjdk.org Tue Nov 28 20:00:09 2023 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Tue, 28 Nov 2023 20:00:09 GMT Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged modules being present [v8] In-Reply-To: References: <3DpzMArCkz5ehvgoid5DPvhy6SQmw9mkKzOBqj6vItU=.54099d82-259c-48ca-8c61-e7b783640ed8@github.com> Message-ID: On Tue, 28 Nov 2023 19:46:45 GMT, Mandy Chung wrote: > Ultimately, we want to know the jlink command-line options if it's linked with packaged modules. So I think `--verbose` output would serve as a good documentation. I'd like to hear other opinions. Are you saying that for a run-time image based link: `--verbose` should tell you exactly which command line options would need to be added to arrive at the same end-result image, but with packaged modules? I.e. do some tracking of cli options when `jlink` runs? ------------- PR Comment: https://git.openjdk.org/jdk/pull/14787#issuecomment-1830626594 From jlaskey at openjdk.org Tue Nov 28 20:04:45 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Tue, 28 Nov 2023 20:04:45 GMT Subject: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v40] In-Reply-To: References: Message-ID: > Address changes from JEP 445 to JEP 463. > > - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. > > - Don't mark class on read. > > - Remove reflection and annotation processing related to unnamed classes. > > - Simplify main method search. Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: Requested changes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16461/files - new: https://git.openjdk.org/jdk/pull/16461/files/6ce7c84a..0d01c488 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16461&range=39 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16461&range=38-39 Stats: 4 lines in 3 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/16461.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16461/head:pull/16461 PR: https://git.openjdk.org/jdk/pull/16461 From jlaskey at openjdk.org Tue Nov 28 20:04:49 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Tue, 28 Nov 2023 20:04:49 GMT Subject: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v36] In-Reply-To: References: <_SVulYe3fr1XL_2ZWqB-pXawtOT9jGGc-SoCojpxW0k=.3cff67d9-4c04-4019-9889-62e98e6276c9@github.com> Message-ID: On Tue, 28 Nov 2023 14:43:36 GMT, Alan Bateman wrote: >> Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 40 commits: >> >> - Merge remote-tracking branch 'upstream/master' into 8315458 >> - Requested changes >> - Remove Test >> - Move findMainMethod to non-public access >> - Handle javadoc on top level elements properly >> - Update Class.java >> - Update test >> - Update findMainMethod as requested >> - Add nested class test >> - Move Implicitly Declared Classes to single directory >> - ... and 30 more: https://git.openjdk.org/jdk/compare/2fae07f5...daacc0ba > > test/jdk/tools/launcher/modules/basic/LauncherErrors.java line 97: > >> 95: .shouldContain("Error: Unable to load main class " + MAIN_CLASS + " in module " + TEST_MODULE) >> 96: .shouldContain("java.security.AccessControlException") >> 97: .shouldNotHaveExitValue(0); > > The updates to the launcher tests look okay but I'm wondering if the "Caused by:" is the output now? I get it that the "Unable to ..." message has changed but has the format of the cause changed too? > > I assume you'll fix up the copyright date on Arrrrgs and LauncherErrors before integrating. "Caused by:" has (always) been missing from the named module version of the error message. I'll add in and modify the test accordingly. Updated copyright. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16461#discussion_r1408356364 From lancea at openjdk.org Tue Nov 28 20:09:08 2023 From: lancea at openjdk.org (Lance Andersen) Date: Tue, 28 Nov 2023 20:09:08 GMT Subject: RFR: 8316141: Improve CEN header validation checking In-Reply-To: References: Message-ID: On Thu, 16 Nov 2023 20:52:08 GMT, Eirik Bjorsnos wrote: > > Regarding you comment about checking whether or not to check if the combined length of the CEN header + name length + comment length + extra length > 65K bytes, I chose to add this given the strong wording given this is a really old spec. That being said, I do not object to removing the validation if that is the overall preference. > > I can't claim to have a particularly strong opinion on this, the following is mostly me thinking aloud: > > * Given Hyrum's Law, it is conceivable that someone is currently using the extra or comment fields to attach up to 65535+65535 bytes of metadata for entires. The proposed validation will break such schemes. Does Oracle have a ZIP file corpus which could be used to identify files currently exceeding the combined length clause, just to get a sense of how rare or common this is? > * The actual benefits of adding this validation after all these years is not quite clear to me. I don't see how this improves security, robustness, compatibility, maintainability or other ilities (apart from strictly-following-the-spec-ility :-) > * I created a ZIP file with an entry with an extra field of the maximal expressable length of 0xFFFF. Info-ZIP's `unzip` command on MacOS did not output any warning or error when processing this file. Yes we have a corpus search available and have exercised this patch (along with your ZipInputStream patch) without any regressions. Given where we are in the JDK 22 cycle, going to hold off on finalizing the PR until we fork for JDK 23 and look to move this forward early on allowing for additional time to bake ------------- PR Comment: https://git.openjdk.org/jdk/pull/16570#issuecomment-1830639162 From jlaskey at openjdk.org Tue Nov 28 20:15:06 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Tue, 28 Nov 2023 20:15:06 GMT Subject: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v41] In-Reply-To: References: Message-ID: > Address changes from JEP 445 to JEP 463. > > - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. > > - Don't mark class on read. > > - Remove reflection and annotation processing related to unnamed classes. > > - Simplify main method search. Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: Add comments to invokeXXXX functions ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16461/files - new: https://git.openjdk.org/jdk/pull/16461/files/0d01c488..30170407 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16461&range=40 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16461&range=39-40 Stats: 16 lines in 1 file changed: 15 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/16461.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16461/head:pull/16461 PR: https://git.openjdk.org/jdk/pull/16461 From jlaskey at openjdk.org Tue Nov 28 20:15:12 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Tue, 28 Nov 2023 20:15:12 GMT Subject: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v36] In-Reply-To: References: <_SVulYe3fr1XL_2ZWqB-pXawtOT9jGGc-SoCojpxW0k=.3cff67d9-4c04-4019-9889-62e98e6276c9@github.com> Message-ID: <50sgilEAyAxziPJyoaVqfwv9e3xFAXtSo2cTsUCu3lE=.4baff79c-fbe0-4fdd-bd92-921af3e1fb89@github.com> On Tue, 28 Nov 2023 15:51:37 GMT, Alan Bateman wrote: >> Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 40 commits: >> >> - Merge remote-tracking branch 'upstream/master' into 8315458 >> - Requested changes >> - Remove Test >> - Move findMainMethod to non-public access >> - Handle javadoc on top level elements properly >> - Update Class.java >> - Update test >> - Update findMainMethod as requested >> - Add nested class test >> - Move Implicitly Declared Classes to single directory >> - ... and 30 more: https://git.openjdk.org/jdk/compare/2fae07f5...daacc0ba > > src/java.base/share/native/libjli/java.c line 415: > >> 413: CHECK_EXCEPTION_FAIL(); >> 414: (*env)->CallStaticVoidMethod(env, mainClass, mainID, mainArgs); >> 415: return 1; > > I think we should add a comment to each of the 4 invokeXXXX functions to say that they return 1 if the main method completes successfully or it throws. Just trying to head off someone asking why there isn't a CHECK_XXX after the CallStaticVoidMethod/CallVoidMethod. Comments added. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16461#discussion_r1408365265 From joehw at openjdk.org Tue Nov 28 20:18:13 2023 From: joehw at openjdk.org (Joe Wang) Date: Tue, 28 Nov 2023 20:18:13 GMT Subject: RFR: 8320918: Fix errors in the built-in Catalog implementation Message-ID: Fix errors in the built-in Catalog implementation, specifically: -- incorrect case in the property name as defined in the CSR (https://bugs.openjdk.org/browse/JDK-8306056) -- tests needed to be updated accordingly -- jaxp.properties updated with documentation for the new properties Tests: passed after the update. ------------- Commit messages: - 8320918: Fix errors in the built-in Catalog implementation Changes: https://git.openjdk.org/jdk/pull/16862/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16862&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8320918 Stats: 50 lines in 6 files changed: 38 ins; 4 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/16862.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16862/head:pull/16862 PR: https://git.openjdk.org/jdk/pull/16862 From lancea at openjdk.org Tue Nov 28 20:23:05 2023 From: lancea at openjdk.org (Lance Andersen) Date: Tue, 28 Nov 2023 20:23:05 GMT Subject: RFR: 8320918: Fix errors in the built-in Catalog implementation In-Reply-To: References: Message-ID: On Tue, 28 Nov 2023 20:11:42 GMT, Joe Wang wrote: > Fix errors in the built-in Catalog implementation, specifically: > -- incorrect case in the property name as defined in the CSR (https://bugs.openjdk.org/browse/JDK-8306056) > -- tests needed to be updated accordingly > -- jaxp.properties updated with documentation for the new properties > > Tests: passed after the update. Marked as reviewed by lancea (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/16862#pullrequestreview-1753859021 From joehw at openjdk.org Tue Nov 28 20:23:06 2023 From: joehw at openjdk.org (Joe Wang) Date: Tue, 28 Nov 2023 20:23:06 GMT Subject: RFR: 8320798: Console read line with zero out should zero out underlying buffer [v2] In-Reply-To: References: Message-ID: On Tue, 28 Nov 2023 19:30:34 GMT, Naoto Sato wrote: >> It is best practice to zero out the underlying buffer after use. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > corrected fromIndex Marked as reviewed by joehw (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/16861#pullrequestreview-1753858796 From duke at openjdk.org Tue Nov 28 20:29:04 2023 From: duke at openjdk.org (Srinivas Vamsi Parasa) Date: Tue, 28 Nov 2023 20:29:04 GMT Subject: RFR: 8319577: x86_64 AVX2 intrinsics for Arrays.sort methods (int, float arrays) [v2] In-Reply-To: References: Message-ID: On Mon, 27 Nov 2023 23:44:25 GMT, Sandhya Viswanathan wrote: >> Not listed here: https://oca.opensource.oracle.com/?ojr=contributors > > Yes, Vamsi is part of Intel Java team. He also has the author status (https://openjdk.org/census#sparasa). > @sviswa7 I am asking about the copyright holder "Serge Sans Paille". Hi David (@dholmes-ora), Sorry for the late reply as I was on vacation last week. The SIMD sort for Java/OpenJDK is based on Intel's [x86-simd-sort](https://github.com/intel/x86-simd-sort) library. Serge Sans Paille (@serge-sans-paille) was one of the contributors to the x86-simd-sort. That is the reason his name is listed in the copyright notice. Thanks, Vamsi ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16534#discussion_r1408380175 From naoto at openjdk.org Tue Nov 28 20:30:07 2023 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 28 Nov 2023 20:30:07 GMT Subject: RFR: 8320918: Fix errors in the built-in Catalog implementation In-Reply-To: References: Message-ID: On Tue, 28 Nov 2023 20:11:42 GMT, Joe Wang wrote: > Fix errors in the built-in Catalog implementation, specifically: > -- incorrect case in the property name as defined in the CSR (https://bugs.openjdk.org/browse/JDK-8306056) > -- tests needed to be updated accordingly > -- jaxp.properties updated with documentation for the new properties > > Tests: passed after the update. src/java.xml/share/conf/jaxp.properties line 52: > 50: # For example, the FILES property in CatalogFeatures has an associated system > 51: # property called javax.xml.catalog.files. An entry for the FILES property in the > 52: # configuration file would therefore use javax.xml.catalog.files as the key, that Should these lines be changed as well? Applies to the other locations too. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16862#discussion_r1408381325 From alanb at openjdk.org Tue Nov 28 20:33:06 2023 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 28 Nov 2023 20:33:06 GMT Subject: RFR: 8310994: Add JFR event for selection operations In-Reply-To: References: Message-ID: On Tue, 28 Nov 2023 18:21:33 GMT, Markus Gr?nlund wrote: > It would be good to integrate this quite soon because it would release the reliance on ASM and let us only use the new ClassFile API. Now, we need to load both implementations, leading to startup regression. This is a new event so there isn't existing instrumentation to remove. I think this will need changes before it can be integrated as there are naming issues and needs the timeout to at least be able to distinguish immediately selection operations from others. There are quite a few use-cases to work through on how it might be used too. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16710#issuecomment-1830675271 From alanb at openjdk.org Tue Nov 28 20:37:10 2023 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 28 Nov 2023 20:37:10 GMT Subject: RFR: 8320665: update jdk_core at test/jdk/TEST.groups [v2] In-Reply-To: References: Message-ID: On Tue, 28 Nov 2023 18:26:37 GMT, Ivan ?ipka wrote: >> @bwhuang-us @mahendrachhipa > > Ivan ?ipka has updated the pull request incrementally with one additional commit since the last revision: > > added jdk_core_no_security as additional group defintion, reverting old base definition test/jdk/TEST.groups line 647: > 645: jdk_core_no_security = \ > 646: :jdk_core \ > 647: -:jdk_security Good, that is a lot more maintainable. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16796#discussion_r1408388935 From mgronlun at openjdk.org Tue Nov 28 20:39:08 2023 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Tue, 28 Nov 2023 20:39:08 GMT Subject: RFR: 8310994: Add JFR event for selection operations In-Reply-To: References: Message-ID: On Tue, 28 Nov 2023 20:30:52 GMT, Alan Bateman wrote: > > It would be good to integrate this quite soon because it would release the reliance on ASM and let us only use the new ClassFile API. Now, we need to load both implementations, leading to startup regression. > > This is a new event so there isn't existing instrumentation to remove. I think this will need changes before it can be integrated as there are naming issues and needs the timeout to at least be able to distinguish immediately selection operations from others. There are quite a few use-cases to work through on how it might be used too. Isn't this a replacement for the existing instrumentation? If these are new events I am sorry. What is keeping us from removing ASM in that case? ------------- PR Comment: https://git.openjdk.org/jdk/pull/16710#issuecomment-1830684595 From alanb at openjdk.org Tue Nov 28 20:41:08 2023 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 28 Nov 2023 20:41:08 GMT Subject: RFR: 8320798: Console read line with zero out should zero out underlying buffer [v2] In-Reply-To: References: Message-ID: <8iNMIOZuwP6-W26OQIuvoTWRb6wNp9FBPBZaxGuAIqE=.b36c2264-ab0a-4c40-adec-e9b1c1d6dfc3@github.com> On Tue, 28 Nov 2023 19:30:34 GMT, Naoto Sato wrote: >> It is best practice to zero out the underlying buffer after use. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > corrected fromIndex Marked as reviewed by alanb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/16861#pullrequestreview-1753892317 From alanb at openjdk.org Tue Nov 28 20:41:10 2023 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 28 Nov 2023 20:41:10 GMT Subject: RFR: 8320798: Console read line with zero out should zero out underlying buffer [v2] In-Reply-To: References: Message-ID: On Tue, 28 Nov 2023 19:27:45 GMT, Naoto Sato wrote: >> src/java.base/share/classes/sun/nio/cs/StreamDecoder.java line 294: >> >>> 292: private void lockedFillZeroToPosition() throws IOException { >>> 293: ensureOpen(); >>> 294: Arrays.fill(bb.array(), 0, bb.arrayOffset() + bb.position(), (byte)0); >> >> Should the `from` parameter be zero or `bb.arrayOffset()`? > > Right. Fixed. The buffer is allocated in StreamDecoder so I assume the array offset is 0 anyway, so I think they will be the same. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16861#discussion_r1408394249 From naoto at openjdk.org Tue Nov 28 20:43:06 2023 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 28 Nov 2023 20:43:06 GMT Subject: RFR: JDK-8210410: Refactor java.util.Currency:i18n shell tests to plain java tests [v2] In-Reply-To: References: Message-ID: On Tue, 28 Nov 2023 18:28:37 GMT, Justin Lu wrote: >> Please review this PR which converts the shell test, _java/util/currency/PropertiesTest.sh_ to a normal java test. >> >> This test is a test runner that launches test methods from _PropertiesTest.java_. It tests both the ways to supersede the default currencies, that is, either using a custom properties file under the lib directory, or setting the path to a custom properties file via the system property. > > Justin Lu has updated the pull request incrementally with one additional commit since the last revision: > > cleanup + naming Looks good. Please retain the original copyright year (2007) with the refactored launcher file. ------------- Marked as reviewed by naoto (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16787#pullrequestreview-1753893945 From alanb at openjdk.org Tue Nov 28 20:44:09 2023 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 28 Nov 2023 20:44:09 GMT Subject: RFR: 8316141: Improve CEN header validation checking In-Reply-To: References: Message-ID: On Tue, 28 Nov 2023 20:06:25 GMT, Lance Andersen wrote: > Given where we are in the JDK 22 cycle, going to hold off on finalizing the PR until we fork for JDK 23 and look to move this forward early on allowing for additional time to bake Tightening validation always comes with risk. Doing it early in JDK 23 to allow time for course correction if needed seems a good plan. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16570#issuecomment-1830700871 From joehw at openjdk.org Tue Nov 28 20:45:20 2023 From: joehw at openjdk.org (Joe Wang) Date: Tue, 28 Nov 2023 20:45:20 GMT Subject: RFR: 8320918: Fix errors in the built-in Catalog implementation [v2] In-Reply-To: References: Message-ID: > Fix errors in the built-in Catalog implementation, specifically: > -- incorrect case in the property name as defined in the CSR (https://bugs.openjdk.org/browse/JDK-8306056) > -- tests needed to be updated accordingly > -- jaxp.properties updated with documentation for the new properties > > Tests: passed after the update. Joe Wang has updated the pull request incrementally with one additional commit since the last revision: fix typo in the comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16862/files - new: https://git.openjdk.org/jdk/pull/16862/files/e3908863..af0c7438 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16862&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16862&range=00-01 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/16862.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16862/head:pull/16862 PR: https://git.openjdk.org/jdk/pull/16862 From joehw at openjdk.org Tue Nov 28 20:45:21 2023 From: joehw at openjdk.org (Joe Wang) Date: Tue, 28 Nov 2023 20:45:21 GMT Subject: RFR: 8320918: Fix errors in the built-in Catalog implementation [v2] In-Reply-To: References: Message-ID: On Tue, 28 Nov 2023 20:27:32 GMT, Naoto Sato wrote: >> Joe Wang has updated the pull request incrementally with one additional commit since the last revision: >> >> fix typo in the comments > > src/java.xml/share/conf/jaxp.properties line 52: > >> 50: # For example, the FILES property in CatalogFeatures has an associated system >> 51: # property called javax.xml.catalog.files. An entry for the FILES property in the >> 52: # configuration file would therefore use javax.xml.catalog.files as the key, that > > Should these lines be changed as well? Applies to the other locations too. Fixed, thanks! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16862#discussion_r1408397256 From alanb at openjdk.org Tue Nov 28 20:46:10 2023 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 28 Nov 2023 20:46:10 GMT Subject: RFR: 8310994: Add JFR event for selection operations In-Reply-To: References: Message-ID: <9uNVx-mdtv6JcAZwi55bpD5gyV-EnPUPus3AIf0Harc=.e97702d3-ee3a-48d9-b2a8-f93c7d7fcf87@github.com> On Tue, 28 Nov 2023 20:34:34 GMT, Markus Gr?nlund wrote: > Isn't this a replacement for the existing instrumentation? If these are new events I am sorry. It's a new event. > What is keeping us from removing ASM in that case? I think file I/O, there is still instrumentation used for FileInputStream, FileOutputStream, RandomAccessFile and nio.FileChannel. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16710#issuecomment-1830703533 From duke at openjdk.org Tue Nov 28 20:51:31 2023 From: duke at openjdk.org (Srinivas Vamsi Parasa) Date: Tue, 28 Nov 2023 20:51:31 GMT Subject: RFR: 8319577: x86_64 AVX2 intrinsics for Arrays.sort methods (int, float arrays) [v3] In-Reply-To: References: Message-ID: > The goal is to develop faster sort routines for x86_64 CPUs by taking advantage of AVX2 instructions. This enhancement provides an order of magnitude speedup for Arrays.sort() using int, long, float and double arrays. > > For serial sort on random data, this PR shows upto ~7.5x improvement for 32-bit datatypes (int, float) on Intel TigerLake machine as shown in the performance data below. > > For parallel sort on random data, this PR shows upto ~3.4x for 32-bit datatypes (int, float) as shown below. > > **Note:** This PR also improves the performance of AVX512 sort by upto 35%. > > xmlns:o="urn:schemas-microsoft-com:office:office" > xmlns:x="urn:schemas-microsoft-com:office:excel" > xmlns="http://www.w3.org/TR/REC-html40"> > > > > > > href="file:///C:/Users/sparasa/AppData/Local/Temp/msohtmlclip1/01/clip.htm"> > href="file:///C:/Users/sparasa/AppData/Local/Temp/msohtmlclip1/01/clip_filelist.xml"> > > > > > > > > > Benchmark (Serial Sort) | Size | Baseline (us/op) | AVX2 (us/op) | Speedup > -- | -- | -- | -- | -- > ArraysSort.intSort | 10 | 0.034 | 0.029 | 1.2 > ArraysSort.intSort | 25 | 0.088 | 0.044 | 2.0 > ArraysSort.intSort | 50 | 0.239 | 0.159 | 1.5 > ArraysSort.intSort | 75 | 0.417 | 0.27 | 1.5 > ArraysSort.intSort | 100 | 0.572 | 0.265 | 2.2 > ArraysSort.intSort | 1000 | 10.098 | 4.282 | 2.4 > ArraysSort.intSort | 10000 | 330.065 | 43.383 | 7.6 > ArraysSort.intSort | 100000 | 4099.527 | 778.943 | 5.3 > ArraysSort.intSort | 1000000 | 49150.16 | 9634.335 | 5.1 > ArraysSort.floatSort | 10 | 0.045 | 0.043 | 1.0 > ArraysSort.floatSort | 25 | 0.105 | 0.073 | 1.4 > ArraysSort.floatSort | 50 | 0.278 | 0.216 | 1.3 > ArraysSort.floatSort | 75 | 0.476 | 0.241 | 2.0 > ArraysSort.floatSort | 100 | 0.583 | 0.313 | 1.9 > ArraysSort.floatSort | 1000 | 10.182 | 4.329 | 2.4 > ArraysSort.floatSort | 10000 | 323.136 | 57.175 | 5.7 > ArraysSort.floatSort | 100000 | 4299.519 | 862.63 | 5.0 > ArraysSort.floatSort | 1000000 | 50889.4 | 10972.19 | 4.6 > > > > > > xmlns:o="urn:schemas-microsoft-com:office:office" > xmlns:x="urn:schemas-microsoft-com:office:excel" > xmlns="http://www.w3.org/TR/REC-html40"> > > > > > > href="file:///C:/Users/... Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision: update the code to check for supported simd sort cpus ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16534/files - new: https://git.openjdk.org/jdk/pull/16534/files/08307b6a..9a3b86a3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16534&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16534&range=01-02 Stats: 42 lines in 7 files changed: 38 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/16534.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16534/head:pull/16534 PR: https://git.openjdk.org/jdk/pull/16534 From duke at openjdk.org Tue Nov 28 20:51:36 2023 From: duke at openjdk.org (Srinivas Vamsi Parasa) Date: Tue, 28 Nov 2023 20:51:36 GMT Subject: RFR: 8319577: x86_64 AVX2 intrinsics for Arrays.sort methods (int, float arrays) [v2] In-Reply-To: References: <4XHLjTI5l8tGKCU8_iE53H7EY9-0EjR1gbbFWF57rfI=.8b7585bd-f829-4c3b-81ca-ddc8301c2179@github.com> Message-ID: On Tue, 28 Nov 2023 12:23:00 GMT, Jatin Bhateja wrote: >> Srinivas Vamsi Parasa has updated the pull request with a new target base 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: >> >> - Disable AVX2 sort for 64-bit types >> - Merge branch 'master' of https://git.openjdk.java.net/jdk into simdsort >> - fix jcheck failures due to windows encoding >> - fix carriage return and change insertion sort thresholds >> - fix formatting and white spaces >> - cleanup unused code >> - fix insertion sort thresholds >> - add insertion sort >> - fix headers >> - revert to xss-common-qsort >> - ... and 1 more: https://git.openjdk.org/jdk/compare/ae4d7f96...08307b6a > > src/hotspot/share/opto/library_call.cpp line 5391: > >> 5389: BasicType bt = elem_type->basic_type(); >> 5390: // Disable the intrinsic for 64-bit types with AVX2 >> 5391: if ((bt == T_LONG || bt == T_DOUBLE) && UseAVX == 2) { > > You can directly use convenience routine _is_double_word_type_ Thanks Jatin for the suggestion. Please see your suggestion incorporated in the new code upstreamed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16534#discussion_r1408403056 From jlu at openjdk.org Tue Nov 28 20:52:25 2023 From: jlu at openjdk.org (Justin Lu) Date: Tue, 28 Nov 2023 20:52:25 GMT Subject: RFR: JDK-8210410: Refactor java.util.Currency:i18n shell tests to plain java tests [v3] In-Reply-To: References: Message-ID: > Please review this PR which converts the shell test, _java/util/currency/PropertiesTest.sh_ to a normal java test. > > This test is a test runner that launches test methods from _PropertiesTest.java_. It tests both the ways to supersede the default currencies, that is, either using a custom properties file under the lib directory, or setting the path to a custom properties file via the system property. Justin Lu has updated the pull request incrementally with one additional commit since the last revision: retain original copyright year ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16787/files - new: https://git.openjdk.org/jdk/pull/16787/files/efc6da98..105a6755 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16787&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16787&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/16787.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16787/head:pull/16787 PR: https://git.openjdk.org/jdk/pull/16787 From lancea at openjdk.org Tue Nov 28 20:52:25 2023 From: lancea at openjdk.org (Lance Andersen) Date: Tue, 28 Nov 2023 20:52:25 GMT Subject: RFR: JDK-8210410: Refactor java.util.Currency:i18n shell tests to plain java tests [v3] In-Reply-To: References: Message-ID: On Tue, 28 Nov 2023 20:49:38 GMT, Justin Lu wrote: >> Please review this PR which converts the shell test, _java/util/currency/PropertiesTest.sh_ to a normal java test. >> >> This test is a test runner that launches test methods from _PropertiesTest.java_. It tests both the ways to supersede the default currencies, that is, either using a custom properties file under the lib directory, or setting the path to a custom properties file via the system property. > > Justin Lu has updated the pull request incrementally with one additional commit since the last revision: > > retain original copyright year Marked as reviewed by lancea (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/16787#pullrequestreview-1753905849 From duke at openjdk.org Tue Nov 28 20:55:06 2023 From: duke at openjdk.org (Eirik Bjorsnos) Date: Tue, 28 Nov 2023 20:55:06 GMT Subject: RFR: 8316141: Improve CEN header validation checking In-Reply-To: References: Message-ID: On Tue, 28 Nov 2023 20:41:21 GMT, Alan Bateman wrote: > Doing it early in JDK 23 to allow time for course correction if needed seems a good plan. Another benefit is that if we should decide to validate LOC headers similarly in `ZipInputStream`, delaying until 23 will allow us to introduce these very similar changes in the same release. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16570#issuecomment-1830715882 From duke at openjdk.org Tue Nov 28 20:57:09 2023 From: duke at openjdk.org (Srinivas Vamsi Parasa) Date: Tue, 28 Nov 2023 20:57:09 GMT Subject: RFR: 8319577: x86_64 AVX2 intrinsics for Arrays.sort methods (int, float arrays) [v2] In-Reply-To: References: <4XHLjTI5l8tGKCU8_iE53H7EY9-0EjR1gbbFWF57rfI=.8b7585bd-f829-4c3b-81ca-ddc8301c2179@github.com> Message-ID: On Tue, 28 Nov 2023 00:08:00 GMT, Srinivas Vamsi Parasa wrote: >> src/hotspot/share/opto/library_call.cpp line 5391: >> >>> 5389: BasicType bt = elem_type->basic_type(); >>> 5390: // Disable the intrinsic for 64-bit types with AVX2 >>> 5391: if ((bt == T_LONG || bt == T_DOUBLE) && UseAVX == 2) { >> >> UseAVX is platform specific and cannot be used in library_call.cpp. > > Thanks Sandhya, will fix this issue. Thanks Sandhya for suggesting the change to use supports_simd_sort(BasicType bt). Please see the updated code upstreamed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16534#discussion_r1408407158 From duke at openjdk.org Tue Nov 28 20:57:13 2023 From: duke at openjdk.org (Srinivas Vamsi Parasa) Date: Tue, 28 Nov 2023 20:57:13 GMT Subject: RFR: 8319577: x86_64 AVX2 intrinsics for Arrays.sort methods (int, float arrays) [v2] In-Reply-To: References: <4XHLjTI5l8tGKCU8_iE53H7EY9-0EjR1gbbFWF57rfI=.8b7585bd-f829-4c3b-81ca-ddc8301c2179@github.com> Message-ID: On Tue, 28 Nov 2023 12:25:57 GMT, Jatin Bhateja wrote: >> src/hotspot/share/opto/library_call.cpp line 5448: >> >>> 5446: BasicType bt = elem_type->basic_type(); >>> 5447: // Disable the intrinsic for 64-bit types with AVX2 >>> 5448: if ((bt == T_LONG || bt == T_DOUBLE) && UseAVX == 2) { >> >> Same as above. > > You can move this entire check to platform specific matcher file (matcher_x86.hpp) Please see the checks moved to matcher_x86.hpp. Was suggested the same yesterday. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16534#discussion_r1408409059 From almatvee at openjdk.org Tue Nov 28 21:14:04 2023 From: almatvee at openjdk.org (Alexander Matveev) Date: Tue, 28 Nov 2023 21:14:04 GMT Subject: RFR: 8320858: Move jpackage tests to tier3 In-Reply-To: References: Message-ID: On Tue, 28 Nov 2023 08:51:17 GMT, Alan Bateman wrote: > Update the jtreg test group configuration in the jdk test tree so that the jpackage tests run in tier3 rather than tier2. > > At this time, the jpackage tests run in jdk:tier2, more specifically jdk:tier2_part2 as part of the core_tools test group. The jpackage tests take a significant amount of time on some platforms (on macOS and Windows in particular). The changes here remove tools/jpackage from core_tools (it's not a core tool anyway) and adds the tests to tier3. In the future then maybe tier3 can be split up if needed. Marked as reviewed by almatvee (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/16841#pullrequestreview-1753956164 From duke at openjdk.org Tue Nov 28 21:22:16 2023 From: duke at openjdk.org (Vladimir Yaroslavskiy) Date: Tue, 28 Nov 2023 21:22:16 GMT Subject: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort) [v11] In-Reply-To: References: <918oCEfFu2JweXfV-afD1l_AGDDuc7dJwAxip-Ze6ZI=.8d5e9692-23db-47e4-9586-99e53b9cfbb6@github.com> Message-ID: On Tue, 28 Nov 2023 00:35:48 GMT, Srinivas Vamsi Parasa wrote: >> Laurent Bourg?s has updated the pull request incrementally with one additional commit since the last revision: >> >> add @SuppressWarnings (serial) > > xmlns:o="urn:schemas-microsoft-com:office:office" > xmlns:x="urn:schemas-microsoft-com:office:excel" > xmlns="http://www.w3.org/TR/REC-html40"> > > > > > > href="file:///C:/Users/sparasa/AppData/Local/Temp/msohtmlclip1/01/clip.htm"> > href="file:///C:/Users/sparasa/AppData/Local/Temp/msohtmlclip1/01/clip_filelist.xml"> > > > > > > > > > Benchmark (us/op) | Builder | (size) | Stock JDK (+ AVX512 sort) | DPQS_r01 (+ AVX512 sort) | Speedup > -- | -- | -- | -- | -- | -- > ArraysSort.Int.testSort | RANDOM | 600 | 2.256 | 1.713 | 1.32 > ArraysSort.Int.testSort | RANDOM | 9000 | 41.457 | 38.316 | 1.08 > ArraysSort.Int.testSort | RANDOM | 20000 | 98.448 | 86.376 | 1.14 > ArraysSort.Int.testSort | RANDOM | 400000 | 2820.939 | 2792.333 | 1.01 > ArraysSort.Int.testSort | RANDOM | 3000000 | 23426.411 | 23711.885 | 0.99 > ArraysSort.Int.testSort | REPEATED | 600 | 1.032 | 0.859 | 1.20 > ArraysSort.Int.testSort | REPEATED | 9000 | 5.114 | 5.014 | 1.02 > ArraysSort.Int.testSort | REPEATED | 20000 | 10.3 | 9.532 | 1.08 > ArraysSort.Int.testSort | REPEATED | 400000 | 210.742 | 235.281 | 0.90 > ArraysSort.Int.testSort | REPEATED | 3000000 | 1948.589 | 1955.258 | 1.00 > ArraysSort.Int.testSort | STAGGER | 600 | 2.125 | 2.157 | 0.99 > ArraysSort.Int.testSort | STAGGER | 9000 | 29.86 | 29.931 | 1.00 > ArraysSort.Int.testSort | STAGGER | 20000 | 67.096 | 66.543 | 1.01 > ArraysSort.Int.testSort | STAGGER | 400000 | 1247.53 | 1224.999 | 1.02 > ArraysSort.Int.testSort | STAGGER | 3000000 | 9435.404 | 9495.189 | 0.99 > ArraysSort.Int.testSort | SHUFFLE | 600 | 2.701 | 1.64 | 1.65 > ArraysSort.Int.testSort | SHUFFLE | 9000 | 38.976 | 34.201 | 1.14 > ArraysSort.Int.testSort | SHUFFLE | 20000 | 96.399 | 79.616 | 1.21 > ArraysSort.Int.testSort | SHUFFLE | 400000 | 2566.338 | 2436.271 | 1.05 > ArraysSort.Int.testSort | SHUFFLE | 3000000 | 20835.935 | 20071.12 | 1.04 > > > > > > Hello Vamsi (@vamsi-parasa), Thank you for details! I will analyze and return with the next variants to be benchmarked to find the best DPQS. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13568#issuecomment-1830763949 From mchung at openjdk.org Tue Nov 28 21:36:08 2023 From: mchung at openjdk.org (Mandy Chung) Date: Tue, 28 Nov 2023 21:36:08 GMT Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged modules being present [v8] In-Reply-To: References: <3DpzMArCkz5ehvgoid5DPvhy6SQmw9mkKzOBqj6vItU=.54099d82-259c-48ca-8c61-e7b783640ed8@github.com> Message-ID: <5tTzzcFEHrkWgUGP8LLco2ErVYSBaI7hLuEkr8vgElY=.4ae79877-cef8-4985-bb6a-22c579284fcf@github.com> On Tue, 28 Nov 2023 19:57:03 GMT, Severin Gehwolf wrote: > --verbose should tell you exactly which command line options would need to be added to arrive at the same end-result image, but with packaged modules? I.e. do some tracking of cli options when jlink runs? Yes that's the idea. It seems the simplest for users to understand and for testing (to compare with the image created with packaged modules). ------------- PR Comment: https://git.openjdk.org/jdk/pull/14787#issuecomment-1830783746 From joehw at openjdk.org Tue Nov 28 21:36:20 2023 From: joehw at openjdk.org (Joe Wang) Date: Tue, 28 Nov 2023 21:36:20 GMT Subject: RFR: 8320918: Fix errors in the built-in Catalog implementation [v3] In-Reply-To: References: Message-ID: > Fix errors in the built-in Catalog implementation, specifically: > -- incorrect case in the property name as defined in the CSR (https://bugs.openjdk.org/browse/JDK-8306056) > -- tests needed to be updated accordingly > -- jaxp.properties updated with documentation for the new properties > > Tests: passed after the update. Joe Wang has updated the pull request incrementally with one additional commit since the last revision: the example now uses RESOLVE instead of FILES. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16862/files - new: https://git.openjdk.org/jdk/pull/16862/files/af0c7438..de3b7c24 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16862&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16862&range=01-02 Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/16862.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16862/head:pull/16862 PR: https://git.openjdk.org/jdk/pull/16862 From naoto at openjdk.org Tue Nov 28 21:40:05 2023 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 28 Nov 2023 21:40:05 GMT Subject: RFR: 8320918: Fix errors in the built-in Catalog implementation [v3] In-Reply-To: References: Message-ID: On Tue, 28 Nov 2023 21:36:20 GMT, Joe Wang wrote: >> Fix errors in the built-in Catalog implementation, specifically: >> -- incorrect case in the property name as defined in the CSR (https://bugs.openjdk.org/browse/JDK-8306056) >> -- tests needed to be updated accordingly >> -- jaxp.properties updated with documentation for the new properties >> >> Tests: passed after the update. > > Joe Wang has updated the pull request incrementally with one additional commit since the last revision: > > the example now uses RESOLVE instead of FILES. Marked as reviewed by naoto (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/16862#pullrequestreview-1753994121 From duke at openjdk.org Tue Nov 28 22:13:08 2023 From: duke at openjdk.org (fabioromano1) Date: Tue, 28 Nov 2023 22:13:08 GMT Subject: RFR: 8320759: Creation of random BigIntegers can be made faster [v2] In-Reply-To: References: Message-ID: On Tue, 28 Nov 2023 19:31:14 GMT, Brian Burkhalter wrote: >> Do you have any actual benchmark measurements that you could share? > >> @bplb I have not yet made benchmark measurements, but I can produce them. > > @fabioromano1 I think it would be good to measure and report the benefit, if you don't mind. @bplb I have done some tests, these are the results: Older implementation: JVM: Java HotSpot(TM) 64-Bit Server VM 21.0.1+12-LTS-29 OS: Linux 5.5.0-kali2-amd64 Test 1: numBits=1, execution time=PT0.000699157S numBits=2, execution time=PT0.000023952S numBits=4, execution time=PT0.000009588S numBits=8, execution time=PT0.000008189S numBits=16, execution time=PT0.000010701S numBits=32, execution time=PT0.000011743S numBits=64, execution time=PT0.000018907S numBits=128, execution time=PT0.000021929S numBits=256, execution time=PT0.000045141S numBits=512, execution time=PT0.000069789S numBits=1024, execution time=PT0.000438628S numBits=2048, execution time=PT0.000619775S numBits=4096, execution time=PT0.007964754S numBits=8192, execution time=PT0.00092404S numBits=16384, execution time=PT0.010798554S numBits=32768, execution time=PT0.009661368S numBits=65536, execution time=PT0.015757106S numBits=131072, execution time=PT0.043498597S numBits=262144, execution time=PT0.049676326S numBits=524288, execution time=PT0.01529584S numBits=1048576, execution time=PT0.002818203S numBits=2097152, execution time=PT0.013192936S numBits=4194304, execution time=PT0.026337619S numBits=8388608, execution time=PT0.059158393S numBits=16777216, execution time=PT0.093313405S numBits=33554432, execution time=PT0.123457485S numBits=67108864, execution time=PT0.089361357S numBits=134217728, execution time=PT0.219089575S numBits=268435456, execution time=PT0.683150564S numBits=536870912, execution time=PT1.580409429S numBits=1073741824, execution time=PT2.517073472S Test 2: numBits=1, execution time=PT0.000927963S numBits=2, execution time=PT0.000081967S numBits=4, execution time=PT0.000020935S numBits=8, execution time=PT0.000016594S numBits=16, execution time=PT0.000018655S numBits=32, execution time=PT0.00001965S numBits=64, execution time=PT0.000015891S numBits=128, execution time=PT0.000035207S numBits=256, execution time=PT0.000047545S numBits=512, execution time=PT0.00010469S numBits=1024, execution time=PT0.000148356S numBits=2048, execution time=PT0.000400422S numBits=4096, execution time=PT0.000678288S numBits=8192, execution time=PT0.001286059S numBits=16384, execution time=PT0.0033047S numBits=32768, execution time=PT0.003497816S numBits=65536, execution time=PT0.008359785S numBits=131072, execution time=PT0.02874995S numBits=262144, execution time=PT0.033667068S numBits=524288, execution time=PT0.001652314S numBits=1048576, execution time=PT0.003623258S numBits=2097152, execution time=PT0.004878528S numBits=4194304, execution time=PT0.012982859S numBits=8388608, execution time=PT0.024819597S numBits=16777216, execution time=PT0.040988123S numBits=33554432, execution time=PT0.117394044S numBits=67108864, execution time=PT0.155300788S numBits=134217728, execution time=PT0.312046375S numBits=268435456, execution time=PT0.489544424S numBits=536870912, execution time=PT0.648922766S numBits=1073741824, execution time=PT1.694348228S Newer implementation: JVM: OpenJDK 64-Bit Server VM 22-internal-adhoc.kali.jdk OS: Linux 5.5.0-kali2-amd64 Test 1: numBits=1, execution time=PT0.000931361S numBits=2, execution time=PT0.000009131S numBits=4, execution time=PT0.000005598S numBits=8, execution time=PT0.000005079S numBits=16, execution time=PT0.000005173S numBits=32, execution time=PT0.00000528S numBits=64, execution time=PT0.000007437S numBits=128, execution time=PT0.000008283S numBits=256, execution time=PT0.000012538S numBits=512, execution time=PT0.000020438S numBits=1024, execution time=PT0.000036785S numBits=2048, execution time=PT0.000185241S numBits=4096, execution time=PT0.000197063S numBits=8192, execution time=PT0.000223476S numBits=16384, execution time=PT0.000257176S numBits=32768, execution time=PT0.000243897S numBits=65536, execution time=PT0.000510034S numBits=131072, execution time=PT0.00097546S numBits=262144, execution time=PT0.010734387S numBits=524288, execution time=PT0.003521437S numBits=1048576, execution time=PT0.019798445S numBits=2097152, execution time=PT0.002221943S numBits=4194304, execution time=PT0.003967343S numBits=8388608, execution time=PT0.012686879S numBits=16777216, execution time=PT0.020487223S numBits=33554432, execution time=PT0.059377121S numBits=67108864, execution time=PT0.057220115S numBits=134217728, execution time=PT0.116699493S numBits=268435456, execution time=PT0.259903987S numBits=536870912, execution time=PT0.389077171S numBits=1073741824, execution time=PT0.700334039S Test 2: numBits=1, execution time=PT0.000784538S numBits=2, execution time=PT0.000011703S numBits=4, execution time=PT0.000008531S numBits=8, execution time=PT0.000005882S numBits=16, execution time=PT0.00000598S numBits=32, execution time=PT0.00000988S numBits=64, execution time=PT0.000009407S numBits=128, execution time=PT0.00001319S numBits=256, execution time=PT0.000013505S numBits=512, execution time=PT0.000021383S numBits=1024, execution time=PT0.000058492S numBits=2048, execution time=PT0.000482897S numBits=4096, execution time=PT0.001244931S numBits=8192, execution time=PT0.001768842S numBits=16384, execution time=PT0.000231889S numBits=32768, execution time=PT0.001336978S numBits=65536, execution time=PT0.000591514S numBits=131072, execution time=PT0.005367744S numBits=262144, execution time=PT0.002301247S numBits=524288, execution time=PT0.006544409S numBits=1048576, execution time=PT0.010711628S numBits=2097152, execution time=PT0.012067186S numBits=4194304, execution time=PT0.002592803S numBits=8388608, execution time=PT0.005091683S numBits=16777216, execution time=PT0.023796749S numBits=33554432, execution time=PT0.020254963S numBits=67108864, execution time=PT0.055511959S numBits=134217728, execution time=PT0.0909186S numBits=268435456, execution time=PT0.158207744S numBits=536870912, execution time=PT0.422297073S numBits=1073741824, execution time=PT0.615943347S ------------- PR Comment: https://git.openjdk.org/jdk/pull/16817#issuecomment-1830839416 From tprinzing at openjdk.org Tue Nov 28 22:15:06 2023 From: tprinzing at openjdk.org (Tim Prinzing) Date: Tue, 28 Nov 2023 22:15:06 GMT Subject: RFR: 8310994: Add JFR event for selection operations In-Reply-To: References: Message-ID: <1DFRyaMd3eg3u2dA4DoIMaCUFuL_3jewY9hXusCtE9o=.7da770e9-7d1a-451c-b759-abf9fb2ed5cc@github.com> On Fri, 17 Nov 2023 16:22:55 GMT, Tim Prinzing wrote: > Added mirror event with static methods: jdk.internal.event.SelectionEvent that provides the duration of select calls and the count of how many keys are available. > > Emit the event from SelectorImpl::lockAndDoSelect > > Test at jdk.jfr.event.io.TestSelectionEvents Yes, in JDKEvents this is the list: private static final Class[] instrumentationClasses = new Class[] { FileInputStreamInstrumentor.class, FileOutputStreamInstrumentor.class, RandomAccessFileInstrumentor.class, FileChannelImplInstrumentor.class }; On Tue, Nov 28, 2023 at 2:43?PM Alan Bateman ***@***.***> wrote: > Isn't this a replacement for the existing instrumentation? If these are > new events I am sorry. > > It's a new event. > > What is keeping us from removing ASM in that case? > > I think file I/O, there is still instrumentation used for FileInputStream, > FileOutputStream, RandomAccessFile and nio.FileChannel. > > ? > Reply to this email directly, view it on GitHub > , or > unsubscribe > > . > You are receiving this because you were mentioned.Message ID: > ***@***.***> > ------------- PR Comment: https://git.openjdk.org/jdk/pull/16710#issuecomment-1830842223 From duke at openjdk.org Tue Nov 28 22:19:06 2023 From: duke at openjdk.org (fabioromano1) Date: Tue, 28 Nov 2023 22:19:06 GMT Subject: RFR: 8320759: Creation of random BigIntegers can be made faster [v2] In-Reply-To: References: Message-ID: <9k4S0i1fTeFbJumlmellLx8VRQ5rFHxrsRJquu-b7T8=.e5c4279f-a7a6-40a3-b8c6-44cf3012c73a@github.com> On Tue, 28 Nov 2023 19:31:14 GMT, Brian Burkhalter wrote: >> Do you have any actual benchmark measurements that you could share? > >> @bplb I have not yet made benchmark measurements, but I can produce them. > > @fabioromano1 I think it would be good to measure and report the benefit, if you don't mind. @bplb As you might expect, the newer implementation takes about half the time, since it avoids copying the random byte array into the magnitude array. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16817#issuecomment-1830846472 From mbalao at openjdk.org Tue Nov 28 22:21:40 2023 From: mbalao at openjdk.org (Martin Balao) Date: Tue, 28 Nov 2023 22:21:40 GMT Subject: RFR: 8315487: Security Providers Filter [v2] In-Reply-To: References: Message-ID: <0QDh7oONGo90Kx11J-jlUsgq12JJ6SP989qvpdVN6jc=.7371792b-26e6-4270-9668-aa3ef7f608a8@github.com> > In addition to the goals, scope, motivation, specification and requirement notes in [JDK-8315487](https://bugs.openjdk.org/browse/JDK-8315487), we would like to describe the most relevant decisions taken during the implementation of this enhancement. These notes are organized by feature, may encompass more than one file or code segment, and are aimed to provide a high-level view of this PR. > > ## ProvidersFilter > > ### Filter construction (parser) > > The providers filter is constructed from a string value, taken from either a system or a security property with name "jdk.security.providers.filter". This process occurs at sun.security.jca.ProvidersFilter class ?simply referred as ProvidersFilter onward? static initialization. Thus, changes to the filter's overridable property are not effective afterwards and no assumptions should be made regarding when this class gets initialized. > > The filter's string value is processed with a custom parser of order 'n', being 'n' the number of characters. The parser, represented by the ProvidersFilter.Parser class, can be characterized as a Deterministic Finite Automaton (DFA). The ProvidersFilter.Parser::parse method is the starting point to get characters from the filter's string value and generate state transitions in the parser's internal state-machine. See ProvidersFilter.Parser::nextState for more details about the parser's states and both valid and invalid transitions. The ParsingState enum defines valid parser states and Transition the reasons to move between states. If a filter string cannot be parsed, a ProvidersFilter.ParserException exception is thrown, and turned into an unchecked IllegalArgumentException in the ProvidersFilter.Filter constructor. > > While we analyzed ?and even tried, at early stages of the development? the use of regular expressions for filter parsing, we discarded the approach in order to get maximum performance, support a more advanced syntax and have flexibility for further extensions in the future. > > ### Filter (structure and behavior) > > A filter is represented by the ProvidersFilter.Filter class. It consists of an ordered list of rules, returned by the parser, that represents filter patterns from left to right (see the filter syntax for reference). At the end of this list, a match-all and deny rule is added for default behavior. When a service is evaluated against the filter, each filter rule is checked in the ProvidersFilter.Filter::apply method. The rule makes an allow or deny decision if the ser... Martin Balao has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains one additional commit since the last revision: 8315487: Security Providers Filter Co-authored-by: Francisco Ferrari Bihurriet Co-authored-by: Martin Balao ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15539/files - new: https://git.openjdk.org/jdk/pull/15539/files/9b9350b9..ef6eafcf Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15539&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15539&range=00-01 Stats: 853008 lines in 6797 files changed: 202450 ins; 527667 del; 122891 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 iris at openjdk.org Tue Nov 28 22:30:04 2023 From: iris at openjdk.org (Iris Clark) Date: Tue, 28 Nov 2023 22:30:04 GMT Subject: RFR: 8320918: Fix errors in the built-in Catalog implementation [v3] In-Reply-To: References: Message-ID: <4OIM4Hh5BWkkBEXk5XbLlZSe7cAxhBqqHekTHkK0sZk=.090871cd-c057-45c7-85ed-eed55bc4ba68@github.com> On Tue, 28 Nov 2023 21:36:20 GMT, Joe Wang wrote: >> Fix errors in the built-in Catalog implementation, specifically: >> -- incorrect case in the property name as defined in the CSR (https://bugs.openjdk.org/browse/JDK-8306056) >> -- tests needed to be updated accordingly >> -- jaxp.properties updated with documentation for the new properties >> >> Tests: passed after the update. > > Joe Wang has updated the pull request incrementally with one additional commit since the last revision: > > the example now uses RESOLVE instead of FILES. Marked as reviewed by iris (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/16862#pullrequestreview-1754066853 From erikj at openjdk.org Tue Nov 28 23:19:06 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Tue, 28 Nov 2023 23:19:06 GMT Subject: RFR: JDK-8319413: Start of release updates for JDK 23 In-Reply-To: References: Message-ID: On Fri, 3 Nov 2023 23:42:03 GMT, Joe Darcy wrote: > Time to start making preparations for JDK 23. Build changes look good. ------------- Marked as reviewed by erikj (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16505#pullrequestreview-1754115586 From mchung at openjdk.org Tue Nov 28 23:22:22 2023 From: mchung at openjdk.org (Mandy Chung) Date: Tue, 28 Nov 2023 23:22:22 GMT Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged modules being present [v10] In-Reply-To: References: Message-ID: On Fri, 24 Nov 2023 13:25:35 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 one additional commit since the last revision: > > Tighten ModifiedFilesExitTest > > Ensure the error message is reasonable and doesn't include > Exceptions presented to the user. src/jdk.jlink/share/classes/jdk/tools/jlink/internal/TaskHelper.java line 452: > 450: String addOptionsGlob = "glob:" + AddOptionsPlugin.OPTS_FILE; > 451: String saveJlinkOptsGlob = "glob:/jdk.jlink/" + JlinkTask.OPTIONS_RESOURCE; > 452: String additionalPatterns = systemModulesPattern + "," + Suggest to have each plugin to define `Plugin::excludeResourcesPattern` to return a non-empty string if linking from the run-time image. Construct this pattern using the API. src/jdk.jlink/share/classes/jdk/tools/jlink/internal/TaskHelper.java line 475: > 473: // SystemModulesMap class isn't guaranteed to be correct for the > 474: // current module set. > 475: if (systemModulesPlugin == null) { Suggest to fail if system modules plugin does not exist which should not happen. The `disableFastPath` system property was added for testing only. src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/AddRunImageResourcesPlugin.java line 56: > 54: * resources. Needed for the the run-time image based jlink. > 55: */ > 56: public final class AddRunImageResourcesPlugin extends AbstractPlugin { This resource file is generated if jdk.jlink is linked in the resulting image. Maybe this plugin can be named `GenerateJlinkResourcesListPlugin` or `JlinkResourcesListPlugin`??? src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/AddRunImageResourcesPlugin.java line 67: > 65: // RunImageArchive for further processing. > 66: private static final String RESPATH = RESPATH_PREFIX + "%s_resources"; > 67: private static final String JLINK_MOD_NAME = "jdk.jlink"; There are only 2 occurrences of "jdk.jlink". I guess you plan to replace them with the constant variable? src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/AddRunImageResourcesPlugin.java line 102: > 100: Platform targetPlatform = getTargetPlatform(in); > 101: in.transformAndCopy(e -> { ResourcePoolEntry retval = recordAndFilterEntry(e, targetPlatform); > 102: return retval;}, out); Suggestion: in.transformAndCopy(e -> recordAndFilterEntry(e, targetPlatform), out); src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/AddRunImageResourcesPlugin.java line 116: > 114: if (platform == null) { > 115: throw new IllegalStateException("java.base not part of the image?"); > 116: } Can simply use `orElseThrow`. It should not reach here and so it's ok to use InternalError or AssertionError (which is also used in this code). Suggestion: String platform = in.moduleView().findModule("java.base") .map(ResourcePoolModule::targetPlatform) ..orElseThrow(() -> new AssertionError("java.base not found")); src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/AddRunImageResourcesPlugin.java line 121: > 119: > 120: private void addModuleResourceEntries(ResourcePoolBuilder out) { > 121: for (String module: keysInSortedOrder()) { Suggestion: nonClassResEntries.keySet().stream().sorted().forEach(module -> { `keysInSortedOrder` can be removed. src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/AddRunImageResourcesPlugin.java line 126: > 124: if (mResources == null) { > 125: throw new AssertionError("Module listed, but no resources?"); > 126: } Since it is always non-null, this check can be dropped. NPE will be thrown if such bug exists. src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/AddRunImageResourcesPlugin.java line 159: > 157: // Filter internal runtime image based link resource file which we > 158: // create later on-the-fly > 159: return null; why this one is not excluded in the same way as other plugins? src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/AddRunImageResourcesPlugin.java line 184: > 182: } catch (RunImageLinkException e) { > 183: // RunImageArchive::RunImageFile.content() may throw this when > 184: // getting the content(). Propagate this specific exeption. Suggestion: // getting the content(). Propagate this specific exception. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14787#discussion_r1408528283 PR Review Comment: https://git.openjdk.org/jdk/pull/14787#discussion_r1408529843 PR Review Comment: https://git.openjdk.org/jdk/pull/14787#discussion_r1408525936 PR Review Comment: https://git.openjdk.org/jdk/pull/14787#discussion_r1408457185 PR Review Comment: https://git.openjdk.org/jdk/pull/14787#discussion_r1408453177 PR Review Comment: https://git.openjdk.org/jdk/pull/14787#discussion_r1408463342 PR Review Comment: https://git.openjdk.org/jdk/pull/14787#discussion_r1408470820 PR Review Comment: https://git.openjdk.org/jdk/pull/14787#discussion_r1408469356 PR Review Comment: https://git.openjdk.org/jdk/pull/14787#discussion_r1408472411 PR Review Comment: https://git.openjdk.org/jdk/pull/14787#discussion_r1408475136 From jlu at openjdk.org Tue Nov 28 23:27:17 2023 From: jlu at openjdk.org (Justin Lu) Date: Tue, 28 Nov 2023 23:27:17 GMT Subject: RFR: JDK-8319626: Override toString() for ZipFile [v4] In-Reply-To: References: Message-ID: > Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8319982) which overrides and provides an implementation of `toString()` in _java.util.zip.ZipFile_ (and by extension, _java.util.jar.JarFile_). > > This change is primarily to provide a more informative String representation of the two classes rather than the default hexadecimal representation of the hash code. Justin Lu has updated the pull request incrementally with one additional commit since the last revision: shorten wording ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16643/files - new: https://git.openjdk.org/jdk/pull/16643/files/c0b269b4..8c182f07 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16643&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16643&range=02-03 Stats: 5 lines in 1 file changed: 0 ins; 1 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/16643.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16643/head:pull/16643 PR: https://git.openjdk.org/jdk/pull/16643 From duke at openjdk.org Wed Nov 29 00:54:36 2023 From: duke at openjdk.org (Srinivas Vamsi Parasa) Date: Wed, 29 Nov 2023 00:54:36 GMT Subject: RFR: 8319577: x86_64 AVX2 intrinsics for Arrays.sort methods (int, float arrays) [v4] In-Reply-To: References: Message-ID: > The goal is to develop faster sort routines for x86_64 CPUs by taking advantage of AVX2 instructions. This enhancement provides an order of magnitude speedup for Arrays.sort() using int, long, float and double arrays. > > For serial sort on random data, this PR shows upto ~7.5x improvement for 32-bit datatypes (int, float) on Intel TigerLake machine as shown in the performance data below. > > For parallel sort on random data, this PR shows upto ~3.4x for 32-bit datatypes (int, float) as shown below. > > **Note:** This PR also improves the performance of AVX512 sort by upto 35%. > > xmlns:o="urn:schemas-microsoft-com:office:office" > xmlns:x="urn:schemas-microsoft-com:office:excel" > xmlns="http://www.w3.org/TR/REC-html40"> > > > > > > href="file:///C:/Users/sparasa/AppData/Local/Temp/msohtmlclip1/01/clip.htm"> > href="file:///C:/Users/sparasa/AppData/Local/Temp/msohtmlclip1/01/clip_filelist.xml"> > > > > > > > > > Benchmark (Serial Sort) | Size | Baseline (us/op) | AVX2 (us/op) | Speedup > -- | -- | -- | -- | -- > ArraysSort.intSort | 10 | 0.034 | 0.029 | 1.2 > ArraysSort.intSort | 25 | 0.088 | 0.044 | 2.0 > ArraysSort.intSort | 50 | 0.239 | 0.159 | 1.5 > ArraysSort.intSort | 75 | 0.417 | 0.27 | 1.5 > ArraysSort.intSort | 100 | 0.572 | 0.265 | 2.2 > ArraysSort.intSort | 1000 | 10.098 | 4.282 | 2.4 > ArraysSort.intSort | 10000 | 330.065 | 43.383 | 7.6 > ArraysSort.intSort | 100000 | 4099.527 | 778.943 | 5.3 > ArraysSort.intSort | 1000000 | 49150.16 | 9634.335 | 5.1 > ArraysSort.floatSort | 10 | 0.045 | 0.043 | 1.0 > ArraysSort.floatSort | 25 | 0.105 | 0.073 | 1.4 > ArraysSort.floatSort | 50 | 0.278 | 0.216 | 1.3 > ArraysSort.floatSort | 75 | 0.476 | 0.241 | 2.0 > ArraysSort.floatSort | 100 | 0.583 | 0.313 | 1.9 > ArraysSort.floatSort | 1000 | 10.182 | 4.329 | 2.4 > ArraysSort.floatSort | 10000 | 323.136 | 57.175 | 5.7 > ArraysSort.floatSort | 100000 | 4299.519 | 862.63 | 5.0 > ArraysSort.floatSort | 1000000 | 50889.4 | 10972.19 | 4.6 > > > > > > xmlns:o="urn:schemas-microsoft-com:office:office" > xmlns:x="urn:schemas-microsoft-com:office:excel" > xmlns="http://www.w3.org/TR/REC-html40"> > > > > > > href="file:///C:/Users/... Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision: add avoid masked stores operation ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16534/files - new: https://git.openjdk.org/jdk/pull/16534/files/9a3b86a3..893951e8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16534&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16534&range=02-03 Stats: 666 lines in 4 files changed: 311 ins; 349 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/16534.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16534/head:pull/16534 PR: https://git.openjdk.org/jdk/pull/16534 From asemenyuk at openjdk.org Wed Nov 29 01:10:04 2023 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Wed, 29 Nov 2023 01:10:04 GMT Subject: RFR: 8320681: [macos] Test tools/jpackage/macosx/MacAppStoreJlinkOptionsTest.java timed out on macOS In-Reply-To: References: Message-ID: On Tue, 28 Nov 2023 02:24:20 GMT, Alexander Matveev wrote: > Looks like the test timed out due to slow/loaded host. Failure log similar to [JDK-8296489](https://bugs.openjdk.org/browse/JDK-8296489) and [JDK-8298735](https://bugs.openjdk.org/browse/JDK-8298735). Fixed by increasing test timeout. Marked as reviewed by asemenyuk (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/16838#pullrequestreview-1754212378 From sgibbons at openjdk.org Wed Nov 29 01:11:21 2023 From: sgibbons at openjdk.org (Scott Gibbons) Date: Wed, 29 Nov 2023 01:11:21 GMT Subject: RFR: JDK-8320448 Accelerate IndexOf using AVX2 Message-ID: Re-write the IndexOf code without the use of the pcmpestri instruction, only using AVX2 instructions. This change accelerates String.IndexOf on average 1.3x for AVX2. The benchmark numbers: Benchmark Score Latest StringIndexOf.advancedWithMediumSub 343.573 317.934 0.925375393x StringIndexOf.advancedWithShortSub1 1039.081 1053.96 1.014319384x StringIndexOf.advancedWithShortSub2 55.828 110.541 1.980027943x StringIndexOf.constantPattern 9.361 11.906 1.271872663x StringIndexOf.searchCharLongSuccess 4.216 4.218 1.000474383x StringIndexOf.searchCharMediumSuccess 3.133 3.216 1.02649218x StringIndexOf.searchCharShortSuccess 3.76 3.761 1.000265957x StringIndexOf.success 9.186 9.713 1.057369911x StringIndexOf.successBig 14.341 46.343 3.231504079x StringIndexOfChar.latin1_AVX2_String 6220.918 12154.52 1.953814533x StringIndexOfChar.latin1_AVX2_char 5503.556 5540.044 1.006629895x StringIndexOfChar.latin1_SSE4_String 6978.854 6818.689 0.977049957x StringIndexOfChar.latin1_SSE4_char 5657.499 5474.624 0.967675646x StringIndexOfChar.latin1_Short_String 7132.541 6863.359 0.962260014x StringIndexOfChar.latin1_Short_char 16013.389 16162.437 1.009307711x StringIndexOfChar.latin1_mixed_String 7386.123 14771.622 1.999915517x StringIndexOfChar.latin1_mixed_char 9901.671 9782.245 0.987938803 ------------- Commit messages: - Fix whitespace - Merge branch 'openjdk:master' into indexof - Comments; added exhaustive-ish test - Subtracting 0x10 twice. - Stomped on r13 in switch branch calculation - Windows register preservation fix - Fix merge problem - Merge branch 'master' into indexof - Working version - Protecting against page faults - ... and 6 more: https://git.openjdk.org/jdk/compare/ce4e6e2b...60d762b9 Changes: https://git.openjdk.org/jdk/pull/16753/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16753&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8320448 Stats: 3062 lines in 14 files changed: 2928 ins; 11 del; 123 mod Patch: https://git.openjdk.org/jdk/pull/16753.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16753/head:pull/16753 PR: https://git.openjdk.org/jdk/pull/16753 From sgibbons at openjdk.org Wed Nov 29 01:11:21 2023 From: sgibbons at openjdk.org (Scott Gibbons) Date: Wed, 29 Nov 2023 01:11:21 GMT Subject: RFR: JDK-8320448 Accelerate IndexOf using AVX2 In-Reply-To: References: Message-ID: On Tue, 21 Nov 2023 00:06:19 GMT, Scott Gibbons wrote: > Re-write the IndexOf code without the use of the pcmpestri instruction, only using AVX2 instructions. This change accelerates String.IndexOf on average 1.3x for AVX2. The benchmark numbers: > > > Benchmark Score Latest > StringIndexOf.advancedWithMediumSub 343.573 317.934 0.925375393x > StringIndexOf.advancedWithShortSub1 1039.081 1053.96 1.014319384x > StringIndexOf.advancedWithShortSub2 55.828 110.541 1.980027943x > StringIndexOf.constantPattern 9.361 11.906 1.271872663x > StringIndexOf.searchCharLongSuccess 4.216 4.218 1.000474383x > StringIndexOf.searchCharMediumSuccess 3.133 3.216 1.02649218x > StringIndexOf.searchCharShortSuccess 3.76 3.761 1.000265957x > StringIndexOf.success 9.186 9.713 1.057369911x > StringIndexOf.successBig 14.341 46.343 3.231504079x > StringIndexOfChar.latin1_AVX2_String 6220.918 12154.52 1.953814533x > StringIndexOfChar.latin1_AVX2_char 5503.556 5540.044 1.006629895x > StringIndexOfChar.latin1_SSE4_String 6978.854 6818.689 0.977049957x > StringIndexOfChar.latin1_SSE4_char 5657.499 5474.624 0.967675646x > StringIndexOfChar.latin1_Short_String 7132.541 6863.359 0.962260014x > StringIndexOfChar.latin1_Short_char 16013.389 16162.437 1.009307711x > StringIndexOfChar.latin1_mixed_String 7386.123 14771.622 1.999915517x > StringIndexOfChar.latin1_mixed_char 9901.671 9782.245 0.987938803 Opening up for review. Fixed last whitespace error. I will post final performance numbers soon. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16753#issuecomment-1831031294 From duke at openjdk.org Wed Nov 29 01:13:06 2023 From: duke at openjdk.org (Bernd) Date: Wed, 29 Nov 2023 01:13:06 GMT Subject: RFR: JDK-8319626: Override toString() for ZipFile [v4] In-Reply-To: References: Message-ID: On Wed, 15 Nov 2023 18:30:27 GMT, Justin Lu wrote: >> src/java.base/share/classes/java/util/zip/ZipFile.java line 498: >> >>> 496: */ >>> 497: @Override >>> 498: public String toString() { >> >> I don't think the file name on its own is very helpful as it may not be unique or there may be several instances of ZipFile that are backed by the same zip file. Can you try `"" + file + "@" + Integer.toHexString(System.identityHashCode(this))` ? Or, if you really want to hide the file path in the String representation, then just use file.getName() + identity string. No need for baseName field. I think we need to be cautious about specifying anything, otherwise code will rely on it. > > Hi Alan, > > Thanks for taking a look. I updated the toString() value to the one you suggested, and also dropped the specific aspects of the specification. > > I am not sure if you have a preference one way or another regarding providing the full path versus just the file name, but I can switch the full path for just the file name if need be. I like the new wording (have no oppinion if absolute path is better). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16643#discussion_r1408597540 From almatvee at openjdk.org Wed Nov 29 01:44:21 2023 From: almatvee at openjdk.org (Alexander Matveev) Date: Wed, 29 Nov 2023 01:44:21 GMT Subject: Integrated: 8320681: [macos] Test tools/jpackage/macosx/MacAppStoreJlinkOptionsTest.java timed out on macOS In-Reply-To: References: Message-ID: <5JnWBHclf0t1rl4p1soWPJkhdtiYON9n3cl13_tvxu8=.50f84aba-2c76-41ff-90a1-7ccc9113509b@github.com> On Tue, 28 Nov 2023 02:24:20 GMT, Alexander Matveev wrote: > Looks like the test timed out due to slow/loaded host. Failure log similar to [JDK-8296489](https://bugs.openjdk.org/browse/JDK-8296489) and [JDK-8298735](https://bugs.openjdk.org/browse/JDK-8298735). Fixed by increasing test timeout. This pull request has now been integrated. Changeset: a657aa38 Author: Alexander Matveev URL: https://git.openjdk.org/jdk/commit/a657aa38a56056211a9d2773b30e8fe1a89c128e Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8320681: [macos] Test tools/jpackage/macosx/MacAppStoreJlinkOptionsTest.java timed out on macOS Reviewed-by: asemenyuk ------------- PR: https://git.openjdk.org/jdk/pull/16838 From darcy at openjdk.org Wed Nov 29 02:05:15 2023 From: darcy at openjdk.org (Joe Darcy) Date: Wed, 29 Nov 2023 02:05:15 GMT Subject: RFR: JDK-8320940: Fix typo in java.lang.Double Message-ID: Typo fix to to the new text added in JDK-8295391. ------------- Commit messages: - JDK-8320940: Fix typo in java.lang.Double Changes: https://git.openjdk.org/jdk/pull/16872/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16872&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8320940 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/16872.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16872/head:pull/16872 PR: https://git.openjdk.org/jdk/pull/16872 From rriggs at openjdk.org Wed Nov 29 02:15:08 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 29 Nov 2023 02:15:08 GMT Subject: RFR: JDK-8320940: Fix typo in java.lang.Double In-Reply-To: References: Message-ID: On Wed, 29 Nov 2023 02:00:14 GMT, Joe Darcy wrote: > Typo fix to to the new text added in JDK-8295391. LGTM ------------- Marked as reviewed by rriggs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16872#pullrequestreview-1754293335 From bchristi at openjdk.org Wed Nov 29 02:16:08 2023 From: bchristi at openjdk.org (Brent Christian) Date: Wed, 29 Nov 2023 02:16:08 GMT Subject: RFR: 8314480: Memory ordering spec updates in java.lang.ref In-Reply-To: References: Message-ID: On Tue, 21 Nov 2023 09:08:06 GMT, Viktor Klang wrote: >> Classes in the `java.lang.ref` package would benefit from an update to bring the spec in line with how the VM already behaves. The changes would focus on _happens-before_ edges at some key points during reference processing. >> >> A couple key things we want to be able to say are: >> - `Reference.reachabilityFence(x)` _happens-before_ reference processing occurs for 'x'. >> - `Cleaner.register()` _happens-before_ the Cleaner thread runs the registered cleaning action. >> >> This will bring Cleaner in line (or close) with the memory visibility guarantees made for finalizers in [JLS 17.4.5](https://docs.oracle.com/javase/specs/jls/se18/html/jls-17.html#jls-17.4.5): >> _"There is a happens-before edge from the end of a constructor of an object to the start of a finalizer (?12.6) for that object."_ > > src/java.base/share/classes/java/lang/ref/Reference.java line 405: > >> 403: *

    This method is invoked only by Java code; when the garbage collector >> 404: * clears references it does so directly, without invoking this method. The >> 405: * {@link #enqueue} method also clears references directly, without invoking > > The last sentence might make sense to have as an apiNote? ? I will remove that sentence here, and instead update the `enqueue()` doc to say that the GC clears and enqueues references without calling `clear()` or `enqueue()`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16644#discussion_r1408644358 From bchristi at openjdk.org Wed Nov 29 02:23:07 2023 From: bchristi at openjdk.org (Brent Christian) Date: Wed, 29 Nov 2023 02:23:07 GMT Subject: RFR: 8314480: Memory ordering spec updates in java.lang.ref In-Reply-To: <43LafiZ5jzSYbhw1iC-lPCfN4ODUn7kPYORh6vSqR0k=.92d6caaf-159c-4118-a0ba-b21e16f9f49b@github.com> References: <2RqnhMueD0a9fejTHvEmtcXQ7TK4XbAgI4y19dRLU68=.cdf8c60c-1148-44b2-8436-6aa7258bfe83@github.com> <43LafiZ5jzSYbhw1iC-lPCfN4ODUn7kPYORh6vSqR0k=.92d6caaf-159c-4118-a0ba-b21e16f9f49b@github.com> Message-ID: On Sat, 18 Nov 2023 01:55:00 GMT, Mandy Chung wrote: >> Perhaps it's sufficient to say simply that, _"the garbage collector will no longer enqueue this object."_ > > Is this sentence needed? Excluding the race scenario as described in the javadoc, it would be equivalent as if the Reference with null referent which will never get enqueued? I personally think it's worth clearly stating that calling `clear()` opts you out of getting the GC notification that you signed up for when you registering this Reference with a RefQ. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16644#discussion_r1408648376 From iris at openjdk.org Wed Nov 29 04:16:04 2023 From: iris at openjdk.org (Iris Clark) Date: Wed, 29 Nov 2023 04:16:04 GMT Subject: RFR: JDK-8320940: Fix typo in java.lang.Double In-Reply-To: References: Message-ID: On Wed, 29 Nov 2023 02:00:14 GMT, Joe Darcy wrote: > Typo fix to to the new text added in JDK-8295391. Marked as reviewed by iris (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/16872#pullrequestreview-1754401831 From joehw at openjdk.org Wed Nov 29 04:36:15 2023 From: joehw at openjdk.org (Joe Wang) Date: Wed, 29 Nov 2023 04:36:15 GMT Subject: Integrated: 8320918: Fix errors in the built-in Catalog implementation In-Reply-To: References: Message-ID: <37afDngA_mYUHIlep1zemxQkeePnMnfyCICIie7kzRk=.9632d71b-9d74-48b2-9262-3005c2e49ca7@github.com> On Tue, 28 Nov 2023 20:11:42 GMT, Joe Wang wrote: > Fix errors in the built-in Catalog implementation, specifically: > -- incorrect case in the property name as defined in the CSR (https://bugs.openjdk.org/browse/JDK-8306056) > -- tests needed to be updated accordingly > -- jaxp.properties updated with documentation for the new properties > > Tests: passed after the update. This pull request has now been integrated. Changeset: 9a6ca233 Author: Joe Wang URL: https://git.openjdk.org/jdk/commit/9a6ca233c7e91ffa2ce9451568b3be88ccd04504 Stats: 56 lines in 6 files changed: 38 ins; 4 del; 14 mod 8320918: Fix errors in the built-in Catalog implementation Reviewed-by: lancea, naoto, iris ------------- PR: https://git.openjdk.org/jdk/pull/16862 From vsitnikov at openjdk.org Wed Nov 29 05:52:23 2023 From: vsitnikov at openjdk.org (Vladimir Sitnikov) Date: Wed, 29 Nov 2023 05:52:23 GMT Subject: RFR: 8294696 - BufferedInputStream.transferTo should drain buffer when mark set [v6] In-Reply-To: <6qdrcRAPKcCfsrKlrr91C6mXF9mVKXj3XmDfnvImR_s=.cdb7aac1-abe3-46ea-a573-fd4c0305987e@github.com> References: <6qdrcRAPKcCfsrKlrr91C6mXF9mVKXj3XmDfnvImR_s=.cdb7aac1-abe3-46ea-a573-fd4c0305987e@github.com> Message-ID: On Mon, 31 Oct 2022 13:30:13 GMT, Markus KARG wrote: >> This PR implements JDK-8294696. > > Markus KARG has updated the pull request incrementally with one additional commit since the last revision: > > Alternative C + Arrays.copyOfRange() src/java.base/share/classes/java/io/BufferedInputStream.java line 612: > 610: if (avail > 0) { > 611: // Prevent poisoning and leaking of buf > 612: byte[] buffer = Arrays.copyOfRange(getBufIfOpen(), pos, count); @mkarg , could you please clarify why you added `Arrays.copyOfRange` here? It seems to be an excessive copy that doesn't help much. `buf` is `protected` in `BufferedInputStream`, so if someone really wants to get hold of the actual buffer, they can subclass `BufferedInputStream` and expose the buffer directly. What do you think of removing `copyOfRange`? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/10525#discussion_r1408775984 From vsitnikov at openjdk.org Wed Nov 29 05:58:24 2023 From: vsitnikov at openjdk.org (Vladimir Sitnikov) Date: Wed, 29 Nov 2023 05:58:24 GMT Subject: RFR: 8294696 - BufferedInputStream.transferTo should drain buffer when mark set [v6] In-Reply-To: References: <6qdrcRAPKcCfsrKlrr91C6mXF9mVKXj3XmDfnvImR_s=.cdb7aac1-abe3-46ea-a573-fd4c0305987e@github.com> Message-ID: On Wed, 29 Nov 2023 05:48:58 GMT, Vladimir Sitnikov wrote: >> Markus KARG has updated the pull request incrementally with one additional commit since the last revision: >> >> Alternative C + Arrays.copyOfRange() > > src/java.base/share/classes/java/io/BufferedInputStream.java line 612: > >> 610: if (avail > 0) { >> 611: // Prevent poisoning and leaking of buf >> 612: byte[] buffer = Arrays.copyOfRange(getBufIfOpen(), pos, count); > > @mkarg , could you please clarify why you added `Arrays.copyOfRange` here? > It seems to be an excessive copy that doesn't help much. > > `buf` is `protected` in `BufferedInputStream`, so if someone really wants to get hold of the actual buffer, they can subclass `BufferedInputStream` and expose the buffer directly. > What do you think of removing `copyOfRange`? Buffer copy was not there before, and defensive copy was never present in `ByteArrayInputStream` as well: https://github.com/openjdk/jdk/blob/9a6ca233c7e91ffa2ce9451568b3be88ccd04504/src/java.base/share/classes/java/io/ByteArrayInputStream.java#L213 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/10525#discussion_r1408780382 From dholmes at openjdk.org Wed Nov 29 06:16:07 2023 From: dholmes at openjdk.org (David Holmes) Date: Wed, 29 Nov 2023 06:16:07 GMT Subject: RFR: 8319577: x86_64 AVX2 intrinsics for Arrays.sort methods (int, float arrays) [v4] In-Reply-To: References: Message-ID: <-lVL7hp68aKNlBWHCxdKdPrPDe6NOAKD3zoX-u5ZMEM=.6164666f-7312-4f0c-b15b-2e01a331e820@github.com> On Tue, 21 Nov 2023 15:14:28 GMT, Dalibor Topic wrote: >> src/java.base/linux/native/libsimdsort/avx2-32bit-qsort.hpp line 3: >> >>> 1: /* >>> 2: * Copyright (c) 2021, 2023, Intel Corporation. All rights reserved. >>> 3: * Copyright (c) 2021 Serge Sans Paille. All rights reserved. >> >> Is this person an OpenJDK Contributor? > > Not listed here: https://oca.opensource.oracle.com/?ojr=contributors I take it he is not an Intel employee, in which case he has to be an OpenJDK contributor himself for code for which he holds a copyright to be contributed to OpenJDK. @robilad please correct me if I am wrong here. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16534#discussion_r1408793980 From dholmes at openjdk.org Wed Nov 29 06:58:06 2023 From: dholmes at openjdk.org (David Holmes) Date: Wed, 29 Nov 2023 06:58:06 GMT Subject: RFR: 8320786: Remove ThreadGroup.stop In-Reply-To: References: Message-ID: On Mon, 27 Nov 2023 16:58:29 GMT, Alan Bateman wrote: > ThreadGroup.stop was deprecated since JDK 1.2, deprecated for removal in Java 18, and re-specified/degraded to throw UnsupportedOperationException unconditionally in Java 20. Early in Java 23 seems a fine time to finally remove this method. Corpus analysis of 176 million classes in 485k artifacts found residual usages in 14 artifacts, so not many. > > It would be nice if we could remove Thread.stop at the same time. Sadly there are still quite a few artifacts containing code (and in some cases tests) that reference this method. We will have to come back to this in some future release. Looks good! Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16828#pullrequestreview-1754563244 From jpai at openjdk.org Wed Nov 29 07:05:08 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 29 Nov 2023 07:05:08 GMT Subject: RFR: 8320786: Remove ThreadGroup.stop In-Reply-To: References: Message-ID: On Mon, 27 Nov 2023 16:58:29 GMT, Alan Bateman wrote: > ThreadGroup.stop was deprecated since JDK 1.2, deprecated for removal in Java 18, and re-specified/degraded to throw UnsupportedOperationException unconditionally in Java 20. Early in Java 23 seems a fine time to finally remove this method. Corpus analysis of 176 million classes in 485k artifacts found residual usages in 14 artifacts, so not many. > > It would be nice if we could remove Thread.stop at the same time. Sadly there are still quite a few artifacts containing code (and in some cases tests) that reference this method. We will have to come back to this in some future release. Marked as reviewed by jpai (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/16828#pullrequestreview-1754570972 From pminborg at openjdk.org Wed Nov 29 08:49:28 2023 From: pminborg at openjdk.org (Per Minborg) Date: Wed, 29 Nov 2023 08:49:28 GMT Subject: RFR: 8308753: Class-File API transition to Preview [v32] In-Reply-To: References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com> <9-Fm-UXpDT0FLAxTw9xve00qurpqv01xw1uJwG0IXKQ=.06a9e0da-7a8c-462b-9b7a-b1be1b9bff5f@github.com> <8aNWssZUAmka3xQNMbRvY8P8ruJ0-7Eo5NTLeQGPko4=.ac8f1a19-8f0a-42fc-85cf-2fb540d194a7@github.com> Message-ID: On Tue, 28 Nov 2023 13:03:48 GMT, Adam Sotona wrote: >> src/java.base/share/classes/java/lang/classfile/ClassFile.java line 1404: >> >>> (failed to retrieve contents of file, check the PR for context) >> Is there a more scalable way to express the major class version? The current approach means we have to add two fields per year. Maybe a lookup function would be better? > > This is explicit list of supported class file versions, so I don't see any other way. Would it not be possible to expose an immutable `Map` that maps from Java version to major class version? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15706#discussion_r1408941961 From alanb at openjdk.org Wed Nov 29 09:16:18 2023 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 29 Nov 2023 09:16:18 GMT Subject: Integrated: 8320858: Move jpackage tests to tier3 In-Reply-To: References: Message-ID: On Tue, 28 Nov 2023 08:51:17 GMT, Alan Bateman wrote: > Update the jtreg test group configuration in the jdk test tree so that the jpackage tests run in tier3 rather than tier2. > > At this time, the jpackage tests run in jdk:tier2, more specifically jdk:tier2_part2 as part of the core_tools test group. The jpackage tests take a significant amount of time on some platforms (on macOS and Windows in particular). The changes here remove tools/jpackage from core_tools (it's not a core tool anyway) and adds the tests to tier3. In the future then maybe tier3 can be split up if needed. This pull request has now been integrated. Changeset: e44d4b24 Author: Alan Bateman URL: https://git.openjdk.org/jdk/commit/e44d4b24ed794957c47c140ab6f15544efa2b278 Stats: 11 lines in 1 file changed: 6 ins; 0 del; 5 mod 8320858: Move jpackage tests to tier3 Reviewed-by: mchung, asemenyuk, almatvee ------------- PR: https://git.openjdk.org/jdk/pull/16841 From shade at openjdk.org Wed Nov 29 09:33:07 2023 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 29 Nov 2023 09:33:07 GMT Subject: RFR: JDK-8320940: Fix typo in java.lang.Double In-Reply-To: References: Message-ID: On Wed, 29 Nov 2023 02:00:14 GMT, Joe Darcy wrote: > Typo fix to to the new text added in JDK-8295391. Marked as reviewed by shade (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/16872#pullrequestreview-1754814207 From lancea at openjdk.org Wed Nov 29 11:20:04 2023 From: lancea at openjdk.org (Lance Andersen) Date: Wed, 29 Nov 2023 11:20:04 GMT Subject: RFR: JDK-8320940: Fix typo in java.lang.Double In-Reply-To: References: Message-ID: On Wed, 29 Nov 2023 02:00:14 GMT, Joe Darcy wrote: > Typo fix to to the new text added in JDK-8295391. Marked as reviewed by lancea (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/16872#pullrequestreview-1755023783 From stsypanov at openjdk.org Wed Nov 29 12:04:34 2023 From: stsypanov at openjdk.org (Sergey Tsypanov) Date: Wed, 29 Nov 2023 12:04:34 GMT Subject: RFR: 8320971: Use BufferedInputStream.buf directly when param of implTransferTo() is trusted Message-ID: It looks like we can skip copying of `byte[]` in `BufferedInputStream.implTransferTo()` for `OutputStreams` residing in `java.io`. See comment by @vlsi in https://github.com/openjdk/jdk/pull/10525/files#diff-e19c508d1bb6ee78697ecca66947c395adda0d9c49a85bf696e677ecbd977af1R612 ------------- Commit messages: - 8320971: Use BufferedInputStream.class.getPackageName() - 8320971: Use BufferedInputStream.buf directly when param of implTransferTo() is trusted Changes: https://git.openjdk.org/jdk/pull/16879/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16879&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8320971 Stats: 8 lines in 1 file changed: 5 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/16879.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16879/head:pull/16879 PR: https://git.openjdk.org/jdk/pull/16879 From eosterlund at openjdk.org Wed Nov 29 12:40:09 2023 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Wed, 29 Nov 2023 12:40:09 GMT Subject: RFR: 8310644: Make panama memory segment close use async handshakes [v3] In-Reply-To: References: Message-ID: <0KmqmP-3IThcICrsSDxm1BDVPWKarvfoqgAUNnxdA2E=.0891e938-e432-440b-871e-250dd8de02d9@github.com> On Thu, 23 Nov 2023 16:32:28 GMT, Jorn Vernee wrote: >> Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision: >> >> Comments from Jorn > > LGTM Thanks for the reviews @JornVernee @pchilano and @mcimadamore! ------------- PR Comment: https://git.openjdk.org/jdk/pull/16792#issuecomment-1831817744 From eosterlund at openjdk.org Wed Nov 29 12:43:20 2023 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Wed, 29 Nov 2023 12:43:20 GMT Subject: Integrated: 8310644: Make panama memory segment close use async handshakes In-Reply-To: References: Message-ID: On Thu, 23 Nov 2023 11:14:29 GMT, Erik ?sterlund wrote: > The current logic for closing memory in panama today is susceptible to live lock if we have a closing thread that wants to close the memory in a loop that keeps failing, and a bunch of accessing threads that want to perform accesses as long as the memory is alive. They can both create impediments for the other. > > By using asynchronous handshakes to install an exception onto threads that are in @Scoped memory accesses, we can have close always succeed, and the accessing threads bail out. The idea is that we perform a synchronous handshake first to find threads that are in scoped methods. They might however be in the middle of throwing an exception or something wild like there, where an exception can't be delivered. We install an async handshake that will roll us forward to the first place where we can indeed install exceptions, then we reevaluate if we still need to do that, or if we have unwound out from the scoped method. If we are still inside of it, we ensure an exception is installed so we don't continue executing bytecodes that might access the memory that we have freed. > > Tested tier 1-5 as well as running test/jdk/java/foreign/TestHandshake.java hundreds of times, which tests this API pretty well. This pull request has now been integrated. Changeset: 15946532 Author: Erik ?sterlund URL: https://git.openjdk.org/jdk/commit/159465324fc45325d0df438991032ebca9229ca2 Stats: 222 lines in 8 files changed: 76 ins; 63 del; 83 mod 8310644: Make panama memory segment close use async handshakes Reviewed-by: jvernee, mcimadamore, pchilanomate ------------- PR: https://git.openjdk.org/jdk/pull/16792 From anthony.goubard at gmail.com Wed Nov 29 12:54:48 2023 From: anthony.goubard at gmail.com (Anthony Goubard) Date: Wed, 29 Nov 2023 13:54:48 +0100 Subject: Unneeded array assignments in core libs Message-ID: Hello, Last Friday, I decided to look if there were some classes that did unneeded array assignments (e.g. to 0 / 0.0f / null / false) in the JDK. I've found a few places and in particular 2 places where it's done in big for loops (looping more than 500 times). So I thought you might be interested to know about them. https://github.com/openjdk/jdk/blob/6871a2ff1207d3ee70973b1c4ee9bd09969c185b/src/java.base/share/classes/java/text/MergeCollation.java#L72 https://github.com/openjdk/jdk/blob/6871a2ff1207d3ee70973b1c4ee9bd09969c185b/src/java.base/share/classes/sun/text/CompactByteArray.java#L85 Also for CompactByteArray, maybe it's worth checking that defaultValue is different than 0 before entering the for loop (Line 80) Let me know if you're interested in fixing them and if you want me to fill 2 bugs for them in the JBS or in bugreport.java.com. Best regards, Anthony Goubard -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgehwolf at openjdk.org Wed Nov 29 13:55:12 2023 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Wed, 29 Nov 2023 13:55:12 GMT Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged modules being present [v10] In-Reply-To: References: Message-ID: On Fri, 24 Nov 2023 13:25:35 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 one additional commit since the last revision: > > Tighten ModifiedFilesExitTest > > Ensure the error message is reasonable and doesn't include > Exceptions presented to the user. Thanks for the review! I'll work on an update. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14787#issuecomment-1831937187 From vsitnikov at openjdk.org Wed Nov 29 13:59:05 2023 From: vsitnikov at openjdk.org (Vladimir Sitnikov) Date: Wed, 29 Nov 2023 13:59:05 GMT Subject: RFR: 8320971: Use BufferedInputStream.buf directly when param of implTransferTo() is trusted In-Reply-To: References: Message-ID: <8WNLqjn1mU1xQUQV95cLOwe10A7EesefRtdkQ_lQJrs=.278397c2-bc21-484a-ad23-cc0f95261aa1@github.com> On Wed, 29 Nov 2023 11:57:37 GMT, Sergey Tsypanov wrote: > It looks like we can skip copying of `byte[]` in `BufferedInputStream.implTransferTo()` for `OutputStreams` residing in `java.io`. > > See comment by @vlsi in https://github.com/openjdk/jdk/pull/10525/files#diff-e19c508d1bb6ee78697ecca66947c395adda0d9c49a85bf696e677ecbd977af1R612 src/java.base/share/classes/java/io/BufferedInputStream.java line 653: > 651: byte[] buffer = Arrays.copyOfRange(getBufIfOpen(), pos, count); > 652: out.write(buffer); > 653: } Suggestion: out.write(getBufIfOpen(), pos, count); What do you think of passing the buffer as is? `ByteArrayInputStream` passes the buffer without extra copies anyway: https://github.com/openjdk/jdk/blob/9a6ca233c7e91ffa2ce9451568b3be88ccd04504/src/java.base/share/classes/java/io/ByteArrayInputStream.java#L207-L213 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16879#discussion_r1409319731 From jlaskey at openjdk.org Wed Nov 29 14:30:50 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Wed, 29 Nov 2023 14:30:50 GMT Subject: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v42] In-Reply-To: References: Message-ID: <5BIJJ2_LH-qdn05gcgQk6Fx4D9X5XgTmQFsbp5HNXjQ=.860c8efa-521b-49e0-adb2-f05819c53aaf@github.com> > Address changes from JEP 445 to JEP 463. > > - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. > > - Don't mark class on read. > > - Remove reflection and annotation processing related to unnamed classes. > > - Simplify main method search. Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: Windows line endings ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16461/files - new: https://git.openjdk.org/jdk/pull/16461/files/30170407..2f7fdded Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16461&range=41 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16461&range=40-41 Stats: 217 lines in 1 file changed: 0 ins; 0 del; 217 mod Patch: https://git.openjdk.org/jdk/pull/16461.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16461/head:pull/16461 PR: https://git.openjdk.org/jdk/pull/16461 From jlahoda at openjdk.org Wed Nov 29 14:51:33 2023 From: jlahoda at openjdk.org (Jan Lahoda) Date: Wed, 29 Nov 2023 14:51:33 GMT Subject: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v42] In-Reply-To: <5BIJJ2_LH-qdn05gcgQk6Fx4D9X5XgTmQFsbp5HNXjQ=.860c8efa-521b-49e0-adb2-f05819c53aaf@github.com> References: <5BIJJ2_LH-qdn05gcgQk6Fx4D9X5XgTmQFsbp5HNXjQ=.860c8efa-521b-49e0-adb2-f05819c53aaf@github.com> Message-ID: <2M4oi4qxtjx11NMnq_jaH7jjYG5SV2HSO4ypHH1-P6E=.86e7cd2d-d074-48dd-9b3c-1bbe23bc351f@github.com> On Wed, 29 Nov 2023 14:30:50 GMT, Jim Laskey wrote: >> Address changes from JEP 445 to JEP 463. >> >> - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. >> >> - Don't mark class on read. >> >> - Remove reflection and annotation processing related to unnamed classes. >> >> - Simplify main method search. > > Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: > > Windows line endings javac changes seem reasonably to me. Adding two nits to `InstanceMainTest.java`. test/jdk/tools/launcher/InstanceMainTest.java line 45: > 43: """, > 44: > 45: // instance dominating instance Nit: Suggestion: // instance dominating static test/jdk/tools/launcher/InstanceMainTest.java line 84: > 82: """, > 83: > 84: // unnamed class dominating instance Nit: Suggestion: // main with args dominating main without args ------------- Marked as reviewed by jlahoda (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16461#pullrequestreview-1755452564 PR Review Comment: https://git.openjdk.org/jdk/pull/16461#discussion_r1409394109 PR Review Comment: https://git.openjdk.org/jdk/pull/16461#discussion_r1409395226 From sgibbons at openjdk.org Wed Nov 29 15:01:32 2023 From: sgibbons at openjdk.org (Scott Gibbons) Date: Wed, 29 Nov 2023 15:01:32 GMT Subject: RFR: JDK-8320448 Accelerate IndexOf using AVX2 [v2] In-Reply-To: References: Message-ID: > Re-write the IndexOf code without the use of the pcmpestri instruction, only using AVX2 instructions. This change accelerates String.IndexOf on average 1.3x for AVX2. The benchmark numbers: > > > Benchmark Score Latest > StringIndexOf.advancedWithMediumSub 343.573 317.934 0.925375393x > StringIndexOf.advancedWithShortSub1 1039.081 1053.96 1.014319384x > StringIndexOf.advancedWithShortSub2 55.828 110.541 1.980027943x > StringIndexOf.constantPattern 9.361 11.906 1.271872663x > StringIndexOf.searchCharLongSuccess 4.216 4.218 1.000474383x > StringIndexOf.searchCharMediumSuccess 3.133 3.216 1.02649218x > StringIndexOf.searchCharShortSuccess 3.76 3.761 1.000265957x > StringIndexOf.success 9.186 9.713 1.057369911x > StringIndexOf.successBig 14.341 46.343 3.231504079x > StringIndexOfChar.latin1_AVX2_String 6220.918 12154.52 1.953814533x > StringIndexOfChar.latin1_AVX2_char 5503.556 5540.044 1.006629895x > StringIndexOfChar.latin1_SSE4_String 6978.854 6818.689 0.977049957x > StringIndexOfChar.latin1_SSE4_char 5657.499 5474.624 0.967675646x > StringIndexOfChar.latin1_Short_String 7132.541 6863.359 0.962260014x > StringIndexOfChar.latin1_Short_char 16013.389 16162.437 1.009307711x > StringIndexOfChar.latin1_mixed_String 7386.123 14771.622 1.999915517x > StringIndexOfChar.latin1_mixed_char 9901.671 9782.245 0.987938803 Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision: Only use optimization when EnableX86ECoreOpts is true ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16753/files - new: https://git.openjdk.org/jdk/pull/16753/files/60d762b9..e614b86f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16753&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16753&range=00-01 Stats: 6 lines in 3 files changed: 0 ins; 4 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/16753.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16753/head:pull/16753 PR: https://git.openjdk.org/jdk/pull/16753 From jlaskey at openjdk.org Wed Nov 29 15:25:15 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Wed, 29 Nov 2023 15:25:15 GMT Subject: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v43] In-Reply-To: References: Message-ID: > Address changes from JEP 445 to JEP 463. > > - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. > > - Don't mark class on read. > > - Remove reflection and annotation processing related to unnamed classes. > > - Simplify main method search. Jim Laskey has updated the pull request incrementally with two additional commits since the last revision: - Update test/jdk/tools/launcher/InstanceMainTest.java Co-authored-by: Jan Lahoda <51319204+lahodaj at users.noreply.github.com> - Update test/jdk/tools/launcher/InstanceMainTest.java Co-authored-by: Jan Lahoda <51319204+lahodaj at users.noreply.github.com> ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16461/files - new: https://git.openjdk.org/jdk/pull/16461/files/2f7fdded..7ed4045a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16461&range=42 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16461&range=41-42 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/16461.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16461/head:pull/16461 PR: https://git.openjdk.org/jdk/pull/16461 From bpb at openjdk.org Wed Nov 29 17:14:05 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 29 Nov 2023 17:14:05 GMT Subject: RFR: JDK-8320940: Fix typo in java.lang.Double In-Reply-To: References: Message-ID: On Wed, 29 Nov 2023 02:00:14 GMT, Joe Darcy wrote: > Typo fix to to the new text added in JDK-8295391. Marked as reviewed by bpb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/16872#pullrequestreview-1755813777 From darcy at openjdk.org Wed Nov 29 17:26:24 2023 From: darcy at openjdk.org (Joe Darcy) Date: Wed, 29 Nov 2023 17:26:24 GMT Subject: Integrated: JDK-8320940: Fix typo in java.lang.Double In-Reply-To: References: Message-ID: On Wed, 29 Nov 2023 02:00:14 GMT, Joe Darcy wrote: > Typo fix to to the new text added in JDK-8295391. This pull request has now been integrated. Changeset: d783aa31 Author: Joe Darcy URL: https://git.openjdk.org/jdk/commit/d783aa31a9c20f5ac2ee52c55bdc9be2388b1705 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8320940: Fix typo in java.lang.Double Reviewed-by: rriggs, iris, shade, lancea, bpb ------------- PR: https://git.openjdk.org/jdk/pull/16872 From jvernee at openjdk.org Wed Nov 29 17:33:18 2023 From: jvernee at openjdk.org (Jorn Vernee) Date: Wed, 29 Nov 2023 17:33:18 GMT Subject: RFR: 8318966: Some methods make promises about Java array element alignment that are too strong In-Reply-To: References: Message-ID: On Wed, 15 Nov 2023 22:46:03 GMT, Jorn Vernee wrote: > See the JBS issue for an extended problem description. > > This patch changes the specification and implementation of `MethodHandles::byteArrayViewVarHandle`, `MethodHandles::byteBufferViewVarHandle`, `ByteBuffer::alignedSlice`, and `ByteBuffer::alignmentOffset` to weaken the guarantees they make about the alignment of Java array elements, in order to bring them in line with the guarantees made by an arbitrary JVM implementation (which makes no guarantees about array element alignment beyond them being aligned to their natural alignment). > > - `MethodHandles::byteArrayViewVarHandle`: we can not guarantee any alignment for the accesses. Which means we can only reliably support plain get and set access modes. The javadoc text explaining which other access modes are supported, or how to compute aligned offsets into the array is dropped, as it is not guaranteed to be correct on all JVM implementations. The implementation of the returned VarHandle is changed to throw an `UnsupportedOperationException` for the unsupported access modes, as mandated by the spec of `VarHandle` [1]. > > - `MethodHandles::byteBufferViewVarHandle`: the implementation/spec is incorrect when accessing a heap buffer (wrapping a byte[]), for the same reasons as `byteArrayViewVarHandle`. The spec is changed to specify that when accessing a _heap buffer_, only plain get and set access modes are supported. The implementation of the returned var handle is changed to throw an `IllegalStateException` when an access is attempted on a heap buffer using an access mode other than plain get or set. Note that we don't throw an outright `UnsupportedOperationException` for this case, since whether the access modes are supported depends on the byte buffer instance being used. > > - `ByteBuffer::alignedSlice` and `ByteBuffer::alignmentOffset`: The former method depends directly on the latter for all its alignment computations. We change the implementation of the latter method to throw an `UnsupportedOperationException` for all unit sizes greater than 1, when the buffer is non-direct. This change is largely covered by the existing specification: > > > * @throws UnsupportedOperationException > * If the native platform does not guarantee stable alignment offset > * values for the given unit size when managing the memory regions > * of buffers of the same kind as this buffer (direct or > * non-direct). For example, if garbage collection would result > * in the mo... Anything else needed to move this forward? I think I've addressed all the review comments made so far. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16681#issuecomment-1828491878 From sgibbons at openjdk.org Wed Nov 29 18:37:08 2023 From: sgibbons at openjdk.org (Scott Gibbons) Date: Wed, 29 Nov 2023 18:37:08 GMT Subject: RFR: JDK-8320448 Accelerate IndexOf using AVX2 [v2] In-Reply-To: References: Message-ID: On Wed, 29 Nov 2023 15:01:32 GMT, Scott Gibbons wrote: >> Re-write the IndexOf code without the use of the pcmpestri instruction, only using AVX2 instructions. This change accelerates String.IndexOf on average 1.3x for AVX2. The benchmark numbers: >> >> >> Benchmark Score Latest >> StringIndexOf.advancedWithMediumSub 343.573 317.934 0.925375393x >> StringIndexOf.advancedWithShortSub1 1039.081 1053.96 1.014319384x >> StringIndexOf.advancedWithShortSub2 55.828 110.541 1.980027943x >> StringIndexOf.constantPattern 9.361 11.906 1.271872663x >> StringIndexOf.searchCharLongSuccess 4.216 4.218 1.000474383x >> StringIndexOf.searchCharMediumSuccess 3.133 3.216 1.02649218x >> StringIndexOf.searchCharShortSuccess 3.76 3.761 1.000265957x >> StringIndexOf.success 9.186 9.713 1.057369911x >> StringIndexOf.successBig 14.341 46.343 3.231504079x >> StringIndexOfChar.latin1_AVX2_String 6220.918 12154.52 1.953814533x >> StringIndexOfChar.latin1_AVX2_char 5503.556 5540.044 1.006629895x >> StringIndexOfChar.latin1_SSE4_String 6978.854 6818.689 0.977049957x >> StringIndexOfChar.latin1_SSE4_char 5657.499 5474.624 0.967675646x >> StringIndexOfChar.latin1_Short_String 7132.541 6863.359 0.962260014x >> StringIndexOfChar.latin1_Short_char 16013.389 16162.437 1.009307711x >> StringIndexOfChar.latin1_mixed_String 7386.123 14771.622 1.999915517x >> StringIndexOfChar.latin1_mixed_char 9901.671 9782.245 0.987938803 > > Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision: > > Only use optimization when EnableX86ECoreOpts is true Latest numbers vs. top-of-tree JDK. ![JBS IndexOf](https://github.com/openjdk/jdk/assets/6704669/6ed74968-d333-4c70-8fe2-f94a56aaeca9) ------------- PR Comment: https://git.openjdk.org/jdk/pull/16753#issuecomment-1832486450 From darcy at openjdk.org Wed Nov 29 19:00:30 2023 From: darcy at openjdk.org (Joe Darcy) Date: Wed, 29 Nov 2023 19:00:30 GMT Subject: RFR: JDK-8319413: Start of release updates for JDK 23 [v2] In-Reply-To: References: Message-ID: > Time to start making preparations for JDK 23. Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: - Merge branch 'master' into JDK-8319413 - Add symbol files for JDK 22 build 25. - Merge branch 'master' into JDK-8319413 - Merge branch 'master' into JDK-8319413 - Adjust expected release date. - Fix omission in Classfile.java - JDK-8319413: Start of release updates for JDK 23 ------------- Changes: https://git.openjdk.org/jdk/pull/16505/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16505&range=01 Stats: 7694 lines in 70 files changed: 7656 ins; 0 del; 38 mod Patch: https://git.openjdk.org/jdk/pull/16505.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16505/head:pull/16505 PR: https://git.openjdk.org/jdk/pull/16505 From jlu at openjdk.org Wed Nov 29 19:14:20 2023 From: jlu at openjdk.org (Justin Lu) Date: Wed, 29 Nov 2023 19:14:20 GMT Subject: Integrated: JDK-8210410: Refactor java.util.Currency:i18n shell tests to plain java tests In-Reply-To: References: Message-ID: On Thu, 23 Nov 2023 00:26:43 GMT, Justin Lu wrote: > Please review this PR which converts the shell test, _java/util/currency/PropertiesTest.sh_ to a normal java test. > > This test is a test runner that launches test methods from _PropertiesTest.java_. It tests both the ways to supersede the default currencies, that is, either using a custom properties file under the lib directory, or setting the path to a custom properties file via the system property. This pull request has now been integrated. Changeset: 2584bf87 Author: Justin Lu URL: https://git.openjdk.org/jdk/commit/2584bf87aef66744a8e586805735cded0d2f98f1 Stats: 301 lines in 2 files changed: 157 ins; 144 del; 0 mod 8210410: Refactor java.util.Currency:i18n shell tests to plain java tests Reviewed-by: naoto, lancea ------------- PR: https://git.openjdk.org/jdk/pull/16787 From alanb at openjdk.org Wed Nov 29 19:58:07 2023 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 29 Nov 2023 19:58:07 GMT Subject: RFR: 8320971: Use BufferedInputStream.buf directly when param of implTransferTo() is trusted In-Reply-To: <8WNLqjn1mU1xQUQV95cLOwe10A7EesefRtdkQ_lQJrs=.278397c2-bc21-484a-ad23-cc0f95261aa1@github.com> References: <8WNLqjn1mU1xQUQV95cLOwe10A7EesefRtdkQ_lQJrs=.278397c2-bc21-484a-ad23-cc0f95261aa1@github.com> Message-ID: On Wed, 29 Nov 2023 13:56:34 GMT, Vladimir Sitnikov wrote: > What do you think of passing the buffer as is? No, it should only do for trusted targets. BAIS has an issue in that area that should be fixed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16879#discussion_r1409798218 From alanb at openjdk.org Wed Nov 29 20:02:07 2023 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 29 Nov 2023 20:02:07 GMT Subject: RFR: 8320971: Use BufferedInputStream.buf directly when param of implTransferTo() is trusted In-Reply-To: References: Message-ID: On Wed, 29 Nov 2023 11:57:37 GMT, Sergey Tsypanov wrote: > It looks like we can skip copying of `byte[]` in `BufferedInputStream.implTransferTo()` for `OutputStreams` residing in `java.io`. > > See comment by @vlsi in https://github.com/openjdk/jdk/pull/10525/files#diff-e19c508d1bb6ee78697ecca66947c395adda0d9c49a85bf696e677ecbd977af1R612 src/java.base/share/classes/java/io/BufferedInputStream.java line 647: > 645: if (avail > 0) { > 646: // trust all OutputStreams from java.io > 647: if (out.getClass().getPackageName() == BufferedInputStream.class.getPackageName()) { I don't think Class::getPackageName documents that the returned String is intern so I wonder if the == check will lead to questions and suggestions of a bug. Classes with names starting with "java." can only be defined to the boot or platform class loader (details in the ClassLoader API docs) so you could just check if the package name equals "java.io". ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16879#discussion_r1409802437 From vsitnikov at openjdk.org Wed Nov 29 20:10:10 2023 From: vsitnikov at openjdk.org (Vladimir Sitnikov) Date: Wed, 29 Nov 2023 20:10:10 GMT Subject: RFR: 8320971: Use BufferedInputStream.buf directly when param of implTransferTo() is trusted In-Reply-To: References: <8WNLqjn1mU1xQUQV95cLOwe10A7EesefRtdkQ_lQJrs=.278397c2-bc21-484a-ad23-cc0f95261aa1@github.com> Message-ID: <1LvXEZt6nHqyDLZhF7IQkVAPOLu-RVNvscLGE1EnDpw=.7ad864c4-0a17-470b-b8a3-d09291057680@github.com> On Wed, 29 Nov 2023 19:55:09 GMT, Alan Bateman wrote: >> src/java.base/share/classes/java/io/BufferedInputStream.java line 653: >> >>> 651: byte[] buffer = Arrays.copyOfRange(getBufIfOpen(), pos, count); >>> 652: out.write(buffer); >>> 653: } >> >> Suggestion: >> >> out.write(getBufIfOpen(), pos, count); >> >> >> What do you think of passing the buffer as is? >> `ByteArrayInputStream` passes the buffer without extra copies anyway: https://github.com/openjdk/jdk/blob/9a6ca233c7e91ffa2ce9451568b3be88ccd04504/src/java.base/share/classes/java/io/ByteArrayInputStream.java#L207-L213 > >> What do you think of passing the buffer as is? > > No, it should only do for trusted targets. BAIS has an issue in that area that should be fixed. The buffer in question is protected, so any subclass can directly access it. In other words, untrusted code can easily acoess the buffer, and it does not sound fair to add extra overhead to the method which was created for the performance reasons. Does copyOfRange do any good here? Do you mean JDK should copy every buffer it passes to non-JDK code? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16879#discussion_r1409810571 From darcy at openjdk.org Wed Nov 29 20:10:29 2023 From: darcy at openjdk.org (Joe Darcy) Date: Wed, 29 Nov 2023 20:10:29 GMT Subject: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v43] In-Reply-To: References: Message-ID: On Wed, 29 Nov 2023 15:25:15 GMT, Jim Laskey wrote: >> Address changes from JEP 445 to JEP 463. >> >> - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. >> >> - Don't mark class on read. >> >> - Remove reflection and annotation processing related to unnamed classes. >> >> - Simplify main method search. > > Jim Laskey has updated the pull request incrementally with two additional commits since the last revision: > > - Update test/jdk/tools/launcher/InstanceMainTest.java > > Co-authored-by: Jan Lahoda <51319204+lahodaj at users.noreply.github.com> > - Update test/jdk/tools/launcher/InstanceMainTest.java > > Co-authored-by: Jan Lahoda <51319204+lahodaj at users.noreply.github.com> src/jdk.compiler/share/classes/com/sun/tools/javac/processing/PrintingProcessor.java line 129: > 127: Element enclosing = e.getEnclosingElement(); > 128: > 129: // Don't print out the constructor of an anonymous Please add back "class" so that the comment reads "Don't print out the constructor of an anonymous class." ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16461#discussion_r1409810773 From mchung at openjdk.org Wed Nov 29 20:12:05 2023 From: mchung at openjdk.org (Mandy Chung) Date: Wed, 29 Nov 2023 20:12:05 GMT Subject: RFR: 8320716: ResolvedModule::reads includes self when configuration contains two or more automatic modules In-Reply-To: References: Message-ID: On Sun, 26 Nov 2023 18:18:10 GMT, Alan Bateman wrote: > This is update to the specification of the j.l.module.ResolvedModule.reads method to clarify that the set of resolved modules returned does not include itself. There is a small implementation change to align with the specification and fix an anomaly that arises with configurations that contain two or more automatic modules. > > Every module reads itself but the intent with ResolvedModule.reads is that it returns a set that doesn't include self. As things stand right now, the returned set does not include self when all modules in the configuration are explicit modules. However, if the configuration contains two or more automatic modules then the set includes self, a side effect of augmenting the readability graph due to implied readability. > > The specification of the "reads" method is updated. The implementation is also changed to skip automatic modules when augmenting the graph due to implied readability. It is skipped as each automatic module already reads all other modules. Note that it is not goal here to change the algorithm for handling implied readability, this may be a topic for a follow on PR. > > The existing ConfigurationTest already includes several tests for configurations consisting solely of explicit modules, no updates are needed. For configurations that include automatic modules, the existing AutomaticModulesTest is updated to add new asserts to each of the testConfigurationXXX methods. I decided to migrate this test to JUnit while visiting, most of it is just migrating the TestNG data providers to be parameterized tests. If needed then we could separate this but it's a simple migration so I left it in. I read through the resolver implementation and the test changes. Skipping the automatic modules in the process of propagating requires transitive is a simple fix to this issue. Looks good. src/java.base/share/classes/java/lang/module/Resolver.java line 628: > 626: for (Map.Entry> e : g1.entrySet()) { > 627: ResolvedModule m1 = e.getKey(); > 628: if (!m1.descriptor().isAutomatic()) { May be useful to add a comment to explain why automatic modules can be skipped as requires transitive edges for automatic modules already propagated in g1. ------------- Marked as reviewed by mchung (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16818#pullrequestreview-1756073701 PR Review Comment: https://git.openjdk.org/jdk/pull/16818#discussion_r1409779490 From darcy at openjdk.org Wed Nov 29 20:20:31 2023 From: darcy at openjdk.org (Joe Darcy) Date: Wed, 29 Nov 2023 20:20:31 GMT Subject: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v35] In-Reply-To: References: Message-ID: On Tue, 28 Nov 2023 15:00:43 GMT, Jim Laskey wrote: >> test/langtools/tools/javac/ImplicitClass/TestImplicitClass.java line 35: >> >>> 33: import java.lang.reflect.Modifier; >>> 34: >>> 35: public class TestImplicitClass { >> >> The test looks to be testing core reflection behavior (i.e. runtime behavior) and not compile-time behavior via javax.lang.model. >> >> Core reflection tests should be done too, but done the core libraries tests, not langtools tests. >> >> I might have overlooked it, but if some other exercise of compile-time modeling is not being done, please restore and update accordingly the sort of tests previously done in the now-deleted >> >> test/langtools/tools/javac/processing/model/element/TestUnnamedClass.java > > Added To clarify, there should be separate tests of what implicit classes look like under core reflection and under javax.lang.model. As currently written, the current test is a core reflection tests located under the javac/annotation processing test area, which is a misplacement. Please move this test to core reflection, replacing 445's test/jdk/java/lang/Class/UnnamedClass/TestUnnamedClass.java ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16461#discussion_r1409819479 From darcy at openjdk.org Wed Nov 29 20:20:33 2023 From: darcy at openjdk.org (Joe Darcy) Date: Wed, 29 Nov 2023 20:20:33 GMT Subject: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v43] In-Reply-To: References: Message-ID: On Wed, 29 Nov 2023 15:25:15 GMT, Jim Laskey wrote: >> Address changes from JEP 445 to JEP 463. >> >> - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. >> >> - Don't mark class on read. >> >> - Remove reflection and annotation processing related to unnamed classes. >> >> - Simplify main method search. > > Jim Laskey has updated the pull request incrementally with two additional commits since the last revision: > > - Update test/jdk/tools/launcher/InstanceMainTest.java > > Co-authored-by: Jan Lahoda <51319204+lahodaj at users.noreply.github.com> > - Update test/jdk/tools/launcher/InstanceMainTest.java > > Co-authored-by: Jan Lahoda <51319204+lahodaj at users.noreply.github.com> test/langtools/tools/javac/processing/model/element/TestImplicitClass.java line 120: > 118: > 119: /* > 120: * From JEP 445 JLS changes: Update JEP number. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16461#discussion_r1409820065 From alanb at openjdk.org Wed Nov 29 20:23:04 2023 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 29 Nov 2023 20:23:04 GMT Subject: RFR: 8320971: Use BufferedInputStream.buf directly when param of implTransferTo() is trusted In-Reply-To: <1LvXEZt6nHqyDLZhF7IQkVAPOLu-RVNvscLGE1EnDpw=.7ad864c4-0a17-470b-b8a3-d09291057680@github.com> References: <8WNLqjn1mU1xQUQV95cLOwe10A7EesefRtdkQ_lQJrs=.278397c2-bc21-484a-ad23-cc0f95261aa1@github.com> <1LvXEZt6nHqyDLZhF7IQkVAPOLu-RVNvscLGE1EnDpw=.7ad864c4-0a17-470b-b8a3-d09291057680@github.com> Message-ID: On Wed, 29 Nov 2023 20:07:37 GMT, Vladimir Sitnikov wrote: > The buffer in question is protected, so any subclass can directly access it. In other words, untrusted code can easily acoess the buffer, and it does not sound fair to add extra overhead to the method which was created for the performance reasons. If something extends BIS then it has access to the protected fields, this isn't a concern here. Instead, the concern is about passing a reference to the target output stream. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16879#discussion_r1409822279 From roger.riggs at oracle.com Wed Nov 29 20:54:19 2023 From: roger.riggs at oracle.com (Roger Riggs) Date: Wed, 29 Nov 2023 15:54:19 -0500 Subject: Unneeded array assignments in core libs In-Reply-To: References: Message-ID: Hi Anthony, Go ahead a file a single bug (for the two cases). That code may have been written before Arrays.fill(...). Regards, Roger On 11/29/23 7:54 AM, Anthony Goubard wrote: > Hello, > > ?Last Friday, I decided to look if there were some classes that did > unneeded array assignments (e.g. to 0 / 0.0f / null / false) in the JDK. > > ?I've found a few places and in particular 2 places where it's done in > big for loops (looping more than 500 times). So I thought you might be > interested to know about them. > > https://github.com/openjdk/jdk/blob/6871a2ff1207d3ee70973b1c4ee9bd09969c185b/src/java.base/share/classes/java/text/MergeCollation.java#L72 > https://github.com/openjdk/jdk/blob/6871a2ff1207d3ee70973b1c4ee9bd09969c185b/src/java.base/share/classes/sun/text/CompactByteArray.java#L85 > Also for CompactByteArray, maybe it's worth checking that defaultValue > is different than 0 before entering the for loop (Line 80) > > Let me know if you're interested in fixing them and if you want me to > fill 2 bugs for them in the JBS or in bugreport.java.com > . > > Best regards, > Anthony Goubard -------------- next part -------------- An HTML attachment was scrubbed... URL: From anthony.goubard at gmail.com Wed Nov 29 22:18:56 2023 From: anthony.goubard at gmail.com (Anthony Goubard) Date: Wed, 29 Nov 2023 23:18:56 +0100 Subject: Unneeded array assignments in core libs In-Reply-To: References: Message-ID: Thanks for the answers. I've created an issue in bugreport.java.com with internal review ID : 9076287 Hope that helps, Anthony Le mer. 29 nov. 2023 ? 21:55, Roger Riggs a ?crit : > Hi Anthony, > > Go ahead a file a single bug (for the two cases). > That code may have been written before Arrays.fill(...). > > Regards, Roger > > On 11/29/23 7:54 AM, Anthony Goubard wrote: > > Hello, > > Last Friday, I decided to look if there were some classes that did > unneeded array assignments (e.g. to 0 / 0.0f / null / false) in the JDK. > > I've found a few places and in particular 2 places where it's done in big > for loops (looping more than 500 times). So I thought you might be > interested to know about them. > > > https://github.com/openjdk/jdk/blob/6871a2ff1207d3ee70973b1c4ee9bd09969c185b/src/java.base/share/classes/java/text/MergeCollation.java#L72 > > https://github.com/openjdk/jdk/blob/6871a2ff1207d3ee70973b1c4ee9bd09969c185b/src/java.base/share/classes/sun/text/CompactByteArray.java#L85 > Also for CompactByteArray, maybe it's worth checking that defaultValue is > different than 0 before entering the for loop (Line 80) > > Let me know if you're interested in fixing them and if you want me to fill > 2 bugs for them in the JBS or in bugreport.java.com. > > Best regards, > Anthony Goubard > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From duke at openjdk.org Wed Nov 29 22:39:06 2023 From: duke at openjdk.org (Markus KARG) Date: Wed, 29 Nov 2023 22:39:06 GMT Subject: RFR: 8320971: Use BufferedInputStream.buf directly when param of implTransferTo() is trusted In-Reply-To: <1LvXEZt6nHqyDLZhF7IQkVAPOLu-RVNvscLGE1EnDpw=.7ad864c4-0a17-470b-b8a3-d09291057680@github.com> References: <8WNLqjn1mU1xQUQV95cLOwe10A7EesefRtdkQ_lQJrs=.278397c2-bc21-484a-ad23-cc0f95261aa1@github.com> <1LvXEZt6nHqyDLZhF7IQkVAPOLu-RVNvscLGE1EnDpw=.7ad864c4-0a17-470b-b8a3-d09291057680@github.com> Message-ID: On Wed, 29 Nov 2023 20:07:37 GMT, Vladimir Sitnikov wrote: >>> What do you think of passing the buffer as is? >> >> No, it should only do for trusted targets. BAIS has an issue in that area that should be fixed. > > The buffer in question is protected, so any subclass can directly access it. In other words, untrusted code can easily acoess the buffer, and it does not sound fair to add extra overhead to the method which was created for the performance reasons. > > Does copyOfRange do any good here? Do you mean JDK should copy every buffer it passes to non-JDK code? @vlsi Yes, unless the JRE comes up with read-only buffers all untrusted code should get copies of JRE-internal buffers only to provide buffer poisoning and spying data located beyond range limits. Subclasses are free to do what they want with the inherited buffer (it is *their* buffer implicitly), but target output stream might be an injected bad guy that we must not trust in any regard. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16879#discussion_r1409945330 From duke at openjdk.org Wed Nov 29 22:45:05 2023 From: duke at openjdk.org (Markus KARG) Date: Wed, 29 Nov 2023 22:45:05 GMT Subject: RFR: 8320971: Use BufferedInputStream.buf directly when param of implTransferTo() is trusted In-Reply-To: References: Message-ID: On Wed, 29 Nov 2023 11:57:37 GMT, Sergey Tsypanov wrote: > It looks like we can skip copying of `byte[]` in `BufferedInputStream.implTransferTo()` for `OutputStreams` residing in `java.io`. > > See comment by @vlsi in https://github.com/openjdk/jdk/pull/10525/files#diff-e19c508d1bb6ee78697ecca66947c395adda0d9c49a85bf696e677ecbd977af1R612 Thank you for further optimizing transferTo()! If you fix what Alan proposed, this PR LGTM! ? ------------- Changes requested by mkarg at github.com (no known OpenJDK username). PR Review: https://git.openjdk.org/jdk/pull/16879#pullrequestreview-1756336805 From duke at openjdk.org Wed Nov 29 22:45:08 2023 From: duke at openjdk.org (Markus KARG) Date: Wed, 29 Nov 2023 22:45:08 GMT Subject: RFR: 8320971: Use BufferedInputStream.buf directly when param of implTransferTo() is trusted In-Reply-To: References: Message-ID: <06dpAmRUHn4PyHDz2vZLZ9FyzF6u81qj_39hbqP7PnE=.2924f568-9021-46e7-b1fb-0c7a4d5f9c4d@github.com> On Wed, 29 Nov 2023 19:59:03 GMT, Alan Bateman wrote: >> It looks like we can skip copying of `byte[]` in `BufferedInputStream.implTransferTo()` for `OutputStreams` residing in `java.io`. >> >> See comment by @vlsi in https://github.com/openjdk/jdk/pull/10525/files#diff-e19c508d1bb6ee78697ecca66947c395adda0d9c49a85bf696e677ecbd977af1R612 > > src/java.base/share/classes/java/io/BufferedInputStream.java line 647: > >> 645: if (avail > 0) { >> 646: // trust all OutputStreams from java.io >> 647: if (out.getClass().getPackageName() == BufferedInputStream.class.getPackageName()) { > > I don't think Class::getPackageName documents that the returned String is intern so I wonder if the == check will lead to questions and suggestions of a bug. Classes with names starting with "java." can only be defined to the boot or platform class loader (details in the ClassLoader API docs) so you could just check if the package name equals "java.io". Do we only want to trust java.io or anything starting with java.*? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16879#discussion_r1409947085 From jlu at openjdk.org Wed Nov 29 22:47:21 2023 From: jlu at openjdk.org (Justin Lu) Date: Wed, 29 Nov 2023 22:47:21 GMT Subject: RFR: 6230751: [Fmt-Ch] Recursive MessageFormats in ChoiceFormats ignore indicated subformats Message-ID: <7wIjtUukVVmPac0CLynJTK8zIx7Difi9122zthoFj_w=.8e65ff5d-816b-4383-b833-0df272efaede@github.com> Please review this PR which updates an incorrect code example in _java/text/ChoiceFormat_. ChoiceFormat (and MessageFormat) provide an example of how to produce a pattern that supports singular and plural forms. The ChoiceFormat example is incorrect, as recursive MessageFormats produced by a ChoiceFormat subformat only recognize subformats defined through the MessageFormat pattern syntax, not through the subformats contained within the top level MessageFormat. In the original example, `Format[] testFormats = {fileform, null, NumberFormat.getInstance()};` could have been replaced with `Format[] testFormats = {fileform, null, new ChoiceFormat("0#BROKEN")};` and the original output would have been the same. This PR replaces the example with the one used in MessageFormat, which is correct. This PR also includes a drive-by fix to remove leftover `

    `s from a previous `@snippet` conversion. ------------- Commit messages: - change var name in trailing example - replace '.' with ':' - init Changes: https://git.openjdk.org/jdk/pull/16891/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16891&range=00 Issue: https://bugs.openjdk.org/browse/JDK-6230751 Stats: 55 lines in 2 files changed: 1 ins; 29 del; 25 mod Patch: https://git.openjdk.org/jdk/pull/16891.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16891/head:pull/16891 PR: https://git.openjdk.org/jdk/pull/16891 From duke at openjdk.org Wed Nov 29 22:53:22 2023 From: duke at openjdk.org (Markus KARG) Date: Wed, 29 Nov 2023 22:53:22 GMT Subject: RFR: 8294696 - BufferedInputStream.transferTo should drain buffer when mark set [v6] In-Reply-To: References: <6qdrcRAPKcCfsrKlrr91C6mXF9mVKXj3XmDfnvImR_s=.cdb7aac1-abe3-46ea-a573-fd4c0305987e@github.com> Message-ID: On Wed, 29 Nov 2023 05:55:03 GMT, Vladimir Sitnikov wrote: >> src/java.base/share/classes/java/io/BufferedInputStream.java line 612: >> >>> 610: if (avail > 0) { >>> 611: // Prevent poisoning and leaking of buf >>> 612: byte[] buffer = Arrays.copyOfRange(getBufIfOpen(), pos, count); >> >> @mkarg , could you please clarify why you added `Arrays.copyOfRange` here? >> It seems to be an excessive copy that doesn't help much. >> >> `buf` is `protected` in `BufferedInputStream`, so if someone really wants to get hold of the actual buffer, they can subclass `BufferedInputStream` and expose the buffer directly. >> What do you think of removing `copyOfRange`? > > Buffer copy was not there before, and defensive copy was never present in `ByteArrayInputStream` as well: https://github.com/openjdk/jdk/blob/9a6ca233c7e91ffa2ce9451568b3be88ccd04504/src/java.base/share/classes/java/io/ByteArrayInputStream.java#L213 Alan asked for this, and for good reason: While we implicitly trust subclasses as the buffer is "theirs" as part of the inheritance, we do not know where target stream comes from. It could be an injected verhicle to perform (at least) the following: * Leaking data. The target stream could access data beyond the intended region. * Poisoning. The target stream could write into the buffer. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/10525#discussion_r1409957433 From duke at openjdk.org Wed Nov 29 22:53:23 2023 From: duke at openjdk.org (Markus KARG) Date: Wed, 29 Nov 2023 22:53:23 GMT Subject: RFR: 8294696 - BufferedInputStream.transferTo should drain buffer when mark set [v6] In-Reply-To: References: <6qdrcRAPKcCfsrKlrr91C6mXF9mVKXj3XmDfnvImR_s=.cdb7aac1-abe3-46ea-a573-fd4c0305987e@github.com> Message-ID: On Wed, 29 Nov 2023 22:49:17 GMT, Markus KARG wrote: >> Buffer copy was not there before, and defensive copy was never present in `ByteArrayInputStream` as well: https://github.com/openjdk/jdk/blob/9a6ca233c7e91ffa2ce9451568b3be88ccd04504/src/java.base/share/classes/java/io/ByteArrayInputStream.java#L213 > > Alan asked for this, and for good reason: While we implicitly trust subclasses as the buffer is "theirs" as part of the inheritance, we do not know where target stream comes from. It could be an injected verhicle to perform (at least) the following: > * Leaking data. The target stream could access data beyond the intended region. > * Poisoning. The target stream could write into the buffer. As Alan pointed out, it is a bug (actually even a security risk), so BAIS should get fixed, too. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/10525#discussion_r1409958304 From bpb at openjdk.org Wed Nov 29 22:58:22 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 29 Nov 2023 22:58:22 GMT Subject: RFR: 8294696 - BufferedInputStream.transferTo should drain buffer when mark set [v6] In-Reply-To: References: <6qdrcRAPKcCfsrKlrr91C6mXF9mVKXj3XmDfnvImR_s=.cdb7aac1-abe3-46ea-a573-fd4c0305987e@github.com> Message-ID: <10nz53uCtbguOoNZKUl2o2h_1sAvL2OBrMPsD-0HY30=.47617202-6926-4932-b4a8-0880d0585b66@github.com> On Wed, 29 Nov 2023 22:49:58 GMT, Markus KARG wrote: > As Alan pointed out, it is a bug (actually even a security risk), so BAIS should get fixed, too. I am going to file an issue on this. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/10525#discussion_r1409965074 From mchung at openjdk.org Wed Nov 29 23:35:16 2023 From: mchung at openjdk.org (Mandy Chung) Date: Wed, 29 Nov 2023 23:35:16 GMT Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged modules being present [v10] In-Reply-To: References: Message-ID: On Fri, 24 Nov 2023 13:25:35 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 one additional commit since the last revision: > > Tighten ModifiedFilesExitTest > > Ensure the error message is reasonable and doesn't include > Exceptions presented to the user. Thanks. I'll continue the review on the revised version. src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JlinkTask.java line 88: > 86: > 87: // Run time based link internal resources files > 88: private static final String OTHER_RESOURCES_FILE = "jdk/tools/jlink/internal/runlink_%s_resources"; This can be shared with the plugin writing this file. This file collects the hash of the non-class resource files in the image. "runlink" is a confusing prefix. What about: Suggestion: // jlink's internal resource file keeps track of the hash of per-module non-class resources in the run-time image public static final String MODULE_RESOURCES_LIST = "jdk/tools/jlink/internal/%s_resources"; src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JlinkTask.java line 286: > 284: } > 285: > 286: boolean useModulePath = !options.modulePath.isEmpty(); Is there any reason why the run-time image based linking is only supported if `--module-path` is not specified? Linking user modules specified on the module path with the run-time image seems useful. If the module exists in the given module path and the run-time image, the modules from the module path should probably take precedence but it needs to work through the details and potential issues. src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JlinkTask.java line 561: > 559: // Print info message when a run-image link is being performed > 560: if (log != null) { > 561: log.println("'jmods' folder not present, performing a run-time image based link."); This should be a localized message defined in `jlink.properties`. src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JlinkTask.java line 570: > 568: .sorted(Comparator.comparing(ResolvedModule::name)) > 569: .forEach(rm -> log.format("%s %s%s%n", > 570: rm.name(), rm.reference().location().get(), config.useModulePath() ? "" : " (run-time image)")); "run-time image" should also be a localized message. src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JlinkTask.java line 621: > 619: String resName = String.format(OTHER_RESOURCES_FILE, modName); > 620: try { > 621: InputStream inStream = jdkJlink.getResourceAsStream(resName); should it always create the resouorce file for each module even it's empty that might make it easier to catch any issue? src/jdk.jlink/share/classes/jdk/tools/jlink/internal/RunImageArchive.java line 47: > 45: import jdk.tools.jlink.plugin.ResourcePoolEntry.Type; > 46: > 47: public class RunImageArchive implements Archive { What about `JimageArchive` or `JRTArchive`? while jimage does not include the files not in the jimage, it may be okay since that contains most of the files. src/jdk.jlink/share/classes/jdk/tools/jlink/internal/RunImageArchive.java line 52: > 50: // File marker in lib/modules file for java.base indicating it got created > 51: // with a run-image-type link. > 52: private static final String RUNIMAGE_SINGLE_HOP_STAMP = ".runtimeimage.stamp"; This marker file is only used by jlink. So it can be in `jdk.jlink/jdk/tools/jlink/internal/runtimeimage.link.stamp`. src/jdk.jlink/share/classes/jdk/tools/jlink/internal/RunImageArchive.java line 332: > 330: throw new IllegalArgumentException("Unknown type: " + input); > 331: } > 332: } Suggestion: return switch (input) { case CLASS_OR_RESOURCE -> Archive.Entry.EntryType.CLASS_OR_RESOURCE; case CONFIG -> Archive.Entry.EntryType.CONFIG; case HEADER_FILE -> Archive.Entry.EntryType.HEADER_FILE; case LEGAL_NOTICE -> Archive.Entry.EntryType.LEGAL_NOTICE; case MAN_PAGE -> Archive.Entry.EntryType.MAN_PAGE; case NATIVE_CMD -> Archive.Entry.EntryType.NATIVE_CMD; case NATIVE_LIB -> Archive.Entry.EntryType.NATIVE_LIB; case TOP -> throw new IllegalArgumentException("TOP files should be handled by ReleaseInfoPlugin!"); default -> throw new IllegalArgumentException("Unknown type: " + input); }; ------------- PR Comment: https://git.openjdk.org/jdk/pull/14787#issuecomment-1832864251 PR Review Comment: https://git.openjdk.org/jdk/pull/14787#discussion_r1409934416 PR Review Comment: https://git.openjdk.org/jdk/pull/14787#discussion_r1409918050 PR Review Comment: https://git.openjdk.org/jdk/pull/14787#discussion_r1409926488 PR Review Comment: https://git.openjdk.org/jdk/pull/14787#discussion_r1409927957 PR Review Comment: https://git.openjdk.org/jdk/pull/14787#discussion_r1409938120 PR Review Comment: https://git.openjdk.org/jdk/pull/14787#discussion_r1409946933 PR Review Comment: https://git.openjdk.org/jdk/pull/14787#discussion_r1409984852 PR Review Comment: https://git.openjdk.org/jdk/pull/14787#discussion_r1409987063 From naoto at openjdk.org Wed Nov 29 23:37:03 2023 From: naoto at openjdk.org (Naoto Sato) Date: Wed, 29 Nov 2023 23:37:03 GMT Subject: RFR: 6230751: [Fmt-Ch] Recursive MessageFormats in ChoiceFormats ignore indicated subformats In-Reply-To: <7wIjtUukVVmPac0CLynJTK8zIx7Difi9122zthoFj_w=.8e65ff5d-816b-4383-b833-0df272efaede@github.com> References: <7wIjtUukVVmPac0CLynJTK8zIx7Difi9122zthoFj_w=.8e65ff5d-816b-4383-b833-0df272efaede@github.com> Message-ID: On Wed, 29 Nov 2023 22:41:26 GMT, Justin Lu wrote: > Please review this PR which updates an incorrect code example in _java/text/ChoiceFormat_. > > ChoiceFormat (and MessageFormat) provide an example of how to produce a pattern that supports singular and plural forms. The ChoiceFormat example is incorrect, as recursive MessageFormats produced by a ChoiceFormat subformat only recognize subformats defined through the MessageFormat pattern syntax, not through the subformats contained within the top level MessageFormat. > > In the original example, > `Format[] testFormats = {fileform, null, NumberFormat.getInstance()};` could have been replaced with > `Format[] testFormats = {fileform, null, new ChoiceFormat("0#BROKEN")};` and the original output would have been the same. > > This PR replaces the example with the one used in MessageFormat, which is correct. > > This PR also includes a drive-by fix to remove leftover `
    `s from a previous `@snippet` conversion. Do you think it would be helpful if we describe that limitation so that such confusion will not arise? ------------- PR Review: https://git.openjdk.org/jdk/pull/16891#pullrequestreview-1756397913 From bchristi at openjdk.org Wed Nov 29 23:42:06 2023 From: bchristi at openjdk.org (Brent Christian) Date: Wed, 29 Nov 2023 23:42:06 GMT Subject: RFR: 8314480: Memory ordering spec updates in java.lang.ref In-Reply-To: References: Message-ID: On Tue, 21 Nov 2023 09:12:49 GMT, Viktor Klang wrote: >> Classes in the `java.lang.ref` package would benefit from an update to bring the spec in line with how the VM already behaves. The changes would focus on _happens-before_ edges at some key points during reference processing. >> >> A couple key things we want to be able to say are: >> - `Reference.reachabilityFence(x)` _happens-before_ reference processing occurs for 'x'. >> - `Cleaner.register()` _happens-before_ the Cleaner thread runs the registered cleaning action. >> >> This will bring Cleaner in line (or close) with the memory visibility guarantees made for finalizers in [JLS 17.4.5](https://docs.oracle.com/javase/specs/jls/se18/html/jls-17.html#jls-17.4.5): >> _"There is a happens-before edge from the end of a constructor of an object to the start of a finalizer (?12.6) for that object."_ > > src/java.base/share/classes/java/lang/ref/Reference.java line 497: > >> 495: * or {@link ReferenceQueue#remove}. >> 496: * >> 497: *

    This method is invoked only by Java code; when the garbage collector > > Perhaps something along the lines of: > > Suggestion: > > *

    This method is only invoked explicitly; when the garbage collector I think the important part to convey is that the GC won't call this method. So how about _just_:

    When the garbage collector enqueues references it does so directly, without invoking this method. ? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16644#discussion_r1409993103 From bpb at openjdk.org Thu Nov 30 00:08:19 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 30 Nov 2023 00:08:19 GMT Subject: RFR: 8321053: Use ByteArrayInputStream.buf directly when parameter of transferTo() is trusted Message-ID: Pass `ByteArrayInputStream.buf ` directly to the `OutputStream` parameter of `BAIS.transferTo` only if the target stream is in the `java.io` package. ------------- Commit messages: - 8321053: Use ByteArrayInputStream.buf directly when parameter of transferTo() is trusted Changes: https://git.openjdk.org/jdk/pull/16893/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16893&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8321053 Stats: 95 lines in 2 files changed: 94 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/16893.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16893/head:pull/16893 PR: https://git.openjdk.org/jdk/pull/16893 From bpb at openjdk.org Thu Nov 30 00:11:05 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 30 Nov 2023 00:11:05 GMT Subject: RFR: 8320971: Use BufferedInputStream.buf directly when param of implTransferTo() is trusted In-Reply-To: References: Message-ID: On Wed, 29 Nov 2023 11:57:37 GMT, Sergey Tsypanov wrote: > It looks like we can skip copying of `byte[]` in `BufferedInputStream.implTransferTo()` for `OutputStreams` residing in `java.io`. > > See comment by @vlsi in https://github.com/openjdk/jdk/pull/10525/files#diff-e19c508d1bb6ee78697ecca66947c395adda0d9c49a85bf696e677ecbd977af1R612 If there is already test coverage of this area (I don't think there is), then the `noreg-other` label with a comment should be added to the issue. Otherwise, test coverage should be added, or some other `noreg-*` label added to the issue, if justified. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16879#issuecomment-1832894268 From jlu at openjdk.org Thu Nov 30 00:23:04 2023 From: jlu at openjdk.org (Justin Lu) Date: Thu, 30 Nov 2023 00:23:04 GMT Subject: RFR: 6230751: [Fmt-Ch] Recursive MessageFormats in ChoiceFormats ignore indicated subformats In-Reply-To: References: <7wIjtUukVVmPac0CLynJTK8zIx7Difi9122zthoFj_w=.8e65ff5d-816b-4383-b833-0df272efaede@github.com> Message-ID: On Wed, 29 Nov 2023 23:34:14 GMT, Naoto Sato wrote: > Do you think it would be helpful if we describe that limitation so that such confusion will not arise? Yes, that's a good point. I didn't initially include one because I wanted to look into [JDK-4270867](https://bugs.openjdk.org/browse/JDK-4270867) (which would be the fix to the limitation) first. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16891#issuecomment-1832905952 From bchristi at openjdk.org Thu Nov 30 00:53:04 2023 From: bchristi at openjdk.org (Brent Christian) Date: Thu, 30 Nov 2023 00:53:04 GMT Subject: RFR: 8314480: Memory ordering spec updates in java.lang.ref In-Reply-To: References: Message-ID: On Tue, 21 Nov 2023 22:46:32 GMT, Roger Riggs wrote: >> src/java.base/share/classes/java/lang/ref/Reference.java line 489: >> >>> 487: *

    If this reference was already enqueued (by the garbage collector, or a >>> 488: * previous call to {@code enqueue}), this method is not successful, >>> 489: * and returns false. >> >> If we're going to talk about successful and unsuccessful calls, we should define what success is first. I guess that would be something like: if this ref is registered with a queue and not already enqueued, it is enqueued successfully and the method returns true. Otherwise, not successful, and returns false. > > This could be worded as a post condition, after the call the ref is enqueued with the queue; the return is true iff the ref was not previously enqueued. > The enqueuing is not conditional (assuming the queue is non-null). I'll give that some thought. The enqueuing is not conditional, but the _happens-before_ is... ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16644#discussion_r1410031119 From eliu at openjdk.org Thu Nov 30 00:59:05 2023 From: eliu at openjdk.org (Eric Liu) Date: Thu, 30 Nov 2023 00:59:05 GMT Subject: RFR: 8319872: AArch64: [vectorapi] Implementation of unsigned (zero extended) casts [v4] In-Reply-To: References: Message-ID: On Wed, 22 Nov 2023 07:05:21 GMT, Eric Liu wrote: >> Vector API defines zero-extend operations [1], which are going to be intrinsified and generated to `VectorUCastNode` by C2. This patch adds backend implementation for `VectorUCastNode` on AArch64. >> >> The micro benchmark shows significant performance improvement. In my test machine (SVE, 256-bit), the result is shown as below: >> >> >> >> Benchmark Before After Units Gain >> VectorZeroExtend.byte2Int 3168.251 243012.399 ops/ms 75.70 >> VectorZeroExtend.byte2Long 3212.201 216291.588 ops/ms 66.33 >> VectorZeroExtend.byte2Short 3391.968 182655.365 ops/ms 52.85 >> VectorZeroExtend.int2Long 1012.197 80448.553 ops/ms 78.48 >> VectorZeroExtend.short2Int 1812.471 153416.828 ops/ms 83.65 >> VectorZeroExtend.short2Long 1788.382 129794.814 ops/ms 71.58 >> >> >> On other Neon systems, we can get similar performance boost as a result of intrinsification success. >> >> Since `VectorUCastNode` only used in Vector API's zero extension currently, this patch also adds assertion on nodes' definitions to clarify their usages. >> >> [TEST] >> compiler/vectorapi and jdk/incubator/vector passed on NEON and SVE machines. >> >> [1] https://github.com/openjdk/jdk/blob/master/src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorOperators.java#L726 > > Eric Liu has updated the pull request incrementally with one additional commit since the last revision: > > small fix > > Change-Id: Icfe9619af1c9e7d5ea8cac457ccebb4eec5c34ad @theRealAph Could you help to take a look? Thanks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16670#issuecomment-1832934884 From sviswanathan at openjdk.org Thu Nov 30 03:41:04 2023 From: sviswanathan at openjdk.org (Sandhya Viswanathan) Date: Thu, 30 Nov 2023 03:41:04 GMT Subject: RFR: 8319577: x86_64 AVX2 intrinsics for Arrays.sort methods (int, float arrays) [v2] In-Reply-To: References: <4XHLjTI5l8tGKCU8_iE53H7EY9-0EjR1gbbFWF57rfI=.8b7585bd-f829-4c3b-81ca-ddc8301c2179@github.com> Message-ID: On Tue, 28 Nov 2023 20:52:35 GMT, Srinivas Vamsi Parasa wrote: >> Thanks Sandhya, will fix this issue. > > Thanks Sandhya for suggesting the change to use supports_simd_sort(BasicType bt). Please see the updated code upstreamed. @vamsi-parasa Thanks, your changes look good to me. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16534#discussion_r1410117695 From duke at openjdk.org Thu Nov 30 04:29:04 2023 From: duke at openjdk.org (jmehrens) Date: Thu, 30 Nov 2023 04:29:04 GMT Subject: RFR: 8321053: Use ByteArrayInputStream.buf directly when parameter of transferTo() is trusted In-Reply-To: References: Message-ID: On Thu, 30 Nov 2023 00:03:21 GMT, Brian Burkhalter wrote: > Pass `ByteArrayInputStream.buf ` directly to the `OutputStream` parameter of `BAIS.transferTo` only if the target stream is in the `java.io` package. src/java.base/share/classes/java/io/ByteArrayInputStream.java line 211: > 209: if (len > 0) { > 210: byte[] tmp; > 211: if ("java.io".equals(out.getClass().getPackageName())) Isn't this protection defeated with: ByteArrayInputStream bais = new ByteArrayInputStream(bytes); UntrustedOutputStream uos = new UntrustedOutputStream(); bais.transferTo(new java.io.DataOutputStream(uos)); Or am I missing something? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16893#discussion_r1410139928 From duke at openjdk.org Thu Nov 30 04:35:05 2023 From: duke at openjdk.org (jmehrens) Date: Thu, 30 Nov 2023 04:35:05 GMT Subject: RFR: 8320971: Use BufferedInputStream.buf directly when param of implTransferTo() is trusted In-Reply-To: <06dpAmRUHn4PyHDz2vZLZ9FyzF6u81qj_39hbqP7PnE=.2924f568-9021-46e7-b1fb-0c7a4d5f9c4d@github.com> References: <06dpAmRUHn4PyHDz2vZLZ9FyzF6u81qj_39hbqP7PnE=.2924f568-9021-46e7-b1fb-0c7a4d5f9c4d@github.com> Message-ID: On Wed, 29 Nov 2023 22:38:59 GMT, Markus KARG wrote: >> src/java.base/share/classes/java/io/BufferedInputStream.java line 647: >> >>> 645: if (avail > 0) { >>> 646: // trust all OutputStreams from java.io >>> 647: if (out.getClass().getPackageName() == BufferedInputStream.class.getPackageName()) { >> >> I don't think Class::getPackageName documents that the returned String is intern so I wonder if the == check will lead to questions and suggestions of a bug. Classes with names starting with "java." can only be defined to the boot or platform class loader (details in the ClassLoader API docs) so you could just check if the package name equals "java.io". > > Do we only want to trust java.io or anything starting with java.*? I don't think checking if the package is java.io is secure: ByteArrayInputStream bais = new ByteArrayInputStream(bytes); BufferedInputStream bis = new BufferedInputStream(bais); UntrustedOutputStream uos = new UntrustedOutputStream(); bis.transferTo(new java.io.DataOutputStream(uos)); You have to know that it is in the java.io package and it doesn't wrap another stream. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16879#discussion_r1410142200 From xgong at openjdk.org Thu Nov 30 06:39:43 2023 From: xgong at openjdk.org (Xiaohong Gong) Date: Thu, 30 Nov 2023 06:39:43 GMT Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations with SLEEF [v5] In-Reply-To: References: Message-ID: > Currently the vector floating-point math APIs like `VectorOperators.SIN/COS/TAN...` are not intrinsified on AArch64 platform, which causes large performance gap on AArch64. Note that those APIs are optimized by C2 compiler on X86 platforms by calling Intel's SVML code [1]. To close the gap, we would like to optimize these APIs for AArch64 by calling a third-party vector library called libsleef [2], which are available in mainstream Linux distros (e.g. [3] [4]). > > SLEEF supports multiple accuracies. To match Vector API's requirement and implement the math ops on AArch64, we 1) call 1.0 ULP accuracy with FMA instructions used stubs in libsleef for most of the operations by default, and 2) add the vector calling convention to apply with the runtime calls to stub code in libsleef. Note that for those APIs that libsleef does not support 1.0 ULP, we choose 0.5 ULP instead. > > To help loading the expected libsleef library, this patch also adds an experimental JVM option (i.e. `-XX:UseSleefLib`) for AArch64 platforms. People can use it to denote the libsleef path/name explicitly. By default, it points to the system installed library. If the library does not exist or the dynamic loading of it in runtime fails, the math vector ops will fall-back to use the default scalar version without error. But a warning is printed out if people specifies a nonexistent library explicitly. > > Note that this is a part of the original proposed patch in panama-dev [5], just with some initial review comments addressed. And now we'd like to get some wider feedbacks from more hotspot experts. > > [1] https://github.com/openjdk/jdk/pull/3638 > [2] https://sleef.org/ > [3] https://packages.fedoraproject.org/pkgs/sleef/sleef/ > [4] https://packages.debian.org/bookworm/libsleef3 > [5] https://mail.openjdk.org/pipermail/panama-dev/2022-December/018172.html Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision: Rename vmath to sleef in configure ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16234/files - new: https://git.openjdk.org/jdk/pull/16234/files/2c3c4a64..c1ce1968 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16234&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16234&range=03-04 Stats: 268 lines in 6 files changed: 137 ins; 126 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/16234.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16234/head:pull/16234 PR: https://git.openjdk.org/jdk/pull/16234 From xgong at openjdk.org Thu Nov 30 07:54:11 2023 From: xgong at openjdk.org (Xiaohong Gong) Date: Thu, 30 Nov 2023 07:54:11 GMT Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations with SLEEF [v4] In-Reply-To: References: <3dscjw75an6_n3ko_2LjHdpdj08xsyjhfpStuZrS5-M=.f43592fe-036e-47b5-babc-67f126885839@github.com> Message-ID: On Thu, 23 Nov 2023 14:05:51 GMT, Magnus Ihse Bursie wrote: >> Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision: >> >> Address review comments in build system > > make/autoconf/lib-vmath.m4 line 70: > >> 68: if test "x$SYSROOT" = "x" && >> 69: test "x${LIBSLEEF_FOUND}" = "xno"; then >> 70: PKG_CHECK_MODULES([LIBSLEEF], [sleef], [LIBSLEEF_FOUND=yes], [LIBSLEEF_FOUND=no]) > > Suggestion: > > PKG_CHECK_MODULES([SLEEF], [sleef], [LIBSLEEF_FOUND=yes], [LIBSLEEF_FOUND=no]) > > > Otherwise `PKG_CHECK_MODULES` will set the variables LIBSLEEF_CFLAGS and LIBSLEEF_LIBS. Keep using `LIBSLEEF`, as the cflags and libs are named with `LIBSLEEF_` prefix. Thanks! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16234#discussion_r1410275161 From dfenacci at openjdk.org Thu Nov 30 08:05:20 2023 From: dfenacci at openjdk.org (Damon Fenacci) Date: Thu, 30 Nov 2023 08:05:20 GMT Subject: RFR: 8311906: Improve robustness of String constructors with mutable array inputs [v13] In-Reply-To: References: <6SKlGLh5MmxoEx07wHCCUc8KWbbhcspLJmcc1uxQ_FI=.ca33bfb4-fa5c-45f0-b49f-ee6c5c6b68b4@github.com> Message-ID: On Mon, 27 Nov 2023 19:09:40 GMT, Roger Riggs wrote: >> Strings, after construction, are immutable but may be constructed from mutable arrays of bytes, characters, or integers. >> The string constructors should guard against the effects of mutating the arrays during construction that might invalidate internal invariants for the correct behavior of operations on the resulting strings. In particular, a number of operations have optimizations for operations on pairs of latin1 strings and pairs of non-latin1 strings, while operations between latin1 and non-latin1 strings use a more general implementation. >> >> The changes include: >> >> - Adding a warning to each constructor with an array as an argument to indicate that the results are indeterminate >> if the input array is modified before the constructor returns. >> The resulting string may contain any combination of characters sampled from the input array. >> >> - Ensure that strings that are represented as non-latin1 contain at least one non-latin1 character. >> For latin1 inputs, whether the arrays contain ASCII, ISO-8859-1, UTF8, or another encoding decoded to latin1 the scanning and compression is unchanged. >> If a non-latin1 character is found, the string is represented as non-latin1 with the added verification that a non-latin1 character is present at the same index. >> If that character is found to be latin1, then the input array has been modified and the result of the scan may be incorrect. >> Though a ConcurrentModificationException could be thrown, the risk to an existing application of an unexpected exception should be avoided. >> Instead, the non-latin1 copy of the input is re-scanned and compressed; that scan determines whether the latin1 or the non-latin1 representation is returned. >> >> - The methods that scan for non-latin1 characters and their intrinsic implementations are updated to return the index of the non-latin1 character. >> >> - String construction from StringBuilder and CharSequence must also be guarded as their contents may be modified during construction. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Use byte off branches in char_array_compress > Verified by manual tests with "-XX:AVX3Threshold=0" > And test in the PR test/hotspot/jtreg/compiler/intrinsics/string/TestStringConstructionIntrinsics.java src/hotspot/cpu/x86/macroAssembler_x86.cpp line 8547: > 8545: // bail out when there is nothing to be done > 8546: testl(tmp5, 0xFFFFFFFF); > 8547: jcc(Assembler::zero, post_alignment); @RogerRiggs I think you changed the wrong line ? Suggestion: jccb(Assembler::zero, post_alignment); src/hotspot/cpu/x86/macroAssembler_x86.cpp line 8559: > 8557: evpcmpw(mask1, mask2, tmp1Reg, tmp2Reg, Assembler::le, /*signed*/ false, Assembler::AVX_512bit); > 8558: ktestd(mask1, mask2); > 8559: jccb(Assembler::carryClear, copy_tail); Suggestion: jcc(Assembler::carryClear, copy_tail); (in this case the jump can potentially be long) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16425#discussion_r1410283240 PR Review Comment: https://git.openjdk.org/jdk/pull/16425#discussion_r1410284158 From xgong at openjdk.org Thu Nov 30 08:07:15 2023 From: xgong at openjdk.org (Xiaohong Gong) Date: Thu, 30 Nov 2023 08:07:15 GMT Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations with SLEEF [v3] In-Reply-To: References: <97YS_I-DY-Q5agE6mE-iBkoVxtvL7R4Q3NebjTsXMvI=.dac0dc99-84d7-4cbd-ada6-5190564688a9@github.com> Message-ID: On Wed, 22 Nov 2023 09:05:31 GMT, Andrew Haley wrote: >>> Have you considered the possibility of copying the sleef source to the OpenJDK repository and thereby it becomes part of the build process? I don't know how straightforward that is technically and IANAL but I think it's worth exploring. >>> >> >> Hi @PaulSandoz ! Thanks for the suggestion! Copying the sleef source sounds good. However, I actually have no idea about how to handle the third-party licence in OpenJDK project. Do you have any idea about this area? Some suggestions/guidence from the JDK team will be much helpful. Thanks! > >> > Have you considered the possibility of copying the sleef source to the OpenJDK repository and thereby it becomes part of the build process? I don't know how straightforward that is technically and IANAL but I think it's worth exploring. >> >> Hi @PaulSandoz ! Thanks for the suggestion! Copying the sleef source sounds good. However, I actually have no idea about how to handle the third-party licence in OpenJDK project. Do you have any idea about this area? Some suggestions/guidence from the JDK team will be much helpful. Thanks! > > From a legal pespective, we can do this. SLEEF is distributed under Boost Software License Version 1.0., which is a GPL-compatible free software licence. The only issue is whether we want to do so. It would certainly be convenient. Hi @theRealAph , @magicus , The latest commit renamed `vmath` in configure to `sleef`, and the Arm SVE cflags is removed to `flags-cflags.m4` now. I was thinking about separating the NEON and SVE functions in `libvmath.so` to two source files, and add the SVE cflags just for SVE functions as needed. But it seems I have to write the make commands manually, which I think is not good? But I can have a try if it's necessary. Since the sve flags is just used for building `libvmath.so` now, moving it to `flags-cflags.m4` seems not so right? @magicus , may I have your comments on this part? Thanks in advance! > Don't touch the make system.Instead, try to open the library at runtime with os::dll_open(), after (or inside) VM_Version::initialize(). > > If you're not running on an SVE system, none of the SVE routines will be called, so it doesn't matter, right? Yes, the SVE routines are called only on the SVE system. So I think it doesn't matter. I tested with the image built on non-sve machine and ran the Vector API tests on SVE machine, and it works well. It also works well on the contrary situation. Best Regards, Xiaohong ------------- PR Comment: https://git.openjdk.org/jdk/pull/16234#issuecomment-1833278899 From stsypanov at openjdk.org Thu Nov 30 08:58:18 2023 From: stsypanov at openjdk.org (Sergey Tsypanov) Date: Thu, 30 Nov 2023 08:58:18 GMT Subject: RFR: 8320971: Use BufferedInputStream.buf directly when param of implTransferTo() is trusted [v2] In-Reply-To: References: Message-ID: > It looks like we can skip copying of `byte[]` in `BufferedInputStream.implTransferTo()` for `OutputStreams` residing in `java.io`. > > See comment by @vlsi in https://github.com/openjdk/jdk/pull/10525/files#diff-e19c508d1bb6ee78697ecca66947c395adda0d9c49a85bf696e677ecbd977af1R612 Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision: 8320971: Trust any OutputStream from java.* ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16879/files - new: https://git.openjdk.org/jdk/pull/16879/files/d5ab8bfb..7779aaca Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16879&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16879&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/16879.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16879/head:pull/16879 PR: https://git.openjdk.org/jdk/pull/16879 From alanb at openjdk.org Thu Nov 30 09:01:06 2023 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 30 Nov 2023 09:01:06 GMT Subject: RFR: 8320971: Use BufferedInputStream.buf directly when param of implTransferTo() is trusted [v2] In-Reply-To: References: <06dpAmRUHn4PyHDz2vZLZ9FyzF6u81qj_39hbqP7PnE=.2924f568-9021-46e7-b1fb-0c7a4d5f9c4d@github.com> Message-ID: <6IitbefHaaKPhCkB_FRZnBxTyZJi0i8jjh8Pr32jsb8=.956ea224-3aff-4c86-9e28-6399172bfc92@github.com> On Thu, 30 Nov 2023 04:31:41 GMT, jmehrens wrote: > You have to know that it is in the java.io package and it doesn't wrap another stream. That is a good point. In the previous work on this override, we converged on the current implementation to not leak the internal byte[] to the target. It could be special cased for trusted targets but at the cost of auditing and complexity. So more thought needed on this, I don't think the current change can be integrated. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16879#discussion_r1410353132 From ihse at openjdk.org Thu Nov 30 09:20:14 2023 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Thu, 30 Nov 2023 09:20:14 GMT Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations with SLEEF [v5] In-Reply-To: References: Message-ID: On Thu, 30 Nov 2023 06:39:43 GMT, Xiaohong Gong wrote: >> Currently the vector floating-point math APIs like `VectorOperators.SIN/COS/TAN...` are not intrinsified on AArch64 platform, which causes large performance gap on AArch64. Note that those APIs are optimized by C2 compiler on X86 platforms by calling Intel's SVML code [1]. To close the gap, we would like to optimize these APIs for AArch64 by calling a third-party vector library called libsleef [2], which are available in mainstream Linux distros (e.g. [3] [4]). >> >> SLEEF supports multiple accuracies. To match Vector API's requirement and implement the math ops on AArch64, we 1) call 1.0 ULP accuracy with FMA instructions used stubs in libsleef for most of the operations by default, and 2) add the vector calling convention to apply with the runtime calls to stub code in libsleef. Note that for those APIs that libsleef does not support 1.0 ULP, we choose 0.5 ULP instead. >> >> To help loading the expected libsleef library, this patch also adds an experimental JVM option (i.e. `-XX:UseSleefLib`) for AArch64 platforms. People can use it to denote the libsleef path/name explicitly. By default, it points to the system installed library. If the library does not exist or the dynamic loading of it in runtime fails, the math vector ops will fall-back to use the default scalar version without error. But a warning is printed out if people specifies a nonexistent library explicitly. >> >> Note that this is a part of the original proposed patch in panama-dev [5], just with some initial review comments addressed. And now we'd like to get some wider feedbacks from more hotspot experts. >> >> [1] https://github.com/openjdk/jdk/pull/3638 >> [2] https://sleef.org/ >> [3] https://packages.fedoraproject.org/pkgs/sleef/sleef/ >> [4] https://packages.debian.org/bookworm/libsleef3 >> [5] https://mail.openjdk.org/pipermail/panama-dev/2022-December/018172.html > > Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision: > > Rename vmath to sleef in configure make/autoconf/spec.gmk.in line 892: > 890: PNG_CFLAGS:=@PNG_CFLAGS@ > 891: > 892: ENABLE_LIBSLEEF:=@ENABLE_LIBSLEEF@ You need to merge in the latest changes from mainline. I have just updated spec.gmk.in to always have a space around `:=`. Please do so with your additions as well. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16234#discussion_r1410378540 From ihse at openjdk.org Thu Nov 30 09:37:35 2023 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Thu, 30 Nov 2023 09:37:35 GMT Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations with SLEEF [v5] In-Reply-To: References: Message-ID: On Thu, 30 Nov 2023 06:39:43 GMT, Xiaohong Gong wrote: >> Currently the vector floating-point math APIs like `VectorOperators.SIN/COS/TAN...` are not intrinsified on AArch64 platform, which causes large performance gap on AArch64. Note that those APIs are optimized by C2 compiler on X86 platforms by calling Intel's SVML code [1]. To close the gap, we would like to optimize these APIs for AArch64 by calling a third-party vector library called libsleef [2], which are available in mainstream Linux distros (e.g. [3] [4]). >> >> SLEEF supports multiple accuracies. To match Vector API's requirement and implement the math ops on AArch64, we 1) call 1.0 ULP accuracy with FMA instructions used stubs in libsleef for most of the operations by default, and 2) add the vector calling convention to apply with the runtime calls to stub code in libsleef. Note that for those APIs that libsleef does not support 1.0 ULP, we choose 0.5 ULP instead. >> >> To help loading the expected libsleef library, this patch also adds an experimental JVM option (i.e. `-XX:UseSleefLib`) for AArch64 platforms. People can use it to denote the libsleef path/name explicitly. By default, it points to the system installed library. If the library does not exist or the dynamic loading of it in runtime fails, the math vector ops will fall-back to use the default scalar version without error. But a warning is printed out if people specifies a nonexistent library explicitly. >> >> Note that this is a part of the original proposed patch in panama-dev [5], just with some initial review comments addressed. And now we'd like to get some wider feedbacks from more hotspot experts. >> >> [1] https://github.com/openjdk/jdk/pull/3638 >> [2] https://sleef.org/ >> [3] https://packages.fedoraproject.org/pkgs/sleef/sleef/ >> [4] https://packages.debian.org/bookworm/libsleef3 >> [5] https://mail.openjdk.org/pipermail/panama-dev/2022-December/018172.html > > Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision: > > Rename vmath to sleef in configure This version looks much better, thank you! I guess cflags/SVE_CFLAGS is an okay-ish solution. I'm still not 100% happy though, but it might be due to my limited understanding. Let me write down a few numbered statements and then you can tell me if I'm right or wrong. 1. The aarch64 supports two different SIMD instruction set additions, Neon and SVE. 2. A specific instance of an aarch64 CPU can implement Neon, or SVE, or none of them, but not both. 3. SVE is superior to Neon, and is far more common these days. 4. We would like to ship a single version of libvmath.so, that supports SVE if it happens to be run on a CPU with SVE. 5. THe same version will just use the fallback code that "works" but has lower performance if run on a CPU without SVE (regardless of if it has Neon or not) 6. If libvmath.so is built without SVE support, and is then run on a CPU with SVE, it will "work", but not utilize the SVE functionality, so have degraded performance compared to what we want. 7. To be able to build libvmath.so with SVE support, we need to be able to compile a simple test program using `#include ` and `-march=armv8-a+sve`. If this fails, we cannot build libvmath.so with SVE support. 8. The ability to build with SVE support should only be dependent on the gcc compiler and sysroot header files, and not the SIMD instruction set of the build machine CPU. If all these are correct, then I think the problem is that we just silently ignore if building with SVE fails. Instead, it should cause configure to fail. If, for some reason, we must support build environment that cannot build for SVE, then we need to have a configure flag that allows us to require the presence of SVE building ability, like --enable-sve-support, which will be "auto" by default and thus adapt to the platform, but can be set to on, which will cause a configure fail if the platform does not have SVE compilation abilities. We cannot just silently drop expected functionality depending on the build machine, or at the very least, we must have a way to prevent that from happening. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16234#issuecomment-1833403493 From duke at openjdk.org Thu Nov 30 09:38:32 2023 From: duke at openjdk.org (Bernd) Date: Thu, 30 Nov 2023 09:38:32 GMT Subject: RFR: 8320971: Use BufferedInputStream.buf directly when param of implTransferTo() is trusted [v2] In-Reply-To: References: Message-ID: On Thu, 30 Nov 2023 08:58:18 GMT, Sergey Tsypanov wrote: >> It looks like we can skip copying of `byte[]` in `BufferedInputStream.implTransferTo()` for `OutputStreams` residing in `java.io`. >> >> See comment by @vlsi in https://github.com/openjdk/jdk/pull/10525/files#diff-e19c508d1bb6ee78697ecca66947c395adda0d9c49a85bf696e677ecbd977af1R612 > > Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision: > > 8320971: Trust any OutputStream from java.* Did you review if all Java.* streams are safe? There are a few stream adapters in sun.nio.ch, which would benefit this optimization too, unfortunately they wrap the arrays with ByteBuffer.wrap, I guess that?s not safe, so the package can?t be allowed? ------------- PR Comment: https://git.openjdk.org/jdk/pull/16879#issuecomment-1833404968 From ihse at openjdk.org Thu Nov 30 09:40:44 2023 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Thu, 30 Nov 2023 09:40:44 GMT Subject: RFR: 8319577: x86_64 AVX2 intrinsics for Arrays.sort methods (int, float arrays) [v4] In-Reply-To: References: Message-ID: On Thu, 16 Nov 2023 07:04:52 GMT, David Holmes wrote: >> Hi Magnus, the new x86-simd-sort 4.0 needs C++17 to compile. Will look into the changes needed for this library to compile without the C++17 standard and get back to you. >> >> Thanks, >> Vamsi > > Seems a bit odd to me too as the existing simd code seems to C code residing in .cpp files for some reason. Yeah, that is also a good point. Why setting C++ flags in CFLAGS, and not just CXXFLAGS? Also @vamsi-parasa, did you check into if this really was needed and why? To be clear, I basically consider this an integration blocker. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16534#discussion_r1410405668 From vsitnikov at openjdk.org Thu Nov 30 09:50:16 2023 From: vsitnikov at openjdk.org (Vladimir Sitnikov) Date: Thu, 30 Nov 2023 09:50:16 GMT Subject: RFR: 8320971: Use BufferedInputStream.buf directly when param of implTransferTo() is trusted [v2] In-Reply-To: <6IitbefHaaKPhCkB_FRZnBxTyZJi0i8jjh8Pr32jsb8=.956ea224-3aff-4c86-9e28-6399172bfc92@github.com> References: <06dpAmRUHn4PyHDz2vZLZ9FyzF6u81qj_39hbqP7PnE=.2924f568-9021-46e7-b1fb-0c7a4d5f9c4d@github.com> <6IitbefHaaKPhCkB_FRZnBxTyZJi0i8jjh8Pr32jsb8=.956ea224-3aff-4c86-9e28-6399172bfc92@github.com> Message-ID: On Thu, 30 Nov 2023 08:58:18 GMT, Alan Bateman wrote: >> I don't think checking if the package is java.io is secure: >> >> ByteArrayInputStream bais = new ByteArrayInputStream(bytes); >> BufferedInputStream bis = new BufferedInputStream(bais); >> UntrustedOutputStream uos = new UntrustedOutputStream(); >> bis.transferTo(new java.io.DataOutputStream(uos)); >> >> You have to know that it is in the java.io package and it doesn't wrap another stream. > >> You have to know that it is in the java.io package and it doesn't wrap another stream. > > That is a good point. In the previous work on this override, we converged on the current implementation to not leak the internal byte[] to the target. It could be special cased for trusted targets but at the cost of auditing and complexity. So more thought needed on this, I don't think the current change can be integrated. What do you think of adding `OutputStream extends WritableByteChannel`, so `transferTo` could be implemented with `if (target instanceof WritableByteChannel) { target.write(ByteBuffer.wrap(buf, off, len).asReadOnly()); }`? Read-only byte buffer will not allow modifying the data in the buffer, it would eliminate buffer copies, and adding `write(ByteBuffer)` to `OutputStream` seems reasonable. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16879#discussion_r1410416823 From ihse at openjdk.org Thu Nov 30 09:58:21 2023 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Thu, 30 Nov 2023 09:58:21 GMT Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations with SLEEF [v5] In-Reply-To: References: Message-ID: On Thu, 30 Nov 2023 06:39:43 GMT, Xiaohong Gong wrote: >> Currently the vector floating-point math APIs like `VectorOperators.SIN/COS/TAN...` are not intrinsified on AArch64 platform, which causes large performance gap on AArch64. Note that those APIs are optimized by C2 compiler on X86 platforms by calling Intel's SVML code [1]. To close the gap, we would like to optimize these APIs for AArch64 by calling a third-party vector library called libsleef [2], which are available in mainstream Linux distros (e.g. [3] [4]). >> >> SLEEF supports multiple accuracies. To match Vector API's requirement and implement the math ops on AArch64, we 1) call 1.0 ULP accuracy with FMA instructions used stubs in libsleef for most of the operations by default, and 2) add the vector calling convention to apply with the runtime calls to stub code in libsleef. Note that for those APIs that libsleef does not support 1.0 ULP, we choose 0.5 ULP instead. >> >> To help loading the expected libsleef library, this patch also adds an experimental JVM option (i.e. `-XX:UseSleefLib`) for AArch64 platforms. People can use it to denote the libsleef path/name explicitly. By default, it points to the system installed library. If the library does not exist or the dynamic loading of it in runtime fails, the math vector ops will fall-back to use the default scalar version without error. But a warning is printed out if people specifies a nonexistent library explicitly. >> >> Note that this is a part of the original proposed patch in panama-dev [5], just with some initial review comments addressed. And now we'd like to get some wider feedbacks from more hotspot experts. >> >> [1] https://github.com/openjdk/jdk/pull/3638 >> [2] https://sleef.org/ >> [3] https://packages.fedoraproject.org/pkgs/sleef/sleef/ >> [4] https://packages.debian.org/bookworm/libsleef3 >> [5] https://mail.openjdk.org/pipermail/panama-dev/2022-December/018172.html > > Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision: > > Rename vmath to sleef in configure Okay, now I found a few more of your comments that I missed before. I apologize, the Github PR review UI can be a bit confusing when discussions are taking place in multiple locations. So, here's a revision to my list above: 1. An aach64 CPU can have both Neon and SVE present at the same time. 2. You are assuming that Neon is always present, and what I referred to as the fallback case is in fact using Neon instead of SVE. 4. You would like to split vect_math.c into two parts, e.g. vect_math_neon.c and vect_math_sve.c. 5. You will then, use heuristics in hotspot to determine at runtime if SVE or Neon functionality should be used. Even if SVE is present on the runtime machine, heuristics can chose to use the Neon implementation anyway in some cases. 6. Only vect_math_sve.c. need the -march+sve. 7. The neon part do not need the -march+sve flag, and will fail if built with this flag. (???) The last point seemed very confusing to me. Right now, you can compile the entire file with the -march+sve flag, right? Anyway, it is straightforward to add compiler flags to individual files. You do it like this: $(eval $(call SetupJdkLibrary, BUILD_LIBVMATH, \ NAME := vmath, \ CFLAGS := $(CFLAGS_JDKLIB) $(LIBSLEEF_CFLAGS) -fvisibility=default, \ vect_math_sve.c_CFLAGS := $(SVE_CFLAGS), \ ... ------------- PR Comment: https://git.openjdk.org/jdk/pull/16234#issuecomment-1833434870 From sgehwolf at openjdk.org Thu Nov 30 10:00:14 2023 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Thu, 30 Nov 2023 10:00:14 GMT Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged modules being present [v10] In-Reply-To: References: Message-ID: On Wed, 29 Nov 2023 22:26:37 GMT, Mandy Chung wrote: >> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision: >> >> Tighten ModifiedFilesExitTest >> >> Ensure the error message is reasonable and doesn't include >> Exceptions presented to the user. > > src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JlinkTask.java line 621: > >> 619: String resName = String.format(OTHER_RESOURCES_FILE, modName); >> 620: try { >> 621: InputStream inStream = jdkJlink.getResourceAsStream(resName); > > should it always create the resouorce file for each module even it's empty that might make it easier to catch any issue? Sure this can be done. Makes the jimage a bit larger, but probably negligible as the total set of modules is usually small. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14787#discussion_r1410430626 From sgehwolf at openjdk.org Thu Nov 30 10:03:21 2023 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Thu, 30 Nov 2023 10:03:21 GMT Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged modules being present [v10] In-Reply-To: References: Message-ID: <_U2g2Ejo3uiZ3BdWm-lMSFrZG0Bs8kaX-1TyUT-sasM=.8ba32a2b-9841-4912-b37a-40b281ddfe11@github.com> On Wed, 29 Nov 2023 22:21:58 GMT, Mandy Chung wrote: >> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision: >> >> Tighten ModifiedFilesExitTest >> >> Ensure the error message is reasonable and doesn't include >> Exceptions presented to the user. > > src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JlinkTask.java line 88: > >> 86: >> 87: // Run time based link internal resources files >> 88: private static final String OTHER_RESOURCES_FILE = "jdk/tools/jlink/internal/runlink_%s_resources"; > > This can be shared with the plugin writing this file. This file collects the hash of the non-class resource files in the image. "runlink" is a confusing prefix. What about: > Suggestion: > > // jlink's internal resource file keeps track of the hash of per-module non-class resources in the run-time image > public static final String MODULE_RESOURCES_LIST = "jdk/tools/jlink/internal/%s_resources"; Happy to change the prefix. Having a (unique) prefix seems useful, though, since it eases filtering. Note: that file is not only there for the hash sums, but also to keep track of the path to the files in the filesystem, which we'd otherwise not know. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14787#discussion_r1410434806 From vklang at openjdk.org Thu Nov 30 10:05:33 2023 From: vklang at openjdk.org (Viktor Klang) Date: Thu, 30 Nov 2023 10:05:33 GMT Subject: RFR: 8319123: Implement JEP 461: Stream Gatherers (Preview) [v5] In-Reply-To: References: <8VQk_eX35V8wo8YSfdTGCi0XxZklabPegtiBU-lg_8M=.3c560f0e-9df3-4d21-a03a-0554c1451a90@github.com> Message-ID: On Mon, 13 Nov 2023 10:08:20 GMT, Tagir F. Valeev wrote: >> Viktor Klang has updated the pull request incrementally with one additional commit since the last revision: >> >> Minor improvements to Gatherer Javadoc > > Marked as reviewed by tvaleev (Committer). @amaembo, @AlanBateman, @dfuch, @PaulSandoz This is now ready for sponsorship :) ------------- PR Comment: https://git.openjdk.org/jdk/pull/16420#issuecomment-1833446181 From alanb at openjdk.org Thu Nov 30 10:14:31 2023 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 30 Nov 2023 10:14:31 GMT Subject: RFR: 8319123: Implement JEP 461: Stream Gatherers (Preview) [v5] In-Reply-To: References: <8VQk_eX35V8wo8YSfdTGCi0XxZklabPegtiBU-lg_8M=.3c560f0e-9df3-4d21-a03a-0554c1451a90@github.com> Message-ID: On Mon, 13 Nov 2023 10:08:20 GMT, Tagir F. Valeev wrote: >> Viktor Klang has updated the pull request incrementally with one additional commit since the last revision: >> >> Minor improvements to Gatherer Javadoc > > Marked as reviewed by tvaleev (Committer). > @amaembo, @AlanBateman, @dfuch, @PaulSandoz This is now ready for sponsorship :) I can do, just want to double check tier1 with a merge from master as your branch is a bit behind. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16420#issuecomment-1833460716 From sgehwolf at openjdk.org Thu Nov 30 10:16:11 2023 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Thu, 30 Nov 2023 10:16:11 GMT Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged modules being present [v10] In-Reply-To: References: Message-ID: On Wed, 29 Nov 2023 22:01:57 GMT, Mandy Chung wrote: >> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision: >> >> Tighten ModifiedFilesExitTest >> >> Ensure the error message is reasonable and doesn't include >> Exceptions presented to the user. > > src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JlinkTask.java line 286: > >> 284: } >> 285: >> 286: boolean useModulePath = !options.modulePath.isEmpty(); > > Is there any reason why the run-time image based linking is only supported if `--module-path` is not specified? Linking user modules specified on the module path with the run-time image seems useful. If the module exists in the given module path and the run-time image, the modules from the module path should probably take precedence but it needs to work through the details and potential issues. I haven't looked into the details, but the common case is for jlink users to use the default module path (`jmods` folder of the JDK install) and the prime use-case for this is to get away with performing a link without the packaged modules (no "external" dependency if you will; of that `jmods` folder). It could be considered as a follow-up. In this patch I wouldn't want to complicate it further if that sounds OK? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14787#discussion_r1410450707 From jpai at openjdk.org Thu Nov 30 10:20:09 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 30 Nov 2023 10:20:09 GMT Subject: RFR: JDK-8319626: Override toString() for ZipFile [v4] In-Reply-To: References: Message-ID: On Wed, 29 Nov 2023 01:10:29 GMT, Bernd wrote: >> Hi Alan, >> >> Thanks for taking a look. I updated the toString() value to the one you suggested, and also dropped the specific aspects of the specification. >> >> I am not sure if you have a preference one way or another regarding providing the full path versus just the file name, but I can switch the full path for just the file name if need be. > > I like the new wording (have no oppinion if absolute path is better). Hello Justin, > I am not sure if you have a preference one way or another regarding providing the full path versus just the file name, but I can switch the full path for just the file name if need be. My opinion is that we should not use the absolute path here. Section 2.1 of secure coding guidelines https://www.oracle.com/java/technologies/javase/seccodeguide.html#2-1 suggests not to include full paths in exception messages. With the proposed change to the toString() method here, which uses absolute paths, I think it would then mean that we would have to review (within the JDK) usages of (explicit or implicit) `ZipFile.toString()` to prevent accidentally including the complete paths in the exceptions, like in the case below: final ZipFile zf = new ZipFile("/home/me/xyz.zip"); ... // do something throw new Exception("failed to handle zipfile " + zf); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16643#discussion_r1410455514 From aph at openjdk.org Thu Nov 30 10:33:12 2023 From: aph at openjdk.org (Andrew Haley) Date: Thu, 30 Nov 2023 10:33:12 GMT Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations with SLEEF [v5] In-Reply-To: References: Message-ID: On Thu, 30 Nov 2023 09:35:04 GMT, Magnus Ihse Bursie wrote: > This version looks much better, thank you! I guess cflags/SVE_CFLAGS is an okay-ish solution. > > I'm still not 100% happy though, but it might be due to my limited > understanding. Let me write down a few numbered statements and then > you can tell me if I'm right or wrong. > > 1. The aarch64 supports two different SIMD instruction set additions, Neon and SVE. True. > 2. A specific instance of an aarch64 CPU can implement Neon, or SVE, or none of them, but not both. All AArch64 CPUs which support SVE also supprt Neon. SVE is incomplete, and many functions still need Neon. > 3. SVE is superior to Neon, and is far more common these days. No. SVE is partial, and extends Neon, and is still fairly uncommon. > 4. We would like to ship a single version of libvmath.so, that supports SVE if it happens to be run on a CPU with SVE. True. > 5. THe same version will just use the fallback code that "works" > but has lower performance if run on a CPU without SVE (regardless of > if it has Neon or not) True. > 6. If libvmath.so is built without SVE support, and is then run > on a CPU with SVE, it will "work", but not utilize the SVE > functionality, so have degraded performance compared to what we > want. True. > 7. To be able to build libvmath.so with SVE support, we need to > be able to compile a simple test program using `#include > ` and `-march=armv8-a+sve`. If this fails, we cannot > build libvmath.so with SVE support. arm_sve.h is part of GCC. It was added to GCC in 2019. > 8. The ability to build with SVE support should only be > dependent on the gcc compiler and sysroot header files, and not the > SIMD instruction set of the build machine CPU. True. I'm not at all sure it should even depend on GCC. If I were doing this I'd build the interposition library in pure asm. In fact, given that SLEEF is using pure C linkage, defining the library in pure asm is trivial, and we can get rid of all this configury mess. > If all these are correct, then I think the problem is that we just > silently ignore if building with SVE fails. Instead, it should cause > configure to fail. > > If, for some reason, we must support build environment that cannot > build for SVE, then we need to have a configure flag that allows us > to require the presence of SVE building ability, like > --enable-sve-support, which will be "auto" by default and thus adapt > to the platform, but can be set to on, which will cause a configure > fail if the platform does not have SVE compilation abilities. > > We cannot just silently drop expected functionality depending on the > build machine, or at the very least, we must have a way to prevent > that from happening. True. Let's just drop the requirement to require GCC support for SVE. We don't need it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16234#issuecomment-1833489792 From aturbanov at openjdk.org Thu Nov 30 10:53:34 2023 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Thu, 30 Nov 2023 10:53:34 GMT Subject: RFR: 8319123: Implement JEP 461: Stream Gatherers (Preview) [v12] In-Reply-To: References: Message-ID: On Fri, 17 Nov 2023 18:46:57 GMT, Andrey Turbanov wrote: >> Viktor Klang has updated the pull request incrementally with one additional commit since the last revision: >> >> Addressing trailing whitespace complaint > > src/java.base/share/classes/java/util/stream/GathererOp.java line 297: > >> 295: * There's a very small subset of possible Gatherers which would be >> 296: * expressible as Spliterators directly, >> 297: * - the Gatherer's initializer is Gatherer.defaultInitiatizer(), > > typo > Suggestion: > > * - the Gatherer's initializer is Gatherer.defaultInitializer(), Let's fix at least a typo ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1410495723 From jpai at openjdk.org Thu Nov 30 11:01:07 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 30 Nov 2023 11:01:07 GMT Subject: RFR: 8320798: Console read line with zero out should zero out underlying buffer [v2] In-Reply-To: References: Message-ID: On Tue, 28 Nov 2023 19:30:34 GMT, Naoto Sato wrote: >> It is best practice to zero out the underlying buffer after use. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > corrected fromIndex src/java.base/share/classes/sun/nio/cs/StreamDecoder.java line 293: > 291: > 292: private void lockedFillZeroToPosition() throws IOException { > 293: ensureOpen(); Hello Naoto, is this open check needed? Given that we are just zeroing out already read content, would it thus be OK to clear that content to zero even after this `Reader` instance has been closed? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16861#discussion_r1410504144 From stsypanov at openjdk.org Thu Nov 30 11:12:36 2023 From: stsypanov at openjdk.org (Sergey Tsypanov) Date: Thu, 30 Nov 2023 11:12:36 GMT Subject: RFR: 8320971: Use BufferedInputStream.buf directly when param of implTransferTo() is trusted [v3] In-Reply-To: References: Message-ID: > It looks like we can skip copying of `byte[]` in `BufferedInputStream.implTransferTo()` for `OutputStreams` residing in `java.io`. > > See comment by @vlsi in https://github.com/openjdk/jdk/pull/10525/files#diff-e19c508d1bb6ee78697ecca66947c395adda0d9c49a85bf696e677ecbd977af1R612 Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision: 8320971: Add test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16879/files - new: https://git.openjdk.org/jdk/pull/16879/files/7779aaca..a77208e0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16879&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16879&range=01-02 Stats: 80 lines in 1 file changed: 80 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/16879.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16879/head:pull/16879 PR: https://git.openjdk.org/jdk/pull/16879 From jpai at openjdk.org Thu Nov 30 11:13:10 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 30 Nov 2023 11:13:10 GMT Subject: RFR: 8320798: Console read line with zero out should zero out underlying buffer [v2] In-Reply-To: References: Message-ID: On Tue, 28 Nov 2023 19:30:34 GMT, Naoto Sato wrote: >> It is best practice to zero out the underlying buffer after use. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > corrected fromIndex Given that the default `JdkConsole` provider implementation is the one that uses jline (in `jdk.internal.le` module), should we also do something to zero out this data in its implementation too. A brief glance suggests that it too uses an internal implementation class called `jdk.internal.org.jline.reader.impl.BufferImpl`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16861#issuecomment-1833550541 From aph at openjdk.org Thu Nov 30 11:16:12 2023 From: aph at openjdk.org (Andrew Haley) Date: Thu, 30 Nov 2023 11:16:12 GMT Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations with SLEEF [v5] In-Reply-To: References: Message-ID: <9VeMdTAJPaPZDg9ZW7FVJOf9XGl4gGqAS-2g8SFc9c0=.36792cd5-66d9-4abc-ba0c-aee3478627f4@github.com> On Thu, 30 Nov 2023 06:39:43 GMT, Xiaohong Gong wrote: >> Currently the vector floating-point math APIs like `VectorOperators.SIN/COS/TAN...` are not intrinsified on AArch64 platform, which causes large performance gap on AArch64. Note that those APIs are optimized by C2 compiler on X86 platforms by calling Intel's SVML code [1]. To close the gap, we would like to optimize these APIs for AArch64 by calling a third-party vector library called libsleef [2], which are available in mainstream Linux distros (e.g. [3] [4]). >> >> SLEEF supports multiple accuracies. To match Vector API's requirement and implement the math ops on AArch64, we 1) call 1.0 ULP accuracy with FMA instructions used stubs in libsleef for most of the operations by default, and 2) add the vector calling convention to apply with the runtime calls to stub code in libsleef. Note that for those APIs that libsleef does not support 1.0 ULP, we choose 0.5 ULP instead. >> >> To help loading the expected libsleef library, this patch also adds an experimental JVM option (i.e. `-XX:UseSleefLib`) for AArch64 platforms. People can use it to denote the libsleef path/name explicitly. By default, it points to the system installed library. If the library does not exist or the dynamic loading of it in runtime fails, the math vector ops will fall-back to use the default scalar version without error. But a warning is printed out if people specifies a nonexistent library explicitly. >> >> Note that this is a part of the original proposed patch in panama-dev [5], just with some initial review comments addressed. And now we'd like to get some wider feedbacks from more hotspot experts. >> >> [1] https://github.com/openjdk/jdk/pull/3638 >> [2] https://sleef.org/ >> [3] https://packages.fedoraproject.org/pkgs/sleef/sleef/ >> [4] https://packages.debian.org/bookworm/libsleef3 >> [5] https://mail.openjdk.org/pipermail/panama-dev/2022-December/018172.html > > Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision: > > Rename vmath to sleef in configure make/autoconf/lib-sleef.m4 line 56: > 54: AC_MSG_CHECKING([for the specified LIBSLEEF]) > 55: if test -e ${with_libsleef}/lib/libsleef.so && > 56: test -e ${with_libsleef}/include/sleef.h; then This fails on my system because libsleef is in `/usr/local/lib64/`. This is the correct place to look according to the Linux FHS. You should hard-code `/lib` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16234#discussion_r1410520870 From jpai at openjdk.org Thu Nov 30 11:50:11 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 30 Nov 2023 11:50:11 GMT Subject: RFR: 8318971: Better Error Handling for Jar Tool Processing of "@File" [v5] In-Reply-To: References: Message-ID: On Tue, 28 Nov 2023 12:18:23 GMT, Ryan Wallace wrote: >> Hi all, >> >> Please review this fix for jar tool not producing an archive if there is a missing file supplied. >> The current behaviour will recognise missing files as an error but continue processing, >> creating a temporary archive and then deleting it without moving to the current directory. >> The fix is to return false when a missing file is supplied and exit immediately without continuing with any wasted processing. >> >> Thanks, >> Ryan. > > Ryan Wallace has updated the pull request with a new target base 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 8318971 > - 8318971: Better Error Handling for Jar Tool Processing of "@File" > - Merge branch 'master' into 8318971 > - Merge branch 'master' into 8318971 > - 8318971: jar v17 should either exit on error immediately or create archive as jar v1.8 did > - 8318971: jar v17 should either exit on error immediately or create archive as jar v1.8 did > - Merge branch 'master' into 8318971 > - 8318971: jar v17 should either exit on error immediately or create archive as jar v1.8 did > - 8318971: jar v17 should either exit on error immediately or create archive as jar v1.8 did Hello Ryan, I haven't yet had a chance to fully focus on this PR to review. I will do it in the coming days. I think it would anyway be better to have this change done only after the JDK 22 repo is forked. That will then give it some time to be tested in 23 EA releases. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16423#issuecomment-1833611026 From aph at openjdk.org Thu Nov 30 11:51:11 2023 From: aph at openjdk.org (Andrew Haley) Date: Thu, 30 Nov 2023 11:51:11 GMT Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations with SLEEF [v5] In-Reply-To: References: Message-ID: <8SBUvWGDLtQmwYPRBDeUkeuq4pf2nJfKfDY5rzZODFU=.3f1cc0ff-02e6-4a4e-9425-5ffccc9cbc8f@github.com> On Thu, 30 Nov 2023 06:39:43 GMT, Xiaohong Gong wrote: >> Currently the vector floating-point math APIs like `VectorOperators.SIN/COS/TAN...` are not intrinsified on AArch64 platform, which causes large performance gap on AArch64. Note that those APIs are optimized by C2 compiler on X86 platforms by calling Intel's SVML code [1]. To close the gap, we would like to optimize these APIs for AArch64 by calling a third-party vector library called libsleef [2], which are available in mainstream Linux distros (e.g. [3] [4]). >> >> SLEEF supports multiple accuracies. To match Vector API's requirement and implement the math ops on AArch64, we 1) call 1.0 ULP accuracy with FMA instructions used stubs in libsleef for most of the operations by default, and 2) add the vector calling convention to apply with the runtime calls to stub code in libsleef. Note that for those APIs that libsleef does not support 1.0 ULP, we choose 0.5 ULP instead. >> >> To help loading the expected libsleef library, this patch also adds an experimental JVM option (i.e. `-XX:UseSleefLib`) for AArch64 platforms. People can use it to denote the libsleef path/name explicitly. By default, it points to the system installed library. If the library does not exist or the dynamic loading of it in runtime fails, the math vector ops will fall-back to use the default scalar version without error. But a warning is printed out if people specifies a nonexistent library explicitly. >> >> Note that this is a part of the original proposed patch in panama-dev [5], just with some initial review comments addressed. And now we'd like to get some wider feedbacks from more hotspot experts. >> >> [1] https://github.com/openjdk/jdk/pull/3638 >> [2] https://sleef.org/ >> [3] https://packages.fedoraproject.org/pkgs/sleef/sleef/ >> [4] https://packages.debian.org/bookworm/libsleef3 >> [5] https://mail.openjdk.org/pipermail/panama-dev/2022-December/018172.html > > Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision: > > Rename vmath to sleef in configure Do this, but with the name vect_math.S. Don't use SLEEF headers in the build. I think you can do this with no build-time dependency on SLEEF at all if you load the library lazily at runtime. [vect_math.S.txt](https://github.com/openjdk/jdk/files/13512306/vect_math.S.txt) ------------- PR Comment: https://git.openjdk.org/jdk/pull/16234#issuecomment-1833610537 From alanb at openjdk.org Thu Nov 30 11:59:05 2023 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 30 Nov 2023 11:59:05 GMT Subject: RFR: 8320798: Console read line with zero out should zero out underlying buffer [v2] In-Reply-To: References: Message-ID: On Thu, 30 Nov 2023 11:10:44 GMT, Jaikiran Pai wrote: > Given that the default `JdkConsole` provider implementation is the one that uses jline (in `jdk.internal.le` module), should we also do something to zero out this data in its implementation too. A brief glance suggests that it too uses an internal implementation class called `jdk.internal.org.jline.reader.impl.BufferImpl`. This PR is the console implementation in java.base, there will be other changes for jline. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16861#issuecomment-1833622797 From isipka at openjdk.org Thu Nov 30 12:12:19 2023 From: isipka at openjdk.org (Ivan =?UTF-8?B?xaBpcGth?=) Date: Thu, 30 Nov 2023 12:12:19 GMT Subject: Integrated: 8320665: update jdk_core at open/test/jdk/TEST.groups In-Reply-To: References: Message-ID: On Thu, 23 Nov 2023 14:31:40 GMT, Ivan ?ipka wrote: > @bwhuang-us @mahendrachhipa This pull request has now been integrated. Changeset: da7cf258 Author: Ivan ?ipka Committer: Mark Sheppard URL: https://git.openjdk.org/jdk/commit/da7cf258bb5b24788409dde084ad012bd64a032a Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod 8320665: update jdk_core at open/test/jdk/TEST.groups Reviewed-by: msheppar ------------- PR: https://git.openjdk.org/jdk/pull/16796 From jpai at openjdk.org Thu Nov 30 12:25:05 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 30 Nov 2023 12:25:05 GMT Subject: RFR: 8320699: Add parameter to skip progress logging of OutputAnalyzer In-Reply-To: References: Message-ID: <2GfcEQux8lS9so4y1IwGbFg9YAcsJ_XjdhkIdeBdkEE=.1d4b59c7-eef5-406d-8880-d992af851e71@github.com> On Fri, 24 Nov 2023 10:34:02 GMT, Stefan Karlsson wrote: > Tests using ProcessTools.executeProcess gets the following output written to stdout: > [2023-11-24T09:58:16.797540608Z] Gathering output for process 2517117 > [2023-11-24T09:58:23.070781345Z] Waiting for completion for process 2517117 > [2023-11-24T09:58:23.071045055Z] Waiting for completion finished for process 2517117 > > This might be good for some use cases and debugging, but some tests spawns a large number of processes and for those this output fills up the log files. > > I propose that we add a way to turn of this output for tests where we find this output to be too noisy. Hello Stefan, > The test were I want to use this is a long-running stress test that is known to be good at shaking out JVM hangs. It has been written to provide its own output about spawned processes and what they are doing, and have that info written to appropriate files. For me, the OutputAnalyzer logging just adds redundant output to the streams where I don't want the information. Thank you for that context. What you are then proposing is for a way to reuse this utility class in specific tests, like the one you are working on, without needing the progress logs. So the idea isn't really to use this new API in all newly developed tests which use this `ProcessTools` library. Plus the implementation in this PR, retains the existing behaviour of logging the progress by default, which is a good thing. Given that context, I don't have any objection in introducing this enhancemnet. During future reviews, I think, it wouldn't be too difficult to catch misuses of this new API in newer tests where the progress logs shouldn't be disabled. As for whether this "config" should be externalized - I think it shouldn't be, since whether or not the progress logs will be excessive and too distracting (and thus need to be disabled) would be known at test development time itself. The copyright year on `OutputBuffer.java` will need an update. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16807#issuecomment-1833660673 PR Comment: https://git.openjdk.org/jdk/pull/16807#issuecomment-1833664072 From jpai at openjdk.org Thu Nov 30 12:25:06 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 30 Nov 2023 12:25:06 GMT Subject: RFR: 8320699: Add parameter to skip progress logging of OutputAnalyzer In-Reply-To: References: Message-ID: <0YQ_sX9Qd5cLqD4QCmm7tr6-mErCAP5mkcyfhkvM8Rg=.af702b06-57ec-4cf1-99b6-f5b96b9a488e@github.com> On Mon, 27 Nov 2023 08:27:25 GMT, Stefan Karlsson wrote: > So, I think you have found a separate issue. I'll open a separate issue for that and propose a change. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16807#issuecomment-1833661517 From stsypanov at openjdk.org Thu Nov 30 12:37:04 2023 From: stsypanov at openjdk.org (Sergey Tsypanov) Date: Thu, 30 Nov 2023 12:37:04 GMT Subject: RFR: 8321053: Use ByteArrayInputStream.buf directly when parameter of transferTo() is trusted In-Reply-To: References: Message-ID: On Thu, 30 Nov 2023 00:03:21 GMT, Brian Burkhalter wrote: > Pass `ByteArrayInputStream.buf ` directly to the `OutputStream` parameter of `BAIS.transferTo` only if the target stream is in the `java.io` package. src/java.base/share/classes/java/io/ByteArrayInputStream.java line 211: > 209: if (len > 0) { > 210: byte[] tmp; > 211: if ("java.io".equals(out.getClass().getPackageName())) I think we should trust all classes in `java.*` packages, i.e. the check should be out.getClass().getPackageName().startsWith("java.") ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16893#discussion_r1410610109 From jlaskey at openjdk.org Thu Nov 30 12:47:31 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Thu, 30 Nov 2023 12:47:31 GMT Subject: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v43] In-Reply-To: References: Message-ID: On Wed, 29 Nov 2023 20:07:50 GMT, Joe Darcy wrote: >> Jim Laskey has updated the pull request incrementally with two additional commits since the last revision: >> >> - Update test/jdk/tools/launcher/InstanceMainTest.java >> >> Co-authored-by: Jan Lahoda <51319204+lahodaj at users.noreply.github.com> >> - Update test/jdk/tools/launcher/InstanceMainTest.java >> >> Co-authored-by: Jan Lahoda <51319204+lahodaj at users.noreply.github.com> > > src/jdk.compiler/share/classes/com/sun/tools/javac/processing/PrintingProcessor.java line 129: > >> 127: Element enclosing = e.getEnclosingElement(); >> 128: >> 129: // Don't print out the constructor of an anonymous > > Please add back "class" so that the comment reads "Don't print out the constructor of an anonymous class." Done > test/langtools/tools/javac/processing/model/element/TestImplicitClass.java line 120: > >> 118: >> 119: /* >> 120: * From JEP 445 JLS changes: > > Update JEP number. Done ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16461#discussion_r1410623183 PR Review Comment: https://git.openjdk.org/jdk/pull/16461#discussion_r1410623324 From stsypanov at openjdk.org Thu Nov 30 12:48:04 2023 From: stsypanov at openjdk.org (Sergey Tsypanov) Date: Thu, 30 Nov 2023 12:48:04 GMT Subject: RFR: 8320971: Use BufferedInputStream.buf directly when param of implTransferTo() is trusted [v2] In-Reply-To: References: Message-ID: On Thu, 30 Nov 2023 09:36:01 GMT, Bernd wrote: >> Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision: >> >> 8320971: Trust any OutputStream from java.* > > Did you review if all Java.* streams are safe? > > There are a few stream adapters in sun.nio.ch, which would benefit this optimization too, unfortunately they wrap the arrays with ByteBuffer.wrap, I guess that?s not safe, so the package can?t be allowed? @ecki I've checked the streams in `java.*` and it looks like none of them modifies the incoming `byte[]` ------------- PR Comment: https://git.openjdk.org/jdk/pull/16879#issuecomment-1833712361 From jlaskey at openjdk.org Thu Nov 30 12:54:10 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Thu, 30 Nov 2023 12:54:10 GMT Subject: RFR: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) [v44] In-Reply-To: References: Message-ID: > Address changes from JEP 445 to JEP 463. > > - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. > > - Don't mark class on read. > > - Remove reflection and annotation processing related to unnamed classes. > > - Simplify main method search. Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: Correct comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16461/files - new: https://git.openjdk.org/jdk/pull/16461/files/7ed4045a..cb0ed86b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16461&range=43 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16461&range=42-43 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/16461.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16461/head:pull/16461 PR: https://git.openjdk.org/jdk/pull/16461 From jlaskey at openjdk.org Thu Nov 30 12:54:13 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Thu, 30 Nov 2023 12:54:13 GMT Subject: Integrated: JDK-8315458 Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) In-Reply-To: References: Message-ID: On Wed, 1 Nov 2023 18:56:13 GMT, Jim Laskey wrote: > Address changes from JEP 445 to JEP 463. > > - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. > > - Don't mark class on read. > > - Remove reflection and annotation processing related to unnamed classes. > > - Simplify main method search. This pull request has now been integrated. Changeset: 04ad98ed Author: Jim Laskey URL: https://git.openjdk.org/jdk/commit/04ad98ed32cf899404a3ae13e24407e53be7ebc6 Stats: 1529 lines in 52 files changed: 671 ins; 723 del; 135 mod 8315458: Implement JEP 463: Implicitly Declared Classes and Instance Main Method (Second Preview) Reviewed-by: jlahoda, mcimadamore, vromero, rriggs, alanb, mchung ------------- PR: https://git.openjdk.org/jdk/pull/16461 From asemenyuk at openjdk.org Thu Nov 30 14:20:16 2023 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Thu, 30 Nov 2023 14:20:16 GMT Subject: RFR: 8227529: With malformed --app-image the error messages are awful Message-ID: Add tests to make sure jpackage emits meaningful error messages when used with invalid app images. Added `JPackageCommand.nullableOutputBundle()` function that returns an empty `Optional` instance if it fails to deduce a path to the output bundle from jpackage command line. This is the case when jpackage command is used with `--app-image` cli option and referenced app image directory is missing `.jpackage.xml` file. ------------- Commit messages: - 8227529: With malformed --app-image the error messages are awful Changes: https://git.openjdk.org/jdk/pull/16901/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16901&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8227529 Stats: 71 lines in 3 files changed: 64 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/16901.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16901/head:pull/16901 PR: https://git.openjdk.org/jdk/pull/16901 From asemenyuk at openjdk.org Thu Nov 30 14:20:17 2023 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Thu, 30 Nov 2023 14:20:17 GMT Subject: RFR: 8227529: With malformed --app-image the error messages are awful In-Reply-To: References: Message-ID: On Thu, 30 Nov 2023 14:14:56 GMT, Alexey Semenyuk wrote: > Add tests to make sure jpackage emits meaningful error messages when used with invalid app images. > > Added `JPackageCommand.nullableOutputBundle()` function that returns an empty `Optional` instance if it fails to deduce a path to the output bundle from jpackage command line. This is the case when jpackage command is used with `--app-image` cli option and referenced app image directory is missing `.jpackage.xml` file. @sashamatveev please review ------------- PR Comment: https://git.openjdk.org/jdk/pull/16901#issuecomment-1833861929 From duke at openjdk.org Thu Nov 30 14:20:28 2023 From: duke at openjdk.org (Weibing Xiao) Date: Thu, 30 Nov 2023 14:20:28 GMT Subject: RFR: 8315034 : File.mkdirs() occasionally fails to create folders on Windows shared folder Message-ID: File.mkdirs() occasionally fails to create folders on Windows shared folders. It turned out that Windows API FindFirstFileW created the error ERROR_NO_MORE_FILES. In some of the cases with a valid file path, this error still returns this error code, which supposedly should not. Adding this error code into the method of lastErrorReportable in the native code will be handled by JDK. To test the fix, it needs to run three Java processes to create the folders on a remote file server. ------------- Commit messages: - remove test file - 8315034 : File.mkdirs() occasionally fails to create folders on Windows shared folder Changes: https://git.openjdk.org/jdk/pull/16502/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16502&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8315034 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/16502.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16502/head:pull/16502 PR: https://git.openjdk.org/jdk/pull/16502 From duke at openjdk.org Thu Nov 30 14:20:29 2023 From: duke at openjdk.org (Weibing Xiao) Date: Thu, 30 Nov 2023 14:20:29 GMT Subject: RFR: 8315034 : File.mkdirs() occasionally fails to create folders on Windows shared folder In-Reply-To: References: Message-ID: On Fri, 3 Nov 2023 18:11:10 GMT, Weibing Xiao wrote: > File.mkdirs() occasionally fails to create folders on Windows shared folders. It turned out that Windows API FindFirstFileW created the error ERROR_NO_MORE_FILES. In some of the cases with a valid file path, this error still returns this error code, which supposedly should not. > > Adding this error code into the method of lastErrorReportable in the native code will be handled by JDK. > > To test the fix, it needs to run three Java processes to create the folders on a remote file server. Removed the test file and added the label to JBS ------------- PR Comment: https://git.openjdk.org/jdk/pull/16502#issuecomment-1833862715 From alanb at openjdk.org Thu Nov 30 14:20:31 2023 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 30 Nov 2023 14:20:31 GMT Subject: RFR: 8315034 : File.mkdirs() occasionally fails to create folders on Windows shared folder In-Reply-To: References: Message-ID: <3n9ach7f8u8NRqXvRRBchVrkHu6k3wOtHtxB3k61sh8=.2fa0f018-3a42-43d7-ab84-259d5866fa4b@github.com> On Fri, 3 Nov 2023 18:11:10 GMT, Weibing Xiao wrote: > File.mkdirs() occasionally fails to create folders on Windows shared folders. It turned out that Windows API FindFirstFileW created the error ERROR_NO_MORE_FILES. In some of the cases with a valid file path, this error still returns this error code, which supposedly should not. > > Adding this error code into the method of lastErrorReportable in the native code will be handled by JDK. > > To test the fix, it needs to run three Java processes to create the folders on a remote file server. src/java.base/windows/native/libjava/canonicalize_md.c line 142: > 140: || (errval == ERROR_NETWORK_UNREACHABLE) > 141: || (errval == ERROR_NETWORK_ACCESS_DENIED) > 142: || (errval == ERROR_NO_MORE_FILES)) { @bplb Is this the same thing as JDK-8234363? Does this also need to be handled in the FindFirstFile usage in WindowsDirectoryStream? test/jdk/java/io/File/WindowsFileCreation.java line 34: > 32: * needs to run three Java processes simultaneously to verify the fix. > 33: * This test requires to run manually and the parent folder as Windows shared folder should be existing already. > 34: */ There's no `@test` tag so this test won't run, not even as a manual test. I would be inclined to just drop this test and add the "noreg-hard" label to the issue. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16502#discussion_r1382531676 PR Review Comment: https://git.openjdk.org/jdk/pull/16502#discussion_r1382384469 From bpb at openjdk.org Thu Nov 30 14:20:32 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 30 Nov 2023 14:20:32 GMT Subject: RFR: 8315034 : File.mkdirs() occasionally fails to create folders on Windows shared folder In-Reply-To: <3n9ach7f8u8NRqXvRRBchVrkHu6k3wOtHtxB3k61sh8=.2fa0f018-3a42-43d7-ab84-259d5866fa4b@github.com> References: <3n9ach7f8u8NRqXvRRBchVrkHu6k3wOtHtxB3k61sh8=.2fa0f018-3a42-43d7-ab84-259d5866fa4b@github.com> Message-ID: <5Yzs7c3J57atA4SJat5LAh9aXnCd1fAjWQMx51ODApo=.b24d9d27-cc5e-4b62-b6b8-6184ddb468e7@github.com> On Sun, 5 Nov 2023 09:40:00 GMT, Alan Bateman wrote: >> File.mkdirs() occasionally fails to create folders on Windows shared folders. It turned out that Windows API FindFirstFileW created the error ERROR_NO_MORE_FILES. In some of the cases with a valid file path, this error still returns this error code, which supposedly should not. >> >> Adding this error code into the method of lastErrorReportable in the native code will be handled by JDK. >> >> To test the fix, it needs to run three Java processes to create the folders on a remote file server. > > src/java.base/windows/native/libjava/canonicalize_md.c line 142: > >> 140: || (errval == ERROR_NETWORK_UNREACHABLE) >> 141: || (errval == ERROR_NETWORK_ACCESS_DENIED) >> 142: || (errval == ERROR_NO_MORE_FILES)) { > > @bplb Is this the same thing as JDK-8234363? Does this also need to be handled in the FindFirstFile usage in WindowsDirectoryStream? It seems likely. I don't recall having been able to replicate these problems however. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16502#discussion_r1383935522 From duke at openjdk.org Thu Nov 30 14:20:33 2023 From: duke at openjdk.org (Weibing Xiao) Date: Thu, 30 Nov 2023 14:20:33 GMT Subject: RFR: 8315034 : File.mkdirs() occasionally fails to create folders on Windows shared folder In-Reply-To: <5Yzs7c3J57atA4SJat5LAh9aXnCd1fAjWQMx51ODApo=.b24d9d27-cc5e-4b62-b6b8-6184ddb468e7@github.com> References: <3n9ach7f8u8NRqXvRRBchVrkHu6k3wOtHtxB3k61sh8=.2fa0f018-3a42-43d7-ab84-259d5866fa4b@github.com> <5Yzs7c3J57atA4SJat5LAh9aXnCd1fAjWQMx51ODApo=.b24d9d27-cc5e-4b62-b6b8-6184ddb468e7@github.com> Message-ID: On Mon, 6 Nov 2023 20:19:25 GMT, Brian Burkhalter wrote: >> src/java.base/windows/native/libjava/canonicalize_md.c line 142: >> >>> 140: || (errval == ERROR_NETWORK_UNREACHABLE) >>> 141: || (errval == ERROR_NETWORK_ACCESS_DENIED) >>> 142: || (errval == ERROR_NO_MORE_FILES)) { >> >> @bplb Is this the same thing as JDK-8234363? Does this also need to be handled in the FindFirstFile usage in WindowsDirectoryStream? > > It seems likely. I don't recall having been able to replicate these problems however. I used to duplicate it quite easily on my personal laptop with JDK11 (one laptop with Windows 11, the other with Windows 10). After my laptop system got updated, it was almost impossible to recreate it with my two laptops. To verify this bug, we have to configure exactly the same testing environment as the customer was having. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16502#discussion_r1387151896 From vklang at openjdk.org Thu Nov 30 14:34:32 2023 From: vklang at openjdk.org (Viktor Klang) Date: Thu, 30 Nov 2023 14:34:32 GMT Subject: RFR: 8319123: Implement JEP 461: Stream Gatherers (Preview) [v14] In-Reply-To: References: Message-ID: > This Pull-Request implements [JEP-461](https://openjdk.org/jeps/461) Viktor Klang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 32 commits: - Lowering upper boundary of gatherer composition testing to 512 - Javadoc clarifications for Gatherer type parameters, correcting descriptions of Integrator type parameters, and more consistently use "initializer function" instead of "supplier function". - Addressing trailing whitespace complaint - Adding @implSpec for Gatherer.andThen, plus adds tests to verify the default impls for Gatherer-related interfaces - Clarifying that Stream#gather is a stateful intermediate operation - Improvements after feedback - Unpacking the rethrown exceptions from Gatherers.mapConcurrent() - Addressing last review feedback - Apply suggestions from code review Integrates Paul Sandoz's feedback/changes Co-authored-by: Paul Sandoz - Minor improvements to Gatherer Javadoc - ... and 22 more: https://git.openjdk.org/jdk/compare/69413690...49c94c7f ------------- Changes: https://git.openjdk.org/jdk/pull/16420/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16420&range=13 Stats: 4988 lines in 24 files changed: 4981 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/16420.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16420/head:pull/16420 PR: https://git.openjdk.org/jdk/pull/16420 From alanb at openjdk.org Thu Nov 30 14:34:32 2023 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 30 Nov 2023 14:34:32 GMT Subject: RFR: 8319123: Implement JEP 461: Stream Gatherers (Preview) [v14] In-Reply-To: References: Message-ID: On Thu, 30 Nov 2023 14:30:25 GMT, Viktor Klang wrote: >> This Pull-Request implements [JEP-461](https://openjdk.org/jeps/461) > > Viktor Klang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 32 commits: > > - Lowering upper boundary of gatherer composition testing to 512 > - Javadoc clarifications for Gatherer type parameters, > correcting descriptions of Integrator type parameters, > and more consistently use "initializer function" instead > of "supplier function". > - Addressing trailing whitespace complaint > - Adding @implSpec for Gatherer.andThen, plus adds tests to verify the default impls for Gatherer-related interfaces > - Clarifying that Stream#gather is a stateful intermediate operation > - Improvements after feedback > - Unpacking the rethrown exceptions from Gatherers.mapConcurrent() > - Addressing last review feedback > - Apply suggestions from code review > > Integrates Paul Sandoz's feedback/changes > > Co-authored-by: Paul Sandoz > - Minor improvements to Gatherer Javadoc > - ... and 22 more: https://git.openjdk.org/jdk/compare/69413690...49c94c7f Marked as reviewed by alanb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/16420#pullrequestreview-1757596558 From vklang at openjdk.org Thu Nov 30 14:48:45 2023 From: vklang at openjdk.org (Viktor Klang) Date: Thu, 30 Nov 2023 14:48:45 GMT Subject: Integrated: 8319123: Implement JEP 461: Stream Gatherers (Preview) In-Reply-To: References: Message-ID: On Mon, 30 Oct 2023 15:38:35 GMT, Viktor Klang wrote: > This Pull-Request implements [JEP-461](https://openjdk.org/jeps/461) This pull request has now been integrated. Changeset: 33b26f79 Author: Viktor Klang Committer: Alan Bateman URL: https://git.openjdk.org/jdk/commit/33b26f79a986d015abdcd84b89842adc0a4bde64 Stats: 4988 lines in 24 files changed: 4981 ins; 0 del; 7 mod 8319123: Implement JEP 461: Stream Gatherers (Preview) Reviewed-by: tvaleev, alanb, psandoz ------------- PR: https://git.openjdk.org/jdk/pull/16420 From aph at openjdk.org Thu Nov 30 14:53:16 2023 From: aph at openjdk.org (Andrew Haley) Date: Thu, 30 Nov 2023 14:53:16 GMT Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations with SLEEF [v5] In-Reply-To: <8SBUvWGDLtQmwYPRBDeUkeuq4pf2nJfKfDY5rzZODFU=.3f1cc0ff-02e6-4a4e-9425-5ffccc9cbc8f@github.com> References: <8SBUvWGDLtQmwYPRBDeUkeuq4pf2nJfKfDY5rzZODFU=.3f1cc0ff-02e6-4a4e-9425-5ffccc9cbc8f@github.com> Message-ID: On Thu, 30 Nov 2023 11:46:58 GMT, Andrew Haley wrote: > [vect_math.S.txt](https://github.com/openjdk/jdk/files/13512306/vect_math.S.txt) I guess this will live only in os_linux and os_bsd because the Windows compiler won't like it AFAIK. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16234#issuecomment-1833932148 From mcimadamore at openjdk.org Thu Nov 30 14:58:11 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Thu, 30 Nov 2023 14:58:11 GMT Subject: RFR: 8318586: Explicitly handle upcall stub allocation failure [v6] In-Reply-To: References: Message-ID: On Thu, 2 Nov 2023 23:19:24 GMT, Jorn Vernee wrote: >> Explicitly handle UpcallStub allocation failures by terminating. We currently might try to use the returned `nullptr` which would fail sooner or later. This patch just makes the termination explicit. > > Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: > > use alloc_fail_is_fatal = false on all platforms Latest changes look good ------------- Marked as reviewed by mcimadamore (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16311#pullrequestreview-1757671011 From prappo at openjdk.org Thu Nov 30 15:06:15 2023 From: prappo at openjdk.org (Pavel Rappo) Date: Thu, 30 Nov 2023 15:06:15 GMT Subject: RFR: 8321114: Rename "Unnamed Classes" to "Implicitly Declared Classes" better Message-ID: Please review this PR to correctly rename "Unnamed Class" to "Implicitly Declared Class", not "Implicit Class". Renaming is fixed where it affects documentation or the end-user. Renaming is not fixed where it only affects code: it's perfectly okay to derive an internal element name from "Implicit Class" rather than "Implicitly Declared Class", for brevity. ------------- Commit messages: - Initial commit Changes: https://git.openjdk.org/jdk/pull/16904/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16904&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8321114 Stats: 18 lines in 8 files changed: 0 ins; 0 del; 18 mod Patch: https://git.openjdk.org/jdk/pull/16904.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16904/head:pull/16904 PR: https://git.openjdk.org/jdk/pull/16904 From mbalao at openjdk.org Thu Nov 30 15:39:42 2023 From: mbalao at openjdk.org (Martin Balao) Date: Thu, 30 Nov 2023 15:39:42 GMT Subject: RFR: 8315487: Security Providers Filter [v3] In-Reply-To: References: 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 ser... Martin Balao has updated the pull request incrementally with one additional commit since the last revision: More clear text in invalid pattern exception. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15539/files - new: https://git.openjdk.org/jdk/pull/15539/files/ef6eafcf..ea186c25 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15539&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15539&range=01-02 Stats: 5 lines in 1 file changed: 1 ins; 0 del; 4 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 aph at openjdk.org Thu Nov 30 15:42:11 2023 From: aph at openjdk.org (Andrew Haley) Date: Thu, 30 Nov 2023 15:42:11 GMT Subject: RFR: 8319872: AArch64: [vectorapi] Implementation of unsigned (zero extended) casts [v4] In-Reply-To: References: Message-ID: On Wed, 22 Nov 2023 07:05:21 GMT, Eric Liu wrote: >> Vector API defines zero-extend operations [1], which are going to be intrinsified and generated to `VectorUCastNode` by C2. This patch adds backend implementation for `VectorUCastNode` on AArch64. >> >> The micro benchmark shows significant performance improvement. In my test machine (SVE, 256-bit), the result is shown as below: >> >> >> >> Benchmark Before After Units Gain >> VectorZeroExtend.byte2Int 3168.251 243012.399 ops/ms 75.70 >> VectorZeroExtend.byte2Long 3212.201 216291.588 ops/ms 66.33 >> VectorZeroExtend.byte2Short 3391.968 182655.365 ops/ms 52.85 >> VectorZeroExtend.int2Long 1012.197 80448.553 ops/ms 78.48 >> VectorZeroExtend.short2Int 1812.471 153416.828 ops/ms 83.65 >> VectorZeroExtend.short2Long 1788.382 129794.814 ops/ms 71.58 >> >> >> On other Neon systems, we can get similar performance boost as a result of intrinsification success. >> >> Since `VectorUCastNode` only used in Vector API's zero extension currently, this patch also adds assertion on nodes' definitions to clarify their usages. >> >> [TEST] >> compiler/vectorapi and jdk/incubator/vector passed on NEON and SVE machines. >> >> [1] https://github.com/openjdk/jdk/blob/master/src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorOperators.java#L726 > > Eric Liu has updated the pull request incrementally with one additional commit since the last revision: > > small fix > > Change-Id: Icfe9619af1c9e7d5ea8cac457ccebb4eec5c34ad That looks nice. Thanks. ------------- Marked as reviewed by aph (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16670#pullrequestreview-1757770099 From rriggs at openjdk.org Thu Nov 30 15:51:46 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 30 Nov 2023 15:51:46 GMT Subject: RFR: 8311906: Improve robustness of String constructors with mutable array inputs [v14] In-Reply-To: <6SKlGLh5MmxoEx07wHCCUc8KWbbhcspLJmcc1uxQ_FI=.ca33bfb4-fa5c-45f0-b49f-ee6c5c6b68b4@github.com> References: <6SKlGLh5MmxoEx07wHCCUc8KWbbhcspLJmcc1uxQ_FI=.ca33bfb4-fa5c-45f0-b49f-ee6c5c6b68b4@github.com> Message-ID: > Strings, after construction, are immutable but may be constructed from mutable arrays of bytes, characters, or integers. > The string constructors should guard against the effects of mutating the arrays during construction that might invalidate internal invariants for the correct behavior of operations on the resulting strings. In particular, a number of operations have optimizations for operations on pairs of latin1 strings and pairs of non-latin1 strings, while operations between latin1 and non-latin1 strings use a more general implementation. > > The changes include: > > - Adding a warning to each constructor with an array as an argument to indicate that the results are indeterminate > if the input array is modified before the constructor returns. > The resulting string may contain any combination of characters sampled from the input array. > > - Ensure that strings that are represented as non-latin1 contain at least one non-latin1 character. > For latin1 inputs, whether the arrays contain ASCII, ISO-8859-1, UTF8, or another encoding decoded to latin1 the scanning and compression is unchanged. > If a non-latin1 character is found, the string is represented as non-latin1 with the added verification that a non-latin1 character is present at the same index. > If that character is found to be latin1, then the input array has been modified and the result of the scan may be incorrect. > Though a ConcurrentModificationException could be thrown, the risk to an existing application of an unexpected exception should be avoided. > Instead, the non-latin1 copy of the input is re-scanned and compressed; that scan determines whether the latin1 or the non-latin1 representation is returned. > > - The methods that scan for non-latin1 characters and their intrinsic implementations are updated to return the index of the non-latin1 character. > > - String construction from StringBuilder and CharSequence must also be guarded as their contents may be modified during construction. Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: Correct jcc/jccb branches ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16425/files - new: https://git.openjdk.org/jdk/pull/16425/files/5299c43b..b2fc3855 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16425&range=13 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16425&range=12-13 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/16425.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16425/head:pull/16425 PR: https://git.openjdk.org/jdk/pull/16425 From jlaskey at openjdk.org Thu Nov 30 16:14:18 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Thu, 30 Nov 2023 16:14:18 GMT Subject: RFR: 8321114: Rename "Unnamed Classes" to "Implicitly Declared Classes" better In-Reply-To: References: Message-ID: On Thu, 30 Nov 2023 15:00:00 GMT, Pavel Rappo wrote: > Please review this PR to correctly rename "Unnamed Class" to "Implicitly Declared Class", not "Implicit Class". > > Renaming is fixed where it affects documentation or the end-user. Renaming is not fixed where it only affects code: it's perfectly okay to derive an internal element name from "Implicit Class" rather than "Implicitly Declared Class", for brevity. LGTM ------------- Marked as reviewed by jlaskey (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16904#pullrequestreview-1757839510 From jvernee at openjdk.org Thu Nov 30 16:17:34 2023 From: jvernee at openjdk.org (Jorn Vernee) Date: Thu, 30 Nov 2023 16:17:34 GMT Subject: RFR: 8321119: Disable java/foreign/TestHandshake.java on Zero VMs Message-ID: This test is problematic on Zero due to https://bugs.openjdk.org/browse/JDK-8321064 Disable it for now on that platform, until a Zero maintainer has a chance to look into it. Testing: running TestHandshake on zero to see that it is skipped. ------------- Commit messages: - disable TestHandshake on zero Changes: https://git.openjdk.org/jdk/pull/16906/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16906&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8321119 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/16906.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16906/head:pull/16906 PR: https://git.openjdk.org/jdk/pull/16906 From eosterlund at openjdk.org Thu Nov 30 16:17:36 2023 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Thu, 30 Nov 2023 16:17:36 GMT Subject: RFR: 8321119: Disable java/foreign/TestHandshake.java on Zero VMs In-Reply-To: References: Message-ID: <5VZEvA3SibsAxdicTefpMdMF3eKw3biAzoVXwn9lKTI=.81548c70-1f4a-40ae-913e-f6e837c10c8e@github.com> On Thu, 30 Nov 2023 15:48:11 GMT, Jorn Vernee wrote: > This test is problematic on Zero due to https://bugs.openjdk.org/browse/JDK-8321064 > > Disable it for now on that platform, until a Zero maintainer has a chance to look into it. > > Testing: running TestHandshake on zero to see that it is skipped. Looks good. ------------- Marked as reviewed by eosterlund (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16906#pullrequestreview-1757842529 From shade at openjdk.org Thu Nov 30 16:17:37 2023 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 30 Nov 2023 16:17:37 GMT Subject: RFR: 8321119: Disable java/foreign/TestHandshake.java on Zero VMs In-Reply-To: References: Message-ID: On Thu, 30 Nov 2023 15:48:11 GMT, Jorn Vernee wrote: > This test is problematic on Zero due to https://bugs.openjdk.org/browse/JDK-8321064 > > Disable it for now on that platform, until a Zero maintainer has a chance to look into it. > > Testing: running TestHandshake on zero to see that it is skipped. Hold on, can we figure out if Zero can actually be fixed before we go and disable the test? I think we only disable the tests like this if there is an intrinsic reason why the test does not apply to a platform. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16906#issuecomment-1834084558 From dcubed at openjdk.org Thu Nov 30 16:19:47 2023 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Thu, 30 Nov 2023 16:19:47 GMT Subject: Integrated: 8321127: ProblemList java/util/stream/GatherersTest.java Message-ID: A trivial fix to ProblemList java/util/stream/GatherersTest.java. ------------- Commit messages: - 8321127: ProblemList java/util/stream/GatherersTest.java Changes: https://git.openjdk.org/jdk/pull/16909/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16909&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8321127 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/16909.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16909/head:pull/16909 PR: https://git.openjdk.org/jdk/pull/16909 From shade at openjdk.org Thu Nov 30 16:19:48 2023 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 30 Nov 2023 16:19:48 GMT Subject: Integrated: 8321127: ProblemList java/util/stream/GatherersTest.java In-Reply-To: References: Message-ID: On Thu, 30 Nov 2023 16:08:54 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList java/util/stream/GatherersTest.java. All right! Hope it would be fixed soon. Trivial. ------------- Marked as reviewed by shade (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16909#pullrequestreview-1757841717 From alanb at openjdk.org Thu Nov 30 16:19:49 2023 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 30 Nov 2023 16:19:49 GMT Subject: Integrated: 8321127: ProblemList java/util/stream/GatherersTest.java In-Reply-To: References: Message-ID: On Thu, 30 Nov 2023 16:08:54 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList java/util/stream/GatherersTest.java. Marked as reviewed by alanb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/16909#pullrequestreview-1757847283 From dcubed at openjdk.org Thu Nov 30 16:19:50 2023 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Thu, 30 Nov 2023 16:19:50 GMT Subject: Integrated: 8321127: ProblemList java/util/stream/GatherersTest.java In-Reply-To: References: Message-ID: <40-IjeqTksT_gSQsf6w_CeQvXbk7nUaNcr7s9Cd4bEk=.4d2f6e3d-1667-4107-b148-f049715dffe9@github.com> On Thu, 30 Nov 2023 16:12:04 GMT, Aleksey Shipilev wrote: >> A trivial fix to ProblemList java/util/stream/GatherersTest.java. > > All right! Hope it would be fixed soon. Trivial. @shipilev and @AlanBateman - Thanks for the fast reviews. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16909#issuecomment-1834087312 From dcubed at openjdk.org Thu Nov 30 16:19:50 2023 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Thu, 30 Nov 2023 16:19:50 GMT Subject: Integrated: 8321127: ProblemList java/util/stream/GatherersTest.java In-Reply-To: References: Message-ID: On Thu, 30 Nov 2023 16:08:54 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList java/util/stream/GatherersTest.java. This pull request has now been integrated. Changeset: c6a82783 Author: Daniel D. Daugherty URL: https://git.openjdk.org/jdk/commit/c6a827836277f753652815ce6a6bedd426468b87 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 8321127: ProblemList java/util/stream/GatherersTest.java Reviewed-by: shade, alanb ------------- PR: https://git.openjdk.org/jdk/pull/16909 From shade at openjdk.org Thu Nov 30 16:23:22 2023 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 30 Nov 2023 16:23:22 GMT Subject: RFR: 8321119: Disable java/foreign/TestHandshake.java on Zero VMs In-Reply-To: References: Message-ID: On Thu, 30 Nov 2023 15:48:11 GMT, Jorn Vernee wrote: > This test is problematic on Zero due to https://bugs.openjdk.org/browse/JDK-8321064 > > Disable it for now on that platform, until a Zero maintainer has a chance to look into it. > > Testing: running TestHandshake on zero to see that it is skipped. Marked as reviewed by shade (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/16906#pullrequestreview-1757865043 From jvernee at openjdk.org Thu Nov 30 16:23:25 2023 From: jvernee at openjdk.org (Jorn Vernee) Date: Thu, 30 Nov 2023 16:23:25 GMT Subject: RFR: 8321119: Disable java/foreign/TestHandshake.java on Zero VMs In-Reply-To: References: Message-ID: On Thu, 30 Nov 2023 16:14:37 GMT, Aleksey Shipilev wrote: > Hold on, can we figure out if Zero can actually be fixed before we go and disable the test? I think we only disable the tests like this if there is an intrinsic reason why the test does not apply to a platform. I would problem list it, but we can't problem list tests specifically on Zero. The issue seems to be in Zero not polling for safepoints enough. See some discussion on: https://bugs.openjdk.org/browse/JDK-8321064 ------------- PR Comment: https://git.openjdk.org/jdk/pull/16906#issuecomment-1834092904 From shade at openjdk.org Thu Nov 30 16:23:26 2023 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 30 Nov 2023 16:23:26 GMT Subject: RFR: 8321119: Disable java/foreign/TestHandshake.java on Zero VMs In-Reply-To: References: Message-ID: On Thu, 30 Nov 2023 16:18:42 GMT, Jorn Vernee wrote: > > Hold on, can we figure out if Zero can actually be fixed before we go and disable the test? I think we only disable the tests like this if there is an intrinsic reason why the test does not apply to a platform. > > I would problem list it, but we can't problem list tests specifically on Zero. Ah, that is unfortunate. Lacking problem-list support, disabling the test with `@requires` is okay. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16906#issuecomment-1834096799 From stefank at openjdk.org Thu Nov 30 16:23:39 2023 From: stefank at openjdk.org (Stefan Karlsson) Date: Thu, 30 Nov 2023 16:23:39 GMT Subject: RFR: 8320699: Add parameter to skip progress logging of OutputAnalyzer [v2] In-Reply-To: References: Message-ID: <-gLq1S8NvfT65BAJBv59gCbHv6kDsKYV-WszQLgYN1k=.7e0946f2-2cd2-43b4-b48b-93ce0ce86ed7@github.com> > Tests using ProcessTools.executeProcess gets the following output written to stdout: > [2023-11-24T09:58:16.797540608Z] Gathering output for process 2517117 > [2023-11-24T09:58:23.070781345Z] Waiting for completion for process 2517117 > [2023-11-24T09:58:23.071045055Z] Waiting for completion finished for process 2517117 > > This might be good for some use cases and debugging, but some tests spawns a large number of processes and for those this output fills up the log files. > > I propose that we add a way to turn of this output for tests where we find this output to be too noisy. Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: Update OutputBuffer.java copyright years ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16807/files - new: https://git.openjdk.org/jdk/pull/16807/files/d5b13dce..d0091eb6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16807&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16807&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/16807.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16807/head:pull/16807 PR: https://git.openjdk.org/jdk/pull/16807 From stefank at openjdk.org Thu Nov 30 16:27:06 2023 From: stefank at openjdk.org (Stefan Karlsson) Date: Thu, 30 Nov 2023 16:27:06 GMT Subject: RFR: 8320699: Add parameter to skip progress logging of OutputAnalyzer In-Reply-To: <2GfcEQux8lS9so4y1IwGbFg9YAcsJ_XjdhkIdeBdkEE=.1d4b59c7-eef5-406d-8880-d992af851e71@github.com> References: <2GfcEQux8lS9so4y1IwGbFg9YAcsJ_XjdhkIdeBdkEE=.1d4b59c7-eef5-406d-8880-d992af851e71@github.com> Message-ID: On Thu, 30 Nov 2023 12:19:33 GMT, Jaikiran Pai wrote: > Hello Stefan, > > > The test were I want to use this is a long-running stress test that is known to be good at shaking out JVM hangs. It has been written to provide its own output about spawned processes and what they are doing, and have that info written to appropriate files. For me, the OutputAnalyzer logging just adds redundant output to the streams where I don't want the information. > > Thank you for that context. What you are then proposing is for a way to reuse this utility class in specific tests, like the one you are working on, without needing the progress logs. So the idea isn't really to use this new API in all newly developed tests which use this `ProcessTools` library. Plus the implementation in this PR, retains the existing behaviour of logging the progress by default, which is a good thing. Yes, you summarize this well. > > Given that context, I don't have any objection in introducing this enhancemnet. During future reviews, I think, it wouldn't be too difficult to catch misuses of this new API in newer tests where the progress logs shouldn't be disabled. Yes, I agree. It would be quite obvious if someone tries to turn this off. > > As for whether this "config" should be externalized - I think it shouldn't be, since whether or not the progress logs will be excessive and too distracting (and thus need to be disabled) would be known at test development time itself. I agree. > The copyright year on OutputBuffer.java will need an update. Fixed. Thanks for taking a look at this! ------------- PR Comment: https://git.openjdk.org/jdk/pull/16807#issuecomment-1834103958 From jvernee at openjdk.org Thu Nov 30 16:35:23 2023 From: jvernee at openjdk.org (Jorn Vernee) Date: Thu, 30 Nov 2023 16:35:23 GMT Subject: RFR: 8321119: Disable java/foreign/TestHandshake.java on Zero VMs In-Reply-To: References: Message-ID: On Thu, 30 Nov 2023 15:48:11 GMT, Jorn Vernee wrote: > This test is problematic on Zero due to https://bugs.openjdk.org/browse/JDK-8321064 > > Disable it for now on that platform, until a Zero maintainer has a chance to look into it. > > Testing: running TestHandshake on zero to see that it is skipped. Thanks for the reviews. I'll integrate this since it's trivial, and to quiet CI. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16906#issuecomment-1834120742 From jvernee at openjdk.org Thu Nov 30 16:35:54 2023 From: jvernee at openjdk.org (Jorn Vernee) Date: Thu, 30 Nov 2023 16:35:54 GMT Subject: RFR: 8318586: Explicitly handle upcall stub allocation failure [v7] In-Reply-To: References: Message-ID: <01m-ufgCpgyjkFdP9fxvhncIsOe_rzmX_yL2ogXKvi0=.5ccbdc3b-4755-4f48-af7f-8a75956ffc7d@github.com> > Explicitly handle UpcallStub allocation failures by terminating. We currently might try to use the returned `nullptr` which would fail sooner or later. This patch just makes the termination explicit. Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits: - Merge branch 'master' into UpcallStubAllocFailure - use alloc_fail_is_fatal = false on all platforms - add nullptr checks to other platforms - remove unused imports - remove flaky downcall stub oome test - remove @throws - Throw OOME for allocation failures - call fatal without holding code cache lock - Merge branch 'master' into UpcallStubAllocFailure - remove unused import - ... and 4 more: https://git.openjdk.org/jdk/compare/8b102ed6...0a10152b ------------- Changes: https://git.openjdk.org/jdk/pull/16311/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16311&range=06 Stats: 209 lines in 21 files changed: 189 ins; 2 del; 18 mod Patch: https://git.openjdk.org/jdk/pull/16311.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16311/head:pull/16311 PR: https://git.openjdk.org/jdk/pull/16311 From jvernee at openjdk.org Thu Nov 30 16:38:25 2023 From: jvernee at openjdk.org (Jorn Vernee) Date: Thu, 30 Nov 2023 16:38:25 GMT Subject: Integrated: 8321119: Disable java/foreign/TestHandshake.java on Zero VMs In-Reply-To: References: Message-ID: <94-Zh1t_xIrqxXSBBvofWLMBPWuvZwvDvCGgXBQLJa0=.f3705a9a-cb7d-4b9e-bc4f-b13603175238@github.com> On Thu, 30 Nov 2023 15:48:11 GMT, Jorn Vernee wrote: > This test is problematic on Zero due to https://bugs.openjdk.org/browse/JDK-8321064 > > Disable it for now on that platform, until a Zero maintainer has a chance to look into it. > > Testing: running TestHandshake on zero to see that it is skipped. This pull request has now been integrated. Changeset: 8bedb28b Author: Jorn Vernee URL: https://git.openjdk.org/jdk/commit/8bedb28bbc0698dd0592f8e121ce0a4b7b0ac03d Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 8321119: Disable java/foreign/TestHandshake.java on Zero VMs Reviewed-by: eosterlund, shade ------------- PR: https://git.openjdk.org/jdk/pull/16906 From duke at openjdk.org Thu Nov 30 17:01:09 2023 From: duke at openjdk.org (Srinivas Vamsi Parasa) Date: Thu, 30 Nov 2023 17:01:09 GMT Subject: RFR: 8319577: x86_64 AVX2 intrinsics for Arrays.sort methods (int, float arrays) [v4] In-Reply-To: References: Message-ID: <8G3m3YV1Mo4Ub5NVEDrUP5CzYz26Ubecj23jy1eRjM4=.ab8d1802-476b-44b5-a573-81c4d795cd50@github.com> On Thu, 30 Nov 2023 09:38:22 GMT, Magnus Ihse Bursie wrote: >> Seems a bit odd to me too as the existing simd code seems to C code residing in .cpp files for some reason. > > Yeah, that is also a good point. Why setting C++ flags in CFLAGS, and not just CXXFLAGS? > > Also @vamsi-parasa, did you check into if this really was needed and why? To be clear, I basically consider this an integration blocker. Hi Magnus (@magicus), The `-std=c++17` flag was to be placed in CXXFLAGS. Will fix that soon. Also, the latest version of x86-simd-sort is using C++17 features (which are supported from GCC 8 onwards). Would it be possible to restrict the availability of simdsort library in OpenJDK to GCC version >= 8 ? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16534#discussion_r1410969089 From bpb at openjdk.org Thu Nov 30 17:18:10 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 30 Nov 2023 17:18:10 GMT Subject: RFR: 8315034 : File.mkdirs() occasionally fails to create folders on Windows shared folder In-Reply-To: References: Message-ID: On Fri, 3 Nov 2023 18:11:10 GMT, Weibing Xiao wrote: > File.mkdirs() occasionally fails to create folders on Windows shared folders. It turned out that Windows API FindFirstFileW created the error ERROR_NO_MORE_FILES. In some of the cases with a valid file path, this error still returns this error code, which supposedly should not. > > Adding this error code into the method of lastErrorReportable in the native code will be handled by JDK. > > To test the fix, it needs to run three Java processes to create the folders on a remote file server. Marked as reviewed by bpb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/16502#pullrequestreview-1758000120 From mchung at openjdk.org Thu Nov 30 17:22:16 2023 From: mchung at openjdk.org (Mandy Chung) Date: Thu, 30 Nov 2023 17:22:16 GMT Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged modules being present [v10] In-Reply-To: References: Message-ID: On Thu, 30 Nov 2023 09:57:33 GMT, Severin Gehwolf wrote: >> src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JlinkTask.java line 621: >> >>> 619: String resName = String.format(OTHER_RESOURCES_FILE, modName); >>> 620: try { >>> 621: InputStream inStream = jdkJlink.getResourceAsStream(resName); >> >> should it always create the resouorce file for each module even it's empty that might make it easier to catch any issue? > > Sure this can be done. Makes the jimage a bit larger, but probably negligible as the total set of modules is usually small. It adds more empty files which I expect should be very small increase in size. Since this is added by default, we can measure the difference and confirm. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14787#discussion_r1411000019 From aivanov at openjdk.org Thu Nov 30 17:22:12 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 30 Nov 2023 17:22:12 GMT Subject: RFR: 8320608: Many jtreg printing tests are missing the @printer keyword [v2] In-Reply-To: References: <-89UjGPFJWRn0hJIyT5n2YLJKNCyaSeDPjOgw3dmZrw=.613b5081-039a-42cc-8b8c-f48fc91b9abd@github.com> <96ngNnlrygkt0Ni0W2xyr9STyYoQEALdDXtNu_jIQUg=.8969504d-ac54-4dc6-a271-08154523db94@github.com> Message-ID: On Mon, 27 Nov 2023 18:48:52 GMT, Phil Race wrote: >> I see `SetOrient.java` has its sibling `SetOrient.html` where you added `@key printer`. >> >> Since both files contain all the tags except for `@test` in the .java file, you should not remove the `@run` tag from the .java file and add `@key printer` to it. > > "Should not" is strong. Why ? There's no requirement do to this even though you can. > https://openjdk.org/jtreg/faq.html#can-i-use-the-author-run-etc.-tags-in-other-files That's the reason why I prefer you keep the `@run` tag in `SetOrient.java`: to document that it's *an applet test* ? with the html file being the test starter. > I saw that, and it didn't fail at all on mac for any case. > Not sure how much I want to get dragged into fixing the test, and there's no bug id to refer back to. I'd like to make the test useful and ensure it tests the conditions it was written for. This is why I submitted a separate bug for fixing the test ? it's out of scope for the current PR. The test was written for [JDK-4250681](https://bugs.openjdk.org/browse/JDK-4250681): PrinterJob.print() generates IllegalArgumentException,NegativeArraySizeException. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16785#discussion_r1410861731 PR Review Comment: https://git.openjdk.org/jdk/pull/16785#discussion_r1410962571 From aivanov at openjdk.org Thu Nov 30 17:22:16 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 30 Nov 2023 17:22:16 GMT Subject: RFR: 8320608: Many jtreg printing tests are missing the @printer keyword [v2] In-Reply-To: References: <-89UjGPFJWRn0hJIyT5n2YLJKNCyaSeDPjOgw3dmZrw=.613b5081-039a-42cc-8b8c-f48fc91b9abd@github.com> Message-ID: On Mon, 27 Nov 2023 18:53:24 GMT, Phil Race wrote: > I can .. but I am not aware of even a convention to do that ordering. It's not written anywhere as far as I know. There's [an ongoing discussion](https://github.com/openjdk/jdk/pull/16674#discussion_r1402082665) about it in #16674. If the jtreg tags are placed in a comment that precedes the class declaration, after the imports, they're not collapsed ? you can see them right away without scrolling or clicking. I consider the jtreg tags quite relevant to see them easily. I see no benefits to keeping the jtreg tags before the imports where they're collapsed together with the copyright header. At the same time, I see the value in placing them below imports. > I'll update the imports in this file since I touched it more than any other case It's the reason why I asked for it; modifications in this file aren't limited to `@key` or `@author` tags. >> test/jdk/java/awt/print/PrinterJob/PrintAllFonts.java line 26: >> >>> 24: /** >>> 25: * >>> 26: * @bug 4884389 7183516 >> >> Is it intentional that there's no `@test` tag? > > I think this is another test that needs some work. It doesn't wait to see if the user gave it a pass. > I'll add "test" but not "@test". Ah, I see, it falls into the same category as all the tests in [JDK-8320676](https://bugs.openjdk.org/browse/JDK-8320676) which use the `Sysout` framework. I didn't include it because it doesn't have `@test` and therefore it can't be run. I added a comment about the test, it's not worth filing its own bug at this point. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16785#discussion_r1410944165 PR Review Comment: https://git.openjdk.org/jdk/pull/16785#discussion_r1411000260 From aivanov at openjdk.org Thu Nov 30 17:22:21 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 30 Nov 2023 17:22:21 GMT Subject: RFR: 8320608: Many jtreg printing tests are missing the @printer keyword [v2] In-Reply-To: References: Message-ID: On Mon, 27 Nov 2023 20:20:38 GMT, Phil Race wrote: >> Many printing tests do not have the @printer keyword. This adds them to those that need it. >> I also found one test that has nothing to do with printing in the print folder and moved it out. > > Phil Race has updated the pull request incrementally with one additional commit since the last revision: > > 8320608 test/jdk/java/awt/print/PageFormat/SmallPaperPrinting.java line 73: > 71: job.print(); > 72: } > 73: catch (PrinterException e) { Suggestion: } catch (PrinterException e) { The `catch` keyword should be on the line with the closing brace of the `try {}` block. It can be addressed in [JDK-8320671](https://bugs.openjdk.org/browse/JDK-8320671) when the test is updated. test/jdk/java/awt/print/PrinterJob/EmptyFill.java line 72: > 70: return; > 71: } > 72: PrinterJob pj = PrinterJob.getPrinterJob(); It looks good, however, I'd move the blank so that the code groups logically: StreamPrintService svc = spfs[0].getPrintService(baos); if (svc == null) { return; } PrinterJob pj = PrinterJob.getPrinterJob(); Perhaps, the test should fail if `svc` happens to be `null`, after all it's quite unexpected if it's `null`, isn't it? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16785#discussion_r1410886948 PR Review Comment: https://git.openjdk.org/jdk/pull/16785#discussion_r1410980732 From bpb at openjdk.org Thu Nov 30 17:24:08 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 30 Nov 2023 17:24:08 GMT Subject: RFR: 8321053: Use ByteArrayInputStream.buf directly when parameter of transferTo() is trusted In-Reply-To: References: Message-ID: On Thu, 30 Nov 2023 04:26:44 GMT, jmehrens wrote: >> Pass `ByteArrayInputStream.buf ` directly to the `OutputStream` parameter of `BAIS.transferTo` only if the target stream is in the `java.io` package. > > src/java.base/share/classes/java/io/ByteArrayInputStream.java line 211: > >> 209: if (len > 0) { >> 210: byte[] tmp; >> 211: if ("java.io".equals(out.getClass().getPackageName())) > > Isn't this protection defeated with: > > ByteArrayInputStream bais = new ByteArrayInputStream(bytes); > UntrustedOutputStream uos = new UntrustedOutputStream(); > bais.transferTo(new java.io.DataOutputStream(uos)); > > > Or am I missing something? Good catch: that in fact defeats the protection. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16893#discussion_r1411002921 From mchung at openjdk.org Thu Nov 30 17:25:13 2023 From: mchung at openjdk.org (Mandy Chung) Date: Thu, 30 Nov 2023 17:25:13 GMT Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged modules being present [v10] In-Reply-To: <_U2g2Ejo3uiZ3BdWm-lMSFrZG0Bs8kaX-1TyUT-sasM=.8ba32a2b-9841-4912-b37a-40b281ddfe11@github.com> References: <_U2g2Ejo3uiZ3BdWm-lMSFrZG0Bs8kaX-1TyUT-sasM=.8ba32a2b-9841-4912-b37a-40b281ddfe11@github.com> Message-ID: On Thu, 30 Nov 2023 10:00:48 GMT, Severin Gehwolf wrote: >> src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JlinkTask.java line 88: >> >>> 86: >>> 87: // Run time based link internal resources files >>> 88: private static final String OTHER_RESOURCES_FILE = "jdk/tools/jlink/internal/runlink_%s_resources"; >> >> This can be shared with the plugin writing this file. This file collects the hash of the non-class resource files in the image. "runlink" is a confusing prefix. What about: >> Suggestion: >> >> // jlink's internal resource file keeps track of the hash of per-module non-class resources in the run-time image >> public static final String MODULE_RESOURCES_LIST = "jdk/tools/jlink/internal/%s_resources"; > > Happy to change the prefix. Having a (unique) prefix seems useful, though, since it eases filtering. Note: that file is not only there for the hash sums, but also to keep track of the path to the files in the filesystem, which we'd otherwise not know. Will see how a few suggested renames looks like and a better term to describe this may come out ? `runlink` is a bit confusing. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14787#discussion_r1411004395 From bpb at openjdk.org Thu Nov 30 17:27:06 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 30 Nov 2023 17:27:06 GMT Subject: RFR: 8320971: Use BufferedInputStream.buf directly when param of implTransferTo() is trusted [v3] In-Reply-To: References: <06dpAmRUHn4PyHDz2vZLZ9FyzF6u81qj_39hbqP7PnE=.2924f568-9021-46e7-b1fb-0c7a4d5f9c4d@github.com> <6IitbefHaaKPhCkB_FRZnBxTyZJi0i8jjh8Pr32jsb8=.956ea224-3aff-4c86-9e28-6399172bfc92@github.com> Message-ID: On Thu, 30 Nov 2023 09:47:05 GMT, Vladimir Sitnikov wrote: >>> You have to know that it is in the java.io package and it doesn't wrap another stream. >> >> That is a good point. In the previous work on this override, we converged on the current implementation to not leak the internal byte[] to the target. It could be special cased for trusted targets but at the cost of auditing and complexity. So more thought needed on this, I don't think the current change can be integrated. > > What do you think of adding `OutputStream extends WritableByteChannel`, so `transferTo` could be implemented with `if (target instanceof WritableByteChannel) { target.write(ByteBuffer.wrap(buf, off, len).asReadOnly()); }`? > > Read-only byte buffer will not allow modifying the data in the buffer, it would eliminate buffer copies, and adding `write(ByteBuffer)` to `OutputStream` seems reasonable. > It could be special cased for trusted targets but at the cost of auditing and complexity. So more thought needed on this [...] Could the target additionally be checked to see whether it is a `FilterOutputStream` and if so not be trusted? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16879#discussion_r1411007027 From mchung at openjdk.org Thu Nov 30 17:28:12 2023 From: mchung at openjdk.org (Mandy Chung) Date: Thu, 30 Nov 2023 17:28:12 GMT Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged modules being present [v10] In-Reply-To: References: Message-ID: On Thu, 30 Nov 2023 10:13:39 GMT, Severin Gehwolf wrote: >> src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JlinkTask.java line 286: >> >>> 284: } >>> 285: >>> 286: boolean useModulePath = !options.modulePath.isEmpty(); >> >> Is there any reason why the run-time image based linking is only supported if `--module-path` is not specified? Linking user modules specified on the module path with the run-time image seems useful. If the module exists in the given module path and the run-time image, the modules from the module path should probably take precedence but it needs to work through the details and potential issues. > > I haven't looked into the details, but the common case is for jlink users to use the default module path (`jmods` folder of the JDK install) and the prime use-case for this is to get away with performing a link without the packaged modules (no "external" dependency if you will; of that `jmods` folder). It could be considered as a follow-up. In this patch I wouldn't want to complicate it further if that sounds OK? Yes it's fine. We can wait for more feedback and consider this future enhancement if desirable. I just wanted to understand the reason. Good to add a comment to explain. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14787#discussion_r1411009704 From aivanov at openjdk.org Thu Nov 30 17:37:12 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 30 Nov 2023 17:37:12 GMT Subject: RFR: 8320608: Many jtreg printing tests are missing the @printer keyword [v2] In-Reply-To: References: Message-ID: <7ClPt0yP816O2BNX_DvPUnLyXJAjk7yUpdLSqtjTgtU=.bd31651d-4500-4605-98d1-9212e648f290@github.com> On Mon, 27 Nov 2023 20:20:38 GMT, Phil Race wrote: >> Many printing tests do not have the @printer keyword. This adds them to those that need it. >> I also found one test that has nothing to do with printing in the print folder and moved it out. > > Phil Race has updated the pull request incrementally with one additional commit since the last revision: > > 8320608 Looks good to me ?except for some minor comments. test/jdk/java/awt/print/PrinterJob/RemoveListener.java line 28: > 26: * @bug 4459889 > 27: * @summary No NullPointerException should occur. > 28: * @key printer Suggestion: * @test * @bug 4459889 * @key printer * @summary No NullPointerException should occur. To be consistent with other tests. ------------- Marked as reviewed by aivanov (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16785#pullrequestreview-1758016744 PR Review Comment: https://git.openjdk.org/jdk/pull/16785#discussion_r1411002236 From duke at openjdk.org Thu Nov 30 17:38:21 2023 From: duke at openjdk.org (Weibing Xiao) Date: Thu, 30 Nov 2023 17:38:21 GMT Subject: Integrated: 8315034 : File.mkdirs() occasionally fails to create folders on Windows shared folder In-Reply-To: References: Message-ID: On Fri, 3 Nov 2023 18:11:10 GMT, Weibing Xiao wrote: > File.mkdirs() occasionally fails to create folders on Windows shared folders. It turned out that Windows API FindFirstFileW created the error ERROR_NO_MORE_FILES. In some of the cases with a valid file path, this error still returns this error code, which supposedly should not. > > Adding this error code into the method of lastErrorReportable in the native code will be handled by JDK. > > To test the fix, it needs to run three Java processes to create the folders on a remote file server. This pull request has now been integrated. Changeset: 7ad70059 Author: Weibing Xiao Committer: Brian Burkhalter URL: https://git.openjdk.org/jdk/commit/7ad700596fbc58c27fedfa46755e80ea57712fac Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod 8315034: File.mkdirs() occasionally fails to create folders on Windows shared folder Reviewed-by: bpb ------------- PR: https://git.openjdk.org/jdk/pull/16502 From naoto at openjdk.org Thu Nov 30 17:39:30 2023 From: naoto at openjdk.org (Naoto Sato) Date: Thu, 30 Nov 2023 17:39:30 GMT Subject: RFR: 8320798: Console read line with zero out should zero out underlying buffer [v3] In-Reply-To: References: Message-ID: <8mADwh5tk-5DhucpbLxUAiPDOgxSkJru210ndcjXWaU=.f1dbb46e-974a-4975-8b08-cb8d34bf92cc@github.com> > It is best practice to zero out the underlying buffer after use. Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: remove ensureOpen() ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16861/files - new: https://git.openjdk.org/jdk/pull/16861/files/90c4dece..6d2d6368 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16861&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16861&range=01-02 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/16861.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16861/head:pull/16861 PR: https://git.openjdk.org/jdk/pull/16861 From naoto at openjdk.org Thu Nov 30 17:39:33 2023 From: naoto at openjdk.org (Naoto Sato) Date: Thu, 30 Nov 2023 17:39:33 GMT Subject: RFR: 8320798: Console read line with zero out should zero out underlying buffer [v2] In-Reply-To: References: Message-ID: <1fhvC7QU7wM7B6osoSaUQHFV1m4TcfTi884lMOjf_nc=.684114bf-09f1-4285-88b5-2b6fb5a2335f@github.com> On Thu, 30 Nov 2023 10:58:13 GMT, Jaikiran Pai wrote: >> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: >> >> corrected fromIndex > > src/java.base/share/classes/sun/nio/cs/StreamDecoder.java line 293: > >> 291: >> 292: private void lockedFillZeroToPosition() throws IOException { >> 293: ensureOpen(); > > Hello Naoto, is this open check needed? Given that we are just zeroing out already read content, would it thus be OK to clear that content to zero even after this `Reader` instance has been closed? Thanks, Jai. Removed it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16861#discussion_r1411051514 From naoto at openjdk.org Thu Nov 30 17:42:06 2023 From: naoto at openjdk.org (Naoto Sato) Date: Thu, 30 Nov 2023 17:42:06 GMT Subject: RFR: 8320798: Console read line with zero out should zero out underlying buffer [v2] In-Reply-To: References: Message-ID: On Tue, 28 Nov 2023 19:30:34 GMT, Naoto Sato wrote: >> It is best practice to zero out the underlying buffer after use. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > corrected fromIndex Created an equivalent issue for addressing JLine: https://bugs.openjdk.org/browse/JDK-8321131 ------------- PR Comment: https://git.openjdk.org/jdk/pull/16861#issuecomment-1834254962 From duke at openjdk.org Thu Nov 30 17:47:39 2023 From: duke at openjdk.org (Srinivas Vamsi Parasa) Date: Thu, 30 Nov 2023 17:47:39 GMT Subject: RFR: 8319577: x86_64 AVX2 intrinsics for Arrays.sort methods (int, float arrays) [v5] In-Reply-To: References: Message-ID: > The goal is to develop faster sort routines for x86_64 CPUs by taking advantage of AVX2 instructions. This enhancement provides an order of magnitude speedup for Arrays.sort() using int, long, float and double arrays. > > For serial sort on random data, this PR shows upto ~7.5x improvement for 32-bit datatypes (int, float) on Intel TigerLake machine as shown in the performance data below. > > For parallel sort on random data, this PR shows upto ~3.4x for 32-bit datatypes (int, float) as shown below. > > **Note:** This PR also improves the performance of AVX512 sort by upto 35%. > > xmlns:o="urn:schemas-microsoft-com:office:office" > xmlns:x="urn:schemas-microsoft-com:office:excel" > xmlns="http://www.w3.org/TR/REC-html40"> > > > > > > href="file:///C:/Users/sparasa/AppData/Local/Temp/msohtmlclip1/01/clip.htm"> > href="file:///C:/Users/sparasa/AppData/Local/Temp/msohtmlclip1/01/clip_filelist.xml"> > > > > > > > > > Benchmark (Serial Sort) | Size | Baseline (us/op) | AVX2 (us/op) | Speedup > -- | -- | -- | -- | -- > ArraysSort.intSort | 10 | 0.034 | 0.029 | 1.2 > ArraysSort.intSort | 25 | 0.088 | 0.044 | 2.0 > ArraysSort.intSort | 50 | 0.239 | 0.159 | 1.5 > ArraysSort.intSort | 75 | 0.417 | 0.27 | 1.5 > ArraysSort.intSort | 100 | 0.572 | 0.265 | 2.2 > ArraysSort.intSort | 1000 | 10.098 | 4.282 | 2.4 > ArraysSort.intSort | 10000 | 330.065 | 43.383 | 7.6 > ArraysSort.intSort | 100000 | 4099.527 | 778.943 | 5.3 > ArraysSort.intSort | 1000000 | 49150.16 | 9634.335 | 5.1 > ArraysSort.floatSort | 10 | 0.045 | 0.043 | 1.0 > ArraysSort.floatSort | 25 | 0.105 | 0.073 | 1.4 > ArraysSort.floatSort | 50 | 0.278 | 0.216 | 1.3 > ArraysSort.floatSort | 75 | 0.476 | 0.241 | 2.0 > ArraysSort.floatSort | 100 | 0.583 | 0.313 | 1.9 > ArraysSort.floatSort | 1000 | 10.182 | 4.329 | 2.4 > ArraysSort.floatSort | 10000 | 323.136 | 57.175 | 5.7 > ArraysSort.floatSort | 100000 | 4299.519 | 862.63 | 5.0 > ArraysSort.floatSort | 1000000 | 50889.4 | 10972.19 | 4.6 > > > > > > xmlns:o="urn:schemas-microsoft-com:office:office" > xmlns:x="urn:schemas-microsoft-com:office:excel" > xmlns="http://www.w3.org/TR/REC-html40"> > > > > > > href="file:///C:/Users/... Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision: Remove C++17 from C flags ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16534/files - new: https://git.openjdk.org/jdk/pull/16534/files/893951e8..e880917c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16534&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16534&range=03-04 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/16534.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16534/head:pull/16534 PR: https://git.openjdk.org/jdk/pull/16534 From prr at openjdk.org Thu Nov 30 18:18:06 2023 From: prr at openjdk.org (Phil Race) Date: Thu, 30 Nov 2023 18:18:06 GMT Subject: RFR: 8320608: Many jtreg printing tests are missing the @printer keyword [v2] In-Reply-To: References: <-89UjGPFJWRn0hJIyT5n2YLJKNCyaSeDPjOgw3dmZrw=.613b5081-039a-42cc-8b8c-f48fc91b9abd@github.com> <96ngNnlrygkt0Ni0W2xyr9STyYoQEALdDXtNu_jIQUg=.8969504d-ac54-4dc6-a271-08154523db94@github.com> Message-ID: On Thu, 30 Nov 2023 15:41:28 GMT, Alexey Ivanov wrote: >> "Should not" is strong. Why ? There's no requirement do to this even though you can. >> https://openjdk.org/jtreg/faq.html#can-i-use-the-author-run-etc.-tags-in-other-files > > That's the reason why I prefer you keep the `@run` tag in `SetOrient.java`: to document that it's *an applet test* ? with the html file being the test starter. Ok, although when I see something like that it looks more like a bug to me. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16785#discussion_r1411093305 From prr at openjdk.org Thu Nov 30 18:18:10 2023 From: prr at openjdk.org (Phil Race) Date: Thu, 30 Nov 2023 18:18:10 GMT Subject: RFR: 8320608: Many jtreg printing tests are missing the @printer keyword [v2] In-Reply-To: References: Message-ID: On Thu, 30 Nov 2023 15:59:29 GMT, Alexey Ivanov wrote: >> Phil Race has updated the pull request incrementally with one additional commit since the last revision: >> >> 8320608 > > test/jdk/java/awt/print/PageFormat/SmallPaperPrinting.java line 73: > >> 71: job.print(); >> 72: } >> 73: catch (PrinterException e) { > > Suggestion: > > } catch (PrinterException e) { > > The `catch` keyword should be on the line with the closing brace of the `try {}` block. > > It can be addressed in [JDK-8320671](https://bugs.openjdk.org/browse/JDK-8320671) when the test is updated. fixed anyway ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16785#discussion_r1411095104 From duke at openjdk.org Thu Nov 30 18:22:10 2023 From: duke at openjdk.org (Srinivas Vamsi Parasa) Date: Thu, 30 Nov 2023 18:22:10 GMT Subject: RFR: 8319577: x86_64 AVX2 intrinsics for Arrays.sort methods (int, float arrays) [v5] In-Reply-To: References: Message-ID: On Thu, 30 Nov 2023 09:38:22 GMT, Magnus Ihse Bursie wrote: >> Seems a bit odd to me too as the existing simd code seems to C code residing in .cpp files for some reason. > > Yeah, that is also a good point. Why setting C++ flags in CFLAGS, and not just CXXFLAGS? > > Also @vamsi-parasa, did you check into if this really was needed and why? To be clear, I basically consider this an integration blocker. Hi Magnus (@magicus), The simdsort has a dependency on some C++ 17 features and would require a lot of changes to avoid that. Please see the latest code which removed the unused flags from CFLAGS. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16534#discussion_r1411099219 From prr at openjdk.org Thu Nov 30 18:23:28 2023 From: prr at openjdk.org (Phil Race) Date: Thu, 30 Nov 2023 18:23:28 GMT Subject: RFR: 8320608: Many jtreg printing tests are missing the @printer keyword [v3] In-Reply-To: References: Message-ID: > Many printing tests do not have the @printer keyword. This adds them to those that need it. > I also found one test that has nothing to do with printing in the print folder and moved it out. Phil Race has updated the pull request incrementally with one additional commit since the last revision: 8320608 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16785/files - new: https://git.openjdk.org/jdk/pull/16785/files/5fbc06d1..383f4532 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16785&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16785&range=01-02 Stats: 7 lines in 4 files changed: 3 ins; 2 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/16785.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16785/head:pull/16785 PR: https://git.openjdk.org/jdk/pull/16785 From prr at openjdk.org Thu Nov 30 18:23:31 2023 From: prr at openjdk.org (Phil Race) Date: Thu, 30 Nov 2023 18:23:31 GMT Subject: RFR: 8320608: Many jtreg printing tests are missing the @printer keyword [v2] In-Reply-To: References: Message-ID: On Thu, 30 Nov 2023 17:08:21 GMT, Alexey Ivanov wrote: >> Phil Race has updated the pull request incrementally with one additional commit since the last revision: >> >> 8320608 > > test/jdk/java/awt/print/PrinterJob/EmptyFill.java line 72: > >> 70: return; >> 71: } >> 72: PrinterJob pj = PrinterJob.getPrinterJob(); > > It looks good, however, I'd move the blank so that the code groups logically: > > > StreamPrintService svc = spfs[0].getPrintService(baos); > if (svc == null) { > return; > } > > PrinterJob pj = PrinterJob.getPrinterJob(); > > > Perhaps, the test should fail if `svc` happens to be `null`, after all it's quite unexpected if it's `null`, isn't it? yes, it should always be possible to create the Postscript Stream PrintService - added throw new RTE. > test/jdk/java/awt/print/PrinterJob/RemoveListener.java line 28: > >> 26: * @bug 4459889 >> 27: * @summary No NullPointerException should occur. >> 28: * @key printer > > Suggestion: > > * @test > * @bug 4459889 > * @key printer > * @summary No NullPointerException should occur. > > To be consistent with other tests. fixed ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16785#discussion_r1411097828 PR Review Comment: https://git.openjdk.org/jdk/pull/16785#discussion_r1411098415 From vklang at openjdk.org Thu Nov 30 18:28:16 2023 From: vklang at openjdk.org (Viktor Klang) Date: Thu, 30 Nov 2023 18:28:16 GMT Subject: Integrated: 8321127: ProblemList java/util/stream/GatherersTest.java In-Reply-To: References: Message-ID: On Thu, 30 Nov 2023 16:12:04 GMT, Aleksey Shipilev wrote: >> A trivial fix to ProblemList java/util/stream/GatherersTest.java. > > All right! Hope it would be fixed soon. Trivial. @shipilev @AlanBateman @dcubed-ojdk I'm on it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16909#issuecomment-1834321347 From sgehwolf at openjdk.org Thu Nov 30 19:10:10 2023 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Thu, 30 Nov 2023 19:10:10 GMT Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged modules being present [v10] In-Reply-To: References: Message-ID: On Thu, 30 Nov 2023 17:25:26 GMT, Mandy Chung wrote: >> I haven't looked into the details, but the common case is for jlink users to use the default module path (`jmods` folder of the JDK install) and the prime use-case for this is to get away with performing a link without the packaged modules (no "external" dependency if you will; of that `jmods` folder). It could be considered as a follow-up. In this patch I wouldn't want to complicate it further if that sounds OK? > > Yes it's fine. We can wait for more feedback and consider this future enhancement if desirable. I just wanted to understand the reason. Good to add a comment to explain. Makes sense. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14787#discussion_r1411149264 From jvernee at openjdk.org Thu Nov 30 19:30:21 2023 From: jvernee at openjdk.org (Jorn Vernee) Date: Thu, 30 Nov 2023 19:30:21 GMT Subject: Integrated: 8318586: Explicitly handle upcall stub allocation failure In-Reply-To: References: Message-ID: <6dnlWMoyG0eZSs66183EkNGUyP7LHDy3GGHn1ZhMEzc=.3187a5e9-6855-4ee9-bd23-f74c42404f29@github.com> On Mon, 23 Oct 2023 13:58:27 GMT, Jorn Vernee wrote: > Explicitly handle UpcallStub allocation failures by terminating. We currently might try to use the returned `nullptr` which would fail sooner or later. This patch just makes the termination explicit. This pull request has now been integrated. Changeset: e96e1919 Author: Jorn Vernee URL: https://git.openjdk.org/jdk/commit/e96e19195287a065711358bffde753e9d83e5de3 Stats: 209 lines in 21 files changed: 189 ins; 2 del; 18 mod 8318586: Explicitly handle upcall stub allocation failure 8318653: UpcallTestHelper::runInNewProcess waits for forked process without timeout Reviewed-by: shade, mcimadamore ------------- PR: https://git.openjdk.org/jdk/pull/16311 From serb at openjdk.org Thu Nov 30 19:53:07 2023 From: serb at openjdk.org (Sergey Bylokhov) Date: Thu, 30 Nov 2023 19:53:07 GMT Subject: RFR: 8320608: Many jtreg printing tests are missing the @printer keyword [v3] In-Reply-To: References: Message-ID: On Thu, 30 Nov 2023 18:23:28 GMT, Phil Race wrote: >> Many printing tests do not have the @printer keyword. This adds them to those that need it. >> I also found one test that has nothing to do with printing in the print folder and moved it out. > > Phil Race has updated the pull request incrementally with one additional commit since the last revision: > > 8320608 test/jdk/TEST.ROOT line 19: > 17: # These keywords are there to help with test selection so that > 18: # tests that need a particular resource can be selected to run on a system > 19: # with that resource. Conversely "!somekeyword" can be used to exclude tests probably we can link this from our wiki page where we describe the usage of keywords?: https://wiki.openjdk.org/display/ClientLibs/Automated+client+GUI+testing+system+set+up+requirements BTW the "doc" has nothing related to printers right now as well: https://github.com/openjdk/jdk/blob/master/doc/testing.md ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16785#discussion_r1411189538 From alanb at openjdk.org Thu Nov 30 19:58:27 2023 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 30 Nov 2023 19:58:27 GMT Subject: RFR: 8320716: ResolvedModule::reads includes self when configuration contains two or more automatic modules [v2] In-Reply-To: References: Message-ID: <1w1Pzrqtyk8n2h85M9UjV_baxDkQ6ofIX97x9eXnKv8=.0274df67-1714-4f26-bf68-54222879b10c@github.com> > This is update to the specification of the j.l.module.ResolvedModule.reads method to clarify that the set of resolved modules returned does not include itself. There is a small implementation change to align with the specification and fix an anomaly that arises with configurations that contain two or more automatic modules. > > Every module reads itself but the intent with ResolvedModule.reads is that it returns a set that doesn't include self. As things stand right now, the returned set does not include self when all modules in the configuration are explicit modules. However, if the configuration contains two or more automatic modules then the set includes self, a side effect of augmenting the readability graph due to implied readability. > > The specification of the "reads" method is updated. The implementation is also changed to skip automatic modules when augmenting the graph due to implied readability. It is skipped as each automatic module already reads all other modules. Note that it is not goal here to change the algorithm for handling implied readability, this may be a topic for a follow on PR. > > The existing ConfigurationTest already includes several tests for configurations consisting solely of explicit modules, no updates are needed. For configurations that include automatic modules, the existing AutomaticModulesTest is updated to add new asserts to each of the testConfigurationXXX methods. I decided to migrate this test to JUnit while visiting, most of it is just migrating the TestNG data providers to be parameterized tests. If needed then we could separate this but it's a simple migration so I left it in. 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 four additional commits since the last revision: - Add comment to say that automatic module already reads all selected modules - Merge - Reorder asserts - Initial commit ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16818/files - new: https://git.openjdk.org/jdk/pull/16818/files/0330f005..53c4f068 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16818&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16818&range=00-01 Stats: 19018 lines in 528 files changed: 13858 ins; 3199 del; 1961 mod Patch: https://git.openjdk.org/jdk/pull/16818.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16818/head:pull/16818 PR: https://git.openjdk.org/jdk/pull/16818 From duke at openjdk.org Thu Nov 30 20:00:29 2023 From: duke at openjdk.org (Srinivas Vamsi Parasa) Date: Thu, 30 Nov 2023 20:00:29 GMT Subject: RFR: 8319577: x86_64 AVX2 intrinsics for Arrays.sort methods (int, float arrays) [v6] In-Reply-To: References: Message-ID: > The goal is to develop faster sort routines for x86_64 CPUs by taking advantage of AVX2 instructions. This enhancement provides an order of magnitude speedup for Arrays.sort() using int, long, float and double arrays. > > For serial sort on random data, this PR shows upto ~7.5x improvement for 32-bit datatypes (int, float) on Intel TigerLake machine as shown in the performance data below. > > For parallel sort on random data, this PR shows upto ~3.4x for 32-bit datatypes (int, float) as shown below. > > **Note:** This PR also improves the performance of AVX512 sort by upto 35%. > > xmlns:o="urn:schemas-microsoft-com:office:office" > xmlns:x="urn:schemas-microsoft-com:office:excel" > xmlns="http://www.w3.org/TR/REC-html40"> > > > > > > href="file:///C:/Users/sparasa/AppData/Local/Temp/msohtmlclip1/01/clip.htm"> > href="file:///C:/Users/sparasa/AppData/Local/Temp/msohtmlclip1/01/clip_filelist.xml"> > > > > > > > > > Benchmark (Serial Sort) | Size | Baseline (us/op) | AVX2 (us/op) | Speedup > -- | -- | -- | -- | -- > ArraysSort.intSort | 10 | 0.034 | 0.029 | 1.2 > ArraysSort.intSort | 25 | 0.088 | 0.044 | 2.0 > ArraysSort.intSort | 50 | 0.239 | 0.159 | 1.5 > ArraysSort.intSort | 75 | 0.417 | 0.27 | 1.5 > ArraysSort.intSort | 100 | 0.572 | 0.265 | 2.2 > ArraysSort.intSort | 1000 | 10.098 | 4.282 | 2.4 > ArraysSort.intSort | 10000 | 330.065 | 43.383 | 7.6 > ArraysSort.intSort | 100000 | 4099.527 | 778.943 | 5.3 > ArraysSort.intSort | 1000000 | 49150.16 | 9634.335 | 5.1 > ArraysSort.floatSort | 10 | 0.045 | 0.043 | 1.0 > ArraysSort.floatSort | 25 | 0.105 | 0.073 | 1.4 > ArraysSort.floatSort | 50 | 0.278 | 0.216 | 1.3 > ArraysSort.floatSort | 75 | 0.476 | 0.241 | 2.0 > ArraysSort.floatSort | 100 | 0.583 | 0.313 | 1.9 > ArraysSort.floatSort | 1000 | 10.182 | 4.329 | 2.4 > ArraysSort.floatSort | 10000 | 323.136 | 57.175 | 5.7 > ArraysSort.floatSort | 100000 | 4299.519 | 862.63 | 5.0 > ArraysSort.floatSort | 1000000 | 50889.4 | 10972.19 | 4.6 > > > > > > xmlns:o="urn:schemas-microsoft-com:office:office" > xmlns:x="urn:schemas-microsoft-com:office:excel" > xmlns="http://www.w3.org/TR/REC-html40"> > > > > > > href="file:///C:/Users/... Srinivas Vamsi Parasa has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 15 additional commits since the last revision: - Merge branch 'master' of https://git.openjdk.java.net/jdk into simdsort - Remove C++17 from C flags - add avoid masked stores operation - update the code to check for supported simd sort cpus - Disable AVX2 sort for 64-bit types - Merge branch 'master' of https://git.openjdk.java.net/jdk into simdsort - fix jcheck failures due to windows encoding - fix carriage return and change insertion sort thresholds - fix formatting and white spaces - cleanup unused code - ... and 5 more: https://git.openjdk.org/jdk/compare/1f320d8f...d957f413 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16534/files - new: https://git.openjdk.org/jdk/pull/16534/files/e880917c..d957f413 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16534&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16534&range=04-05 Stats: 35498 lines in 1124 files changed: 24902 ins; 5663 del; 4933 mod Patch: https://git.openjdk.org/jdk/pull/16534.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16534/head:pull/16534 PR: https://git.openjdk.org/jdk/pull/16534 From ihse at openjdk.org Thu Nov 30 20:10:07 2023 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Thu, 30 Nov 2023 20:10:07 GMT Subject: RFR: 8319577: x86_64 AVX2 intrinsics for Arrays.sort methods (int, float arrays) [v6] In-Reply-To: References: Message-ID: On Thu, 30 Nov 2023 18:19:51 GMT, Srinivas Vamsi Parasa wrote: >> Yeah, that is also a good point. Why setting C++ flags in CFLAGS, and not just CXXFLAGS? >> >> Also @vamsi-parasa, did you check into if this really was needed and why? To be clear, I basically consider this an integration blocker. > > Hi Magnus (@magicus), > The simdsort has a dependency on some C++ 17 features and would require a lot of changes to avoid that. > Please see the latest code which removed the unused flags from CFLAGS. Raising the minimum gcc version is not done willy-nilly. (I feel a "You just don't ..." meme coming up) But you are saying that you want to skip building this library unless you have a gcc version that supports c++17? I still don't really like it. I'd like to hear someone else who can think clearly about this, if we want to go down this path, and start adding libraries that use C++17. Maybe @kimbarrett has some input? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16534#discussion_r1411206324 From prr at openjdk.org Thu Nov 30 20:16:10 2023 From: prr at openjdk.org (Phil Race) Date: Thu, 30 Nov 2023 20:16:10 GMT Subject: RFR: 8320608: Many jtreg printing tests are missing the @printer keyword [v3] In-Reply-To: References: Message-ID: On Thu, 30 Nov 2023 19:50:00 GMT, Sergey Bylokhov wrote: > probably we can link this from our wiki page where we describe the usage of keywords?: https://wiki.openjdk.org/display/ClientLibs/Automated+client+GUI+testing+system+set+up+requirements Good idea, once this is pushed, I'll add that right where we discuss the keywords. If I remember ! > > BTW the "doc" has nothing related to printers right now as well: https://github.com/openjdk/jdk/blob/master/doc/testing.md Perhaps this is a bit too specialised to discuss there. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16785#discussion_r1411211838 From ihse at openjdk.org Thu Nov 30 20:16:14 2023 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Thu, 30 Nov 2023 20:16:14 GMT Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations with SLEEF [v5] In-Reply-To: References: <8SBUvWGDLtQmwYPRBDeUkeuq4pf2nJfKfDY5rzZODFU=.3f1cc0ff-02e6-4a4e-9425-5ffccc9cbc8f@github.com> Message-ID: On Thu, 30 Nov 2023 14:50:24 GMT, Andrew Haley wrote: >> Do this, but with the name vect_math.S. Don't use SLEEF headers in the build. I think you can do this with no build-time dependency on SLEEF at all if you load the library lazily at runtime. >> >> [vect_math.S.txt](https://github.com/openjdk/jdk/files/13512306/vect_math.S.txt) > >> [vect_math.S.txt](https://github.com/openjdk/jdk/files/13512306/vect_math.S.txt) > > I guess this will live only in os_linux and os_bsd because the Windows compiler won't like it AFAIK. @theRealAph So your suggestion is that this assembly files lives in hotspot, instead of jdk.incubator.vector? ------------- PR Comment: https://git.openjdk.org/jdk/pull/16234#issuecomment-1834474434 From ihse at openjdk.org Thu Nov 30 20:16:16 2023 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Thu, 30 Nov 2023 20:16:16 GMT Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations with SLEEF [v5] In-Reply-To: References: Message-ID: On Thu, 30 Nov 2023 06:39:43 GMT, Xiaohong Gong wrote: >> Currently the vector floating-point math APIs like `VectorOperators.SIN/COS/TAN...` are not intrinsified on AArch64 platform, which causes large performance gap on AArch64. Note that those APIs are optimized by C2 compiler on X86 platforms by calling Intel's SVML code [1]. To close the gap, we would like to optimize these APIs for AArch64 by calling a third-party vector library called libsleef [2], which are available in mainstream Linux distros (e.g. [3] [4]). >> >> SLEEF supports multiple accuracies. To match Vector API's requirement and implement the math ops on AArch64, we 1) call 1.0 ULP accuracy with FMA instructions used stubs in libsleef for most of the operations by default, and 2) add the vector calling convention to apply with the runtime calls to stub code in libsleef. Note that for those APIs that libsleef does not support 1.0 ULP, we choose 0.5 ULP instead. >> >> To help loading the expected libsleef library, this patch also adds an experimental JVM option (i.e. `-XX:UseSleefLib`) for AArch64 platforms. People can use it to denote the libsleef path/name explicitly. By default, it points to the system installed library. If the library does not exist or the dynamic loading of it in runtime fails, the math vector ops will fall-back to use the default scalar version without error. But a warning is printed out if people specifies a nonexistent library explicitly. >> >> Note that this is a part of the original proposed patch in panama-dev [5], just with some initial review comments addressed. And now we'd like to get some wider feedbacks from more hotspot experts. >> >> [1] https://github.com/openjdk/jdk/pull/3638 >> [2] https://sleef.org/ >> [3] https://packages.fedoraproject.org/pkgs/sleef/sleef/ >> [4] https://packages.debian.org/bookworm/libsleef3 >> [5] https://mail.openjdk.org/pipermail/panama-dev/2022-December/018172.html > > Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision: > > Rename vmath to sleef in configure Not having a build time dependency on libsleef means you cannot really verify that the functions you want to call are correct, but maybe you feel secure that they will never change? ------------- PR Comment: https://git.openjdk.org/jdk/pull/16234#issuecomment-1834476264 From duke at openjdk.org Thu Nov 30 20:23:05 2023 From: duke at openjdk.org (Srinivas Vamsi Parasa) Date: Thu, 30 Nov 2023 20:23:05 GMT Subject: RFR: 8319577: x86_64 AVX2 intrinsics for Arrays.sort methods (int, float arrays) [v6] In-Reply-To: References: Message-ID: On Thu, 30 Nov 2023 20:07:19 GMT, Magnus Ihse Bursie wrote: > But you are saying that you want to skip building this library unless you have a gcc version that supports c++17? > Yes, the request is to skip building the simdsort library if GCC version is < 8 as only GCC >= 8 supports C++17 features. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16534#discussion_r1411218074 From aivanov at openjdk.org Thu Nov 30 20:38:13 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 30 Nov 2023 20:38:13 GMT Subject: RFR: 8320608: Many jtreg printing tests are missing the @printer keyword [v3] In-Reply-To: References: <-89UjGPFJWRn0hJIyT5n2YLJKNCyaSeDPjOgw3dmZrw=.613b5081-039a-42cc-8b8c-f48fc91b9abd@github.com> <96ngNnlrygkt0Ni0W2xyr9STyYoQEALdDXtNu_jIQUg=.8969504d-ac54-4dc6-a271-08154523db94@github.com> Message-ID: On Thu, 30 Nov 2023 18:14:21 GMT, Phil Race wrote: >> That's the reason why I prefer you keep the `@run` tag in `SetOrient.java`: to document that it's *an applet test* ? with the html file being the test starter. > > Ok, although when I see something like that it looks more like a bug to me. It's an applet, it should be re-written as a standalone app. I'll submit a bug for it, if I don't forget. It could be picked up by an external contributor? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16785#discussion_r1411231060 From serb at openjdk.org Thu Nov 30 20:38:11 2023 From: serb at openjdk.org (Sergey Bylokhov) Date: Thu, 30 Nov 2023 20:38:11 GMT Subject: RFR: 8320608: Many jtreg printing tests are missing the @printer keyword [v3] In-Reply-To: References: Message-ID: On Thu, 30 Nov 2023 18:23:28 GMT, Phil Race wrote: >> Many printing tests do not have the @printer keyword. This adds them to those that need it. >> I also found one test that has nothing to do with printing in the print folder and moved it out. > > Phil Race has updated the pull request incrementally with one additional commit since the last revision: > > 8320608 Marked as reviewed by serb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/16785#pullrequestreview-1758403498 From rriggs at openjdk.org Thu Nov 30 20:40:09 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 30 Nov 2023 20:40:09 GMT Subject: RFR: 8320759: Creation of random BigIntegers can be made faster [v2] In-Reply-To: References: Message-ID: On Mon, 27 Nov 2023 22:58:17 GMT, fabioromano1 wrote: >> A faster and simpler way to generate random BigIntegers, avoiding eventually trimming of leading zeros in magnitude array. > > fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: > > Update BigInteger(int, Random) > > Update a comment There are some JMH tests for BigInteger in test/micro/org/openjdk/bench/java/math/Big*. Can you create a new benchmark for the computations above and include it in the PR. That will make it easier to keep track of the performance over time. Thanks ------------- PR Comment: https://git.openjdk.org/jdk/pull/16817#issuecomment-1834525902 From aivanov at openjdk.org Thu Nov 30 20:42:10 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 30 Nov 2023 20:42:10 GMT Subject: RFR: 8320608: Many jtreg printing tests are missing the @printer keyword [v3] In-Reply-To: References: Message-ID: On Thu, 30 Nov 2023 18:23:28 GMT, Phil Race wrote: >> Many printing tests do not have the @printer keyword. This adds them to those that need it. >> I also found one test that has nothing to do with printing in the print folder and moved it out. > > Phil Race has updated the pull request incrementally with one additional commit since the last revision: > > 8320608 Marked as reviewed by aivanov (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/16785#pullrequestreview-1758414252 From darcy at openjdk.org Thu Nov 30 20:48:21 2023 From: darcy at openjdk.org (Joe Darcy) Date: Thu, 30 Nov 2023 20:48:21 GMT Subject: RFR: JDK-8319413: Start of release updates for JDK 23 [v3] In-Reply-To: References: Message-ID: > Time to start making preparations for JDK 23. Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits: - Merge branch 'master' into JDK-8319413 - Merge branch 'master' into JDK-8319413 - Add symbol files for JDK 22 build 25. - Merge branch 'master' into JDK-8319413 - Merge branch 'master' into JDK-8319413 - Adjust expected release date. - Fix omission in Classfile.java - JDK-8319413: Start of release updates for JDK 23 ------------- Changes: https://git.openjdk.org/jdk/pull/16505/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16505&range=02 Stats: 7694 lines in 70 files changed: 7656 ins; 0 del; 38 mod Patch: https://git.openjdk.org/jdk/pull/16505.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16505/head:pull/16505 PR: https://git.openjdk.org/jdk/pull/16505 From naoto at openjdk.org Thu Nov 30 20:52:10 2023 From: naoto at openjdk.org (Naoto Sato) Date: Thu, 30 Nov 2023 20:52:10 GMT Subject: RFR: 8321059: Unneeded array assignments in MergeCollation and CompactByteArray Message-ID: Removing the unnecessary array assignments. ------------- Commit messages: - initial commit Changes: https://git.openjdk.org/jdk/pull/16912/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16912&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8321059 Stats: 8 lines in 2 files changed: 2 ins; 3 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/16912.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16912/head:pull/16912 PR: https://git.openjdk.org/jdk/pull/16912 From naoto.sato at oracle.com Thu Nov 30 20:57:25 2023 From: naoto.sato at oracle.com (Naoto Sato) Date: Thu, 30 Nov 2023 12:57:25 -0800 Subject: Unneeded array assignments in core libs In-Reply-To: References: Message-ID: <2ebd64f4-c442-4eb5-ae08-72e28b536d93@oracle.com> PR submitted. I was pleasantly surprised how quickly bugreport.java.com turned reports into issues. Naoto On 11/29/23 2:18 PM, Anthony Goubard wrote: > Thanks for the answers. > I've created an issue in bugreport.java.com > with?internal review ID : 9076287 > > Hope that helps, > Anthony > > Le?mer. 29 nov. 2023 ??21:55, Roger Riggs > a ?crit?: > > Hi Anthony, > > Go ahead a file a single bug (for the two cases). > That code may have been written before Arrays.fill(...). > > Regards, Roger > > On 11/29/23 7:54 AM, Anthony Goubard wrote: >> Hello, >> >> ?Last Friday, I decided to look if there were some classes that >> did unneeded array assignments (e.g. to 0 / 0.0f / null / false) >> in the JDK. >> >> ?I've found a few places and in particular 2 places where it's >> done in big for loops (looping more than 500 times). So I thought >> you might be interested to know about them. >> >> https://github.com/openjdk/jdk/blob/6871a2ff1207d3ee70973b1c4ee9bd09969c185b/src/java.base/share/classes/java/text/MergeCollation.java#L72 >> https://github.com/openjdk/jdk/blob/6871a2ff1207d3ee70973b1c4ee9bd09969c185b/src/java.base/share/classes/sun/text/CompactByteArray.java#L85 >> Also for CompactByteArray, maybe it's worth checking that >> defaultValue is different than 0 before entering the for loop >> (Line 80) >> >> Let me know if you're interested in fixing them and if you want me >> to fill 2 bugs for them in the JBS or in bugreport.java.com >> . >> >> Best regards, >> Anthony Goubard > From duke at openjdk.org Thu Nov 30 21:03:14 2023 From: duke at openjdk.org (Vladimir Yaroslavskiy) Date: Thu, 30 Nov 2023 21:03:14 GMT Subject: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort) [v11] In-Reply-To: References: <918oCEfFu2JweXfV-afD1l_AGDDuc7dJwAxip-Ze6ZI=.8d5e9692-23db-47e4-9586-99e53b9cfbb6@github.com> Message-ID: On Tue, 28 Nov 2023 00:35:48 GMT, Srinivas Vamsi Parasa wrote: >> Laurent Bourg?s has updated the pull request incrementally with one additional commit since the last revision: >> >> add @SuppressWarnings (serial) > > xmlns:o="urn:schemas-microsoft-com:office:office" > xmlns:x="urn:schemas-microsoft-com:office:excel" > xmlns="http://www.w3.org/TR/REC-html40"> > > > > > > href="file:///C:/Users/sparasa/AppData/Local/Temp/msohtmlclip1/01/clip.htm"> > href="file:///C:/Users/sparasa/AppData/Local/Temp/msohtmlclip1/01/clip_filelist.xml"> > > > > > > > > > Benchmark (us/op) | Builder | (size) | Stock JDK (+ AVX512 sort) | DPQS_r01 (+ AVX512 sort) | Speedup > -- | -- | -- | -- | -- | -- > ArraysSort.Int.testSort | RANDOM | 600 | 2.256 | 1.713 | 1.32 > ArraysSort.Int.testSort | RANDOM | 9000 | 41.457 | 38.316 | 1.08 > ArraysSort.Int.testSort | RANDOM | 20000 | 98.448 | 86.376 | 1.14 > ArraysSort.Int.testSort | RANDOM | 400000 | 2820.939 | 2792.333 | 1.01 > ArraysSort.Int.testSort | RANDOM | 3000000 | 23426.411 | 23711.885 | 0.99 > ArraysSort.Int.testSort | REPEATED | 600 | 1.032 | 0.859 | 1.20 > ArraysSort.Int.testSort | REPEATED | 9000 | 5.114 | 5.014 | 1.02 > ArraysSort.Int.testSort | REPEATED | 20000 | 10.3 | 9.532 | 1.08 > ArraysSort.Int.testSort | REPEATED | 400000 | 210.742 | 235.281 | 0.90 > ArraysSort.Int.testSort | REPEATED | 3000000 | 1948.589 | 1955.258 | 1.00 > ArraysSort.Int.testSort | STAGGER | 600 | 2.125 | 2.157 | 0.99 > ArraysSort.Int.testSort | STAGGER | 9000 | 29.86 | 29.931 | 1.00 > ArraysSort.Int.testSort | STAGGER | 20000 | 67.096 | 66.543 | 1.01 > ArraysSort.Int.testSort | STAGGER | 400000 | 1247.53 | 1224.999 | 1.02 > ArraysSort.Int.testSort | STAGGER | 3000000 | 9435.404 | 9495.189 | 0.99 > ArraysSort.Int.testSort | SHUFFLE | 600 | 2.701 | 1.64 | 1.65 > ArraysSort.Int.testSort | SHUFFLE | 9000 | 38.976 | 34.201 | 1.14 > ArraysSort.Int.testSort | SHUFFLE | 20000 | 96.399 | 79.616 | 1.21 > ArraysSort.Int.testSort | SHUFFLE | 400000 | 2566.338 | 2436.271 | 1.05 > ArraysSort.Int.testSort | SHUFFLE | 3000000 | 20835.935 | 20071.12 | 1.04 > > > > > > Hello Vamsi (@vamsi-parasa), Could you please run benchmarking for these classes? Test suite is the same (non-parallel case only) https://github.com/iaroslavski/sorting/blob/master/radixsort/ArraysSort.java https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_r02.java https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_r03.java https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_r04.java https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_r05.java https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_r06.java https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_r07.java https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_r08.java https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_r98.java https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_r99.java Many thanks, Vladimir ------------- PR Comment: https://git.openjdk.org/jdk/pull/13568#issuecomment-1834552717 From jlu at openjdk.org Thu Nov 30 21:11:33 2023 From: jlu at openjdk.org (Justin Lu) Date: Thu, 30 Nov 2023 21:11:33 GMT Subject: RFR: JDK-8319626: Override toString() for ZipFile [v5] In-Reply-To: References: Message-ID: <1B6yDwztQFOTF5T9Ztu8aDE7uYDYDzvd6ntbVaQoEhU=.b9c434e5-72e3-4ca5-882a-4b0029066ca6@github.com> > Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8319982) which overrides and provides an implementation of `toString()` in _java.util.zip.ZipFile_ (and by extension, _java.util.jar.JarFile_). Justin Lu has updated the pull request incrementally with one additional commit since the last revision: return base name, not full path ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16643/files - new: https://git.openjdk.org/jdk/pull/16643/files/8c182f07..3d8ed448 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16643&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16643&range=03-04 Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/16643.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16643/head:pull/16643 PR: https://git.openjdk.org/jdk/pull/16643 From jlu at openjdk.org Thu Nov 30 21:11:34 2023 From: jlu at openjdk.org (Justin Lu) Date: Thu, 30 Nov 2023 21:11:34 GMT Subject: RFR: JDK-8319626: Override toString() for ZipFile [v5] In-Reply-To: References: Message-ID: <7Iv6zv2OJnMWtJLbxAm8UnyphN19jbbJ-FuzK4yzr58=.4f1d7891-9484-4e79-8bb0-922cdc094034@github.com> On Thu, 30 Nov 2023 10:17:23 GMT, Jaikiran Pai wrote: >> I like the new wording (have no oppinion if absolute path is better). > > Hello Justin, > >> I am not sure if you have a preference one way or another regarding providing the full path versus just the file name, but I can switch the full path for just the file name if need be. > > My opinion is that we should not use the absolute path here. Section 2.1 of secure coding guidelines https://www.oracle.com/java/technologies/javase/seccodeguide.html#2-1 suggests not to include full paths in exception messages. > > With the proposed change to the toString() method here, which uses absolute paths, I think it would then mean that we would have to review (within the JDK) usages of (explicit or implicit) `ZipFile.toString()` to prevent accidentally including the complete paths in the exceptions, like in the case below: > > > final ZipFile zf = new ZipFile("/home/me/xyz.zip"); > ... // do something > throw new Exception("failed to handle zipfile " + zf); Thanks Jai, that makes sense. Replaced full path with just the base name in latest commit. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16643#discussion_r1411262907 From jlu at openjdk.org Thu Nov 30 21:13:06 2023 From: jlu at openjdk.org (Justin Lu) Date: Thu, 30 Nov 2023 21:13:06 GMT Subject: RFR: 8321059: Unneeded array assignments in MergeCollation and CompactByteArray In-Reply-To: References: Message-ID: On Thu, 30 Nov 2023 20:46:12 GMT, Naoto Sato wrote: > Removing the unnecessary array assignments. Looks good ------------- Marked as reviewed by jlu (Committer). PR Review: https://git.openjdk.org/jdk/pull/16912#pullrequestreview-1758458649 From bpb at openjdk.org Thu Nov 30 21:21:12 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 30 Nov 2023 21:21:12 GMT Subject: RFR: 8321059: Unneeded array assignments in MergeCollation and CompactByteArray In-Reply-To: References: Message-ID: On Thu, 30 Nov 2023 20:46:12 GMT, Naoto Sato wrote: > Removing the unnecessary array assignments. Looks fine. Is that "XXX" reminder at line 58 in MergeCollation still pertinent or could it be removed? ------------- Marked as reviewed by bpb (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16912#pullrequestreview-1758469599 From jvernee at openjdk.org Thu Nov 30 21:26:16 2023 From: jvernee at openjdk.org (Jorn Vernee) Date: Thu, 30 Nov 2023 21:26:16 GMT Subject: RFR: 8321130: Microbenchmarks do not build any more after 8254693 on 32 bit platforms Message-ID: Need to use `jlong_to_ptr` instead of raw cast. I've also fixed another latent issue in `CLayouts` where we were initializing `C_LONG_LONG` with the `long` layout. This was resulting in a class cast exception when running the XorTest benchmark. The size of `long` on Linux x86 32-bits is 4 bytes, so the returned layout has type `ValueLayout.OfInt` which we then try to cast to `ValueLayout.OfLong`, resulting in a CCE. This would also be an issue on Windows. Testing: running XorTest benchmark on linux-x86 and windows-x64. ------------- Commit messages: - Fix x86 running of XorTest Changes: https://git.openjdk.org/jdk/pull/16913/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16913&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8321130 Stats: 5 lines in 2 files changed: 2 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/16913.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16913/head:pull/16913 PR: https://git.openjdk.org/jdk/pull/16913 From duke at openjdk.org Thu Nov 30 21:29:05 2023 From: duke at openjdk.org (Brett Okken) Date: Thu, 30 Nov 2023 21:29:05 GMT Subject: RFR: 8321059: Unneeded array assignments in MergeCollation and CompactByteArray In-Reply-To: References: Message-ID: <6Umy3nxhMKROX_8fgY7AqGqBkvX3EhRBF9tBo6L8BKE=.feac8b48-bc7f-41e9-b6b5-37111e8edbd8@github.com> On Thu, 30 Nov 2023 20:46:12 GMT, Naoto Sato wrote: > Removing the unnecessary array assignments. src/java.base/share/classes/sun/text/CompactByteArray.java line 83: > 81: for (i = 0; i < UNICODECOUNT; ++i) { > 82: values[i] = defaultValue; > 83: } should this be `Arrays.fill(values, defaultValue);` ? https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/util/Arrays.html#fill(byte%5B%5D,byte) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16912#discussion_r1411279673 From mcimadamore at openjdk.org Thu Nov 30 21:38:04 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Thu, 30 Nov 2023 21:38:04 GMT Subject: RFR: 8321130: Microbenchmarks do not build any more after 8254693 on 32 bit platforms In-Reply-To: References: Message-ID: On Thu, 30 Nov 2023 20:59:01 GMT, Jorn Vernee wrote: > Need to use `jlong_to_ptr` instead of raw cast. > > I've also fixed another latent issue in `CLayouts` where we were initializing `C_LONG_LONG` with the `long` layout. This was resulting in a class cast exception when running the XorTest benchmark. The size of `long` on Linux x86 32-bits is 4 bytes, so the returned layout has type `ValueLayout.OfInt` which we then try to cast to `ValueLayout.OfLong`, resulting in a CCE. This would also be an issue on Windows. > > Testing: running XorTest benchmark on linux-x86 and windows-x64. Marked as reviewed by mcimadamore (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/16913#pullrequestreview-1758494120 From naoto at openjdk.org Thu Nov 30 21:51:19 2023 From: naoto at openjdk.org (Naoto Sato) Date: Thu, 30 Nov 2023 21:51:19 GMT Subject: RFR: 8321059: Unneeded array assignments in MergeCollation and CompactByteArray [v2] In-Reply-To: References: Message-ID: > Removing the unnecessary array assignments. Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: Use Arrays.fill() ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16912/files - new: https://git.openjdk.org/jdk/pull/16912/files/4fd6e61b..b1708ddb Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16912&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16912&range=00-01 Stats: 5 lines in 1 file changed: 2 ins; 2 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/16912.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16912/head:pull/16912 PR: https://git.openjdk.org/jdk/pull/16912 From naoto at openjdk.org Thu Nov 30 21:51:21 2023 From: naoto at openjdk.org (Naoto Sato) Date: Thu, 30 Nov 2023 21:51:21 GMT Subject: RFR: 8321059: Unneeded array assignments in MergeCollation and CompactByteArray [v2] In-Reply-To: References: Message-ID: On Thu, 30 Nov 2023 21:17:57 GMT, Brian Burkhalter wrote: > Is that "XXX" reminder at line 58 in MergeCollation still pertinent or could it be removed? Maybe, but not 100% sure, so I just left it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16912#issuecomment-1834615018 From naoto at openjdk.org Thu Nov 30 21:51:23 2023 From: naoto at openjdk.org (Naoto Sato) Date: Thu, 30 Nov 2023 21:51:23 GMT Subject: RFR: 8321059: Unneeded array assignments in MergeCollation and CompactByteArray [v2] In-Reply-To: <6Umy3nxhMKROX_8fgY7AqGqBkvX3EhRBF9tBo6L8BKE=.feac8b48-bc7f-41e9-b6b5-37111e8edbd8@github.com> References: <6Umy3nxhMKROX_8fgY7AqGqBkvX3EhRBF9tBo6L8BKE=.feac8b48-bc7f-41e9-b6b5-37111e8edbd8@github.com> Message-ID: On Thu, 30 Nov 2023 21:26:20 GMT, Brett Okken wrote: >> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: >> >> Use Arrays.fill() > > src/java.base/share/classes/sun/text/CompactByteArray.java line 83: > >> 81: for (i = 0; i < UNICODECOUNT; ++i) { >> 82: values[i] = defaultValue; >> 83: } > > should this be `Arrays.fill(values, defaultValue);` ? > > https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/util/Arrays.html#fill(byte%5B%5D,byte) Thanks. Modernized. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16912#discussion_r1411299519 From bchristi at openjdk.org Thu Nov 30 21:56:09 2023 From: bchristi at openjdk.org (Brent Christian) Date: Thu, 30 Nov 2023 21:56:09 GMT Subject: RFR: 8314480: Memory ordering spec updates in java.lang.ref In-Reply-To: References: Message-ID: On Tue, 21 Nov 2023 09:13:59 GMT, Viktor Klang wrote: >> src/java.base/share/classes/java/lang/ref/Reference.java line 505: >> >>> 503: * to return this reference even though the referent is still strongly >>> 504: * reachable. That is, before the referent has reached the expected >>> 505: * reachability level. >> >> The wording here is kind of awkward. We could try to wordsmith it, but there is also the possibility that there are valid use cases for using enqueue(), which makes this caution seem misplaced. An alternative would simply be to omit this paragraph. > > Might be better to leave out the last sencence? I'll take out the last sentence, and we can continue discussing whether to keep this note at all. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16644#discussion_r1411305306 From bpb at openjdk.org Thu Nov 30 22:12:06 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 30 Nov 2023 22:12:06 GMT Subject: RFR: 8321059: Unneeded array assignments in MergeCollation and CompactByteArray [v2] In-Reply-To: References: Message-ID: <93i4ohpMOEB7bUtMijikxjOKBB2DVRP9Z_rRyFh4YPI=.7077f21c-86a6-488d-87aa-f35d8b00e64b@github.com> On Thu, 30 Nov 2023 21:51:19 GMT, Naoto Sato wrote: >> Removing the unnecessary array assignments. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Use Arrays.fill() Marked as reviewed by bpb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/16912#pullrequestreview-1758547239 From iris at openjdk.org Thu Nov 30 22:12:09 2023 From: iris at openjdk.org (Iris Clark) Date: Thu, 30 Nov 2023 22:12:09 GMT Subject: RFR: JDK-8319413: Start of release updates for JDK 23 [v3] In-Reply-To: References: Message-ID: On Thu, 30 Nov 2023 20:48:21 GMT, Joe Darcy wrote: >> Time to start making preparations for JDK 23. > > Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits: > > - Merge branch 'master' into JDK-8319413 > - Merge branch 'master' into JDK-8319413 > - Add symbol files for JDK 22 build 25. > - Merge branch 'master' into JDK-8319413 > - Merge branch 'master' into JDK-8319413 > - Adjust expected release date. > - Fix omission in Classfile.java > - JDK-8319413: Start of release updates for JDK 23 Marked as reviewed by iris (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/16505#pullrequestreview-1758548243 From bpb at openjdk.org Thu Nov 30 22:12:08 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 30 Nov 2023 22:12:08 GMT Subject: RFR: 8321059: Unneeded array assignments in MergeCollation and CompactByteArray [v2] In-Reply-To: References: Message-ID: On Thu, 30 Nov 2023 21:47:27 GMT, Naoto Sato wrote: > > Is that "XXX" reminder at line 58 in MergeCollation still pertinent or could it be removed? > > Maybe, but not 100% sure, so I just left it. If unsure, better to leave it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16912#issuecomment-1834640272 From almatvee at openjdk.org Thu Nov 30 22:28:04 2023 From: almatvee at openjdk.org (Alexander Matveev) Date: Thu, 30 Nov 2023 22:28:04 GMT Subject: RFR: 8227529: With malformed --app-image the error messages are awful In-Reply-To: References: Message-ID: On Thu, 30 Nov 2023 14:14:56 GMT, Alexey Semenyuk wrote: > Add tests to make sure jpackage emits meaningful error messages when used with invalid app images. > > Added `JPackageCommand.nullableOutputBundle()` function that returns an empty `Optional` instance if it fails to deduce a path to the output bundle from jpackage command line. This is the case when jpackage command is used with `--app-image` cli option and referenced app image directory is missing `.jpackage.xml` file. Looks good. ------------- Marked as reviewed by almatvee (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16901#pullrequestreview-1758569694 From bchristi at openjdk.org Thu Nov 30 22:42:07 2023 From: bchristi at openjdk.org (Brent Christian) Date: Thu, 30 Nov 2023 22:42:07 GMT Subject: RFR: 8314480: Memory ordering spec updates in java.lang.ref In-Reply-To: References: Message-ID: <-EMuHypBSxQF40bnTvD13GKpGbx59CRml904UB6owkc=.c173d608-9e4e-4455-aab2-d0327733f236@github.com> On Tue, 21 Nov 2023 22:58:09 GMT, Roger Riggs wrote: >> Classes in the `java.lang.ref` package would benefit from an update to bring the spec in line with how the VM already behaves. The changes would focus on _happens-before_ edges at some key points during reference processing. >> >> A couple key things we want to be able to say are: >> - `Reference.reachabilityFence(x)` _happens-before_ reference processing occurs for 'x'. >> - `Cleaner.register()` _happens-before_ the Cleaner thread runs the registered cleaning action. >> >> This will bring Cleaner in line (or close) with the memory visibility guarantees made for finalizers in [JLS 17.4.5](https://docs.oracle.com/javase/specs/jls/se18/html/jls-17.html#jls-17.4.5): >> _"There is a happens-before edge from the end of a constructor of an object to the start of a finalizer (?12.6) for that object."_ > > src/java.base/share/classes/java/lang/ref/Reference.java line 552: > >> 550: * of this method. >> 551: * Invocation of this method does not itself initiate reference processing, >> 552: * garbage collection, or finalization. > > My understanding was that it is not the object instance that is being guarded, only that the reference holding the object is considered a strong root and is only used to delimit a range of bytecodes for which the reference is considered to be strong. > In particular, the invocation of the method itself has no semantics, only that a control flow could reach that statement and the reference was considered strong as long as the reference was in a scope that included the reachability fence. The existing docs refer to "invocation" of this method. I've continued with that, and in general have kept this at a bit higher level, in order to simplify understanding. I'm open to more detailed wording, if it would improve understandability, (or if what I have is not functionally accurate). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16644#discussion_r1411372474 From rriggs at openjdk.org Thu Nov 30 22:56:06 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 30 Nov 2023 22:56:06 GMT Subject: RFR: 8321059: Unneeded array assignments in MergeCollation and CompactByteArray [v2] In-Reply-To: References: Message-ID: On Thu, 30 Nov 2023 21:51:19 GMT, Naoto Sato wrote: >> Removing the unnecessary array assignments. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Use Arrays.fill() LGTM ------------- Marked as reviewed by rriggs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16912#pullrequestreview-1758625426 From prr at openjdk.org Thu Nov 30 23:02:17 2023 From: prr at openjdk.org (Phil Race) Date: Thu, 30 Nov 2023 23:02:17 GMT Subject: Integrated: 8320608: Many jtreg printing tests are missing the @printer keyword In-Reply-To: References: Message-ID: On Wed, 22 Nov 2023 19:26:40 GMT, Phil Race wrote: > Many printing tests do not have the @printer keyword. This adds them to those that need it. > I also found one test that has nothing to do with printing in the print folder and moved it out. This pull request has now been integrated. Changeset: 76fea807 Author: Phil Race URL: https://git.openjdk.org/jdk/commit/76fea807071eee80a1e00aae7bc4784a6d35bf4b Stats: 247 lines in 139 files changed: 140 ins; 23 del; 84 mod 8320608: Many jtreg printing tests are missing the @printer keyword Reviewed-by: aivanov, serb ------------- PR: https://git.openjdk.org/jdk/pull/16785 From bchristi at openjdk.org Thu Nov 30 23:09:09 2023 From: bchristi at openjdk.org (Brent Christian) Date: Thu, 30 Nov 2023 23:09:09 GMT Subject: RFR: 8314480: Memory ordering spec updates in java.lang.ref In-Reply-To: References: Message-ID: On Wed, 15 Nov 2023 22:45:46 GMT, Stuart Marks wrote: >> Classes in the `java.lang.ref` package would benefit from an update to bring the spec in line with how the VM already behaves. The changes would focus on _happens-before_ edges at some key points during reference processing. >> >> A couple key things we want to be able to say are: >> - `Reference.reachabilityFence(x)` _happens-before_ reference processing occurs for 'x'. >> - `Cleaner.register()` _happens-before_ the Cleaner thread runs the registered cleaning action. >> >> This will bring Cleaner in line (or close) with the memory visibility guarantees made for finalizers in [JLS 17.4.5](https://docs.oracle.com/javase/specs/jls/se18/html/jls-17.html#jls-17.4.5): >> _"There is a happens-before edge from the end of a constructor of an object to the start of a finalizer (?12.6) for that object."_ > > src/java.base/share/classes/java/lang/ref/ReferenceQueue.java line 187: > >> 185: * {@link Reference#enqueue()} instead of by the garbage collector, its >> 186: * former referent (which has since been cleared) could still be strongly >> 187: * reachable. > > See my comments on the corresponding Reference.enqueue() apiNote. I'm not sure we want to have this issue sprinkled around in the apiNotes for several methods, including others here on ReferenceQueue. > > If we do want to address this issue -- and it's not clear to me that we do -- then perhaps we should do it in a central location? We can cover this issue just in `Reference.enqueue()`. I'll take out these `@apiNote`s, and put in `@see Reference.enqueue()`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16644#discussion_r1411395204 From bpb at openjdk.org Thu Nov 30 23:30:25 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 30 Nov 2023 23:30:25 GMT Subject: RFR: 8321053: Use ByteArrayInputStream.buf directly when parameter of transferTo() is trusted [v2] In-Reply-To: References: Message-ID: On Thu, 30 Nov 2023 12:34:24 GMT, Sergey Tsypanov wrote: >> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: >> >> 8321053: Trust non-FilterOutputStreams in "java." packages > > src/java.base/share/classes/java/io/ByteArrayInputStream.java line 211: > >> 209: if (len > 0) { >> 210: byte[] tmp; >> 211: if ("java.io".equals(out.getClass().getPackageName())) > > I think we should trust all classes in `java.*` packages, i.e. the check should be > > out.getClass().getPackageName().startsWith("java.") Change in 176d5165f7d8f3fa4814c9838abb5d18d9f3c338 to use `java.` instead of `java.io`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16893#discussion_r1411408644 From bpb at openjdk.org Thu Nov 30 23:30:20 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 30 Nov 2023 23:30:20 GMT Subject: RFR: 8321053: Use ByteArrayInputStream.buf directly when parameter of transferTo() is trusted [v2] In-Reply-To: References: Message-ID: > Pass `ByteArrayInputStream.buf ` directly to the `OutputStream` parameter of `BAIS.transferTo` only if the target stream is in the `java.io` package. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8321053: Trust non-FilterOutputStreams in "java." packages ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16893/files - new: https://git.openjdk.org/jdk/pull/16893/files/a42a45ce..176d5165 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16893&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16893&range=00-01 Stats: 23 lines in 2 files changed: 10 ins; 0 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/16893.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16893/head:pull/16893 PR: https://git.openjdk.org/jdk/pull/16893 From bpb at openjdk.org Thu Nov 30 23:30:22 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 30 Nov 2023 23:30:22 GMT Subject: RFR: 8321053: Use ByteArrayInputStream.buf directly when parameter of transferTo() is trusted [v2] In-Reply-To: References: Message-ID: On Thu, 30 Nov 2023 17:21:50 GMT, Brian Burkhalter wrote: >> src/java.base/share/classes/java/io/ByteArrayInputStream.java line 211: >> >>> 209: if (len > 0) { >>> 210: byte[] tmp; >>> 211: if ("java.io".equals(out.getClass().getPackageName())) >> >> Isn't this protection defeated with: >> >> ByteArrayInputStream bais = new ByteArrayInputStream(bytes); >> UntrustedOutputStream uos = new UntrustedOutputStream(); >> bais.transferTo(new java.io.DataOutputStream(uos)); >> >> >> Or am I missing something? > > Good catch: that in fact defeats the protection. Changed in 176d5165f7d8f3fa4814c9838abb5d18d9f3c338 not to trust `FilterOutputStream`s. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16893#discussion_r1411408253 From darcy at openjdk.org Thu Nov 30 23:49:24 2023 From: darcy at openjdk.org (Joe Darcy) Date: Thu, 30 Nov 2023 23:49:24 GMT Subject: RFR: JDK-8319413: Start of release updates for JDK 23 [v4] In-Reply-To: References: Message-ID: > Time to start making preparations for JDK 23. Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Update symbol files to JDK 22 b26. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16505/files - new: https://git.openjdk.org/jdk/pull/16505/files/d5cb53c8..9daf1014 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16505&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16505&range=02-03 Stats: 2876 lines in 43 files changed: 2738 ins; 97 del; 41 mod Patch: https://git.openjdk.org/jdk/pull/16505.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16505/head:pull/16505 PR: https://git.openjdk.org/jdk/pull/16505

    System properties` elements in HTML tables: this is indeed questionable. I assume it was based on the notion that a `` element is required in HTML tables, which is not the case (neither for HTML4 nor HTML5). However, it is quite pervasive (there are around 170 occurrences of `` in OpenJDK source), and one could argue that it serves as an informational comment both in Java and HTML. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15762#discussion_r1379955443 From mcimadamore at openjdk.org Thu Nov 2 11:30:05 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Thu, 2 Nov 2023 11:30:05 GMT Subject: RFR: 8319166: Typos in the JavaDocs for MemorySegment In-Reply-To: References: Message-ID: On Thu, 2 Nov 2023 07:40:52 GMT, Per Minborg wrote: > This PR proposes to fix a number of JavaDoc typos in the `MemorySegment::getAtIndex` and `::setAtIndex`. src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 1997: > 1995: * @throws IndexOutOfBoundsException if {@code index * layout.byteSize() > byteSize() - layout.byteSize()}. > 1996: */ > 1997: MemorySegment getAtIndex(AddressLayout layout, long index); I think the fix for `setAtIndex(AddressLayout)` is missing? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16469#discussion_r1379958626 From alanb at openjdk.org Thu Nov 2 11:34:01 2023 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 2 Nov 2023 11:34:01 GMT Subject: RFR: JDK-8315921: Invalid CSS declarations in java.lang class documentation [v2] In-Reply-To: References: Message-ID: On Thu, 2 Nov 2023 10:57:15 GMT, Hannes Walln?fer wrote: >> This change fixes two errors in inline HTML styles in the `java.lang` package: >> >> - wrong CSS property name in `java.lang.String` >> - CSS declaration terminated by colon instead of semicolon in `java.lang.Thread` >> >> Both errors caused the style declarations to be ignored and an error message to be shown in the browser console. >> >> The bug is `noreg-doc`, I tested the docs in the browser to make sure the error message is gone and the HTML displays as intended. > > Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision: > > Find and fix more invalid CSS declarations I think two of cases where the CSS was terminated with a colon may have been my fault. ------------- Marked as reviewed by alanb (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15762#pullrequestreview-1710024507 From jlaskey at openjdk.org Thu Nov 2 11:39:19 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Thu, 2 Nov 2023 11:39:19 GMT Subject: RFR: JDK-8315458 Implementation of Implicitly Declared Classes and Instance Main Method (Second Preview) [v3] In-Reply-To: References: Message-ID: > Address changes from JEP 445 to JEP 463. > > - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. > > - Don't mark class on read. > > - Remove reflection and annotation processing related to unnamed classes. > > - Simplify main method search. Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: Remove .orig files ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16461/files - new: https://git.openjdk.org/jdk/pull/16461/files/a07b8d29..b98e40f2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16461&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16461&range=01-02 Stats: 720 lines in 3 files changed: 0 ins; 720 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/16461.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16461/head:pull/16461 PR: https://git.openjdk.org/jdk/pull/16461 From pminborg at openjdk.org Thu Nov 2 11:53:05 2023 From: pminborg at openjdk.org (Per Minborg) Date: Thu, 2 Nov 2023 11:53:05 GMT Subject: RFR: 8319166: Typos in the JavaDocs for MemorySegment In-Reply-To: References: Message-ID: On Thu, 2 Nov 2023 07:40:52 GMT, Per Minborg wrote: > This PR proposes to fix a number of JavaDoc typos in the `MemorySegment::getAtIndex` and `::setAtIndex`. src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 2014: > 2012: * @throws IllegalArgumentException if {@code layout.byteAlignment() > layout.byteSize()}. > 2013: * @throws IndexOutOfBoundsException if {@code index * layout.byteSize()} overflows. > 2014: * @throws IndexOutOfBoundsException if {@code index * layout.byteSize() > byteSize() - layout.byteSize()}. Here is the change for `setAtIndex(AddressLayout, ...)` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16469#discussion_r1379987973 From mail at sebfisch.de Thu Nov 2 11:56:23 2023 From: mail at sebfisch.de (Sebastian Fischer) Date: Thu, 2 Nov 2023 12:56:23 +0100 Subject: Provide thread-safe and concurrent sequenced collections with insertion order? Message-ID: Hello. I am new to this list so might have missed previous discussion about this but could not find what I was looking for in the archives. The Sequenced collections JEP adds the following static methods to java.util.Collections. - unmodifiableSequencedCollection - unmodifiableSequencedSet - unmodifiableSequencedMap However, the set of static methods returning thread-safe versions of their arguments (like synchronizedCollection, synchronizedSet, and synchronizedMap) has not been extended. As a consequence, I don't see a straightforward way to create thread-safe sequenced sets or maps where encounter-order corresponds to insertion order (like LinkedHashSet or LinkedHashMap) and access them as SequencedSet or SequencedMap. When using the available methods mentioned above, the result is not a sequenced type. For predefined sets and maps where encounter order corresponds to natural order, there are the following methods in java.util.Collections. - synchronizedNavigableSet - synchronizedNavigableMap - synchronizedSortedSet - synchronizedSortedMap However, these methods cannot be used with LinkedHashSet or LinkedHashMap. The following methods would be useful in order to create thread-safe sequenced collections where encounter order is insertion order, but they are currently not provided. - synchronizedSequencedCollection - synchronizedSequencedSet - synchronizedSequencedMap What are the reasons for or against adding these methods? There are also no implementations of concurrent sequenced sets and maps where encounter order is insertion order in java.util.concurrent. All of the provided concurrent sequenced sets and maps are based on natural order, and consequently do not support addFirst, and so on. Are there plans to add concurrent sequenced collections that support the whole interface of sequenced collections? Kind regards, Sebastian -------------- next part -------------- An HTML attachment was scrubbed... URL: From hannesw at openjdk.org Thu Nov 2 11:57:13 2023 From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Thu, 2 Nov 2023 11:57:13 GMT Subject: RFR: JDK-8315921: Invalid CSS declarations in java.lang class documentation [v2] In-Reply-To: References: Message-ID: On Thu, 2 Nov 2023 10:57:15 GMT, Hannes Walln?fer wrote: >> This change fixes two errors in inline HTML styles in the `java.lang` package: >> >> - wrong CSS property name in `java.lang.String` >> - CSS declaration terminated by colon instead of semicolon in `java.lang.Thread` >> >> Both errors caused the style declarations to be ignored and an error message to be shown in the browser console. >> >> The bug is `noreg-doc`, I tested the docs in the browser to make sure the error message is gone and the HTML displays as intended. > > Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision: > > Find and fix more invalid CSS declarations Thanks, I won't blame you, CSS within HTML within JavaDoc comments is weird. :) ------------- PR Comment: https://git.openjdk.org/jdk/pull/15762#issuecomment-1790588443 From hannesw at openjdk.org Thu Nov 2 11:57:15 2023 From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Thu, 2 Nov 2023 11:57:15 GMT Subject: Integrated: JDK-8315921: Invalid CSS declarations in java.lang class documentation In-Reply-To: References: Message-ID: On Fri, 15 Sep 2023 13:56:21 GMT, Hannes Walln?fer wrote: > This change fixes two errors in inline HTML styles in the `java.lang` package: > > - wrong CSS property name in `java.lang.String` > - CSS declaration terminated by colon instead of semicolon in `java.lang.Thread` > > Both errors caused the style declarations to be ignored and an error message to be shown in the browser console. > > The bug is `noreg-doc`, I tested the docs in the browser to make sure the error message is gone and the HTML displays as intended. This pull request has now been integrated. Changeset: 2d4a4d04 Author: Hannes Walln?fer URL: https://git.openjdk.org/jdk/commit/2d4a4d04b876a8da5fa6c962911d36d547f214fe Stats: 42 lines in 5 files changed: 0 ins; 0 del; 42 mod 8315921: Invalid CSS declarations in java.lang class documentation Reviewed-by: jpai, alanb ------------- PR: https://git.openjdk.org/jdk/pull/15762 From mcimadamore at openjdk.org Thu Nov 2 11:59:03 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Thu, 2 Nov 2023 11:59:03 GMT Subject: RFR: 8319166: Typos in the JavaDocs for MemorySegment In-Reply-To: References: Message-ID: On Thu, 2 Nov 2023 07:40:52 GMT, Per Minborg wrote: > This PR proposes to fix a number of JavaDoc typos in the `MemorySegment::getAtIndex` and `::setAtIndex`. Marked as reviewed by mcimadamore (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/16469#pullrequestreview-1710069176 From mcimadamore at openjdk.org Thu Nov 2 11:59:04 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Thu, 2 Nov 2023 11:59:04 GMT Subject: RFR: 8319166: Typos in the JavaDocs for MemorySegment In-Reply-To: References: Message-ID: <1wtdBxolnaRSx9wsF_0SSoxlhxsqFJlStItcLPCwDuQ=.0bece8d8-bf69-4ddd-80d6-623bebcc160e@github.com> On Thu, 2 Nov 2023 11:50:13 GMT, Per Minborg wrote: >> This PR proposes to fix a number of JavaDoc typos in the `MemorySegment::getAtIndex` and `::setAtIndex`. > > src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 2014: > >> 2012: * @throws IllegalArgumentException if {@code layout.byteAlignment() > layout.byteSize()}. >> 2013: * @throws IndexOutOfBoundsException if {@code index * layout.byteSize()} overflows. >> 2014: * @throws IndexOutOfBoundsException if {@code index * layout.byteSize() > byteSize() - layout.byteSize()}. > > Here is the change for `setAtIndex(AddressLayout, ...)` Ah - true ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16469#discussion_r1379994096 From jlaskey at openjdk.org Thu Nov 2 12:01:05 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Thu, 2 Nov 2023 12:01:05 GMT Subject: RFR: JDK-8315458 Implementation of Implicitly Declared Classes and Instance Main Method (Second Preview) [v3] In-Reply-To: References: Message-ID: On Thu, 2 Nov 2023 11:39:19 GMT, Jim Laskey wrote: >> Address changes from JEP 445 to JEP 463. >> >> - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. >> >> - Don't mark class on read. >> >> - Remove reflection and annotation processing related to unnamed classes. >> >> - Simplify main method search. > > Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: > > Remove .orig files Re .orig. Thank you Alan. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16461#issuecomment-1790596666 From jlaskey at openjdk.org Thu Nov 2 12:01:13 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Thu, 2 Nov 2023 12:01:13 GMT Subject: RFR: JDK-8315458 Implementation of Implicitly Declared Classes and Instance Main Method (Second Preview) [v2] In-Reply-To: References: Message-ID: On Thu, 2 Nov 2023 11:12:14 GMT, Maurizio Cimadamore wrote: >> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove obsolete tests > > src/jdk.compiler/share/classes/com/sun/tools/javac/code/Source.java line 249: > >> 247: STRING_TEMPLATES(JDK21, Fragments.FeatureStringTemplates, DiagKind.PLURAL), >> 248: UNNAMED_CLASSES(JDK21, Fragments.FeatureUnnamedClasses, DiagKind.PLURAL), >> 249: IMPLICIT_CLASSES(JDK21, Fragments.FeatureImplicitClasses, DiagKind.PLURAL), > > Should this be JDK22? No. It should be left at the first preview level. > src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Enter.java line 442: > >> 440: Errors.ClassPublicShouldBeInFile(topElement, tree.name)); >> 441: } >> 442: if ((tree.mods.flags & IMPLICIT_CLASS) != 0) { > > I'm not 100% sure about this. Another option would be to tweak Resolve::findType and make sure that `typeNotFound` (or some more specific message!) is returned when an implicit class is referred to by name. If you look at the first few lines in that method you will see: > > > if (name == names.empty) > return typeNotFound; // do not allow inadvertent "lookup" of anonymous types > > > So, there's already some logic there for skipping some types. The main thing here is that it is done once at the source instead of every look up. The symbol should not exist in the compilation unit. > src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java line 4057: > >> 4055: Name name = names.fromString(simplename); >> 4056: JCModifiers implicitMods = F.at(Position.NOPOS) >> 4057: .Modifiers(Flags.FINAL|Flags.MANDATED|Flags.IMPLICIT_CLASS, List.nil()); > > I don't think the JVMS allows for a flag to have ACC_MANDATED flags? > > > It is a limitation of the class file format that only formal parameters and modules can be flagged as ACC_MANDATED ([?4.7.24](https://docs.oracle.com/javase/specs/jvms/se21/html/jvms-4.html#jvms-4.7.24), [?4.7.25](https://docs.oracle.com/javase/specs/jvms/se21/html/jvms-4.html#jvms-4.7.25)) to indicate that, despite being compiler-generated, they are not considered implementation artifacts. There is no way to flag other compiler-generated constructs so that they too are not considered implementation artifacts (JLS ?13.1). This limitation means that reflective APIs of the Java SE Platform may not accurately indicate the "mandated" status of such constructs. The spec has been updated to include implicit classes. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16461#discussion_r1379993631 PR Review Comment: https://git.openjdk.org/jdk/pull/16461#discussion_r1379993078 PR Review Comment: https://git.openjdk.org/jdk/pull/16461#discussion_r1379990952 From jlaskey at openjdk.org Thu Nov 2 12:01:16 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Thu, 2 Nov 2023 12:01:16 GMT Subject: RFR: JDK-8315458 Implementation of Implicitly Declared Classes and Instance Main Method (Second Preview) [v3] In-Reply-To: <5_K9YYjKcoj4kFnNXrHm_f2GbX1gCZrv60BeBTreEWY=.6b0f0615-4c5e-4200-a8d2-5ce5825b391a@github.com> References: <5_K9YYjKcoj4kFnNXrHm_f2GbX1gCZrv60BeBTreEWY=.6b0f0615-4c5e-4200-a8d2-5ce5825b391a@github.com> Message-ID: On Thu, 2 Nov 2023 11:18:19 GMT, Maurizio Cimadamore wrote: >> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove .orig files > > test/langtools/tools/javac/processing/model/element/TestUnnamedClass.java line 1: > >> 1: /* > > Is the implicit class no longer discoverable through annotation processing? The class is discoverable but only as a regular class. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16461#discussion_r1379994884 From mcimadamore at openjdk.org Thu Nov 2 12:09:05 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Thu, 2 Nov 2023 12:09:05 GMT Subject: RFR: JDK-8315458 Implementation of Implicitly Declared Classes and Instance Main Method (Second Preview) [v2] In-Reply-To: References: Message-ID: <9g7BSn0mYpRLBVI_MNp0tpHI_DggkE_rs1KPrTBRGm0=.50c46c99-8257-4c32-8a44-f3f6a77d463b@github.com> On Thu, 2 Nov 2023 11:55:17 GMT, Jim Laskey wrote: >> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Enter.java line 442: >> >>> 440: Errors.ClassPublicShouldBeInFile(topElement, tree.name)); >>> 441: } >>> 442: if ((tree.mods.flags & IMPLICIT_CLASS) != 0) { >> >> I'm not 100% sure about this. Another option would be to tweak Resolve::findType and make sure that `typeNotFound` (or some more specific message!) is returned when an implicit class is referred to by name. If you look at the first few lines in that method you will see: >> >> >> if (name == names.empty) >> return typeNotFound; // do not allow inadvertent "lookup" of anonymous types >> >> >> So, there's already some logic there for skipping some types. > > The main thing here is that it is done once at the source instead of every look up. The symbol should not exist in the compilation unit. Yep - I think the main consequence of this choice is the fact that we cannot generate a specific error message - but perhaps that's ok (after all, having a special message would equate to admitting that the compiler _does know_ about the name :-) ) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16461#discussion_r1380003979 From mcimadamore at openjdk.org Thu Nov 2 12:09:07 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Thu, 2 Nov 2023 12:09:07 GMT Subject: RFR: JDK-8315458 Implementation of Implicitly Declared Classes and Instance Main Method (Second Preview) [v3] In-Reply-To: References: <5_K9YYjKcoj4kFnNXrHm_f2GbX1gCZrv60BeBTreEWY=.6b0f0615-4c5e-4200-a8d2-5ce5825b391a@github.com> Message-ID: On Thu, 2 Nov 2023 11:57:09 GMT, Jim Laskey wrote: >> test/langtools/tools/javac/processing/model/element/TestUnnamedClass.java line 1: >> >>> 1: /* >> >> Is the implicit class no longer discoverable through annotation processing? > > The class is discoverable but only as a regular class. Why is the test removed? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16461#discussion_r1380002037 From mcimadamore at openjdk.org Thu Nov 2 12:15:05 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Thu, 2 Nov 2023 12:15:05 GMT Subject: RFR: JDK-8315458 Implementation of Implicitly Declared Classes and Instance Main Method (Second Preview) [v2] In-Reply-To: References: Message-ID: On Thu, 2 Nov 2023 11:53:09 GMT, Jim Laskey wrote: >> src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java line 4057: >> >>> 4055: Name name = names.fromString(simplename); >>> 4056: JCModifiers implicitMods = F.at(Position.NOPOS) >>> 4057: .Modifiers(Flags.FINAL|Flags.MANDATED|Flags.IMPLICIT_CLASS, List.nil()); >> >> I don't think the JVMS allows for a flag to have ACC_MANDATED flags? >> >> >> It is a limitation of the class file format that only formal parameters and modules can be flagged as ACC_MANDATED ([?4.7.24](https://docs.oracle.com/javase/specs/jvms/se21/html/jvms-4.html#jvms-4.7.24), [?4.7.25](https://docs.oracle.com/javase/specs/jvms/se21/html/jvms-4.html#jvms-4.7.25)) to indicate that, despite being compiler-generated, they are not considered implementation artifacts. There is no way to flag other compiler-generated constructs so that they too are not considered implementation artifacts (JLS ?13.1). This limitation means that reflective APIs of the Java SE Platform may not accurately indicate the "mandated" status of such constructs. > > The spec has been updated to include implicit classes. Uhmm. In the spec I see implicit classes named here: For reference, the following constructs are declared implicitly in source code, but are not marked as mandated because only formal parameters and modules can be so marked in a class file (JVMS ?4.7.24, JVMS ?4.7.25): ``` Note the `but are not marked as mandated`. I don't think javac sets the mandated flag for any of these. Note that ACC_MANDATED has the same value as the ACC_MODULE flag, so setting that flag on a class w/o at least filtering out when writing the classfile will be problematic. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16461#discussion_r1380009418 From jlaskey at openjdk.org Thu Nov 2 12:27:05 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Thu, 2 Nov 2023 12:27:05 GMT Subject: RFR: JDK-8315458 Implementation of Implicitly Declared Classes and Instance Main Method (Second Preview) [v2] In-Reply-To: References: Message-ID: <82F0iwMjHokh7ezwshT0kdYKvZ37h_XG3L1m_fsfUPQ=.d5e5c36c-768d-4835-8470-d95007fb5435@github.com> On Thu, 2 Nov 2023 12:11:52 GMT, Maurizio Cimadamore wrote: >> The spec has been updated to include implicit classes. > > Uhmm. In the spec I see implicit classes named here: > > > For reference, the following constructs are declared implicitly in source code, but are not marked as mandated because only formal parameters and modules can be so marked in a class file (JVMS ?4.7.24, JVMS ?4.7.25): > ``` > > Note the `but are not marked as mandated`. > > I don't think javac sets the mandated flag for any of these. Note that ACC_MANDATED has the same value as the ACC_MODULE flag, so setting that flag on a class w/o at least filtering out when writing the classfile will be problematic. Hmmm. I'll check with Gavin, but I thought in discussions Alex said that it should be mandated. At any rate, seems the ACC_MANDATED should be removed for stated reasons. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16461#discussion_r1380022715 From jlaskey at openjdk.org Thu Nov 2 12:33:27 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Thu, 2 Nov 2023 12:33:27 GMT Subject: RFR: JDK-8315458 Implementation of Implicitly Declared Classes and Instance Main Method (Second Preview) [v4] In-Reply-To: References: Message-ID: > Address changes from JEP 445 to JEP 463. > > - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. > > - Don't mark class on read. > > - Remove reflection and annotation processing related to unnamed classes. > > - Simplify main method search. Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: Remove MANDATED flag from implicit classes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16461/files - new: https://git.openjdk.org/jdk/pull/16461/files/b98e40f2..2bb3047a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16461&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16461&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/16461.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16461/head:pull/16461 PR: https://git.openjdk.org/jdk/pull/16461 From jlaskey at openjdk.org Thu Nov 2 12:37:03 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Thu, 2 Nov 2023 12:37:03 GMT Subject: RFR: JDK-8315458 Implementation of Implicitly Declared Classes and Instance Main Method (Second Preview) [v4] In-Reply-To: References: <5_K9YYjKcoj4kFnNXrHm_f2GbX1gCZrv60BeBTreEWY=.6b0f0615-4c5e-4200-a8d2-5ce5825b391a@github.com> Message-ID: On Thu, 2 Nov 2023 12:04:22 GMT, Maurizio Cimadamore wrote: >> The class is discoverable but only as a regular class. > > Why is the test removed? Since there is no way to detect an implicit class, the test is no longer relevant. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16461#discussion_r1380034414 From jvernee at openjdk.org Thu Nov 2 13:00:07 2023 From: jvernee at openjdk.org (Jorn Vernee) Date: Thu, 2 Nov 2023 13:00:07 GMT Subject: RFR: 8317545: AIX PPC64: Implementation of Foreign Function & Memory API [v5] In-Reply-To: References: Message-ID: On Wed, 1 Nov 2023 18:43:24 GMT, Martin Doerr wrote: >> Martin Doerr has updated the pull request incrementally with two additional commits since the last revision: >> >> - Improve handling of layouts in NativeType.java >> - Check byte order of 4-byte aligned double. > > Thanks for testing! This sounds good. We need to handle the failing tests separately as they are not immediately related to the up-/downcalls. TestUpcallAsync is failing because of problems with AttachCurrentThreadAsDaemon on AIX. The other ones because libLoaderLookupInvoker.so seems to be broken on AIX. > @JornVernee: You had mentioned a javadoc update. Do we have to wait for anything or can we ship it? > @suchismith1993: Please approve it when you think it's good to go. @TheRealMDoerr This is good to go. We will clarify the javadoc separately (https://bugs.openjdk.org/browse/JDK-8319316) ------------- PR Comment: https://git.openjdk.org/jdk/pull/16179#issuecomment-1790677435 From mdoerr at openjdk.org Thu Nov 2 13:17:19 2023 From: mdoerr at openjdk.org (Martin Doerr) Date: Thu, 2 Nov 2023 13:17:19 GMT Subject: RFR: 8317545: AIX PPC64: Implementation of Foreign Function & Memory API [v5] In-Reply-To: References: Message-ID: On Tue, 17 Oct 2023 14:17:20 GMT, Martin Doerr wrote: >> The AIX linker has a few minor diffs to the linux ABIv1 linker. In addition, double values have only 4 Byte alignment within structures. This PR is based on JDK22 version of the FFI. > > Martin Doerr has updated the pull request incrementally with two additional commits since the last revision: > > - Improve handling of layouts in NativeType.java > - Check byte order of 4-byte aligned double. Thanks for doing that! ------------- PR Comment: https://git.openjdk.org/jdk/pull/16179#issuecomment-1790700379 From mdoerr at openjdk.org Thu Nov 2 13:17:21 2023 From: mdoerr at openjdk.org (Martin Doerr) Date: Thu, 2 Nov 2023 13:17:21 GMT Subject: Integrated: 8317545: AIX PPC64: Implementation of Foreign Function & Memory API In-Reply-To: References: Message-ID: On Fri, 13 Oct 2023 10:12:24 GMT, Martin Doerr wrote: > The AIX linker has a few minor diffs to the linux ABIv1 linker. In addition, double values have only 4 Byte alignment within structures. This PR is based on JDK22 version of the FFI. This pull request has now been integrated. Changeset: 99efcded Author: Martin Doerr URL: https://git.openjdk.org/jdk/commit/99efcded6cd95ceb8a0265c679a8542396aff5c5 Stats: 363 lines in 14 files changed: 261 ins; 82 del; 20 mod 8317545: AIX PPC64: Implementation of Foreign Function & Memory API Reviewed-by: jvernee ------------- PR: https://git.openjdk.org/jdk/pull/16179 From pminborg at openjdk.org Thu Nov 2 13:32:10 2023 From: pminborg at openjdk.org (Per Minborg) Date: Thu, 2 Nov 2023 13:32:10 GMT Subject: Integrated: 8319166: Typos in the JavaDocs for MemorySegment In-Reply-To: References: Message-ID: On Thu, 2 Nov 2023 07:40:52 GMT, Per Minborg wrote: > This PR proposes to fix a number of JavaDoc typos in the `MemorySegment::getAtIndex` and `::setAtIndex`. This pull request has now been integrated. Changeset: cb20a3e7 Author: Per Minborg URL: https://git.openjdk.org/jdk/commit/cb20a3e7a64f977015984a7835ea7fe04b45de7b Stats: 36 lines in 1 file changed: 0 ins; 0 del; 36 mod 8319166: Typos in the JavaDocs for MemorySegment Reviewed-by: mcimadamore ------------- PR: https://git.openjdk.org/jdk/pull/16469 From asotona at openjdk.org Thu Nov 2 13:54:33 2023 From: asotona at openjdk.org (Adam Sotona) Date: Thu, 2 Nov 2023 13:54:33 GMT Subject: RFR: 8304446: javap --system flag doesn't override system APIs Message-ID: Javap ignores --system option when searching for JDK classes. This patch prepends search over JDK system modules. Please review. Thanks, Adam ------------- Commit messages: - 8304446: javap --system flag doesn't override system APIs Changes: https://git.openjdk.org/jdk/pull/16476/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16476&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8304446 Stats: 12 lines in 1 file changed: 12 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/16476.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16476/head:pull/16476 PR: https://git.openjdk.org/jdk/pull/16476 From alanb at openjdk.org Thu Nov 2 13:57:07 2023 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 2 Nov 2023 13:57:07 GMT Subject: RFR: JDK-8315458 Implementation of Implicitly Declared Classes and Instance Main Method (Second Preview) [v4] In-Reply-To: References: Message-ID: On Thu, 2 Nov 2023 12:33:27 GMT, Jim Laskey wrote: >> Address changes from JEP 445 to JEP 463. >> >> - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. >> >> - Don't mark class on read. >> >> - Remove reflection and annotation processing related to unnamed classes. >> >> - Simplify main method search. > > Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: > > Remove MANDATED flag from implicit classes src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java line 76: > 74: UNNAMED_CLASSES, > 75: @JEP(number=999, title="Implicit Classes and Instance Main Methods") > 76: IMPLICIT_CLASSES, I assume you'll change this to 463 before integrating. Can 445 be removed or is there an issue with the symbol database that means it has to stay for a release? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16461#discussion_r1380180698 From rgiulietti at openjdk.org Thu Nov 2 14:25:20 2023 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Thu, 2 Nov 2023 14:25:20 GMT Subject: RFR: 8319174: Enhance robustness of some j.m.BigInteger constructors [v3] In-Reply-To: <0iccBwbAhAmIPGxnz1bhry2Sj_Kz2xngZmb2lPFCUpU=.c2b7c8ef-4e77-4c8f-a7ec-7c5c0980e59e@github.com> References: <0iccBwbAhAmIPGxnz1bhry2Sj_Kz2xngZmb2lPFCUpU=.c2b7c8ef-4e77-4c8f-a7ec-7c5c0980e59e@github.com> Message-ID: > Enhance `java.math.BigInteger` constructors taking a `byte[]` argument by improving guarantees of internal invariants. Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: Restored ordering of exceptions. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16449/files - new: https://git.openjdk.org/jdk/pull/16449/files/af2e4158..33a6ed36 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16449&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16449&range=01-02 Stats: 5 lines in 1 file changed: 2 ins; 1 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/16449.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16449/head:pull/16449 PR: https://git.openjdk.org/jdk/pull/16449 From alanb at openjdk.org Thu Nov 2 14:42:11 2023 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 2 Nov 2023 14:42:11 GMT Subject: RFR: JDK-8315458 Implementation of Implicitly Declared Classes and Instance Main Method (Second Preview) [v4] In-Reply-To: References: Message-ID: On Thu, 2 Nov 2023 12:33:27 GMT, Jim Laskey wrote: >> Address changes from JEP 445 to JEP 463. >> >> - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. >> >> - Don't mark class on read. >> >> - Remove reflection and annotation processing related to unnamed classes. >> >> - Simplify main method search. > > Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: > > Remove MANDATED flag from implicit classes src/java.base/share/classes/sun/launcher/LauncherHelper.java line 973: > 971: abort(null, "java.launcher.cls.error3", > 972: mainMethod.getDeclaringClass().getName()); > 973: } The simplification to LauncherHelper.validateMainClass looks okay but one thing is a bit annoying is the side effect to set mainType. What would you think about changing validateMainClass to return the Method for the main class and have checkAndLoadMain set mainType after validateMainClass succeeds, right not it gets set even if the validate fails. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16461#discussion_r1380252317 From pminborg at openjdk.org Thu Nov 2 14:52:12 2023 From: pminborg at openjdk.org (Per Minborg) Date: Thu, 2 Nov 2023 14:52:12 GMT Subject: RFR: 8319323: FFM: Harmonize the @throws tags in the javadocs Message-ID: <85ItsgUDPivZOhZGk6goTf7kWw0mBj2CQ_5SG9dq8BE=.46ede8a1-f474-4ab9-b18e-4798a08138b9@github.com> This PR proposes to harmonize the @throws tags in the javadocs for the FFM API. The @throws tags are using a bit different principles with respect to formatting and ending with a period or not. Looking at some prominent Java classes like `List` and `Stream`, they: 1) Indent such that multi-line texts align with the beginning of the Exception type 2) Do not have a period after the text. Some of the tags in the FFM classes already conform to these bullets. This PR proposes to make them all do. ------------- Commit messages: - FFM: Harmonize the @throws tags in the javadocs - Merge branch 'master' into javadoc-throws - Harmonize some of the javadoc throws Changes: https://git.openjdk.org/jdk/pull/16478/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16478&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8319323 Stats: 455 lines in 10 files changed: 4 ins; 1 del; 450 mod Patch: https://git.openjdk.org/jdk/pull/16478.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16478/head:pull/16478 PR: https://git.openjdk.org/jdk/pull/16478 From jlaskey at openjdk.org Thu Nov 2 14:56:33 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Thu, 2 Nov 2023 14:56:33 GMT Subject: RFR: JDK-8315458 Implementation of Implicitly Declared Classes and Instance Main Method (Second Preview) [v5] In-Reply-To: References: Message-ID: > Address changes from JEP 445 to JEP 463. > > - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. > > - Don't mark class on read. > > - Remove reflection and annotation processing related to unnamed classes. > > - Simplify main method search. Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: Update JEP number in PreviewFeature ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16461/files - new: https://git.openjdk.org/jdk/pull/16461/files/2bb3047a..05945ebb Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16461&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16461&range=03-04 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/16461.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16461/head:pull/16461 PR: https://git.openjdk.org/jdk/pull/16461 From jlaskey at openjdk.org Thu Nov 2 14:56:36 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Thu, 2 Nov 2023 14:56:36 GMT Subject: RFR: JDK-8315458 Implementation of Implicitly Declared Classes and Instance Main Method (Second Preview) [v4] In-Reply-To: References: Message-ID: On Thu, 2 Nov 2023 13:53:02 GMT, Alan Bateman wrote: >> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove MANDATED flag from implicit classes > > src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java line 76: > >> 74: UNNAMED_CLASSES, >> 75: @JEP(number=999, title="Implicit Classes and Instance Main Methods") >> 76: IMPLICIT_CLASSES, > > I assume you'll change this to 463 before integrating. Can 445 be removed or is there an issue with the symbol database that means it has to stay for a release? Missed that. The issue is that Implicit Classes don't have any API and don't show up in the preview page. Fixed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16461#discussion_r1380274616 From jlaskey at openjdk.org Thu Nov 2 14:56:38 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Thu, 2 Nov 2023 14:56:38 GMT Subject: RFR: JDK-8315458 Implementation of Implicitly Declared Classes and Instance Main Method (Second Preview) [v5] In-Reply-To: References: Message-ID: <9tVB9AKXsJb5Nx7UdwoqtyDs3WIfdJDU40E1jR-Au2k=.a341dbca-ab73-4f06-a50c-bf259711fdb3@github.com> On Thu, 2 Nov 2023 14:38:06 GMT, Alan Bateman wrote: >> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: >> >> Update JEP number in PreviewFeature > > src/java.base/share/classes/sun/launcher/LauncherHelper.java line 973: > >> 971: abort(null, "java.launcher.cls.error3", >> 972: mainMethod.getDeclaringClass().getName()); >> 973: } > > The simplification to LauncherHelper.validateMainClass looks okay but one thing is a bit annoying is the side effect to set mainType. What would you think about changing validateMainClass to return the Method for the main class and have checkAndLoadMain set mainType after validateMainClass succeeds, right not it gets set even if the validate fails. Agree. Will fetch flags from second call from JVM. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16461#discussion_r1380276024 From rriggs at openjdk.org Thu Nov 2 15:35:02 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 2 Nov 2023 15:35:02 GMT Subject: RFR: 8319323: FFM: Harmonize the @throws tags in the javadocs In-Reply-To: <85ItsgUDPivZOhZGk6goTf7kWw0mBj2CQ_5SG9dq8BE=.46ede8a1-f474-4ab9-b18e-4798a08138b9@github.com> References: <85ItsgUDPivZOhZGk6goTf7kWw0mBj2CQ_5SG9dq8BE=.46ede8a1-f474-4ab9-b18e-4798a08138b9@github.com> Message-ID: On Thu, 2 Nov 2023 14:46:49 GMT, Per Minborg wrote: > This PR proposes to harmonize the @throws tags in the javadocs for the FFM API. > > The @throws tags are using a bit different principles with respect to formatting and ending with a period or not. > > Looking at some prominent Java classes like `List` and `Stream`, they: > > 1) Indent such that multi-line texts align with the beginning of the Exception type > 2) Do not have a period after the text. > > Some of the tags in the FFM classes already conform to these bullets. This PR proposes to make them all do. Nice to see consistency, while respecting English grammar. If any javadoc text is a full sentence, it should end with a period. If it is a fragment, then the period is omitted. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16478#issuecomment-1790966335 From mcimadamore at openjdk.org Thu Nov 2 15:36:08 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Thu, 2 Nov 2023 15:36:08 GMT Subject: RFR: JDK-8315458 Implementation of Implicitly Declared Classes and Instance Main Method (Second Preview) [v5] In-Reply-To: References: <5_K9YYjKcoj4kFnNXrHm_f2GbX1gCZrv60BeBTreEWY=.6b0f0615-4c5e-4200-a8d2-5ce5825b391a@github.com> Message-ID: On Thu, 2 Nov 2023 12:34:49 GMT, Jim Laskey wrote: >> Why is the test removed? > > Since there is no way to detect an implicit class, the test is no longer relevant. Right, but the test was still checking useful stuff - e.g. like the fact that the class generated by javac was final, etc (in accordance with the JLS). So some of that should be resurrected I think? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16461#discussion_r1380342689 From jlaskey at openjdk.org Thu Nov 2 15:45:26 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Thu, 2 Nov 2023 15:45:26 GMT Subject: RFR: JDK-8315458 Implementation of Implicitly Declared Classes and Instance Main Method (Second Preview) [v6] In-Reply-To: References: Message-ID: > Address changes from JEP 445 to JEP 463. > > - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. > > - Don't mark class on read. > > - Remove reflection and annotation processing related to unnamed classes. > > - Simplify main method search. Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: Don't store main method info globally. Use addition calls to fetch info. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16461/files - new: https://git.openjdk.org/jdk/pull/16461/files/05945ebb..edbe208b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16461&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16461&range=04-05 Stats: 40 lines in 2 files changed: 21 ins; 10 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/16461.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16461/head:pull/16461 PR: https://git.openjdk.org/jdk/pull/16461 From jlaskey at openjdk.org Thu Nov 2 15:49:15 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Thu, 2 Nov 2023 15:49:15 GMT Subject: RFR: JDK-8315458 Implementation of Implicitly Declared Classes and Instance Main Method (Second Preview) [v6] In-Reply-To: <9tVB9AKXsJb5Nx7UdwoqtyDs3WIfdJDU40E1jR-Au2k=.a341dbca-ab73-4f06-a50c-bf259711fdb3@github.com> References: <9tVB9AKXsJb5Nx7UdwoqtyDs3WIfdJDU40E1jR-Au2k=.a341dbca-ab73-4f06-a50c-bf259711fdb3@github.com> Message-ID: <0S6Mt7XNQICFBpJinq1WP0aDRcEVD_E1i0w1d0e_zb0=.4c996a92-09e9-4c30-b0fa-93281add3231@github.com> On Thu, 2 Nov 2023 14:53:44 GMT, Jim Laskey wrote: >> src/java.base/share/classes/sun/launcher/LauncherHelper.java line 973: >> >>> 971: abort(null, "java.launcher.cls.error3", >>> 972: mainMethod.getDeclaringClass().getName()); >>> 973: } >> >> The simplification to LauncherHelper.validateMainClass looks okay but one thing is a bit annoying is the side effect to set mainType. What would you think about changing validateMainClass to return the Method for the main class and have checkAndLoadMain set mainType after validateMainClass succeeds, right not it gets set even if the validate fails. > > Agree. Will fetch flags from second call from JVM. Amazingly enough I seem to have the JNI straight on the first try. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16461#discussion_r1380359994 From jlaskey at openjdk.org Thu Nov 2 15:49:17 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Thu, 2 Nov 2023 15:49:17 GMT Subject: RFR: JDK-8315458 Implementation of Implicitly Declared Classes and Instance Main Method (Second Preview) [v6] In-Reply-To: References: <5_K9YYjKcoj4kFnNXrHm_f2GbX1gCZrv60BeBTreEWY=.6b0f0615-4c5e-4200-a8d2-5ce5825b391a@github.com> Message-ID: On Thu, 2 Nov 2023 15:33:25 GMT, Maurizio Cimadamore wrote: >> Since there is no way to detect an implicit class, the test is no longer relevant. > > Right, but the test was still checking useful stuff - e.g. like the fact that the class generated by javac was final, etc (in accordance with the JLS). So some of that should be resurrected I think? Agree. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16461#discussion_r1380361777 From mchung at openjdk.org Thu Nov 2 15:57:18 2023 From: mchung at openjdk.org (Mandy Chung) Date: Thu, 2 Nov 2023 15:57:18 GMT Subject: RFR: 8319265: TestLoadLibraryDeadlock.java fails on windows-x64 "Unable to load b.jar" [v2] In-Reply-To: References: Message-ID: On Thu, 2 Nov 2023 06:38:18 GMT, Jaikiran Pai wrote: >> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: >> >> review feedback > > test/jdk/java/lang/ClassLoader/loadLibraryDeadlock/TestLoadLibraryDeadlock.java line 185: > >> 183: >> 184: private static String toLocationString(Path path) { >> 185: return path.toUri().getPath(); > > Hello Mandy, this looks OK to me. Because the `LoadLibraryDeadlock.getLocation()` uses `URL.getPath()` to print the message in the logs, maybe for consistency and to rule out any unexpected differences, perhaps use `path.toUri().toURL().getPath()` instead? Ok. Updated to use consistent format. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16466#discussion_r1380370877 From mchung at openjdk.org Thu Nov 2 15:57:15 2023 From: mchung at openjdk.org (Mandy Chung) Date: Thu, 2 Nov 2023 15:57:15 GMT Subject: RFR: 8319265: TestLoadLibraryDeadlock.java fails on windows-x64 "Unable to load b.jar" [v2] In-Reply-To: References: Message-ID: <3vBpv_9I28dTCTEBZECu9q8HfvWAcGIz5LUPL8-eJi0=.a5d9db4d-b51a-4217-b6ac-56e2253aed21@github.com> > The test fails on windows because unmatched comparison of `Path.toString()` vs `URL.getPath().toString()` after JDK-8317965. A simple fix is to evaluate the JAR file path in the same way as `LoadLibraryDeadlock` does. 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/16466/files - new: https://git.openjdk.org/jdk/pull/16466/files/e82c38d7..a29e15b3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16466&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16466&range=00-01 Stats: 8 lines in 2 files changed: 7 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/16466.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16466/head:pull/16466 PR: https://git.openjdk.org/jdk/pull/16466 From rriggs at openjdk.org Thu Nov 2 16:02:05 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 2 Nov 2023 16:02:05 GMT Subject: RFR: 8319265: TestLoadLibraryDeadlock.java fails on windows-x64 "Unable to load b.jar" [v2] In-Reply-To: <3vBpv_9I28dTCTEBZECu9q8HfvWAcGIz5LUPL8-eJi0=.a5d9db4d-b51a-4217-b6ac-56e2253aed21@github.com> References: <3vBpv_9I28dTCTEBZECu9q8HfvWAcGIz5LUPL8-eJi0=.a5d9db4d-b51a-4217-b6ac-56e2253aed21@github.com> Message-ID: <9eF-i9-c2jsRINH9uIPG0ZiAN9QK6RuTgt-3Bd3eaos=.7c6a0496-cd73-40e4-8904-cc17516bb15b@github.com> On Thu, 2 Nov 2023 15:57:15 GMT, Mandy Chung wrote: >> The test fails on windows because unmatched comparison of `Path.toString()` vs `URL.getPath().toString()` after JDK-8317965. A simple fix is to evaluate the JAR file path in the same way as `LoadLibraryDeadlock` does. > > Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: > > review feedback Marked as reviewed by rriggs (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/16466#pullrequestreview-1710672266 From ccheung at openjdk.org Thu Nov 2 16:06:22 2023 From: ccheung at openjdk.org (Calvin Cheung) Date: Thu, 2 Nov 2023 16:06:22 GMT Subject: RFR: 8316969: Improve CDS module graph support for --module option [v8] In-Reply-To: References: <48Cg1jcgwdrXwlEB4uFoxVyB6Adug9kL2zTNhtzuMp8=.e6f7d190-3b66-4e7e-8c52-9e67dfdd0f6d@github.com> Message-ID: On Wed, 1 Nov 2023 11:26:48 GMT, Alan Bateman wrote: >> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: >> >> more comments from Alan and Ioi; copyright year update > > Marked as reviewed by alanb (Reviewer). Thanks @AlanBateman, @iklam for the reviews. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16016#issuecomment-1791020669 From ccheung at openjdk.org Thu Nov 2 16:06:23 2023 From: ccheung at openjdk.org (Calvin Cheung) Date: Thu, 2 Nov 2023 16:06:23 GMT Subject: Integrated: 8316969: Improve CDS module graph support for --module option In-Reply-To: References: Message-ID: On Mon, 2 Oct 2023 22:17:34 GMT, Calvin Cheung wrote: > Please review this changeset for adding support for `--module` (-m) option for CDS. > Changes in the `ModuleBootstrap.java` are needed so that the `ArchivedModuleGraph.archive` and `ArchivedBootLayer.archive` are called if the main module is specified. The module name will be stored in the ro region of the CDS archive. During runtime, the archived module name will be compared with the runtime module name. If comparison fails, the archived full module graph won't be used. > > Note: this RFE is a subtask of [JDK-8266329](https://bugs.openjdk.org/browse/JDK-8266329). More subtask(s) will be created to support other options such as `--add-modules`. > > Passed tiers 1 - 4 testing. This pull request has now been integrated. Changeset: e318cd25 Author: Calvin Cheung URL: https://git.openjdk.org/jdk/commit/e318cd25cbb9619c5add0d00b2f192c3a7b3e4c4 Stats: 302 lines in 13 files changed: 281 ins; 6 del; 15 mod 8316969: Improve CDS module graph support for --module option Reviewed-by: iklam, alanb ------------- PR: https://git.openjdk.org/jdk/pull/16016 From msheppar at openjdk.org Thu Nov 2 16:16:06 2023 From: msheppar at openjdk.org (Mark Sheppard) Date: Thu, 2 Nov 2023 16:16:06 GMT Subject: RFR: 8319265: TestLoadLibraryDeadlock.java fails on windows-x64 "Unable to load b.jar" [v2] In-Reply-To: <3vBpv_9I28dTCTEBZECu9q8HfvWAcGIz5LUPL8-eJi0=.a5d9db4d-b51a-4217-b6ac-56e2253aed21@github.com> References: <3vBpv_9I28dTCTEBZECu9q8HfvWAcGIz5LUPL8-eJi0=.a5d9db4d-b51a-4217-b6ac-56e2253aed21@github.com> Message-ID: On Thu, 2 Nov 2023 15:57:15 GMT, Mandy Chung wrote: >> The test fails on windows because unmatched comparison of `Path.toString()` vs `URL.getPath().toString()` after JDK-8317965. A simple fix is to evaluate the JAR file path in the same way as `LoadLibraryDeadlock` does. > > Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: > > review feedback TestLoadLibraryDeadlock.java: at line 144 after the creation of the jar files via method createJar, it would seem prudent to test that they actually exist at the expected location prior to executing the actual load tests, rather than purely relying createJar not throwing a RuntimeException ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/16466#issuecomment-1791043721 From jlaskey at openjdk.org Thu Nov 2 16:19:07 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Thu, 2 Nov 2023 16:19:07 GMT Subject: RFR: JDK-8315458 Implementation of Implicitly Declared Classes and Instance Main Method (Second Preview) [v7] In-Reply-To: References: Message-ID: > Address changes from JEP 445 to JEP 463. > > - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. > > - Don't mark class on read. > > - Remove reflection and annotation processing related to unnamed classes. > > - Simplify main method search. Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: Revised implicit class test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16461/files - new: https://git.openjdk.org/jdk/pull/16461/files/edbe208b..7c92e852 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16461&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16461&range=05-06 Stats: 93 lines in 2 files changed: 91 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/16461.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16461/head:pull/16461 PR: https://git.openjdk.org/jdk/pull/16461 From jpai at openjdk.org Thu Nov 2 16:28:09 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 2 Nov 2023 16:28:09 GMT Subject: RFR: 8319265: TestLoadLibraryDeadlock.java fails on windows-x64 "Unable to load b.jar" [v2] In-Reply-To: <3vBpv_9I28dTCTEBZECu9q8HfvWAcGIz5LUPL8-eJi0=.a5d9db4d-b51a-4217-b6ac-56e2253aed21@github.com> References: <3vBpv_9I28dTCTEBZECu9q8HfvWAcGIz5LUPL8-eJi0=.a5d9db4d-b51a-4217-b6ac-56e2253aed21@github.com> Message-ID: On Thu, 2 Nov 2023 15:57:15 GMT, Mandy Chung wrote: >> The test fails on windows because unmatched comparison of `Path.toString()` vs `URL.getPath().toString()` after JDK-8317965. A simple fix is to evaluate the JAR file path in the same way as `LoadLibraryDeadlock` does. > > Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: > > review feedback Marked as reviewed by jpai (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/16466#pullrequestreview-1710744416 From mchung at openjdk.org Thu Nov 2 16:28:09 2023 From: mchung at openjdk.org (Mandy Chung) Date: Thu, 2 Nov 2023 16:28:09 GMT Subject: RFR: 8319265: TestLoadLibraryDeadlock.java fails on windows-x64 "Unable to load b.jar" [v2] In-Reply-To: <3vBpv_9I28dTCTEBZECu9q8HfvWAcGIz5LUPL8-eJi0=.a5d9db4d-b51a-4217-b6ac-56e2253aed21@github.com> References: <3vBpv_9I28dTCTEBZECu9q8HfvWAcGIz5LUPL8-eJi0=.a5d9db4d-b51a-4217-b6ac-56e2253aed21@github.com> Message-ID: On Thu, 2 Nov 2023 15:57:15 GMT, Mandy Chung wrote: >> The test fails on windows because unmatched comparison of `Path.toString()` vs `URL.getPath().toString()` after JDK-8317965. A simple fix is to evaluate the JAR file path in the same way as `LoadLibraryDeadlock` does. > > Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: > > review feedback If any JAR file is not created, `LoadLibraryDeadlock` will fail as the class is not found. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16466#issuecomment-1791060998 From mchung at openjdk.org Thu Nov 2 16:41:22 2023 From: mchung at openjdk.org (Mandy Chung) Date: Thu, 2 Nov 2023 16:41:22 GMT Subject: Integrated: 8319265: TestLoadLibraryDeadlock.java fails on windows-x64 "Unable to load b.jar" In-Reply-To: References: Message-ID: On Thu, 2 Nov 2023 01:00:38 GMT, Mandy Chung wrote: > The test fails on windows because unmatched comparison of `Path.toString()` vs `URL.getPath().toString()` after JDK-8317965. A simple fix is to evaluate the JAR file path in the same way as `LoadLibraryDeadlock` does. This pull request has now been integrated. Changeset: 6ad093ef Author: Mandy Chung URL: https://git.openjdk.org/jdk/commit/6ad093ef12ccb2ee2c3da93f43dc1780f4bcf1c8 Stats: 16 lines in 2 files changed: 11 ins; 0 del; 5 mod 8319265: TestLoadLibraryDeadlock.java fails on windows-x64 "Unable to load b.jar" Reviewed-by: jpai, rriggs ------------- PR: https://git.openjdk.org/jdk/pull/16466 From naoto at openjdk.org Thu Nov 2 16:46:04 2023 From: naoto at openjdk.org (Naoto Sato) Date: Thu, 2 Nov 2023 16:46:04 GMT Subject: RFR: 8318466: Improve spec of NumberFormat's methods with unsupported operations In-Reply-To: References: Message-ID: On Wed, 1 Nov 2023 21:27:57 GMT, Justin Lu wrote: > Please review this simple change which refines the specification of some NumberFormat methods (with unsupported operations) to separate the API and implementation specification. LGTM ------------- Marked as reviewed by naoto (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16464#pullrequestreview-1710785970 From iris at openjdk.org Thu Nov 2 17:14:02 2023 From: iris at openjdk.org (Iris Clark) Date: Thu, 2 Nov 2023 17:14:02 GMT Subject: RFR: 8318466: Improve spec of NumberFormat's methods with unsupported operations In-Reply-To: References: Message-ID: <3ZrP-Qi2CcTiQYmZps5GlU8yJf-98rr5Qfefd_gvnI8=.9b34fbd4-db01-4089-83db-f130682a0aa1@github.com> On Wed, 1 Nov 2023 21:27:57 GMT, Justin Lu wrote: > Please review this simple change which refines the specification of some NumberFormat methods (with unsupported operations) to separate the API and implementation specification. Marked as reviewed by iris (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/16464#pullrequestreview-1710843738 From jlahoda at openjdk.org Thu Nov 2 17:36:17 2023 From: jlahoda at openjdk.org (Jan Lahoda) Date: Thu, 2 Nov 2023 17:36:17 GMT Subject: RFR: JDK-8315458 Implementation of Implicitly Declared Classes and Instance Main Method (Second Preview) [v7] In-Reply-To: References: Message-ID: <1CHjbxrpJ3EB9o-WNQwtl-XqCAWbPd1LIuYmo_0cWUs=.d1218d12-877e-402a-b21e-39ff681ea0ca@github.com> On Thu, 2 Nov 2023 16:19:07 GMT, Jim Laskey wrote: >> Address changes from JEP 445 to JEP 463. >> >> - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. >> >> - Don't mark class on read. >> >> - Remove reflection and annotation processing related to unnamed classes. >> >> - Simplify main method search. > > Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: > > Revised implicit class test Added a few minor comments inline. src/java.base/share/classes/jdk/internal/misc/MainMethodFinder.java line 33: > 31: public class MainMethodFinder { > 32: /** > 33: * {@return true if method mets the requirements of a main method} Nit/typo Suggestion: * {@return true if the method meets the requirements of a main method} test/jdk/java/lang/Class/ImplicitClass/TestImplicitClass.java line 25: > 23: > 24: /* > 25: * @test As a mild preference, I would move this test into the javac/langtools tests. I don't think it tests the reflection anymore, it rather tests that javac desugars the code correctly. ------------- PR Review: https://git.openjdk.org/jdk/pull/16461#pullrequestreview-1710864094 PR Review Comment: https://git.openjdk.org/jdk/pull/16461#discussion_r1380519226 PR Review Comment: https://git.openjdk.org/jdk/pull/16461#discussion_r1380544805 From jlahoda at openjdk.org Thu Nov 2 17:36:19 2023 From: jlahoda at openjdk.org (Jan Lahoda) Date: Thu, 2 Nov 2023 17:36:19 GMT Subject: RFR: JDK-8315458 Implementation of Implicitly Declared Classes and Instance Main Method (Second Preview) [v4] In-Reply-To: References: Message-ID: On Thu, 2 Nov 2023 14:52:46 GMT, Jim Laskey wrote: >> src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java line 76: >> >>> 74: UNNAMED_CLASSES, >>> 75: @JEP(number=999, title="Implicit Classes and Instance Main Methods") >>> 76: IMPLICIT_CLASSES, >> >> I assume you'll change this to 463 before integrating. Can 445 be removed or is there an issue with the symbol database that means it has to stay for a release? > > Missed that. The issue is that Implicit Classes don't have any API and don't show up in the preview page. Fixed. Regarding removal of `UNNAMED_CLASSES` here, there was an API annotated using this constant in `j.l.Class` (`isUnnamedClass()`). I suspect it unfortunately means we need to keep the enum constant as long as this method exists in the bootstrap JDK, i.e. until the bootstrap is switches to JDK 22. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16461#discussion_r1380557036 From jlahoda at openjdk.org Thu Nov 2 17:36:22 2023 From: jlahoda at openjdk.org (Jan Lahoda) Date: Thu, 2 Nov 2023 17:36:22 GMT Subject: RFR: JDK-8315458 Implementation of Implicitly Declared Classes and Instance Main Method (Second Preview) [v2] In-Reply-To: References: Message-ID: <3pl66yHVt5I61JBf_1hKObxaK7Tiutw6S5a6MFhiSqY=.7b4b525c-19a0-4a46-8ecb-d26a27c6427f@github.com> On Thu, 2 Nov 2023 11:55:50 GMT, Jim Laskey wrote: >> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Source.java line 249: >> >>> 247: STRING_TEMPLATES(JDK21, Fragments.FeatureStringTemplates, DiagKind.PLURAL), >>> 248: UNNAMED_CLASSES(JDK21, Fragments.FeatureUnnamedClasses, DiagKind.PLURAL), >>> 249: IMPLICIT_CLASSES(JDK21, Fragments.FeatureImplicitClasses, DiagKind.PLURAL), >> >> Should this be JDK22? > > No. It should be left at the first preview level. `UNNAMED_CLASSES` should probably be removed, as I think it is fully replaced with `IMPLICIT_CLASSES`, and I don't think there are bootstrap problems here (unlike in `jdk.internal.java.PreviewFeature`). I would say it would make sense to set the version to `JDK22`, although the difference is very small given the feature is a preview and requires `-source 22` anyway. (Although we keep the `@since` value for the duration of preview.) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16461#discussion_r1380529383 From jlaskey at openjdk.org Thu Nov 2 17:49:12 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Thu, 2 Nov 2023 17:49:12 GMT Subject: RFR: JDK-8315458 Implementation of Implicitly Declared Classes and Instance Main Method (Second Preview) [v4] In-Reply-To: References: Message-ID: <0Rm3u8y7eDy1QVUSco7BRq9HAT_P9ZusKALEKCiWFLg=.a3400dc4-88d1-43eb-86a8-92447ae127c0@github.com> On Thu, 2 Nov 2023 17:30:40 GMT, Jan Lahoda wrote: >> Missed that. The issue is that Implicit Classes don't have any API and don't show up in the preview page. Fixed. > > Regarding removal of `UNNAMED_CLASSES` here, there was an API annotated using this constant in `j.l.Class` (`isUnnamedClass()`). I suspect it unfortunately means we need to keep the enum constant as long as this method exists in the bootstrap JDK, i.e. until the bootstrap is switches to JDK 22. Correct ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16461#discussion_r1380578763 From jlaskey at openjdk.org Thu Nov 2 17:49:15 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Thu, 2 Nov 2023 17:49:15 GMT Subject: RFR: JDK-8315458 Implementation of Implicitly Declared Classes and Instance Main Method (Second Preview) [v7] In-Reply-To: <1CHjbxrpJ3EB9o-WNQwtl-XqCAWbPd1LIuYmo_0cWUs=.d1218d12-877e-402a-b21e-39ff681ea0ca@github.com> References: <1CHjbxrpJ3EB9o-WNQwtl-XqCAWbPd1LIuYmo_0cWUs=.d1218d12-877e-402a-b21e-39ff681ea0ca@github.com> Message-ID: On Thu, 2 Nov 2023 17:17:42 GMT, Jan Lahoda wrote: >> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: >> >> Revised implicit class test > > src/java.base/share/classes/jdk/internal/misc/MainMethodFinder.java line 33: > >> 31: public class MainMethodFinder { >> 32: /** >> 33: * {@return true if method mets the requirements of a main method} > > Nit/typo > Suggestion: > > * {@return true if the method meets the requirements of a main method} Changing ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16461#discussion_r1380575947 From alanb at openjdk.org Thu Nov 2 17:49:16 2023 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 2 Nov 2023 17:49:16 GMT Subject: RFR: JDK-8315458 Implementation of Implicitly Declared Classes and Instance Main Method (Second Preview) [v7] In-Reply-To: <0S6Mt7XNQICFBpJinq1WP0aDRcEVD_E1i0w1d0e_zb0=.4c996a92-09e9-4c30-b0fa-93281add3231@github.com> References: <9tVB9AKXsJb5Nx7UdwoqtyDs3WIfdJDU40E1jR-Au2k=.a341dbca-ab73-4f06-a50c-bf259711fdb3@github.com> <0S6Mt7XNQICFBpJinq1WP0aDRcEVD_E1i0w1d0e_zb0=.4c996a92-09e9-4c30-b0fa-93281add3231@github.com> Message-ID: On Thu, 2 Nov 2023 15:45:03 GMT, Jim Laskey wrote: > Amazingly enough I seem to have the JNI straight on the first try. Oh, I wasn't expecting that. My comment was suggesting we change LauncherHelper.checkAndLoadMain to set both appClass and mainType after the validate succeeds. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16461#discussion_r1380577942 From jlaskey at openjdk.org Thu Nov 2 17:49:18 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Thu, 2 Nov 2023 17:49:18 GMT Subject: RFR: JDK-8315458 Implementation of Implicitly Declared Classes and Instance Main Method (Second Preview) [v2] In-Reply-To: <3pl66yHVt5I61JBf_1hKObxaK7Tiutw6S5a6MFhiSqY=.7b4b525c-19a0-4a46-8ecb-d26a27c6427f@github.com> References: <3pl66yHVt5I61JBf_1hKObxaK7Tiutw6S5a6MFhiSqY=.7b4b525c-19a0-4a46-8ecb-d26a27c6427f@github.com> Message-ID: On Thu, 2 Nov 2023 17:21:02 GMT, Jan Lahoda wrote: >> No. It should be left at the first preview level. > > `UNNAMED_CLASSES` should probably be removed, as I think it is fully replaced with `IMPLICIT_CLASSES`, and I don't think there are bootstrap problems here (unlike in `jdk.internal.java.PreviewFeature`). I would say it would make sense to set the version to `JDK22`, although the difference is very small given the feature is a preview and requires `-source 22` anyway. (Although we keep the `@since` value for the duration of preview.) Changing ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16461#discussion_r1380574753 From jlaskey at openjdk.org Thu Nov 2 17:53:32 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Thu, 2 Nov 2023 17:53:32 GMT Subject: RFR: JDK-8315458 Implementation of Implicitly Declared Classes and Instance Main Method (Second Preview) [v8] In-Reply-To: References: Message-ID: <4n7npXZsDTQF4dswNSRYXN49xfkFOkAIhF6TXtojb9g=.18c6dd36-5905-4caa-adc5-c058dcff6182@github.com> > Address changes from JEP 445 to JEP 463. > > - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. > > - Don't mark class on read. > > - Remove reflection and annotation processing related to unnamed classes. > > - Simplify main method search. Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: Changes recommended by Jan ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16461/files - new: https://git.openjdk.org/jdk/pull/16461/files/7c92e852..afdd078f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16461&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16461&range=06-07 Stats: 4 lines in 4 files changed: 0 ins; 3 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/16461.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16461/head:pull/16461 PR: https://git.openjdk.org/jdk/pull/16461 From jlaskey at openjdk.org Thu Nov 2 17:56:13 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Thu, 2 Nov 2023 17:56:13 GMT Subject: RFR: JDK-8315458 Implementation of Implicitly Declared Classes and Instance Main Method (Second Preview) [v8] In-Reply-To: References: <9tVB9AKXsJb5Nx7UdwoqtyDs3WIfdJDU40E1jR-Au2k=.a341dbca-ab73-4f06-a50c-bf259711fdb3@github.com> <0S6Mt7XNQICFBpJinq1WP0aDRcEVD_E1i0w1d0e_zb0=.4c996a92-09e9-4c30-b0fa-93281add3231@github.com> Message-ID: On Thu, 2 Nov 2023 17:45:51 GMT, Alan Bateman wrote: >> Amazingly enough I seem to have the JNI straight on the first try. > >> Amazingly enough I seem to have the JNI straight on the first try. > > Oh, I wasn't expecting that. My comment was suggesting we change LauncherHelper.checkAndLoadMain to set both appClass and mainType after the validate succeeds. I thought it was a clearer way to get rid of the side effect. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16461#discussion_r1380585433 From jlaskey at openjdk.org Thu Nov 2 17:59:14 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Thu, 2 Nov 2023 17:59:14 GMT Subject: RFR: JDK-8315458 Implementation of Implicitly Declared Classes and Instance Main Method (Second Preview) [v7] In-Reply-To: <1CHjbxrpJ3EB9o-WNQwtl-XqCAWbPd1LIuYmo_0cWUs=.d1218d12-877e-402a-b21e-39ff681ea0ca@github.com> References: <1CHjbxrpJ3EB9o-WNQwtl-XqCAWbPd1LIuYmo_0cWUs=.d1218d12-877e-402a-b21e-39ff681ea0ca@github.com> Message-ID: On Thu, 2 Nov 2023 17:26:19 GMT, Jan Lahoda wrote: >> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: >> >> Revised implicit class test > > test/jdk/java/lang/Class/ImplicitClass/TestImplicitClass.java line 25: > >> 23: >> 24: /* >> 25: * @test > > As a mild preference, I would move this test into the javac/langtools tests. I don't think it tests the reflection anymore, it rather tests that javac desugars the code correctly. Moving ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16461#discussion_r1380588699 From forax at openjdk.org Thu Nov 2 18:13:17 2023 From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax) Date: Thu, 2 Nov 2023 18:13:17 GMT Subject: RFR: JDK-8315458 Implementation of Implicitly Declared Classes and Instance Main Method (Second Preview) [v2] In-Reply-To: <82F0iwMjHokh7ezwshT0kdYKvZ37h_XG3L1m_fsfUPQ=.d5e5c36c-768d-4835-8470-d95007fb5435@github.com> References: <82F0iwMjHokh7ezwshT0kdYKvZ37h_XG3L1m_fsfUPQ=.d5e5c36c-768d-4835-8470-d95007fb5435@github.com> Message-ID: On Thu, 2 Nov 2023 12:24:31 GMT, Jim Laskey wrote: >> Uhmm. In the spec I see implicit classes named here: >> >> >> For reference, the following constructs are declared implicitly in source code, but are not marked as mandated because only formal parameters and modules can be so marked in a class file (JVMS ?4.7.24, JVMS ?4.7.25): >> ``` >> >> Note the `but are not marked as mandated`. >> >> I don't think javac sets the mandated flag for any of these. Note that ACC_MANDATED has the same value as the ACC_MODULE flag, so setting that flag on a class w/o at least filtering out when writing the classfile will be problematic. > > Hmmm. I'll check with Gavin, but I thought in discussions Alex said that it should be mandated. At any rate, seems the ACC_MANDATED should be removed for stated reasons. It should be MANDATED in theory given it's not an artifact of the compilation like SYNTHETIC is. Sadly, as Maurizio said ACC_MANDATED has the same value as ACC_MODULE. I think there is a value to still make it as SYNTHETIC, apart if we add a new specific attribute for implicit classes. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16461#discussion_r1380604311 From duke at openjdk.org Thu Nov 2 18:24:05 2023 From: duke at openjdk.org (Eirik Bjorsnos) Date: Thu, 2 Nov 2023 18:24:05 GMT Subject: RFR: 8303920: Avoid calling out to python in DataDescriptorSignatureMissing test [v9] In-Reply-To: References: Message-ID: <4CM5Kyw9VMUsblh1OuQJHwheuyhArBONizPWDsmg6N8=.19f7c9bc-d4bc-4c72-bf25-8b7ec24ce337@github.com> On Mon, 30 Oct 2023 19:54:12 GMT, Lance Andersen wrote: > Thinking some more about this, I would like to see us keep the Zip generated by python, store it in a byte array (or equivalent) as it also validate that we can still process the zip given this was the original test and the zip is being generated by a 3rd party tool. Lance, I was finally able to reproduce the original issue using Python 3.4.4. (Which was a challenge to install given its archaic dependencies!) I was able to verfy that the missing signature is the ONLY difference between the input and output files. (Except updated LOC and CEN offsets accounting for the missing bytes). Additionally, I independently removed the signature files from the input file, this produced an output file binary identical to Python's. Given that the one and only difference introduced by the Python script is covered by the test in this PR, I'm not sure I see any additional value in adding a test with the binary test vector produced by Python. I think it will just increase our maintenance costs, without adding any real value or coverage. If you see this differently, that's of course ok. Just let me know and I'll create the test with the encoded binary ZIP (which I have easily available now). Waiting for your guidance, thanks :-) ------------- PR Comment: https://git.openjdk.org/jdk/pull/12959#issuecomment-1791298079 From alanb at openjdk.org Thu Nov 2 18:34:13 2023 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 2 Nov 2023 18:34:13 GMT Subject: RFR: JDK-8315458 Implementation of Implicitly Declared Classes and Instance Main Method (Second Preview) [v8] In-Reply-To: References: <9tVB9AKXsJb5Nx7UdwoqtyDs3WIfdJDU40E1jR-Au2k=.a341dbca-ab73-4f06-a50c-bf259711fdb3@github.com> <0S6Mt7XNQICFBpJinq1WP0aDRcEVD_E1i0w1d0e_zb0=.4c996a92-09e9-4c30-b0fa-93281add3231@github.com> Message-ID: On Thu, 2 Nov 2023 17:53:12 GMT, Jim Laskey wrote: > I thought it was a clearer way to get rid of the side effect. It means LauncherHelper.checkAndLoadMain description will need to be updated as it says that it checks the public static void main method. But okay, I'll go through what you have now. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16461#discussion_r1380625507 From darcy at openjdk.org Thu Nov 2 19:02:15 2023 From: darcy at openjdk.org (Joe Darcy) Date: Thu, 2 Nov 2023 19:02:15 GMT Subject: Integrated: JDK-8319195: Move most tier 1 vector API regression tests to tier 3 In-Reply-To: References: Message-ID: On Tue, 31 Oct 2023 20:14:45 GMT, Joe Darcy wrote: > Due to their longer-than-typical running time and because the vector API is not (yet) in the base module, move the vector API tests in tier 1 to tier 2. This pull request has now been integrated. Changeset: 9dc40ba4 Author: Joe Darcy URL: https://git.openjdk.org/jdk/commit/9dc40ba48ec15d5775537c4c2224ee5bb563629a Stats: 20 lines in 1 file changed: 0 ins; 20 del; 0 mod 8319195: Move most tier 1 vector API regression tests to tier 3 Reviewed-by: kvn, jiefu ------------- PR: https://git.openjdk.org/jdk/pull/16437 From lancea at openjdk.org Thu Nov 2 19:49:04 2023 From: lancea at openjdk.org (Lance Andersen) Date: Thu, 2 Nov 2023 19:49:04 GMT Subject: RFR: 8303920: Avoid calling out to python in DataDescriptorSignatureMissing test [v9] In-Reply-To: <4CM5Kyw9VMUsblh1OuQJHwheuyhArBONizPWDsmg6N8=.19f7c9bc-d4bc-4c72-bf25-8b7ec24ce337@github.com> References: <4CM5Kyw9VMUsblh1OuQJHwheuyhArBONizPWDsmg6N8=.19f7c9bc-d4bc-4c72-bf25-8b7ec24ce337@github.com> Message-ID: On Thu, 2 Nov 2023 18:21:07 GMT, Eirik Bjorsnos wrote: > > Thinking some more about this, I would like to see us keep the Zip generated by python, store it in a byte array (or equivalent) as it also validate that we can still process the zip given this was the original test and the zip is being generated by a 3rd party tool. > > Lance, > > I was finally able to reproduce the original issue using Python 3.4.4. (Which was a challenge to install given its archaic dependencies!) > > I was able to verfy that the missing signature is the ONLY difference between the input and output files. (Except updated LOC and CEN offsets accounting for the missing bytes). Additionally, I independently removed the signature files from the input file, this produced an output file binary identical to Python's. > > Given that the one and only difference introduced by the Python script is covered by the test in this PR, I'm not sure I see any additional value in adding a test with the binary test vector produced by Python. I think it will just increase our maintenance costs, without adding any real value or coverage. > > If you see this differently, that's of course ok. Just let me know and I'll create the test with the encoded binary ZIP (which I have easily available now). > > Waiting for your guidance, thanks :-) If you verified that we are a complete match, I am good with that. Thank you for validating ------------- PR Comment: https://git.openjdk.org/jdk/pull/12959#issuecomment-1791444261 From jlaskey at openjdk.org Thu Nov 2 20:36:52 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Thu, 2 Nov 2023 20:36:52 GMT Subject: RFR: JDK-8315458 Implementation of Implicitly Declared Classes and Instance Main Method (Second Preview) [v9] In-Reply-To: References: Message-ID: <_-aKRLbUA-RNzGDfn4fFhRzB2A1jSUMeoRKIBZ3v5eE=.975a8dc0-951c-4664-b502-3ad2fe1992a8@github.com> > Address changes from JEP 445 to JEP 463. > > - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. > > - Don't mark class on read. > > - Remove reflection and annotation processing related to unnamed classes. > > - Simplify main method search. Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: Requested corrections ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16461/files - new: https://git.openjdk.org/jdk/pull/16461/files/afdd078f..742fed7d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16461&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16461&range=07-08 Stats: 4 lines in 3 files changed: 0 ins; 2 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/16461.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16461/head:pull/16461 PR: https://git.openjdk.org/jdk/pull/16461 From jlaskey at openjdk.org Thu Nov 2 20:48:45 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Thu, 2 Nov 2023 20:48:45 GMT Subject: RFR: JDK-8315458 Implementation of Implicitly Declared Classes and Instance Main Method (Second Preview) [v10] In-Reply-To: References: Message-ID: <81FKbm7lDo5GAxBrDd7bmXF13qRuF5J3BBQrQZKJ89Y=.f852a869-b3a1-4571-808a-4241246b95cf@github.com> > Address changes from JEP 445 to JEP 463. > > - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. > > - Don't mark class on read. > > - Remove reflection and annotation processing related to unnamed classes. > > - Simplify main method search. Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: Remove unnamed classes from examples.not-yet.txt ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16461/files - new: https://git.openjdk.org/jdk/pull/16461/files/742fed7d..72033bcc Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16461&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16461&range=08-09 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/16461.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16461/head:pull/16461 PR: https://git.openjdk.org/jdk/pull/16461 From rriggs at openjdk.org Thu Nov 2 22:25:05 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 2 Nov 2023 22:25:05 GMT Subject: RFR: 8319174: Enhance robustness of some j.m.BigInteger constructors [v3] In-Reply-To: References: <0iccBwbAhAmIPGxnz1bhry2Sj_Kz2xngZmb2lPFCUpU=.c2b7c8ef-4e77-4c8f-a7ec-7c5c0980e59e@github.com> Message-ID: <5cQfuCE-3mwLfGSanw9OTraCquw3Oh3x5BuUPkXZu50=.c484f3da-ac91-40c0-a097-7979febcdc39@github.com> On Thu, 2 Nov 2023 14:25:20 GMT, Raffaello Giulietti wrote: >> Enhance `java.math.BigInteger` constructors taking a `byte[]` argument by improving guarantees of internal invariants. > > Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: > > Restored ordering of exceptions. src/java.base/share/classes/java/math/BigInteger.java line 344: > 342: * @param len the number of bytes to use. > 343: * @throws NumberFormatException {@code val} is zero bytes long, > 344: * or {@code len} is zero. I would be concerned about the compatibility impact on existing applications. Though (very) uncommon, an existing application be using a non-zero length array and a len of zero to represent zero. With this change it will throw an unexpected exception. src/java.base/share/classes/java/math/BigInteger.java line 4707: > 4705: ++from; > 4706: /* Skip leading -1 bytes. */ > 4707: for (; b == -1 && from < to; b = a[from++]); //empty body The style for an empty body in this file seems to be a ";" on a line by itself. The comment make it explicit but visually it might stand out more on a separate line. (My preferred style is `{}` with enough visual space to make it stand out.) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16449#discussion_r1380843814 PR Review Comment: https://git.openjdk.org/jdk/pull/16449#discussion_r1380839094 From jvernee at openjdk.org Thu Nov 2 23:19:24 2023 From: jvernee at openjdk.org (Jorn Vernee) Date: Thu, 2 Nov 2023 23:19:24 GMT Subject: RFR: 8318586: Explicitly handle upcall stub allocation failure [v6] In-Reply-To: References: Message-ID: > Explicitly handle UpcallStub allocation failures by terminating. We currently might try to use the returned `nullptr` which would fail sooner or later. This patch just makes the termination explicit. Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: use alloc_fail_is_fatal = false on all platforms ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16311/files - new: https://git.openjdk.org/jdk/pull/16311/files/a75d072d..eee7aec5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16311&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16311&range=04-05 Stats: 20 lines in 4 files changed: 16 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/16311.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16311/head:pull/16311 PR: https://git.openjdk.org/jdk/pull/16311 From jvernee at openjdk.org Thu Nov 2 23:24:04 2023 From: jvernee at openjdk.org (Jorn Vernee) Date: Thu, 2 Nov 2023 23:24:04 GMT Subject: RFR: 8319323: FFM: Harmonize the @throws tags in the javadocs In-Reply-To: <85ItsgUDPivZOhZGk6goTf7kWw0mBj2CQ_5SG9dq8BE=.46ede8a1-f474-4ab9-b18e-4798a08138b9@github.com> References: <85ItsgUDPivZOhZGk6goTf7kWw0mBj2CQ_5SG9dq8BE=.46ede8a1-f474-4ab9-b18e-4798a08138b9@github.com> Message-ID: On Thu, 2 Nov 2023 14:46:49 GMT, Per Minborg wrote: > This PR proposes to harmonize the @throws tags in the javadocs for the FFM API. > > The @throws tags are using a bit different principles with respect to formatting and ending with a period or not. > > Looking at some prominent Java classes like `List` and `Stream`, they: > > 1) Indent such that multi-line texts align with the beginning of the Exception type > 2) Do not have a period after the text. > > Some of the tags in the FFM classes already conform to these bullets. This PR proposes to make them all do. Marked as reviewed by jvernee (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/16478#pullrequestreview-1711397692 From jvernee at openjdk.org Thu Nov 2 23:54:03 2023 From: jvernee at openjdk.org (Jorn Vernee) Date: Thu, 2 Nov 2023 23:54:03 GMT Subject: RFR: 8318586: Explicitly handle upcall stub allocation failure [v6] In-Reply-To: References: Message-ID: On Thu, 2 Nov 2023 23:19:24 GMT, Jorn Vernee wrote: >> Explicitly handle UpcallStub allocation failures by terminating. We currently might try to use the returned `nullptr` which would fail sooner or later. This patch just makes the termination explicit. > > Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: > > use alloc_fail_is_fatal = false on all platforms Okay, I have (finally) updated all the other platforms. Please take another look. Thanks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16311#issuecomment-1791715185 From sviswanathan at openjdk.org Fri Nov 3 00:28:07 2023 From: sviswanathan at openjdk.org (Sandhya Viswanathan) Date: Fri, 3 Nov 2023 00:28:07 GMT Subject: RFR: 8318650: Optimized subword gather for x86 targets. [v3] In-Reply-To: References: Message-ID: <0Y-DxdTBq9CTvVXyYLQ9KpwU5ms0QdGrwanGkfUfmpQ=.ad118e8d-551f-430d-9040-a10b1366924d@github.com> On Tue, 31 Oct 2023 07:19:55 GMT, Jatin Bhateja wrote: >> Hi All, >> >> This patch optimizes sub-word gather operation for x86 targets with AVX2 and AVX512 features. >> >> Following is the summary of changes:- >> >> 1) Intrinsify sub-word gather with high performance backend implementation based on hybrid algorithm which initially partially unrolls scalar loop to accumulates values from gather indices into a quadword(64bit) slice followed by vector permutation to place the slice into appropriate vector lanes, it prevents code bloating and generates compact >> JIT sequence. This coupled with savings from expansive array allocation in existing java implementation translates into significant performance of 1.3-5x gains with included micro. >> >> >> ![image](https://github.com/openjdk/jdk/assets/59989778/e25ba4ad-6a61-42fa-9566-452f741a9c6d) >> >> >> 2) Patch was also compared against modified java fallback implementation by replacing temporary array allocation with zero initialized vector and a scalar loops which inserts gathered values into vector. But, vector insert operation in higher vector lanes is a three step process which first extracts the upper vector 128 bit lane, updates it with gather subword value and then inserts the lane back to its original position. This makes inserts into higher order lanes costly w.r.t to proposed solution. In addition generated JIT code for modified fallback implementation was very bulky. This may impact in-lining decisions into caller contexts. >> >> 3) Some minor adjustments in existing gather instruction pattens for double/quad words. >> >> >> Kindly review and share your feedback. >> >> >> Best Regards, >> Jatin > > Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: > > Restricting masked sub-word gather to AVX512 target to align with integral gather support. @jatin-bhateja I have gone through part of the code. Please see my comments below. src/hotspot/share/opto/vectornode.hpp line 886: > 884: init_class_id(Class_LoadVectorGather); > 885: add_req(indices); > 886: assert(req() == MemNode::ValueIn + 1, "match_edge expects that index input is in MemNode::ValueIn"); The assert message in "" is questionable. For subword types match_edge expects last input in MemNode::ValueIn+1. I think the assert needs to move in if/else below with correct message. src/hotspot/share/opto/vectornode.hpp line 890: > 888: assert(is_subword_type(vect_type()->element_basic_type()), ""); > 889: add_req(offset); > 890: } It will be good if we retain the other assert on the else path for non subword: assert(indices->bottom_type()->is_vect(), "indices must be in vector"); src/hotspot/share/opto/vectornode.hpp line 999: > 997: add_req(indices); > 998: add_req(mask); > 999: assert(req() == MemNode::ValueIn + 2, "match_edge expects that last input is in MemNode::ValueIn+1"); The assert message in "" is questionable. For subword types match_edge expects last input in MemNode::ValueIn+2. src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ByteVector.java line 3818: > 3816: Class vectorType = vsp.vectorType(); > 3817: > 3818: int loopIncr = 0; loopIncr is not being used in the method below, could be removed. src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ByteVector.java line 3830: > 3828: // Check indices are within array bounds. > 3829: // FIXME: Check index under mask controlling. > 3830: for (int i = 0; i < vsp.length(); i += lsp.length()) { The check (i < vsp.length() ) could instead be (i + lsp.length() <= vsp.length()). src/jdk.incubator.vector/share/classes/jdk/incubator/vector/X-Vector.java.template line 3657: > 3655: } > 3656: #else[byteOrShort] > 3657: Extra blank line on else path could be removed. This will also reduce the number of files changed. ------------- PR Review: https://git.openjdk.org/jdk/pull/16354#pullrequestreview-1711404057 PR Review Comment: https://git.openjdk.org/jdk/pull/16354#discussion_r1380918410 PR Review Comment: https://git.openjdk.org/jdk/pull/16354#discussion_r1380912896 PR Review Comment: https://git.openjdk.org/jdk/pull/16354#discussion_r1380917754 PR Review Comment: https://git.openjdk.org/jdk/pull/16354#discussion_r1380901120 PR Review Comment: https://git.openjdk.org/jdk/pull/16354#discussion_r1380900894 PR Review Comment: https://git.openjdk.org/jdk/pull/16354#discussion_r1380886441 From mchung at openjdk.org Fri Nov 3 01:10:17 2023 From: mchung at openjdk.org (Mandy Chung) Date: Fri, 3 Nov 2023 01:10:17 GMT Subject: RFR: JDK-8315458 Implementation of Implicitly Declared Classes and Instance Main Method (Second Preview) [v10] In-Reply-To: <81FKbm7lDo5GAxBrDd7bmXF13qRuF5J3BBQrQZKJ89Y=.f852a869-b3a1-4571-808a-4241246b95cf@github.com> References: <81FKbm7lDo5GAxBrDd7bmXF13qRuF5J3BBQrQZKJ89Y=.f852a869-b3a1-4571-808a-4241246b95cf@github.com> Message-ID: On Thu, 2 Nov 2023 20:48:45 GMT, Jim Laskey wrote: >> Address changes from JEP 445 to JEP 463. >> >> - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. >> >> - Don't mark class on read. >> >> - Remove reflection and annotation processing related to unnamed classes. >> >> - Simplify main method search. > > Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: > > Remove unnamed classes from examples.not-yet.txt src/java.base/share/native/libjli/java.c line 539: > 537: "validateMainMethod", > 538: "(Ljava/lang/Class;)Ljava/lang/reflect/Method;"); > 539: CHECK_EXCEPTION_NULL_LEAVE(validateMainMethod); The comment in line 498-499 needs update as `LoadMainClass` no longer validates the main method. * Get the application's main class. It also checks if the main * method exists. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16461#discussion_r1380953736 From lmesnik at openjdk.org Fri Nov 3 03:44:31 2023 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Fri, 3 Nov 2023 03:44:31 GMT Subject: RFR: 8318839: Update test thread factory to catch all exceptions [v2] In-Reply-To: <19jJ-G8gCQEMp6p4bp_FQX82RQKBNbvCDSJbFt6EPkM=.a16102c1-afc7-46ec-8d0c-46db236c6510@github.com> References: <19jJ-G8gCQEMp6p4bp_FQX82RQKBNbvCDSJbFt6EPkM=.a16102c1-afc7-46ec-8d0c-46db236c6510@github.com> Message-ID: <9S4kuhxUayZ6r1SjV2F7fbJzclmYevQ-WysyHOcnq_4=.44149a06-c65b-42b5-9b2d-ad9ee430308a@github.com> > The jtreg starts the main thread in a separate ThreadGroup and checks unhandled exceptions for this group. However, it doesn't catch all unhandled exceptions. There is a jtreg issue for this https://bugs.openjdk.org/browse/CODETOOLS-7903526. > Catching such issues for virtual threads is important because they are not included in any groups. So this fix implements the handler for the test thread factory. > > A few tests start failing. > > The test > serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorVMEventsTest.java > has testcases for platform and virtual threads. So, there is there's no need to run it with the thread factory. > > The test > java/lang/Thread/virtual/ThreadAPI.java > tests UncaughtExceptionHandler and virtual threads. No need to run it with a thread factory. > > Test > test/jdk/java/util/concurrent/tck/ThreadTest.java is updated to not check the default empty handler. > > Probably, we need some common approach about dealing with the UncaughtExceptionHandler in jtreg. Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: Replaced System.exit() with exception. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16369/files - new: https://git.openjdk.org/jdk/pull/16369/files/8fbb2798..b0878f35 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16369&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16369&range=00-01 Stats: 48 lines in 1 file changed: 37 ins; 10 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/16369.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16369/head:pull/16369 PR: https://git.openjdk.org/jdk/pull/16369 From lmesnik at openjdk.org Fri Nov 3 03:49:04 2023 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Fri, 3 Nov 2023 03:49:04 GMT Subject: RFR: 8318839: Update test thread factory to catch all exceptions [v2] In-Reply-To: <9S4kuhxUayZ6r1SjV2F7fbJzclmYevQ-WysyHOcnq_4=.44149a06-c65b-42b5-9b2d-ad9ee430308a@github.com> References: <19jJ-G8gCQEMp6p4bp_FQX82RQKBNbvCDSJbFt6EPkM=.a16102c1-afc7-46ec-8d0c-46db236c6510@github.com> <9S4kuhxUayZ6r1SjV2F7fbJzclmYevQ-WysyHOcnq_4=.44149a06-c65b-42b5-9b2d-ad9ee430308a@github.com> Message-ID: On Fri, 3 Nov 2023 03:44:31 GMT, Leonid Mesnik wrote: >> The jtreg starts the main thread in a separate ThreadGroup and checks unhandled exceptions for this group. However, it doesn't catch all unhandled exceptions. There is a jtreg issue for this https://bugs.openjdk.org/browse/CODETOOLS-7903526. >> Catching such issues for virtual threads is important because they are not included in any groups. So this fix implements the handler for the test thread factory. >> >> A few tests start failing. >> >> The test >> serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorVMEventsTest.java >> has testcases for platform and virtual threads. So, there is there's no need to run it with the thread factory. >> >> The test >> java/lang/Thread/virtual/ThreadAPI.java >> tests UncaughtExceptionHandler and virtual threads. No need to run it with a thread factory. >> >> Test >> test/jdk/java/util/concurrent/tck/ThreadTest.java is updated to not check the default empty handler. >> >> Probably, we need some common approach about dealing with the UncaughtExceptionHandler in jtreg. > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > Replaced System.exit() with exception. I updated the test thread factory to check if there are unhandled exceptions after the test is completed. It now works similarly to what I plan to fix in jtreg. So the purpose of this fix is to catch all exceptions with factory enabled and also to "pre-test" jtreg fix in some cases. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16369#issuecomment-1791859353 From vromero at openjdk.org Fri Nov 3 05:19:14 2023 From: vromero at openjdk.org (Vicente Romero) Date: Fri, 3 Nov 2023 05:19:14 GMT Subject: RFR: JDK-8315458 Implementation of Implicitly Declared Classes and Instance Main Method (Second Preview) [v10] In-Reply-To: <81FKbm7lDo5GAxBrDd7bmXF13qRuF5J3BBQrQZKJ89Y=.f852a869-b3a1-4571-808a-4241246b95cf@github.com> References: <81FKbm7lDo5GAxBrDd7bmXF13qRuF5J3BBQrQZKJ89Y=.f852a869-b3a1-4571-808a-4241246b95cf@github.com> Message-ID: On Thu, 2 Nov 2023 20:48:45 GMT, Jim Laskey wrote: >> Address changes from JEP 445 to JEP 463. >> >> - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. >> >> - Don't mark class on read. >> >> - Remove reflection and annotation processing related to unnamed classes. >> >> - Simplify main method search. > > Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: > > Remove unnamed classes from examples.not-yet.txt src/java.base/share/native/libjli/java.c line 544: > 542: > 543: /* Build platform specific argument array */ > 544: mainArgs = CreateApplicationArgs(env, argv, argc); we build the arguments always even if the main we will end up invoking receives no argument and thus these arguments will be discarded. Could it make sense to create the arguments only if they won't be discarded? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16461#discussion_r1381163039 From dholmes at openjdk.org Fri Nov 3 05:47:04 2023 From: dholmes at openjdk.org (David Holmes) Date: Fri, 3 Nov 2023 05:47:04 GMT Subject: RFR: 8318839: Update test thread factory to catch all exceptions [v2] In-Reply-To: <9S4kuhxUayZ6r1SjV2F7fbJzclmYevQ-WysyHOcnq_4=.44149a06-c65b-42b5-9b2d-ad9ee430308a@github.com> References: <19jJ-G8gCQEMp6p4bp_FQX82RQKBNbvCDSJbFt6EPkM=.a16102c1-afc7-46ec-8d0c-46db236c6510@github.com> <9S4kuhxUayZ6r1SjV2F7fbJzclmYevQ-WysyHOcnq_4=.44149a06-c65b-42b5-9b2d-ad9ee430308a@github.com> Message-ID: On Fri, 3 Nov 2023 03:44:31 GMT, Leonid Mesnik wrote: >> The jtreg starts the main thread in a separate ThreadGroup and checks unhandled exceptions for this group. However, it doesn't catch all unhandled exceptions. There is a jtreg issue for this https://bugs.openjdk.org/browse/CODETOOLS-7903526. >> Catching such issues for virtual threads is important because they are not included in any groups. So this fix implements the handler for the test thread factory. >> >> A few tests start failing. >> >> The test >> serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorVMEventsTest.java >> has testcases for platform and virtual threads. So, there is there's no need to run it with the thread factory. >> >> The test >> java/lang/Thread/virtual/ThreadAPI.java >> tests UncaughtExceptionHandler and virtual threads. No need to run it with a thread factory. >> >> Test >> test/jdk/java/util/concurrent/tck/ThreadTest.java is updated to not check the default empty handler. >> >> Probably, we need some common approach about dealing with the UncaughtExceptionHandler in jtreg. > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > Replaced System.exit() with exception. Changes requested by dholmes (Reviewer). test/jtreg_test_thread_factory/src/share/classes/Virtual.java line 76: > 74: uncaughtException = null; > 75: Thread.setDefaultUncaughtExceptionHandler(null); > 76: } I don't understand what this is trying to do. If any virtual thread has an uncaught exception then other virtual threads will throw it wrapped in a RuntimeException. But the first virtual thread that completes (normally or by throwing) will clear the default UEH that you set, so uncaught exceptions from other virtual threads won't do anything. AFAICS setting the UEH for a virtual thread works fine, so why are you not setting a per-thread handler? ------------- PR Review: https://git.openjdk.org/jdk/pull/16369#pullrequestreview-1711859772 PR Review Comment: https://git.openjdk.org/jdk/pull/16369#discussion_r1381179648 From alanb at openjdk.org Fri Nov 3 07:14:05 2023 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 3 Nov 2023 07:14:05 GMT Subject: RFR: 8318839: Update test thread factory to catch all exceptions [v2] In-Reply-To: References: <19jJ-G8gCQEMp6p4bp_FQX82RQKBNbvCDSJbFt6EPkM=.a16102c1-afc7-46ec-8d0c-46db236c6510@github.com> <9S4kuhxUayZ6r1SjV2F7fbJzclmYevQ-WysyHOcnq_4=.44149a06-c65b-42b5-9b2d-ad9ee430308a@github.com> Message-ID: On Fri, 3 Nov 2023 05:43:38 GMT, David Holmes wrote: > I don't understand what this is trying to do. If any virtual thread has an uncaught exception then other virtual threads will throw it wrapped in a RuntimeException. But the first virtual thread that completes (normally or by throwing) will clear the default UEH that you set, so uncaught exceptions from other virtual threads won't do anything. > > AFAICS setting the UEH for a virtual thread works fine, so why are you not setting a per-thread handler? My reading is that it sets default UHE so it means that any thread (not just virtual threads) can potentially execute it. There will be tests that set a per thread UHE that doesn't delegate. There will also be platform threads in a jtreg ThreadGroup (a UHE) so the exceptions will be handled there (AFAIK, the jtreg TG/UGE does not delegate to the default UHE). I think the patch is confusing because uncaughtException may be set several times, last one wins. If virtual "main" completes without an exception then it looks at uncaughtException to see if an exception is recorded by another thread. It does wrap/propagate it as a runtime exception and I think the bit we aren't seeing is that this is handled by the real main on a platform thread in the jtreg TG. If the virtual "main" completes with an exception (meaning task throws), then it resets the default UHE and exits with an uncaught handle. As with the runtime exception case, I think we aren't seeing this being handled by real main. So I think it is working but confusing to read. I wonder if it might be better to just put the effort into helping CODETOOLS-7903526 instead of a workaround. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16369#discussion_r1381220891 From asotona at openjdk.org Fri Nov 3 08:21:15 2023 From: asotona at openjdk.org (Adam Sotona) Date: Fri, 3 Nov 2023 08:21:15 GMT Subject: RFR: 8304446: javap --system flag doesn't override system APIs [v2] In-Reply-To: References: Message-ID: > Javap ignores --system option when searching for JDK classes. > This patch prepends search over JDK system modules. > > Please review. > > Thanks, > Adam Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: Skip search over JDK modules for classes in unnamed package (mainly to skip JDK module-infos) ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16476/files - new: https://git.openjdk.org/jdk/pull/16476/files/3734262a..78dc9840 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16476&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16476&range=00-01 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/16476.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16476/head:pull/16476 PR: https://git.openjdk.org/jdk/pull/16476 From asotona at openjdk.org Fri Nov 3 08:39:37 2023 From: asotona at openjdk.org (Adam Sotona) Date: Fri, 3 Nov 2023 08:39:37 GMT Subject: RFR: 8308753: Class-File API transition to Preview [v24] In-Reply-To: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com> References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com> Message-ID: > Classfile API is an internal library under package `jdk.internal.classfile`?in JDK 21. > This pull request turns the Classfile API into a preview feature and moves it into `java.lang.classfile`. > It repackages all uses across JDK and tests and adds lots of missing Javadoc. > > This PR goes in sync with?[JDK-8308754](https://bugs.openjdk.org/browse/JDK-8308754): Class-File API (Preview) (CSR) > and?[JDK-8280389](https://bugs.openjdk.org/browse/JDK-8280389): Class-File API (Preview) (JEP). > > Online javadoc is available at:? > https://cr.openjdk.org/~asotona/JDK-8308753-preview/api/java.base/java/lang/classfile/package-summary.html > > In addition to the primary transition to preview, this pull request also includes: > - All?Classfile*?classes ranamed to?ClassFile*?(based on JEP discussion). > - A new preview feature, `CLASSFILE_API`, has been added. > - Buildsystem tool required a little patch to support annotated modules. > - All JDK modules using the Classfile API are newly participating in the preview. > - All tests that use the Classfile API now have preview enabled. > - A few Javac tests not allowing preview have been partially reverted; their conversion can be re-applied when the Classfile API leaves preview mode. > > Despite the number of affected files, this pull request is relatively straight-forward. The preview version of the Classfile API is based on the internal version of the library from the JDK master branch, and there are no API features added. > > Please review this pull request to help the Classfile API turn into a preview. > > Any comments are welcome. > > Thanks, > Adam Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 358 commits: - Merge branch 'master' into JDK-8308753-preview # Conflicts: # test/jdk/tools/lib/tests/JImageValidator.java - fixed jdk.jfr - Merge branch 'master' into JDK-8308753-preview # Conflicts: # src/java.base/share/classes/module-info.java - applied javadoc fix suggestions - fixed new benchmark - Merge branch 'master' into JDK-8308753-preview # Conflicts: # src/java.base/share/classes/jdk/internal/classfile/impl/AbstractPoolEntry.java - removed trailing space - Merge branch 'master' into JDK-8308753-preview # Conflicts: # src/java.base/share/classes/module-info.java - package info javadoc improvements - removed obsolete exports from BuildMicrobenchmark.gmk - ... and 348 more: https://git.openjdk.org/jdk/compare/ec79ab4b...5f4f47c4 ------------- Changes: https://git.openjdk.org/jdk/pull/15706/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15706&range=23 Stats: 32167 lines in 768 files changed: 14623 ins; 14055 del; 3489 mod Patch: https://git.openjdk.org/jdk/pull/15706.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15706/head:pull/15706 PR: https://git.openjdk.org/jdk/pull/15706 From rgiulietti at openjdk.org Fri Nov 3 09:04:04 2023 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Fri, 3 Nov 2023 09:04:04 GMT Subject: RFR: 8319174: Enhance robustness of some j.m.BigInteger constructors [v3] In-Reply-To: <5cQfuCE-3mwLfGSanw9OTraCquw3Oh3x5BuUPkXZu50=.c484f3da-ac91-40c0-a097-7979febcdc39@github.com> References: <0iccBwbAhAmIPGxnz1bhry2Sj_Kz2xngZmb2lPFCUpU=.c2b7c8ef-4e77-4c8f-a7ec-7c5c0980e59e@github.com> <5cQfuCE-3mwLfGSanw9OTraCquw3Oh3x5BuUPkXZu50=.c484f3da-ac91-40c0-a097-7979febcdc39@github.com> Message-ID: On Thu, 2 Nov 2023 22:21:15 GMT, Roger Riggs wrote: >> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: >> >> Restored ordering of exceptions. > > src/java.base/share/classes/java/math/BigInteger.java line 344: > >> 342: * @param len the number of bytes to use. >> 343: * @throws NumberFormatException {@code val} is zero bytes long, >> 344: * or {@code len} is zero. > > I would be concerned about the compatibility impact on existing applications. > Though (very) uncommon, an existing application be using a non-zero length array and a len of zero to represent zero. > With this change it will throw an unexpected exception. A zero `len` is meant to indicate an empty range, whether the `val` array is empty or not. So, from a logical perspective, both cases `val.length == 0` or `len == 0` should either both throw, or both should return `BigInteger` 0. I choose the former, but the latter is a consistent choice as well. What I find unpleasant is the current behavior: it throws on `val.length == 0` (even if `len == 0`), but curiously returns 0 when it is non-zero and `len == 0`. I find this rather inconsistent. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16449#discussion_r1381325977 From rgiulietti at openjdk.org Fri Nov 3 09:11:30 2023 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Fri, 3 Nov 2023 09:11:30 GMT Subject: RFR: 8319174: Enhance robustness of some j.m.BigInteger constructors [v4] In-Reply-To: <0iccBwbAhAmIPGxnz1bhry2Sj_Kz2xngZmb2lPFCUpU=.c2b7c8ef-4e77-4c8f-a7ec-7c5c0980e59e@github.com> References: <0iccBwbAhAmIPGxnz1bhry2Sj_Kz2xngZmb2lPFCUpU=.c2b7c8ef-4e77-4c8f-a7ec-7c5c0980e59e@github.com> Message-ID: > Enhance `java.math.BigInteger` constructors taking a `byte[]` argument by improving guarantees of internal invariants. Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: Better formatting for empty loop bodies. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16449/files - new: https://git.openjdk.org/jdk/pull/16449/files/33a6ed36..eafa99c1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16449&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16449&range=02-03 Stats: 8 lines in 1 file changed: 4 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/16449.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16449/head:pull/16449 PR: https://git.openjdk.org/jdk/pull/16449 From jlaskey at openjdk.org Fri Nov 3 12:08:09 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Fri, 3 Nov 2023 12:08:09 GMT Subject: RFR: JDK-8315458 Implementation of Implicitly Declared Classes and Instance Main Method (Second Preview) [v10] In-Reply-To: References: <81FKbm7lDo5GAxBrDd7bmXF13qRuF5J3BBQrQZKJ89Y=.f852a869-b3a1-4571-808a-4241246b95cf@github.com> Message-ID: On Fri, 3 Nov 2023 01:06:56 GMT, Mandy Chung wrote: >> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove unnamed classes from examples.not-yet.txt > > src/java.base/share/native/libjli/java.c line 539: > >> 537: "validateMainMethod", >> 538: "(Ljava/lang/Class;)Ljava/lang/reflect/Method;"); >> 539: CHECK_EXCEPTION_NULL_LEAVE(validateMainMethod); > > The comment in line 498-499 needs update as `LoadMainClass` no longer validates the main method. > > * Get the application's main class. It also checks if the main > * method exists. Changing ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16461#discussion_r1381578668 From jlaskey at openjdk.org Fri Nov 3 12:19:15 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Fri, 3 Nov 2023 12:19:15 GMT Subject: RFR: JDK-8315458 Implementation of Implicitly Declared Classes and Instance Main Method (Second Preview) [v10] In-Reply-To: References: <81FKbm7lDo5GAxBrDd7bmXF13qRuF5J3BBQrQZKJ89Y=.f852a869-b3a1-4571-808a-4241246b95cf@github.com> Message-ID: <6wiZx638zzfyr3EpxS-7-ImsqFmDHQbPqZTePp9K3bU=.7e1c8f9a-4017-4ac1-b2e6-dc083a6302c8@github.com> On Fri, 3 Nov 2023 05:01:19 GMT, Vicente Romero wrote: >> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove unnamed classes from examples.not-yet.txt > > src/java.base/share/native/libjli/java.c line 544: > >> 542: >> 543: /* Build platform specific argument array */ >> 544: mainArgs = CreateApplicationArgs(env, argv, argc); > > we build the arguments always even if the main we will end up invoking receives no argument and thus these arguments will be discarded. Could it make sense to create the arguments only if they won't be discarded? Sure. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16461#discussion_r1381587622 From jlaskey at openjdk.org Fri Nov 3 12:25:49 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Fri, 3 Nov 2023 12:25:49 GMT Subject: RFR: JDK-8315458 Implementation of Implicitly Declared Classes and Instance Main Method (Second Preview) [v11] In-Reply-To: References: Message-ID: <-lo9E6xyDntDpnkpd2rhy2hCJ-WD0cXkjWvA2tkjURE=.b9aa02f3-b032-49ed-937f-4b64bda693e2@github.com> > Address changes from JEP 445 to JEP 463. > > - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. > > - Don't mark class on read. > > - Remove reflection and annotation processing related to unnamed classes. > > - Simplify main method search. Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: Don't get args unless necessary ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16461/files - new: https://git.openjdk.org/jdk/pull/16461/files/72033bcc..4b3c03fe Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16461&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16461&range=09-10 Stats: 38 lines in 1 file changed: 22 ins; 12 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/16461.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16461/head:pull/16461 PR: https://git.openjdk.org/jdk/pull/16461 From mabbay at openjdk.org Fri Nov 3 12:27:15 2023 From: mabbay at openjdk.org (Mourad Abbay) Date: Fri, 3 Nov 2023 12:27:15 GMT Subject: RFR: 8294980: test/jdk/java/lang/invoke 15 test classes use experimental bytecode library Message-ID: <-JRa1cWErB4H5zW-TqhXXd1y3TchfIXPMinb-CJ4OUE=.96cb1861-cb27-4030-a8a0-f90df924f041@github.com> early experimental version of the bytecode library is bundled under: test/jdk/lib/testlibrary/bytecode following tests reference it: test/jdk/java/lang/invoke/common/test/java/lang/invoke/lib/InstructionHelper.java test/jdk/java/lang/invoke/condy/CondyWithGarbageTest.java test/jdk/java/lang/invoke/condy/CondyReturnPrimitiveTest.java test/jdk/java/lang/invoke/condy/CondyWrongType.java test/jdk/java/lang/invoke/condy/CondyNestedTest.java test/jdk/java/lang/invoke/condy/CondyStaticArgumentsTest.java test/jdk/java/lang/invoke/condy/BootstrapMethodJumboArgsTest.java test/jdk/java/lang/invoke/condy/ConstantBootstrapsTest.java test/jdk/java/lang/invoke/condy/CondyRepeatFailedResolution.java test/jdk/java/lang/invoke/condy/CondyBSMInvocation.java test/jdk/java/lang/invoke/condy/CondyTypeValidationTest.java test/jdk/java/lang/invoke/condy/CondyBSMValidationTest.java test/jdk/java/lang/invoke/condy/CondyNameValidationTest.java test/jdk/java/lang/invoke/condy/CondyBSMException.java test/jdk/java/lang/invoke/condy/CondyInterfaceWithOverpassMethods.java ------------- Commit messages: - Remove reference to old bytecode library. - Remove early experimental version of the bytecode library. - Convert CondyInterfaceWithOverpassMethods . - Convert CondyBSMException . - Convert CondyNameValidationTest . - Convert CondyBSMValidationTest . - Convert CondyTypeValidationTest . - Convert CondyBSMInvocation . - Convert CondyRepeatFailedResolution . - Convert ConstantBootstrapsTest . - ... and 7 more: https://git.openjdk.org/jdk/compare/2f311d59...0221e2b4 Changes: https://git.openjdk.org/jdk/pull/16268/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16268&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8294980 Stats: 7526 lines in 38 files changed: 362 ins; 6547 del; 617 mod Patch: https://git.openjdk.org/jdk/pull/16268.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16268/head:pull/16268 PR: https://git.openjdk.org/jdk/pull/16268 From liach at openjdk.org Fri Nov 3 12:27:16 2023 From: liach at openjdk.org (Chen Liang) Date: Fri, 3 Nov 2023 12:27:16 GMT Subject: RFR: 8294980: test/jdk/java/lang/invoke 15 test classes use experimental bytecode library In-Reply-To: <-JRa1cWErB4H5zW-TqhXXd1y3TchfIXPMinb-CJ4OUE=.96cb1861-cb27-4030-a8a0-f90df924f041@github.com> References: <-JRa1cWErB4H5zW-TqhXXd1y3TchfIXPMinb-CJ4OUE=.96cb1861-cb27-4030-a8a0-f90df924f041@github.com> Message-ID: <4nlCKLh6pbazTpYjBzDvzC8cClZvgOHDtQ9VNNDjkiI=.c86cff2c-f7d8-456b-8d1a-5844b1321841@github.com> On Thu, 19 Oct 2023 14:37:06 GMT, Mourad Abbay wrote: > early experimental version of the bytecode library is bundled under: > test/jdk/lib/testlibrary/bytecode > > following tests reference it: > test/jdk/java/lang/invoke/common/test/java/lang/invoke/lib/InstructionHelper.java > test/jdk/java/lang/invoke/condy/CondyWithGarbageTest.java > test/jdk/java/lang/invoke/condy/CondyReturnPrimitiveTest.java > test/jdk/java/lang/invoke/condy/CondyWrongType.java > test/jdk/java/lang/invoke/condy/CondyNestedTest.java > test/jdk/java/lang/invoke/condy/CondyStaticArgumentsTest.java > test/jdk/java/lang/invoke/condy/BootstrapMethodJumboArgsTest.java > test/jdk/java/lang/invoke/condy/ConstantBootstrapsTest.java > test/jdk/java/lang/invoke/condy/CondyRepeatFailedResolution.java > test/jdk/java/lang/invoke/condy/CondyBSMInvocation.java > test/jdk/java/lang/invoke/condy/CondyTypeValidationTest.java > test/jdk/java/lang/invoke/condy/CondyBSMValidationTest.java > test/jdk/java/lang/invoke/condy/CondyNameValidationTest.java > test/jdk/java/lang/invoke/condy/CondyBSMException.java > test/jdk/java/lang/invoke/condy/CondyInterfaceWithOverpassMethods.java test/jdk/java/lang/invoke/common/test/java/lang/invoke/lib/InstructionHelper.java line 71: > 69: for (int i = 0; i < type.parameterCount(); i++) { > 70: codeBuilder.loadInstruction(TypeKind.fromDescriptor( > 71: type.parameterType(i).descriptorString()), i); You can just use `TypeKind.from(type.parameterType(i))` test/jdk/java/lang/invoke/common/test/java/lang/invoke/lib/InstructionHelper.java line 76: > 74: MethodHandleDesc.ofMethod( > 75: DirectMethodHandleDesc.Kind.STATIC, > 76: ClassDesc.of(l.lookupClass().getCanonicalName()), Despite this being part of the original code, `getCanonicalName` is unreliable for bytecode engineering, for it cannot distinguish packages from nested/inner classes. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16268#discussion_r1368033145 PR Review Comment: https://git.openjdk.org/jdk/pull/16268#discussion_r1368033622 From mabbay at openjdk.org Fri Nov 3 12:27:17 2023 From: mabbay at openjdk.org (Mourad Abbay) Date: Fri, 3 Nov 2023 12:27:17 GMT Subject: RFR: 8294980: test/jdk/java/lang/invoke 15 test classes use experimental bytecode library In-Reply-To: <4nlCKLh6pbazTpYjBzDvzC8cClZvgOHDtQ9VNNDjkiI=.c86cff2c-f7d8-456b-8d1a-5844b1321841@github.com> References: <-JRa1cWErB4H5zW-TqhXXd1y3TchfIXPMinb-CJ4OUE=.96cb1861-cb27-4030-a8a0-f90df924f041@github.com> <4nlCKLh6pbazTpYjBzDvzC8cClZvgOHDtQ9VNNDjkiI=.c86cff2c-f7d8-456b-8d1a-5844b1321841@github.com> Message-ID: On Mon, 23 Oct 2023 01:15:54 GMT, Chen Liang wrote: >> early experimental version of the bytecode library is bundled under: >> test/jdk/lib/testlibrary/bytecode >> >> following tests reference it: >> test/jdk/java/lang/invoke/common/test/java/lang/invoke/lib/InstructionHelper.java >> test/jdk/java/lang/invoke/condy/CondyWithGarbageTest.java >> test/jdk/java/lang/invoke/condy/CondyReturnPrimitiveTest.java >> test/jdk/java/lang/invoke/condy/CondyWrongType.java >> test/jdk/java/lang/invoke/condy/CondyNestedTest.java >> test/jdk/java/lang/invoke/condy/CondyStaticArgumentsTest.java >> test/jdk/java/lang/invoke/condy/BootstrapMethodJumboArgsTest.java >> test/jdk/java/lang/invoke/condy/ConstantBootstrapsTest.java >> test/jdk/java/lang/invoke/condy/CondyRepeatFailedResolution.java >> test/jdk/java/lang/invoke/condy/CondyBSMInvocation.java >> test/jdk/java/lang/invoke/condy/CondyTypeValidationTest.java >> test/jdk/java/lang/invoke/condy/CondyBSMValidationTest.java >> test/jdk/java/lang/invoke/condy/CondyNameValidationTest.java >> test/jdk/java/lang/invoke/condy/CondyBSMException.java >> test/jdk/java/lang/invoke/condy/CondyInterfaceWithOverpassMethods.java > > test/jdk/java/lang/invoke/common/test/java/lang/invoke/lib/InstructionHelper.java line 71: > >> 69: for (int i = 0; i < type.parameterCount(); i++) { >> 70: codeBuilder.loadInstruction(TypeKind.fromDescriptor( >> 71: type.parameterType(i).descriptorString()), i); > > You can just use `TypeKind.from(type.parameterType(i))` I can't see such as method. > test/jdk/java/lang/invoke/common/test/java/lang/invoke/lib/InstructionHelper.java line 76: > >> 74: MethodHandleDesc.ofMethod( >> 75: DirectMethodHandleDesc.Kind.STATIC, >> 76: ClassDesc.of(l.lookupClass().getCanonicalName()), > > Despite this being part of the original code, `getCanonicalName` is unreliable for bytecode engineering, for it cannot distinguish packages from nested/inner classes. I will use ClassDesc.ofDescriptor and passes the descriptor string of the type. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16268#discussion_r1371686240 PR Review Comment: https://git.openjdk.org/jdk/pull/16268#discussion_r1371553152 From pminborg at openjdk.org Fri Nov 3 12:31:28 2023 From: pminborg at openjdk.org (Per Minborg) Date: Fri, 3 Nov 2023 12:31:28 GMT Subject: Integrated: 8319323: FFM: Harmonize the @throws tags in the javadocs In-Reply-To: <85ItsgUDPivZOhZGk6goTf7kWw0mBj2CQ_5SG9dq8BE=.46ede8a1-f474-4ab9-b18e-4798a08138b9@github.com> References: <85ItsgUDPivZOhZGk6goTf7kWw0mBj2CQ_5SG9dq8BE=.46ede8a1-f474-4ab9-b18e-4798a08138b9@github.com> Message-ID: On Thu, 2 Nov 2023 14:46:49 GMT, Per Minborg wrote: > This PR proposes to harmonize the @throws tags in the javadocs for the FFM API. > > The @throws tags are using a bit different principles with respect to formatting and ending with a period or not. > > Looking at some prominent Java classes like `List` and `Stream`, they: > > 1) Indent such that multi-line texts align with the beginning of the Exception type > 2) Do not have a period after the text. > > Some of the tags in the FFM classes already conform to these bullets. This PR proposes to make them all do. This pull request has now been integrated. Changeset: be01caf3 Author: Per Minborg URL: https://git.openjdk.org/jdk/commit/be01caf30de5a70684fab25b02f2c6ab346a60cb Stats: 455 lines in 10 files changed: 4 ins; 1 del; 450 mod 8319323: FFM: Harmonize the @throws tags in the javadocs Reviewed-by: jvernee ------------- PR: https://git.openjdk.org/jdk/pull/16478 From jlaskey at openjdk.org Fri Nov 3 12:31:32 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Fri, 3 Nov 2023 12:31:32 GMT Subject: RFR: JDK-8315458 Implementation of Implicitly Declared Classes and Instance Main Method (Second Preview) [v2] In-Reply-To: References: <82F0iwMjHokh7ezwshT0kdYKvZ37h_XG3L1m_fsfUPQ=.d5e5c36c-768d-4835-8470-d95007fb5435@github.com> Message-ID: On Thu, 2 Nov 2023 18:10:27 GMT, R?mi Forax wrote: >> Hmmm. I'll check with Gavin, but I thought in discussions Alex said that it should be mandated. At any rate, seems the ACC_MANDATED should be removed for stated reasons. > > It should be MANDATED in theory given it's not an artifact of the compilation like SYNTHETIC is. Sadly, as Maurizio said ACC_MANDATED has the same value as ACC_MODULE. > I think there is a value to still make it as SYNTHETIC, apart if we add a new specific attribute for implicit classes. We're opting to not to flag the class as special. Implicit classes are just regular classes derived from syntactic sugar. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16461#discussion_r1381606620 From jlahoda at openjdk.org Fri Nov 3 12:40:24 2023 From: jlahoda at openjdk.org (Jan Lahoda) Date: Fri, 3 Nov 2023 12:40:24 GMT Subject: RFR: 8319220: Pattern matching switch with a lot of cases is unduly slow Message-ID: Consider code like: void test(Object o) { switch (o) { case X1 -> {} case X2 -> {} ...(about 100 cases) ``` javac will compile the switch into a switch whose selector is an indy invocation to `SwitchBootstraps.typeSwitch`, with static arguments being the types in the cases. `SwitchBootstraps.typeSwitch` will then create a chain of `MethodHandle`s performing `instanceof` checks between the switch's selector and the given case type. The problem is that when the number of cases is high enough, (more than ~40-50), the chain gets too long, and the tests won't inline anymore. This then leads to a very bad performance, when compared to manually written if-instanceof-else-if-instanceof- chain. The proposal herein is to use bytecode (written using the ClassFile API/library) instead of the `MethodHandle`s chain. The overall performance of this seems to be similar to the manually written if-instanceof-else-if-instanceof- chain. Using the benchmark from the bug, and this patch, I am getting: MyBenchmark.testIfElse100 thrpt 5 521826.326 ? 7510.042 ops/s MyBenchmark.testSwitch100 thrpt 5 505440.170 ? 3757.178 ops/s The most tricky part of this new way to generate the tests is handling of non-type case labels, and in particular cases with enum constant labels. The resolution of enum constants is deferred as much as possible, by using an indirection through the `ResolvedEnumLabels`. Further improvements may be possible, esp. for some specific cases (like all cases having a type, and the type being a final class). ------------- Commit messages: - Avoiding generating dead code - review feedback. - Cleanup. - Attempting to speeding SwitchBootstraps. Changes: https://git.openjdk.org/jdk/pull/16489/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16489&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8319220 Stats: 302 lines in 2 files changed: 187 ins; 89 del; 26 mod Patch: https://git.openjdk.org/jdk/pull/16489.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16489/head:pull/16489 PR: https://git.openjdk.org/jdk/pull/16489 From asotona at openjdk.org Fri Nov 3 12:40:25 2023 From: asotona at openjdk.org (Adam Sotona) Date: Fri, 3 Nov 2023 12:40:25 GMT Subject: RFR: 8319220: Pattern matching switch with a lot of cases is unduly slow In-Reply-To: References: Message-ID: On Fri, 3 Nov 2023 08:41:12 GMT, Jan Lahoda wrote: > Consider code like: > > void test(Object o) { > switch (o) { > case X1 -> {} > case X2 -> {} > ...(about 100 cases) > ``` > > javac will compile the switch into a switch whose selector is an indy invocation to `SwitchBootstraps.typeSwitch`, with static arguments being the types in the cases. > > `SwitchBootstraps.typeSwitch` will then create a chain of `MethodHandle`s performing `instanceof` checks between the switch's selector and the given case type. The problem is that when the number of cases is high enough, (more than ~40-50), the chain gets too long, and the tests won't inline anymore. This then leads to a very bad performance, when compared to manually written if-instanceof-else-if-instanceof- chain. > > The proposal herein is to use bytecode (written using the ClassFile API/library) instead of the `MethodHandle`s chain. The overall performance of this seems to be similar to the manually written if-instanceof-else-if-instanceof- chain. > > Using the benchmark from the bug, and this patch, I am getting: > > MyBenchmark.testIfElse100 thrpt 5 521826.326 ? 7510.042 ops/s > MyBenchmark.testSwitch100 thrpt 5 505440.170 ? 3757.178 ops/s > > > The most tricky part of this new way to generate the tests is handling of non-type case labels, and in particular cases with enum constant labels. The resolution of enum constants is deferred as much as possible, by using an indirection through the `ResolvedEnumLabels`. > > Further improvements may be possible, esp. for some specific cases (like all cases having a type, and the type being a final class). Looks good. src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 393: > 391: cb.constantInstruction(0) > 392: .ireturn(); > 393: } Isn't this generating a dead code for labels.length == 0 ? src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 415: > 413: switchCases.add(SwitchCase.of(idx, target)); > 414: } > 415: cases = cases.reversed(); switchCases for tableswitch do not need to be pre-ordered, code builder does the processign ------------- Marked as reviewed by asotona (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16489#pullrequestreview-1712124690 PR Review Comment: https://git.openjdk.org/jdk/pull/16489#discussion_r1381314992 PR Review Comment: https://git.openjdk.org/jdk/pull/16489#discussion_r1381326838 From liach at openjdk.org Fri Nov 3 12:40:28 2023 From: liach at openjdk.org (Chen Liang) Date: Fri, 3 Nov 2023 12:40:28 GMT Subject: RFR: 8319220: Pattern matching switch with a lot of cases is unduly slow In-Reply-To: References: Message-ID: On Fri, 3 Nov 2023 08:41:12 GMT, Jan Lahoda wrote: > Consider code like: > > void test(Object o) { > switch (o) { > case X1 -> {} > case X2 -> {} > ...(about 100 cases) > ``` > > javac will compile the switch into a switch whose selector is an indy invocation to `SwitchBootstraps.typeSwitch`, with static arguments being the types in the cases. > > `SwitchBootstraps.typeSwitch` will then create a chain of `MethodHandle`s performing `instanceof` checks between the switch's selector and the given case type. The problem is that when the number of cases is high enough, (more than ~40-50), the chain gets too long, and the tests won't inline anymore. This then leads to a very bad performance, when compared to manually written if-instanceof-else-if-instanceof- chain. > > The proposal herein is to use bytecode (written using the ClassFile API/library) instead of the `MethodHandle`s chain. The overall performance of this seems to be similar to the manually written if-instanceof-else-if-instanceof- chain. > > Using the benchmark from the bug, and this patch, I am getting: > > MyBenchmark.testIfElse100 thrpt 5 521826.326 ? 7510.042 ops/s > MyBenchmark.testSwitch100 thrpt 5 505440.170 ? 3757.178 ops/s > > > The most tricky part of this new way to generate the tests is handling of non-type case labels, and in particular cases with enum constant labels. The resolution of enum constants is deferred as much as possible, by using an indirection through the `ResolvedEnumLabels`. > > Further improvements may be possible, esp. for some specific cases (like all cases having a type, and the type being a final class). src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 338: > 336: > 337: @Override > 338: public Object apply(Integer labelIndex, Object value) { Since we already know the EnumDesc (i.e. `result`), we can just convert this to a `BiPredicate` for simplicity. src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 346: > 344: Class clazz = label.constantType().resolveConstantDesc(lookup); > 345: > 346: if (value.getClass() != clazz) { Not related to this patch, but this appears to be wrong: we should do something like if (!(value instanceof Enum ev) || ev.getDeclaringClass() != clazz) return SENTINEL; // or false src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 383: > 381: .withMethod("typeSwitch", MethodTypeDesc.ofDescriptor("(Ljava/lang/Object;ILjava/util/function/BiFunction;)I"), Classfile.ACC_STATIC, mb -> { > 382: mb.withFlags(AccessFlag.PUBLIC, AccessFlag.FINAL, AccessFlag.STATIC) > 383: .withCode(cb -> { Can just use `clb.withMethodBody` and pass the access flags with `Classfile.ACC_PUBLIC | Classfile.ACC_STATIC | Classfile.ACC_FINAL` src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 432: > 430: cb.aload(2); > 431: cb.constantInstruction(enumIdx); > 432: cb.invokestatic(Integer.class.describeConstable().get(), You can use `ConstantDescs.CD_Integer` etc. src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 434: > 432: cb.invokestatic(Integer.class.describeConstable().get(), > 433: "valueOf", > 434: MethodType.methodType(Integer.class, I recommend `MethodTypeDesc.of()` instead. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16489#discussion_r1381409965 PR Review Comment: https://git.openjdk.org/jdk/pull/16489#discussion_r1381411165 PR Review Comment: https://git.openjdk.org/jdk/pull/16489#discussion_r1381384302 PR Review Comment: https://git.openjdk.org/jdk/pull/16489#discussion_r1381388594 PR Review Comment: https://git.openjdk.org/jdk/pull/16489#discussion_r1381391495 From jlahoda at openjdk.org Fri Nov 3 12:40:30 2023 From: jlahoda at openjdk.org (Jan Lahoda) Date: Fri, 3 Nov 2023 12:40:30 GMT Subject: RFR: 8319220: Pattern matching switch with a lot of cases is unduly slow In-Reply-To: References: Message-ID: On Fri, 3 Nov 2023 08:51:48 GMT, Adam Sotona wrote: >> Consider code like: >> >> void test(Object o) { >> switch (o) { >> case X1 -> {} >> case X2 -> {} >> ...(about 100 cases) >> ``` >> >> javac will compile the switch into a switch whose selector is an indy invocation to `SwitchBootstraps.typeSwitch`, with static arguments being the types in the cases. >> >> `SwitchBootstraps.typeSwitch` will then create a chain of `MethodHandle`s performing `instanceof` checks between the switch's selector and the given case type. The problem is that when the number of cases is high enough, (more than ~40-50), the chain gets too long, and the tests won't inline anymore. This then leads to a very bad performance, when compared to manually written if-instanceof-else-if-instanceof- chain. >> >> The proposal herein is to use bytecode (written using the ClassFile API/library) instead of the `MethodHandle`s chain. The overall performance of this seems to be similar to the manually written if-instanceof-else-if-instanceof- chain. >> >> Using the benchmark from the bug, and this patch, I am getting: >> >> MyBenchmark.testIfElse100 thrpt 5 521826.326 ? 7510.042 ops/s >> MyBenchmark.testSwitch100 thrpt 5 505440.170 ? 3757.178 ops/s >> >> >> The most tricky part of this new way to generate the tests is handling of non-type case labels, and in particular cases with enum constant labels. The resolution of enum constants is deferred as much as possible, by using an indirection through the `ResolvedEnumLabels`. >> >> Further improvements may be possible, esp. for some specific cases (like all cases having a type, and the type being a final class). > > src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 393: > >> 391: cb.constantInstruction(0) >> 392: .ireturn(); >> 393: } > > Isn't this generating a dead code for labels.length == 0 ? Right, it does (did). Fixed. Thanks! > src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 415: > >> 413: switchCases.add(SwitchCase.of(idx, target)); >> 414: } >> 415: cases = cases.reversed(); > > switchCases for tableswitch do not need to be pre-ordered, code builder does the processign I guess I would prefer to keep the reverse here, to reduce the cognitive load, as `cases` must be processed in original order (and hence reversed here), and it may not be clear why reverse one, and not the other. (Given the `List` is an `ArrayList`, the reverse operation should not have much impact on anything, if I read how it is implemented correctly.) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16489#discussion_r1381330275 PR Review Comment: https://git.openjdk.org/jdk/pull/16489#discussion_r1381393396 From jlaskey at openjdk.org Fri Nov 3 12:40:48 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Fri, 3 Nov 2023 12:40:48 GMT Subject: RFR: JDK-8315458 Implementation of Implicitly Declared Classes and Instance Main Method (Second Preview) [v12] In-Reply-To: References: Message-ID: > Address changes from JEP 445 to JEP 463. > > - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. > > - Don't mark class on read. > > - Remove reflection and annotation processing related to unnamed classes. > > - Simplify main method search. Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since the last revision: - Merge remote-tracking branch 'upstream/master' into 8315458 - Don't get args unless necessary - Remove unnamed classes from examples.not-yet.txt - Requested corrections - Changes recommended by Jan - Revised implicit class test - Don't store main method info globally. Use addition calls to fetch info. - Update JEP number in PreviewFeature - Remove MANDATED flag from implicit classes - Remove .orig files - ... and 2 more: https://git.openjdk.org/jdk/compare/f04a1529...0bd5b477 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16461/files - new: https://git.openjdk.org/jdk/pull/16461/files/4b3c03fe..0bd5b477 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16461&range=11 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16461&range=10-11 Stats: 23833 lines in 485 files changed: 11893 ins; 4870 del; 7070 mod Patch: https://git.openjdk.org/jdk/pull/16461.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16461/head:pull/16461 PR: https://git.openjdk.org/jdk/pull/16461 From jvernee at openjdk.org Fri Nov 3 13:18:14 2023 From: jvernee at openjdk.org (Jorn Vernee) Date: Fri, 3 Nov 2023 13:18:14 GMT Subject: RFR: 8319316: Clarify text around which layouts a linker supports Message-ID: <59YZ3CcJ5Sfx40UWGpeCLk2Y4ThCocl48YIMEsC8_Qk=.900ebd34-73ed-46a7-aa4e-94f13249273d@github.com> - Add linker note about packed structs. - Relax language a bit to avoid implying that only listed layouts are supported. ------------- Commit messages: - simplify language - - Add linker note about packed structs. Changes: https://git.openjdk.org/jdk/pull/16485/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16485&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8319316 Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/16485.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16485/head:pull/16485 PR: https://git.openjdk.org/jdk/pull/16485 From liach at openjdk.org Fri Nov 3 14:08:16 2023 From: liach at openjdk.org (Chen Liang) Date: Fri, 3 Nov 2023 14:08:16 GMT Subject: RFR: 8319386: Migrate Class::getEnclosingMethod/Constructor away from old generic utilities Message-ID: Please review a patch that migrates `Class::getEnclosingMethod` and `Class::getEnclosingConstructor`'s descriptor parsing from old generic utilities to more simple utilities from java.lang.invoke implementation. This will help migrate away from the old generic repositories in the future. The `getClassLoader()` call plus https://github.com/openjdk/jdk/blob/1a21c1a783d64ca0930c358c06a43975f96ffac6/src/java.base/share/classes/sun/invoke/util/BytecodeDescriptor.java#L93 should be functionally equivalent to the previous `getDeclsLoader()` https://github.com/openjdk/jdk/blob/1a21c1a783d64ca0930c358c06a43975f96ffac6/src/java.base/share/classes/sun/reflect/generics/factory/CoreReflectionFactory.java#L60-L68 plus https://github.com/openjdk/jdk/blob/1a21c1a783d64ca0930c358c06a43975f96ffac6/src/java.base/share/classes/sun/reflect/generics/factory/CoreReflectionFactory.java#L113-L114 ------------- Commit messages: - Migrate getEnclosingMethod/Constructor away from old generic utilities Changes: https://git.openjdk.org/jdk/pull/16496/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16496&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8319386 Stats: 31 lines in 1 file changed: 1 ins; 24 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/16496.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16496/head:pull/16496 PR: https://git.openjdk.org/jdk/pull/16496 From forax at openjdk.org Fri Nov 3 14:23:05 2023 From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax) Date: Fri, 3 Nov 2023 14:23:05 GMT Subject: RFR: 8319220: Pattern matching switch with a lot of cases is unduly slow In-Reply-To: References: Message-ID: On Fri, 3 Nov 2023 08:41:12 GMT, Jan Lahoda wrote: > Consider code like: > > void test(Object o) { > switch (o) { > case X1 -> {} > case X2 -> {} > ...(about 100 cases) > ``` > > javac will compile the switch into a switch whose selector is an indy invocation to `SwitchBootstraps.typeSwitch`, with static arguments being the types in the cases. > > `SwitchBootstraps.typeSwitch` will then create a chain of `MethodHandle`s performing `instanceof` checks between the switch's selector and the given case type. The problem is that when the number of cases is high enough, (more than ~40-50), the chain gets too long, and the tests won't inline anymore. This then leads to a very bad performance, when compared to manually written if-instanceof-else-if-instanceof- chain. > > The proposal herein is to use bytecode (written using the ClassFile API/library) instead of the `MethodHandle`s chain. The overall performance of this seems to be similar to the manually written if-instanceof-else-if-instanceof- chain. > > Using the benchmark from the bug, and this patch, I am getting: > > MyBenchmark.testIfElse100 thrpt 5 521826.326 ? 7510.042 ops/s > MyBenchmark.testSwitch100 thrpt 5 505440.170 ? 3757.178 ops/s > > > The most tricky part of this new way to generate the tests is handling of non-type case labels, and in particular cases with enum constant labels. The resolution of enum constants is deferred as much as possible, by using an indirection through the `ResolvedEnumLabels`. > > Further improvements may be possible, esp. for some specific cases (like all cases having a type, and the type being a final class). src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 397: > 395: cb.iload(1); > 396: Label dflt = cb.newLabel(); > 397: record Element(Label target, Label next, Object label) {} 'label' is not a Label, is there a better name to make the difference between the switch label and the bytecode label src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 423: > 421: Label next = element.next(); > 422: cb.labelBinding(element.target()); > 423: if (element.label() instanceof Class classLabel) { It's too bad we can not use a switch on the label here instead of a bunch of instanceof :) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16489#discussion_r1381754699 PR Review Comment: https://git.openjdk.org/jdk/pull/16489#discussion_r1381756247 From forax at openjdk.org Fri Nov 3 14:34:10 2023 From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax) Date: Fri, 3 Nov 2023 14:34:10 GMT Subject: RFR: 8319220: Pattern matching switch with a lot of cases is unduly slow In-Reply-To: References: Message-ID: On Fri, 3 Nov 2023 08:41:12 GMT, Jan Lahoda wrote: > Consider code like: > > void test(Object o) { > switch (o) { > case X1 -> {} > case X2 -> {} > ...(about 100 cases) > ``` > > javac will compile the switch into a switch whose selector is an indy invocation to `SwitchBootstraps.typeSwitch`, with static arguments being the types in the cases. > > `SwitchBootstraps.typeSwitch` will then create a chain of `MethodHandle`s performing `instanceof` checks between the switch's selector and the given case type. The problem is that when the number of cases is high enough, (more than ~40-50), the chain gets too long, and the tests won't inline anymore. This then leads to a very bad performance, when compared to manually written if-instanceof-else-if-instanceof- chain. > > The proposal herein is to use bytecode (written using the ClassFile API/library) instead of the `MethodHandle`s chain. The overall performance of this seems to be similar to the manually written if-instanceof-else-if-instanceof- chain. > > Using the benchmark from the bug, and this patch, I am getting: > > MyBenchmark.testIfElse100 thrpt 5 521826.326 ? 7510.042 ops/s > MyBenchmark.testSwitch100 thrpt 5 505440.170 ? 3757.178 ops/s > > > The most tricky part of this new way to generate the tests is handling of non-type case labels, and in particular cases with enum constant labels. The resolution of enum constants is deferred as much as possible, by using an indirection through the `ResolvedEnumLabels`. > > Further improvements may be possible, esp. for some specific cases (like all cases having a type, and the type being a final class). src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 425: > 423: if (element.label() instanceof Class classLabel) { > 424: cb.aload(0); > 425: cb.instanceof_(classLabel.describeConstable().get()); You should use orElseThrow() (see the javadoc) instead of get(). This code does not work because hidden class Class are not denotable. My first idea was that it was not a real problem because no code generated by javac will use an hidden class but this is not true. A type pattern can use the current class and this class can be loaded by a defineHiddenClass. A way to solve that issue is to store the non denotable classes inside a list and send that list as a class data when calling defineHiddenClass. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16489#discussion_r1381775426 From vromero at openjdk.org Fri Nov 3 14:34:27 2023 From: vromero at openjdk.org (Vicente Romero) Date: Fri, 3 Nov 2023 14:34:27 GMT Subject: RFR: JDK-8315458 Implementation of Implicitly Declared Classes and Instance Main Method (Second Preview) [v12] In-Reply-To: References: Message-ID: On Fri, 3 Nov 2023 12:40:48 GMT, Jim Laskey wrote: >> Address changes from JEP 445 to JEP 463. >> >> - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. >> >> - Don't mark class on read. >> >> - Remove reflection and annotation processing related to unnamed classes. >> >> - Simplify main method search. > > Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since the last revision: > > - Merge remote-tracking branch 'upstream/master' into 8315458 > - Don't get args unless necessary > - Remove unnamed classes from examples.not-yet.txt > - Requested corrections > - Changes recommended by Jan > - Revised implicit class test > - Don't store main method info globally. Use addition calls to fetch info. > - Update JEP number in PreviewFeature > - Remove MANDATED flag from implicit classes > - Remove .orig files > - ... and 2 more: https://git.openjdk.org/jdk/compare/8f2f4091...0bd5b477 src/java.base/share/native/libjli/java.c line 559: > 557: > 558: /* Build platform specific argument array */ > 559: if ((mainType & MAIN_WITHOUT_ARGS) == 0) { nice, thanks src/java.base/share/native/libjli/java.c line 561: > 559: if ((mainType & MAIN_WITHOUT_ARGS) == 0) { > 560: mainArgs = CreateApplicationArgs(env, argv, argc); > 561: CHECK_EXCEPTION_NULL_LEAVE(mainArgs); side: this is just a comment not proposing any change, I know it is a good practice to check for nulls here, but having a null here is really possible? how can we have a null here? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16461#discussion_r1381763339 PR Review Comment: https://git.openjdk.org/jdk/pull/16461#discussion_r1381775757 From mcimadamore at openjdk.org Fri Nov 3 14:51:05 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Fri, 3 Nov 2023 14:51:05 GMT Subject: RFR: 8319316: Clarify text around which layouts a linker supports In-Reply-To: <59YZ3CcJ5Sfx40UWGpeCLk2Y4ThCocl48YIMEsC8_Qk=.900ebd34-73ed-46a7-aa4e-94f13249273d@github.com> References: <59YZ3CcJ5Sfx40UWGpeCLk2Y4ThCocl48YIMEsC8_Qk=.900ebd34-73ed-46a7-aa4e-94f13249273d@github.com> Message-ID: On Fri, 3 Nov 2023 00:10:48 GMT, Jorn Vernee wrote: > - Add linker note about packed structs. > - Relax language a bit to avoid implying that only listed layouts are supported. src/java.base/share/classes/java/lang/foreign/Linker.java line 247: > 245: * > 246: * > 247: * Linker implementations may optionally support additional layouts, such as 'packed' struct layouts. Optional: should we say what a packed struct layout is? E.g. make `packed` italic. Then follow up with a sentence like: a packed struct is a struct in which there is at least one member layouts L whose offsets does not respect L's natural alignment: ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16485#discussion_r1381806211 From jlahoda at openjdk.org Fri Nov 3 15:02:11 2023 From: jlahoda at openjdk.org (Jan Lahoda) Date: Fri, 3 Nov 2023 15:02:11 GMT Subject: RFR: JDK-8315457 Implementation of String Templates (Second Preview) [v3] In-Reply-To: <_XrazddvO7-8lIILbhUn9VBpcp_YErXSWtxK4-eE53o=.7f423608-6901-4b34-a963-abc132d6c3cc@github.com> References: <_XrazddvO7-8lIILbhUn9VBpcp_YErXSWtxK4-eE53o=.7f423608-6901-4b34-a963-abc132d6c3cc@github.com> Message-ID: On Tue, 17 Oct 2023 16:03:25 GMT, Jim Laskey wrote: >> Update String Templates for a second preview. With the addition of >> >> - Expression type and throws are determined from the `process` method of the processor type and not the processor type. >> >> - Qualified `STR` and `RAW` are treated the same as unqualified `STR` and `RAW` . >> >> - Raw (generic) process types are no longer an error. > > Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: > > Cache process method type in JCStringTemplate Looks good to me. ------------- Marked as reviewed by jlahoda (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16202#pullrequestreview-1712905674 From jlaskey at openjdk.org Fri Nov 3 15:04:25 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Fri, 3 Nov 2023 15:04:25 GMT Subject: RFR: JDK-8315458 Implementation of Implicitly Declared Classes and Instance Main Method (Second Preview) [v12] In-Reply-To: References: Message-ID: On Fri, 3 Nov 2023 14:26:29 GMT, Vicente Romero wrote: >> Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since the last revision: >> >> - Merge remote-tracking branch 'upstream/master' into 8315458 >> - Don't get args unless necessary >> - Remove unnamed classes from examples.not-yet.txt >> - Requested corrections >> - Changes recommended by Jan >> - Revised implicit class test >> - Don't store main method info globally. Use addition calls to fetch info. >> - Update JEP number in PreviewFeature >> - Remove MANDATED flag from implicit classes >> - Remove .orig files >> - ... and 2 more: https://git.openjdk.org/jdk/compare/64f1c416...0bd5b477 > > src/java.base/share/native/libjli/java.c line 559: > >> 557: >> 558: /* Build platform specific argument array */ >> 559: if ((mainType & MAIN_WITHOUT_ARGS) == 0) { > > nice, thanks, a minor addition to the condition: `&& argc > 0`? Need an empty array when argc == 0. > src/java.base/share/native/libjli/java.c line 561: > >> 559: if ((mainType & MAIN_WITHOUT_ARGS) == 0) { >> 560: mainArgs = CreateApplicationArgs(env, argv, argc); >> 561: CHECK_EXCEPTION_NULL_LEAVE(mainArgs); > > side: this is just a comment not proposing any change, I know it is a good practice to check for nulls here, but having a null here is really possible? how can we have a null here? but I guess this also check for any other exception right? Yes it's a combo thing. This was the code that was there BTW. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16461#discussion_r1381823409 PR Review Comment: https://git.openjdk.org/jdk/pull/16461#discussion_r1381824589 From mabbay at openjdk.org Fri Nov 3 15:20:43 2023 From: mabbay at openjdk.org (Mourad Abbay) Date: Fri, 3 Nov 2023 15:20:43 GMT Subject: RFR: 8294980: test/jdk/java/lang/invoke 15 test classes use experimental bytecode library [v2] In-Reply-To: <-JRa1cWErB4H5zW-TqhXXd1y3TchfIXPMinb-CJ4OUE=.96cb1861-cb27-4030-a8a0-f90df924f041@github.com> References: <-JRa1cWErB4H5zW-TqhXXd1y3TchfIXPMinb-CJ4OUE=.96cb1861-cb27-4030-a8a0-f90df924f041@github.com> Message-ID: > early experimental version of the bytecode library is bundled under: > test/jdk/lib/testlibrary/bytecode > > following tests reference it: > test/jdk/java/lang/invoke/common/test/java/lang/invoke/lib/InstructionHelper.java > test/jdk/java/lang/invoke/condy/CondyWithGarbageTest.java > test/jdk/java/lang/invoke/condy/CondyReturnPrimitiveTest.java > test/jdk/java/lang/invoke/condy/CondyWrongType.java > test/jdk/java/lang/invoke/condy/CondyNestedTest.java > test/jdk/java/lang/invoke/condy/CondyStaticArgumentsTest.java > test/jdk/java/lang/invoke/condy/BootstrapMethodJumboArgsTest.java > test/jdk/java/lang/invoke/condy/ConstantBootstrapsTest.java > test/jdk/java/lang/invoke/condy/CondyRepeatFailedResolution.java > test/jdk/java/lang/invoke/condy/CondyBSMInvocation.java > test/jdk/java/lang/invoke/condy/CondyTypeValidationTest.java > test/jdk/java/lang/invoke/condy/CondyBSMValidationTest.java > test/jdk/java/lang/invoke/condy/CondyNameValidationTest.java > test/jdk/java/lang/invoke/condy/CondyBSMException.java > test/jdk/java/lang/invoke/condy/CondyInterfaceWithOverpassMethods.java Mourad Abbay has updated the pull request incrementally with one additional commit since the last revision: specify packages to export in jtreg tests. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16268/files - new: https://git.openjdk.org/jdk/pull/16268/files/0221e2b4..96301a6d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16268&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16268&range=00-01 Stats: 70 lines in 14 files changed: 70 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/16268.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16268/head:pull/16268 PR: https://git.openjdk.org/jdk/pull/16268 From forax at openjdk.org Fri Nov 3 15:21:12 2023 From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax) Date: Fri, 3 Nov 2023 15:21:12 GMT Subject: RFR: 8319220: Pattern matching switch with a lot of cases is unduly slow In-Reply-To: References: Message-ID: <9PEJuwdi6M83XFE2vTPgTAUvfBCoZMMEAkYPKe1rZ-s=.d8868c80-ca65-4ba0-a8d1-60b74c31820e@github.com> On Fri, 3 Nov 2023 08:41:12 GMT, Jan Lahoda wrote: > Consider code like: > > void test(Object o) { > switch (o) { > case X1 -> {} > case X2 -> {} > ...(about 100 cases) > ``` > > javac will compile the switch into a switch whose selector is an indy invocation to `SwitchBootstraps.typeSwitch`, with static arguments being the types in the cases. > > `SwitchBootstraps.typeSwitch` will then create a chain of `MethodHandle`s performing `instanceof` checks between the switch's selector and the given case type. The problem is that when the number of cases is high enough, (more than ~40-50), the chain gets too long, and the tests won't inline anymore. This then leads to a very bad performance, when compared to manually written if-instanceof-else-if-instanceof- chain. > > The proposal herein is to use bytecode (written using the ClassFile API/library) instead of the `MethodHandle`s chain. The overall performance of this seems to be similar to the manually written if-instanceof-else-if-instanceof- chain. > > Using the benchmark from the bug, and this patch, I am getting: > > MyBenchmark.testIfElse100 thrpt 5 521826.326 ? 7510.042 ops/s > MyBenchmark.testSwitch100 thrpt 5 505440.170 ? 3757.178 ops/s > > > The most tricky part of this new way to generate the tests is handling of non-type case labels, and in particular cases with enum constant labels. The resolution of enum constants is deferred as much as possible, by using an indirection through the `ResolvedEnumLabels`. > > Further improvements may be possible, esp. for some specific cases (like all cases having a type, and the type being a final class). Here is a test that uses a hidden class that works with the current implementation. If i'm not mistaken, the proposed implementation fails that test. public class SwitchBootstrapTest { public static void main(String[] args) throws Throwable { var className = SwitchBootstrapTest.class.getName(); byte[] data; try(var input = SwitchBootstrapTest.class.getResourceAsStream('/' + className.replace('.', '/') + ".class")) { data = input.readAllBytes(); } var lookup = MethodHandles.lookup().defineHiddenClass(data, true, ClassOption.NESTMATE, ClassOption.STRONG); var hiddenClass = lookup.lookupClass(); var constructor = lookup.findConstructor(hiddenClass, methodType(void.class)); var instance = constructor.invoke(); var methodType = methodType(int.class, Object.class, int.class); var callSite = SwitchBootstraps.typeSwitch(lookup, "", methodType, hiddenClass, Object.class); var index = (int) callSite.getTarget().invokeExact(instance, 0); System.out.println("index " + index); } } ------------- PR Comment: https://git.openjdk.org/jdk/pull/16489#issuecomment-1792629864 From vromero at openjdk.org Fri Nov 3 15:22:25 2023 From: vromero at openjdk.org (Vicente Romero) Date: Fri, 3 Nov 2023 15:22:25 GMT Subject: RFR: JDK-8315458 Implementation of Implicitly Declared Classes and Instance Main Method (Second Preview) [v12] In-Reply-To: References: Message-ID: On Fri, 3 Nov 2023 15:00:41 GMT, Jim Laskey wrote: >> src/java.base/share/native/libjli/java.c line 559: >> >>> 557: >>> 558: /* Build platform specific argument array */ >>> 559: if ((mainType & MAIN_WITHOUT_ARGS) == 0) { >> >> nice, thanks, a minor addition to the condition: `&& argc > 0`? > > Need an empty array when argc == 0. oh I see >> src/java.base/share/native/libjli/java.c line 561: >> >>> 559: if ((mainType & MAIN_WITHOUT_ARGS) == 0) { >>> 560: mainArgs = CreateApplicationArgs(env, argv, argc); >>> 561: CHECK_EXCEPTION_NULL_LEAVE(mainArgs); >> >> side: this is just a comment not proposing any change, I know it is a good practice to check for nulls here, but having a null here is really possible? how can we have a null here? but I guess this also check for any other exception right? > > Yes it's a combo thing. This was the code that was there BTW. yes I know it is previous code, I was just wondering how we could have a null exception here but it is true that other exceptions can occur ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16461#discussion_r1381846743 PR Review Comment: https://git.openjdk.org/jdk/pull/16461#discussion_r1381848172 From jlaskey at openjdk.org Fri Nov 3 15:29:25 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Fri, 3 Nov 2023 15:29:25 GMT Subject: RFR: JDK-8315457 Implementation of String Templates (Second Preview) [v4] In-Reply-To: References: Message-ID: > Update String Templates for a second preview. With the addition of > > - Expression type and throws are determined from the `process` method of the processor type and not the processor type. > > - Qualified `STR` and `RAW` are treated the same as unqualified `STR` and `RAW` . > > - Raw (generic) process types are no longer an error. Jim Laskey has updated the pull request with a new target base 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 remote-tracking branch 'upstream/master' into 8315457 - Cache process method type in JCStringTemplate - Revert source - Revert @since 22 - Accept qualified STR and RAW - String Templates (second preview) ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16202/files - new: https://git.openjdk.org/jdk/pull/16202/files/ae136779..2afadc69 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16202&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16202&range=02-03 Stats: 53408 lines in 1930 files changed: 29390 ins; 10168 del; 13850 mod Patch: https://git.openjdk.org/jdk/pull/16202.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16202/head:pull/16202 PR: https://git.openjdk.org/jdk/pull/16202 From jlahoda at openjdk.org Fri Nov 3 15:32:34 2023 From: jlahoda at openjdk.org (Jan Lahoda) Date: Fri, 3 Nov 2023 15:32:34 GMT Subject: RFR: 8319220: Pattern matching switch with a lot of cases is unduly slow [v2] In-Reply-To: References: Message-ID: > Consider code like: > > void test(Object o) { > switch (o) { > case X1 -> {} > case X2 -> {} > ...(about 100 cases) > ``` > > javac will compile the switch into a switch whose selector is an indy invocation to `SwitchBootstraps.typeSwitch`, with static arguments being the types in the cases. > > `SwitchBootstraps.typeSwitch` will then create a chain of `MethodHandle`s performing `instanceof` checks between the switch's selector and the given case type. The problem is that when the number of cases is high enough, (more than ~40-50), the chain gets too long, and the tests won't inline anymore. This then leads to a very bad performance, when compared to manually written if-instanceof-else-if-instanceof- chain. > > The proposal herein is to use bytecode (written using the ClassFile API/library) instead of the `MethodHandle`s chain. The overall performance of this seems to be similar to the manually written if-instanceof-else-if-instanceof- chain. > > Using the benchmark from the bug, and this patch, I am getting: > > MyBenchmark.testIfElse100 thrpt 5 521826.326 ? 7510.042 ops/s > MyBenchmark.testSwitch100 thrpt 5 505440.170 ? 3757.178 ops/s > > > The most tricky part of this new way to generate the tests is handling of non-type case labels, and in particular cases with enum constant labels. The resolution of enum constants is deferred as much as possible, by using an indirection through the `ResolvedEnumLabels`. > > Further improvements may be possible, esp. for some specific cases (like all cases having a type, and the type being a final class). Jan Lahoda has updated the pull request incrementally with two additional commits since the last revision: - Some more get->orElseThrow - Reflecting review feedback. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16489/files - new: https://git.openjdk.org/jdk/pull/16489/files/263bd3d6..94d47488 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16489&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16489&range=00-01 Stats: 167 lines in 2 files changed: 46 ins; 4 del; 117 mod Patch: https://git.openjdk.org/jdk/pull/16489.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16489/head:pull/16489 PR: https://git.openjdk.org/jdk/pull/16489 From jlahoda at openjdk.org Fri Nov 3 15:32:36 2023 From: jlahoda at openjdk.org (Jan Lahoda) Date: Fri, 3 Nov 2023 15:32:36 GMT Subject: RFR: 8319220: Pattern matching switch with a lot of cases is unduly slow In-Reply-To: References: Message-ID: On Fri, 3 Nov 2023 08:41:12 GMT, Jan Lahoda wrote: > Consider code like: > > void test(Object o) { > switch (o) { > case X1 -> {} > case X2 -> {} > ...(about 100 cases) > ``` > > javac will compile the switch into a switch whose selector is an indy invocation to `SwitchBootstraps.typeSwitch`, with static arguments being the types in the cases. > > `SwitchBootstraps.typeSwitch` will then create a chain of `MethodHandle`s performing `instanceof` checks between the switch's selector and the given case type. The problem is that when the number of cases is high enough, (more than ~40-50), the chain gets too long, and the tests won't inline anymore. This then leads to a very bad performance, when compared to manually written if-instanceof-else-if-instanceof- chain. > > The proposal herein is to use bytecode (written using the ClassFile API/library) instead of the `MethodHandle`s chain. The overall performance of this seems to be similar to the manually written if-instanceof-else-if-instanceof- chain. > > Using the benchmark from the bug, and this patch, I am getting: > > MyBenchmark.testIfElse100 thrpt 5 521826.326 ? 7510.042 ops/s > MyBenchmark.testSwitch100 thrpt 5 505440.170 ? 3757.178 ops/s > > > The most tricky part of this new way to generate the tests is handling of non-type case labels, and in particular cases with enum constant labels. The resolution of enum constants is deferred as much as possible, by using an indirection through the `ResolvedEnumLabels`. > > Further improvements may be possible, esp. for some specific cases (like all cases having a type, and the type being a final class). Thanks for all the comments so far - I think I've either reflected them, or wrote a comment to each of them. Please let me know if there's something else, or if I've forgotten something. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16489#issuecomment-1792651632 From jlahoda at openjdk.org Fri Nov 3 15:32:41 2023 From: jlahoda at openjdk.org (Jan Lahoda) Date: Fri, 3 Nov 2023 15:32:41 GMT Subject: RFR: 8319220: Pattern matching switch with a lot of cases is unduly slow [v2] In-Reply-To: References: Message-ID: <3lMBRL6ySJSD0yNH6pSAC3DdBzCa2YCD6whxXa6VcoY=.e608ca81-63c9-4434-8cc4-f07e883b4113@github.com> On Fri, 3 Nov 2023 09:48:15 GMT, Chen Liang wrote: >> Jan Lahoda has updated the pull request incrementally with two additional commits since the last revision: >> >> - Some more get->orElseThrow >> - Reflecting review feedback. > > src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 338: > >> 336: >> 337: @Override >> 338: public Object apply(Integer labelIndex, Object value) { > > Since we already know the EnumDesc (i.e. `result`), we can just convert this to a `BiPredicate` for simplicity. Done. > src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 346: > >> 344: Class clazz = label.constantType().resolveConstantDesc(lookup); >> 345: >> 346: if (value.getClass() != clazz) { > > Not related to this patch, but this appears to be wrong: we should do something like > > if (!(value instanceof Enum ev) || ev.getDeclaringClass() != clazz) > return SENTINEL; // or false You are right, of course, but let's solve that under [JDK-8318144](https://bugs.openjdk.org/browse/JDK-8318144), to ensure that can more easily be backported. Tests are running on the fix, will publish PR once they pass. Thanks! > src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 383: > >> 381: .withMethod("typeSwitch", MethodTypeDesc.ofDescriptor("(Ljava/lang/Object;ILjava/util/function/BiFunction;)I"), Classfile.ACC_STATIC, mb -> { >> 382: mb.withFlags(AccessFlag.PUBLIC, AccessFlag.FINAL, AccessFlag.STATIC) >> 383: .withCode(cb -> { > > Can just use `clb.withMethodBody` and pass the access flags with `Classfile.ACC_PUBLIC | Classfile.ACC_STATIC | Classfile.ACC_FINAL` Done. > src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 432: > >> 430: cb.aload(2); >> 431: cb.constantInstruction(enumIdx); >> 432: cb.invokestatic(Integer.class.describeConstable().get(), > > You can use `ConstantDescs.CD_Integer` etc. Done. > src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 434: > >> 432: cb.invokestatic(Integer.class.describeConstable().get(), >> 433: "valueOf", >> 434: MethodType.methodType(Integer.class, > > I recommend `MethodTypeDesc.of()` instead. Done. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16489#discussion_r1381868349 PR Review Comment: https://git.openjdk.org/jdk/pull/16489#discussion_r1381871678 PR Review Comment: https://git.openjdk.org/jdk/pull/16489#discussion_r1381866683 PR Review Comment: https://git.openjdk.org/jdk/pull/16489#discussion_r1381866943 PR Review Comment: https://git.openjdk.org/jdk/pull/16489#discussion_r1381867739 From jlahoda at openjdk.org Fri Nov 3 15:32:43 2023 From: jlahoda at openjdk.org (Jan Lahoda) Date: Fri, 3 Nov 2023 15:32:43 GMT Subject: RFR: 8319220: Pattern matching switch with a lot of cases is unduly slow [v2] In-Reply-To: References: Message-ID: On Fri, 3 Nov 2023 14:19:17 GMT, R?mi Forax wrote: >> Jan Lahoda has updated the pull request incrementally with two additional commits since the last revision: >> >> - Some more get->orElseThrow >> - Reflecting review feedback. > > src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 397: > >> 395: cb.iload(1); >> 396: Label dflt = cb.newLabel(); >> 397: record Element(Label target, Label next, Object label) {} > > 'label' is not a Label, is there a better name to make the difference between the switch label and the bytecode label Changed to `caseLabel`. > src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 423: > >> 421: Label next = element.next(); >> 422: cb.labelBinding(element.target()); >> 423: if (element.label() instanceof Class classLabel) { > > It's too bad we can not use a switch on the label here instead of a bunch of instanceof :) Well, we could, if we tweaked javac so that it would produce a different/simplified code for java.base for pattern switches (i.e. hardcode an if-else cascade). Which we may or may not do at some point. > src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 425: > >> 423: if (element.label() instanceof Class classLabel) { >> 424: cb.aload(0); >> 425: cb.instanceof_(classLabel.describeConstable().get()); > > You should use orElseThrow() (see the javadoc) instead of get(). This code does not work because hidden class Class are not denotable. My first idea was that it was not a real problem because no code generated by javac will use an hidden class but this is not true. A type pattern can use the current class and this class can be loaded by a defineHiddenClass. > > A way to solve that issue is to store the non denotable classes inside a list and send that list as a class data when calling defineHiddenClass. Done (both `orElseThrow()` and the hidden classes). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16489#discussion_r1381873158 PR Review Comment: https://git.openjdk.org/jdk/pull/16489#discussion_r1381879214 PR Review Comment: https://git.openjdk.org/jdk/pull/16489#discussion_r1381879791 From forax at openjdk.org Fri Nov 3 15:43:05 2023 From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax) Date: Fri, 3 Nov 2023 15:43:05 GMT Subject: RFR: 8319220: Pattern matching switch with a lot of cases is unduly slow [v2] In-Reply-To: References: Message-ID: On Fri, 3 Nov 2023 15:32:34 GMT, Jan Lahoda wrote: >> Consider code like: >> >> void test(Object o) { >> switch (o) { >> case X1 -> {} >> case X2 -> {} >> ...(about 100 cases) >> ``` >> >> javac will compile the switch into a switch whose selector is an indy invocation to `SwitchBootstraps.typeSwitch`, with static arguments being the types in the cases. >> >> `SwitchBootstraps.typeSwitch` will then create a chain of `MethodHandle`s performing `instanceof` checks between the switch's selector and the given case type. The problem is that when the number of cases is high enough, (more than ~40-50), the chain gets too long, and the tests won't inline anymore. This then leads to a very bad performance, when compared to manually written if-instanceof-else-if-instanceof- chain. >> >> The proposal herein is to use bytecode (written using the ClassFile API/library) instead of the `MethodHandle`s chain. The overall performance of this seems to be similar to the manually written if-instanceof-else-if-instanceof- chain. >> >> Using the benchmark from the bug, and this patch, I am getting: >> >> MyBenchmark.testIfElse100 thrpt 5 521826.326 ? 7510.042 ops/s >> MyBenchmark.testSwitch100 thrpt 5 505440.170 ? 3757.178 ops/s >> >> >> The most tricky part of this new way to generate the tests is handling of non-type case labels, and in particular cases with enum constant labels. The resolution of enum constants is deferred as much as possible, by using an indirection through the `ResolvedEnumLabels`. >> >> Further improvements may be possible, esp. for some specific cases (like all cases having a type, and the type being a final class). > > Jan Lahoda has updated the pull request incrementally with two additional commits since the last revision: > > - Some more get->orElseThrow > - Reflecting review feedback. src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 385: > 383: > 384: byte[] classBytes = Classfile.of().build(ClassDesc.of(typeSwitchClassName(caller.lookupClass())), clb -> { > 385: clb.withFlags(AccessFlag.FINAL, AccessFlag.SYNTHETIC) `AccessFlag.SUPER` is missing, this will make this class a value class in the Valhalla repo ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16489#discussion_r1381896567 From forax at openjdk.org Fri Nov 3 15:53:08 2023 From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax) Date: Fri, 3 Nov 2023 15:53:08 GMT Subject: RFR: 8319220: Pattern matching switch with a lot of cases is unduly slow [v2] In-Reply-To: References: Message-ID: On Fri, 3 Nov 2023 15:32:34 GMT, Jan Lahoda wrote: >> Consider code like: >> >> void test(Object o) { >> switch (o) { >> case X1 -> {} >> case X2 -> {} >> ...(about 100 cases) >> ``` >> >> javac will compile the switch into a switch whose selector is an indy invocation to `SwitchBootstraps.typeSwitch`, with static arguments being the types in the cases. >> >> `SwitchBootstraps.typeSwitch` will then create a chain of `MethodHandle`s performing `instanceof` checks between the switch's selector and the given case type. The problem is that when the number of cases is high enough, (more than ~40-50), the chain gets too long, and the tests won't inline anymore. This then leads to a very bad performance, when compared to manually written if-instanceof-else-if-instanceof- chain. >> >> The proposal herein is to use bytecode (written using the ClassFile API/library) instead of the `MethodHandle`s chain. The overall performance of this seems to be similar to the manually written if-instanceof-else-if-instanceof- chain. >> >> Using the benchmark from the bug, and this patch, I am getting: >> >> MyBenchmark.testIfElse100 thrpt 5 521826.326 ? 7510.042 ops/s >> MyBenchmark.testSwitch100 thrpt 5 505440.170 ? 3757.178 ops/s >> >> >> The most tricky part of this new way to generate the tests is handling of non-type case labels, and in particular cases with enum constant labels. The resolution of enum constants is deferred as much as possible, by using an indirection through the `ResolvedEnumLabels`. >> >> Further improvements may be possible, esp. for some specific cases (like all cases having a type, and the type being a final class). > > Jan Lahoda has updated the pull request incrementally with two additional commits since the last revision: > > - Some more get->orElseThrow > - Reflecting review feedback. src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 429: > 427: Label next = element.next(); > 428: cb.labelBinding(element.target()); > 429: if (element.caseLabel() instanceof Class classLabel && I think you can do a if else of isPresent inside instanceof Class to avoid to reapeat the instanceof and store `classLabel.describeConstable()` into a local variable. src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 517: > 515: BiPredicate.class, > 516: Class[].class)); > 517: return MethodHandles.insertArguments(typeSwitch, 2, new ResolvedEnumLabels(caller, enumDescs.toArray(s -> new EnumDesc[s])), you can use the method reference `EnumDesc[]::new`instead of `s -> new EnumDesc[s]` and same below Class[]::new (the wirldcard should not be necessary) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16489#discussion_r1381910073 PR Review Comment: https://git.openjdk.org/jdk/pull/16489#discussion_r1381908291 From forax at openjdk.org Fri Nov 3 16:00:03 2023 From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax) Date: Fri, 3 Nov 2023 16:00:03 GMT Subject: RFR: 8319220: Pattern matching switch with a lot of cases is unduly slow In-Reply-To: References: Message-ID: On Fri, 3 Nov 2023 15:29:05 GMT, Jan Lahoda wrote: > Thanks for all the comments so far - I think I've either reflected them, or wrote a comment to each of them. Please let me know if there's something else, or if I've forgotten something. You idea to use an extra array is clever. Using an immutable List instead of an array should allow the VM to constant fold the Class.isInstance (see above). ------------- PR Comment: https://git.openjdk.org/jdk/pull/16489#issuecomment-1792698583 From forax at openjdk.org Fri Nov 3 16:00:08 2023 From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax) Date: Fri, 3 Nov 2023 16:00:08 GMT Subject: RFR: 8319220: Pattern matching switch with a lot of cases is unduly slow [v2] In-Reply-To: References: Message-ID: On Fri, 3 Nov 2023 15:32:34 GMT, Jan Lahoda wrote: >> Consider code like: >> >> void test(Object o) { >> switch (o) { >> case X1 -> {} >> case X2 -> {} >> ...(about 100 cases) >> ``` >> >> javac will compile the switch into a switch whose selector is an indy invocation to `SwitchBootstraps.typeSwitch`, with static arguments being the types in the cases. >> >> `SwitchBootstraps.typeSwitch` will then create a chain of `MethodHandle`s performing `instanceof` checks between the switch's selector and the given case type. The problem is that when the number of cases is high enough, (more than ~40-50), the chain gets too long, and the tests won't inline anymore. This then leads to a very bad performance, when compared to manually written if-instanceof-else-if-instanceof- chain. >> >> The proposal herein is to use bytecode (written using the ClassFile API/library) instead of the `MethodHandle`s chain. The overall performance of this seems to be similar to the manually written if-instanceof-else-if-instanceof- chain. >> >> Using the benchmark from the bug, and this patch, I am getting: >> >> MyBenchmark.testIfElse100 thrpt 5 521826.326 ? 7510.042 ops/s >> MyBenchmark.testSwitch100 thrpt 5 505440.170 ? 3757.178 ops/s >> >> >> The most tricky part of this new way to generate the tests is handling of non-type case labels, and in particular cases with enum constant labels. The resolution of enum constants is deferred as much as possible, by using an indirection through the `ResolvedEnumLabels`. >> >> Further improvements may be possible, esp. for some specific cases (like all cases having a type, and the type being a final class). > > Jan Lahoda has updated the pull request incrementally with two additional commits since the last revision: > > - Some more get->orElseThrow > - Reflecting review feedback. src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 437: > 435: cb.aload(3); > 436: cb.constantInstruction(extraClassLabels.size()); > 437: cb.aaload(); Arrays are mutable in Java, so the VM can not know if the array of non denotable classes (`extraClassLabels`) will be changed or not so the result of aaload is not a constant so the call to isInstance can not be optimized. Using a immutable list (`List.of()`) instead of an array should work, because all the implementation of List.of() are using @Stable. In that case aaload becomes invokevirtual List.get(). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16489#discussion_r1381915611 From jvernee at openjdk.org Fri Nov 3 16:20:03 2023 From: jvernee at openjdk.org (Jorn Vernee) Date: Fri, 3 Nov 2023 16:20:03 GMT Subject: RFR: 8319316: Clarify text around which layouts a linker supports In-Reply-To: References: <59YZ3CcJ5Sfx40UWGpeCLk2Y4ThCocl48YIMEsC8_Qk=.900ebd34-73ed-46a7-aa4e-94f13249273d@github.com> Message-ID: On Fri, 3 Nov 2023 14:48:31 GMT, Maurizio Cimadamore wrote: >> - Add linker note about packed structs. >> - Relax language a bit to avoid implying that only listed layouts are supported. > > src/java.base/share/classes/java/lang/foreign/Linker.java line 247: > >> 245: * >> 246: * >> 247: * Linker implementations may optionally support additional layouts, such as 'packed' struct layouts. > > Optional: should we say what a packed struct layout is? E.g. make `packed` italic. Then follow up with a sentence like: > > a packed struct is a struct in which there is at least one member layouts L whose offsets does not respect L's natural alignment: Yes, good idea ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16485#discussion_r1381939792 From jlahoda at openjdk.org Fri Nov 3 16:30:08 2023 From: jlahoda at openjdk.org (Jan Lahoda) Date: Fri, 3 Nov 2023 16:30:08 GMT Subject: RFR: 8319220: Pattern matching switch with a lot of cases is unduly slow [v2] In-Reply-To: <3lMBRL6ySJSD0yNH6pSAC3DdBzCa2YCD6whxXa6VcoY=.e608ca81-63c9-4434-8cc4-f07e883b4113@github.com> References: <3lMBRL6ySJSD0yNH6pSAC3DdBzCa2YCD6whxXa6VcoY=.e608ca81-63c9-4434-8cc4-f07e883b4113@github.com> Message-ID: On Fri, 3 Nov 2023 15:24:48 GMT, Jan Lahoda wrote: >> src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 346: >> >>> 344: Class clazz = label.constantType().resolveConstantDesc(lookup); >>> 345: >>> 346: if (value.getClass() != clazz) { >> >> Not related to this patch, but this appears to be wrong: we should do something like >> >> if (!(value instanceof Enum ev) || ev.getDeclaringClass() != clazz) >> return SENTINEL; // or false > > You are right, of course, but let's solve that under [JDK-8318144](https://bugs.openjdk.org/browse/JDK-8318144), to ensure that can more easily be backported. Tests are running on the fix, will publish PR once they pass. Thanks! FYI: https://github.com/openjdk/jdk/pull/16499 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16489#discussion_r1381950105 From jlahoda at openjdk.org Fri Nov 3 16:32:16 2023 From: jlahoda at openjdk.org (Jan Lahoda) Date: Fri, 3 Nov 2023 16:32:16 GMT Subject: RFR: 8318144: Match on enum constants with body compiles but fails with MatchException Message-ID: For code like: enum E {A {}, B {} } Object o = E.A; switch (o) { case E.A -> System.err.println(o); default -> System.err.println("default"); } The result is `default`, not `A`, due to incorrect classes being compared. Thanks for @liach for noting the solution here: https://github.com/openjdk/jdk/pull/16489#discussion_r1381411165 ------------- Commit messages: - 8318144: Match on enum constants with body compiles but fails with MatchException Changes: https://git.openjdk.org/jdk/pull/16499/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16499&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8318144 Stats: 109 lines in 3 files changed: 107 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/16499.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16499/head:pull/16499 PR: https://git.openjdk.org/jdk/pull/16499 From jvernee at openjdk.org Fri Nov 3 16:35:18 2023 From: jvernee at openjdk.org (Jorn Vernee) Date: Fri, 3 Nov 2023 16:35:18 GMT Subject: RFR: 8319316: Clarify text around which layouts a linker supports [v2] In-Reply-To: <59YZ3CcJ5Sfx40UWGpeCLk2Y4ThCocl48YIMEsC8_Qk=.900ebd34-73ed-46a7-aa4e-94f13249273d@github.com> References: <59YZ3CcJ5Sfx40UWGpeCLk2Y4ThCocl48YIMEsC8_Qk=.900ebd34-73ed-46a7-aa4e-94f13249273d@github.com> Message-ID: <9K5jLL1imVvAoglzwYIubqIwp0xcCr_appJyUXJH-OU=.757c93fd-68a5-420e-9fcd-fc0da728438e@github.com> > - Add linker note about packed structs. > - Relax language a bit to avoid implying that only listed layouts are supported. Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: add examples of packed structs ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16485/files - new: https://git.openjdk.org/jdk/pull/16485/files/b8b5d024..fea8a263 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16485&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16485&range=00-01 Stats: 15 lines in 1 file changed: 14 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/16485.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16485/head:pull/16485 PR: https://git.openjdk.org/jdk/pull/16485 From jvernee at openjdk.org Fri Nov 3 16:35:19 2023 From: jvernee at openjdk.org (Jorn Vernee) Date: Fri, 3 Nov 2023 16:35:19 GMT Subject: RFR: 8319316: Clarify text around which layouts a linker supports [v2] In-Reply-To: References: <59YZ3CcJ5Sfx40UWGpeCLk2Y4ThCocl48YIMEsC8_Qk=.900ebd34-73ed-46a7-aa4e-94f13249273d@github.com> Message-ID: On Fri, 3 Nov 2023 16:17:32 GMT, Jorn Vernee wrote: >> src/java.base/share/classes/java/lang/foreign/Linker.java line 247: >> >>> 245: * >>> 246: * >>> 247: * Linker implementations may optionally support additional layouts, such as 'packed' struct layouts. >> >> Optional: should we say what a packed struct layout is? E.g. make `packed` italic. Then follow up with a sentence like: >> >> a packed struct is a struct in which there is at least one member layouts L whose offsets does not respect L's natural alignment: > > Yes, good idea See https://github.com/openjdk/jdk/pull/16485/commits/fea8a26325b3e6142c652821e0ef95d78992b36c I've avoided talking about offset, since packing can also be used to avoid trailing padding. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16485#discussion_r1381955593 From lmesnik at openjdk.org Fri Nov 3 16:39:18 2023 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Fri, 3 Nov 2023 16:39:18 GMT Subject: RFR: 8318839: Update test thread factory to catch all exceptions [v2] In-Reply-To: <9S4kuhxUayZ6r1SjV2F7fbJzclmYevQ-WysyHOcnq_4=.44149a06-c65b-42b5-9b2d-ad9ee430308a@github.com> References: <19jJ-G8gCQEMp6p4bp_FQX82RQKBNbvCDSJbFt6EPkM=.a16102c1-afc7-46ec-8d0c-46db236c6510@github.com> <9S4kuhxUayZ6r1SjV2F7fbJzclmYevQ-WysyHOcnq_4=.44149a06-c65b-42b5-9b2d-ad9ee430308a@github.com> Message-ID: <_kF5hp2T1M6e_pCi6Meiz5hcqbJw4wg_i0Rjeb8rX0c=.096f2213-4e6c-4a03-b051-433b8449b6f7@github.com> On Fri, 3 Nov 2023 03:44:31 GMT, Leonid Mesnik wrote: >> The jtreg starts the main thread in a separate ThreadGroup and checks unhandled exceptions for this group. However, it doesn't catch all unhandled exceptions. There is a jtreg issue for this https://bugs.openjdk.org/browse/CODETOOLS-7903526. >> Catching such issues for virtual threads is important because they are not included in any groups. So this fix implements the handler for the test thread factory. >> >> A few tests start failing. >> >> The test >> serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorVMEventsTest.java >> has testcases for platform and virtual threads. So, there is there's no need to run it with the thread factory. >> >> The test >> java/lang/Thread/virtual/ThreadAPI.java >> tests UncaughtExceptionHandler and virtual threads. No need to run it with a thread factory. >> >> Test >> test/jdk/java/util/concurrent/tck/ThreadTest.java is updated to not check the default empty handler. >> >> Probably, we need some common approach about dealing with the UncaughtExceptionHandler in jtreg. > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > Replaced System.exit() with exception. ok, seems there is no good way to process exceptions here. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16369#issuecomment-1792774893 From lmesnik at openjdk.org Fri Nov 3 16:39:20 2023 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Fri, 3 Nov 2023 16:39:20 GMT Subject: Withdrawn: 8318839: Update test thread factory to catch all exceptions In-Reply-To: <19jJ-G8gCQEMp6p4bp_FQX82RQKBNbvCDSJbFt6EPkM=.a16102c1-afc7-46ec-8d0c-46db236c6510@github.com> References: <19jJ-G8gCQEMp6p4bp_FQX82RQKBNbvCDSJbFt6EPkM=.a16102c1-afc7-46ec-8d0c-46db236c6510@github.com> Message-ID: <7N3MQZ3asiMcuw2eEp9AX9nIcRh_en_R9paR_BJOqIk=.f27ae87d-326c-4fb7-86cf-0befd196e9c9@github.com> On Wed, 25 Oct 2023 21:08:01 GMT, Leonid Mesnik wrote: > The jtreg starts the main thread in a separate ThreadGroup and checks unhandled exceptions for this group. However, it doesn't catch all unhandled exceptions. There is a jtreg issue for this https://bugs.openjdk.org/browse/CODETOOLS-7903526. > Catching such issues for virtual threads is important because they are not included in any groups. So this fix implements the handler for the test thread factory. > > A few tests start failing. > > The test > serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorVMEventsTest.java > has testcases for platform and virtual threads. So, there is there's no need to run it with the thread factory. > > The test > java/lang/Thread/virtual/ThreadAPI.java > tests UncaughtExceptionHandler and virtual threads. No need to run it with a thread factory. > > Test > test/jdk/java/util/concurrent/tck/ThreadTest.java is updated to not check the default empty handler. > > Probably, we need some common approach about dealing with the UncaughtExceptionHandler in jtreg. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/16369 From jlahoda at openjdk.org Fri Nov 3 16:43:30 2023 From: jlahoda at openjdk.org (Jan Lahoda) Date: Fri, 3 Nov 2023 16:43:30 GMT Subject: RFR: 8319220: Pattern matching switch with a lot of cases is unduly slow [v3] In-Reply-To: References: Message-ID: > Consider code like: > > void test(Object o) { > switch (o) { > case X1 -> {} > case X2 -> {} > ...(about 100 cases) > ``` > > javac will compile the switch into a switch whose selector is an indy invocation to `SwitchBootstraps.typeSwitch`, with static arguments being the types in the cases. > > `SwitchBootstraps.typeSwitch` will then create a chain of `MethodHandle`s performing `instanceof` checks between the switch's selector and the given case type. The problem is that when the number of cases is high enough, (more than ~40-50), the chain gets too long, and the tests won't inline anymore. This then leads to a very bad performance, when compared to manually written if-instanceof-else-if-instanceof- chain. > > The proposal herein is to use bytecode (written using the ClassFile API/library) instead of the `MethodHandle`s chain. The overall performance of this seems to be similar to the manually written if-instanceof-else-if-instanceof- chain. > > Using the benchmark from the bug, and this patch, I am getting: > > MyBenchmark.testIfElse100 thrpt 5 521826.326 ? 7510.042 ops/s > MyBenchmark.testSwitch100 thrpt 5 505440.170 ? 3757.178 ops/s > > > The most tricky part of this new way to generate the tests is handling of non-type case labels, and in particular cases with enum constant labels. The resolution of enum constants is deferred as much as possible, by using an indirection through the `ResolvedEnumLabels`. > > Further improvements may be possible, esp. for some specific cases (like all cases having a type, and the type being a final class). Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: Reflecting review feedback. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16489/files - new: https://git.openjdk.org/jdk/pull/16489/files/94d47488..ff390e97 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16489&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16489&range=01-02 Stats: 28 lines in 1 file changed: 7 ins; 0 del; 21 mod Patch: https://git.openjdk.org/jdk/pull/16489.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16489/head:pull/16489 PR: https://git.openjdk.org/jdk/pull/16489 From jlahoda at openjdk.org Fri Nov 3 16:43:34 2023 From: jlahoda at openjdk.org (Jan Lahoda) Date: Fri, 3 Nov 2023 16:43:34 GMT Subject: RFR: 8319220: Pattern matching switch with a lot of cases is unduly slow [v2] In-Reply-To: References: Message-ID: On Fri, 3 Nov 2023 15:50:43 GMT, R?mi Forax wrote: >> Jan Lahoda has updated the pull request incrementally with two additional commits since the last revision: >> >> - Some more get->orElseThrow >> - Reflecting review feedback. > > src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 429: > >> 427: Label next = element.next(); >> 428: cb.labelBinding(element.target()); >> 429: if (element.caseLabel() instanceof Class classLabel && > > I think you can do a if else of isPresent inside instanceof Class to avoid to reapeat the instanceof and store `classLabel.describeConstable()` into a local variable. Done, thanks. > src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 437: > >> 435: cb.aload(3); >> 436: cb.constantInstruction(extraClassLabels.size()); >> 437: cb.aaload(); > > Arrays are mutable in Java, so the VM can not know if the array of non denotable classes (`extraClassLabels`) will be changed or not so the result of aaload is not a constant so the call to isInstance can not be optimized. Using a immutable list (`List.of()`) instead of an array should work, because all the implementation of List.of() are using @Stable. In that case aaload becomes invokevirtual List.get(). Done, thanks. > src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 517: > >> 515: BiPredicate.class, >> 516: Class[].class)); >> 517: return MethodHandles.insertArguments(typeSwitch, 2, new ResolvedEnumLabels(caller, enumDescs.toArray(s -> new EnumDesc[s])), > > you can use the method reference `EnumDesc[]::new`instead of `s -> new EnumDesc[s]` and same below Class[]::new (the wirldcard should not be necessary) Done, thanks. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16489#discussion_r1381963834 PR Review Comment: https://git.openjdk.org/jdk/pull/16489#discussion_r1381963986 PR Review Comment: https://git.openjdk.org/jdk/pull/16489#discussion_r1381963719 From forax at openjdk.org Fri Nov 3 16:59:07 2023 From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax) Date: Fri, 3 Nov 2023 16:59:07 GMT Subject: RFR: 8319220: Pattern matching switch with a lot of cases is unduly slow [v3] In-Reply-To: References: Message-ID: On Fri, 3 Nov 2023 16:43:30 GMT, Jan Lahoda wrote: >> Consider code like: >> >> void test(Object o) { >> switch (o) { >> case X1 -> {} >> case X2 -> {} >> ...(about 100 cases) >> ``` >> >> javac will compile the switch into a switch whose selector is an indy invocation to `SwitchBootstraps.typeSwitch`, with static arguments being the types in the cases. >> >> `SwitchBootstraps.typeSwitch` will then create a chain of `MethodHandle`s performing `instanceof` checks between the switch's selector and the given case type. The problem is that when the number of cases is high enough, (more than ~40-50), the chain gets too long, and the tests won't inline anymore. This then leads to a very bad performance, when compared to manually written if-instanceof-else-if-instanceof- chain. >> >> The proposal herein is to use bytecode (written using the ClassFile API/library) instead of the `MethodHandle`s chain. The overall performance of this seems to be similar to the manually written if-instanceof-else-if-instanceof- chain. >> >> Using the benchmark from the bug, and this patch, I am getting: >> >> MyBenchmark.testIfElse100 thrpt 5 521826.326 ? 7510.042 ops/s >> MyBenchmark.testSwitch100 thrpt 5 505440.170 ? 3757.178 ops/s >> >> >> The most tricky part of this new way to generate the tests is handling of non-type case labels, and in particular cases with enum constant labels. The resolution of enum constants is deferred as much as possible, by using an indirection through the `ResolvedEnumLabels`. >> >> Further improvements may be possible, esp. for some specific cases (like all cases having a type, and the type being a final class). > > Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: > > Reflecting review feedback. Looks good to me :) src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 74: > 72: private static final MethodHandle MAPPED_ENUM_LOOKUP; > 73: > 74: private static final MethodTypeDesc typesSwitchDescriptor = Given that it's a static final, the name should be in uppercase, `TYPES_SWITCH_DESCRIPTOR` ------------- PR Comment: https://git.openjdk.org/jdk/pull/16489#issuecomment-1792807480 PR Review Comment: https://git.openjdk.org/jdk/pull/16489#discussion_r1381980130 From jlahoda at openjdk.org Fri Nov 3 17:22:18 2023 From: jlahoda at openjdk.org (Jan Lahoda) Date: Fri, 3 Nov 2023 17:22:18 GMT Subject: RFR: 8319220: Pattern matching switch with a lot of cases is unduly slow [v4] In-Reply-To: References: Message-ID: <4SvaqXe3eTyH1nSe6WIvQcIRvjk0VUDKapwtPY10-3Q=.cb0b6a2d-9cd0-49ae-b5bc-91171a038d70@github.com> > Consider code like: > > void test(Object o) { > switch (o) { > case X1 -> {} > case X2 -> {} > ...(about 100 cases) > ``` > > javac will compile the switch into a switch whose selector is an indy invocation to `SwitchBootstraps.typeSwitch`, with static arguments being the types in the cases. > > `SwitchBootstraps.typeSwitch` will then create a chain of `MethodHandle`s performing `instanceof` checks between the switch's selector and the given case type. The problem is that when the number of cases is high enough, (more than ~40-50), the chain gets too long, and the tests won't inline anymore. This then leads to a very bad performance, when compared to manually written if-instanceof-else-if-instanceof- chain. > > The proposal herein is to use bytecode (written using the ClassFile API/library) instead of the `MethodHandle`s chain. The overall performance of this seems to be similar to the manually written if-instanceof-else-if-instanceof- chain. > > Using the benchmark from the bug, and this patch, I am getting: > > MyBenchmark.testIfElse100 thrpt 5 521826.326 ? 7510.042 ops/s > MyBenchmark.testSwitch100 thrpt 5 505440.170 ? 3757.178 ops/s > > > The most tricky part of this new way to generate the tests is handling of non-type case labels, and in particular cases with enum constant labels. The resolution of enum constants is deferred as much as possible, by using an indirection through the `ResolvedEnumLabels`. > > Further improvements may be possible, esp. for some specific cases (like all cases having a type, and the type being a final class). Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: reflecting review comment: fixing letter case. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16489/files - new: https://git.openjdk.org/jdk/pull/16489/files/ff390e97..92f8517a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16489&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16489&range=02-03 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/16489.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16489/head:pull/16489 PR: https://git.openjdk.org/jdk/pull/16489 From jlu at openjdk.org Fri Nov 3 17:36:13 2023 From: jlu at openjdk.org (Justin Lu) Date: Fri, 3 Nov 2023 17:36:13 GMT Subject: Integrated: 8318466: Improve spec of NumberFormat's methods with unsupported operations In-Reply-To: References: Message-ID: On Wed, 1 Nov 2023 21:27:57 GMT, Justin Lu wrote: > Please review this simple change which refines the specification of some NumberFormat methods (with unsupported operations) to separate the API and implementation specification. This pull request has now been integrated. Changeset: ea6a88a0 Author: Justin Lu URL: https://git.openjdk.org/jdk/commit/ea6a88a0aa4e8a365a94e71078e67a4452f40945 Stats: 36 lines in 1 file changed: 9 ins; 11 del; 16 mod 8318466: Improve spec of NumberFormat's methods with unsupported operations Reviewed-by: naoto, iris ------------- PR: https://git.openjdk.org/jdk/pull/16464 From jvernee at openjdk.org Fri Nov 3 18:16:17 2023 From: jvernee at openjdk.org (Jorn Vernee) Date: Fri, 3 Nov 2023 18:16:17 GMT Subject: RFR: 8319316: Clarify text around which layouts a linker supports [v3] In-Reply-To: <59YZ3CcJ5Sfx40UWGpeCLk2Y4ThCocl48YIMEsC8_Qk=.900ebd34-73ed-46a7-aa4e-94f13249273d@github.com> References: <59YZ3CcJ5Sfx40UWGpeCLk2Y4ThCocl48YIMEsC8_Qk=.900ebd34-73ed-46a7-aa4e-94f13249273d@github.com> Message-ID: <_XYcFubf7GVQZ4lYLhXch2XFBKR7nVxJwZAXxWPHGTY=.4032095b-9a89-4090-b58a-51556c16bfd5@github.com> > - Add linker note about packed structs. > - Relax language a bit to avoid implying that only listed layouts are supported. Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: Add 'strict' Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com> ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16485/files - new: https://git.openjdk.org/jdk/pull/16485/files/fea8a263..b9770e0e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16485&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16485&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/16485.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16485/head:pull/16485 PR: https://git.openjdk.org/jdk/pull/16485 From mcimadamore at openjdk.org Fri Nov 3 18:16:20 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Fri, 3 Nov 2023 18:16:20 GMT Subject: RFR: 8319316: Clarify text around which layouts a linker supports [v2] In-Reply-To: <9K5jLL1imVvAoglzwYIubqIwp0xcCr_appJyUXJH-OU=.757c93fd-68a5-420e-9fcd-fc0da728438e@github.com> References: <59YZ3CcJ5Sfx40UWGpeCLk2Y4ThCocl48YIMEsC8_Qk=.900ebd34-73ed-46a7-aa4e-94f13249273d@github.com> <9K5jLL1imVvAoglzwYIubqIwp0xcCr_appJyUXJH-OU=.757c93fd-68a5-420e-9fcd-fc0da728438e@github.com> Message-ID: On Fri, 3 Nov 2023 16:35:18 GMT, Jorn Vernee wrote: >> - Add linker note about packed structs. >> - Relax language a bit to avoid implying that only listed layouts are supported. > > Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: > > add examples of packed structs src/java.base/share/classes/java/lang/foreign/Linker.java line 249: > 247: * Linker implementations may optionally support additional layouts, such as packed struct layouts. > 248: * A packed struct is a struct in which there is at least one member layout {@code L} that has an alignment > 249: * constraint less than its natural alignment. This allows avoiding padding between member layouts, Suggestion: * constraint less strict than its natural alignment. This allows avoiding padding between member layouts, ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16485#discussion_r1382060828 From mcimadamore at openjdk.org Fri Nov 3 18:22:02 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Fri, 3 Nov 2023 18:22:02 GMT Subject: RFR: 8319316: Clarify text around which layouts a linker supports [v3] In-Reply-To: <_XYcFubf7GVQZ4lYLhXch2XFBKR7nVxJwZAXxWPHGTY=.4032095b-9a89-4090-b58a-51556c16bfd5@github.com> References: <59YZ3CcJ5Sfx40UWGpeCLk2Y4ThCocl48YIMEsC8_Qk=.900ebd34-73ed-46a7-aa4e-94f13249273d@github.com> <_XYcFubf7GVQZ4lYLhXch2XFBKR7nVxJwZAXxWPHGTY=.4032095b-9a89-4090-b58a-51556c16bfd5@github.com> Message-ID: On Fri, 3 Nov 2023 18:16:17 GMT, Jorn Vernee wrote: >> - Add linker note about packed structs. >> - Relax language a bit to avoid implying that only listed layouts are supported. > > Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: > > Add 'strict' > > Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com> Marked as reviewed by mcimadamore (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/16485#pullrequestreview-1713318415 From simonis at openjdk.org Fri Nov 3 18:35:12 2023 From: simonis at openjdk.org (Volker Simonis) Date: Fri, 3 Nov 2023 18:35:12 GMT Subject: RFR: JDK-8319122: Improve documentation of various Zip-file related APIs In-Reply-To: <8vEqyECjMkTfesVmL3X0dN4Yu8JShPiUdsKpmEz1WV0=.1b541f77-a05f-490b-aaf1-f6b7456c6d77@github.com> References: <8vEqyECjMkTfesVmL3X0dN4Yu8JShPiUdsKpmEz1WV0=.1b541f77-a05f-490b-aaf1-f6b7456c6d77@github.com> Message-ID: <4Qn3IP1g-qcRgpk0l-bPN1-MIaMf-Zct6Fzg1AvzPQQ=.6646b6c2-197e-4cdd-bc18-05beb1da004f@github.com> On Mon, 30 Oct 2023 17:26:53 GMT, Yakov Shafranovich wrote: > The various Zip/Jar-file related Java APIs have some long-standing differences or peculiarities with respect to the ZIP-file specification or compared to other implementations which should be documented in the API-doc. This documents the following: > - Cache of JAR files in JarURLConnection class > - Cache of JAR/ZIP files in JarFile and ZipFile classes > - Unexpected behavior when parsing ZIP files with duplicate entries in JarFile and ZipFile classes, as well as the zipfs provider > - Directories and filenames with the same name considered to be the same in ZipFile class > - Possible issues when local and central headers conflict in ZipInputStream class > > Related JBS report: > https://bugs.openjdk.org/browse/JDK-8319122 @robilad, Yakov Shafranovich is covered by Amazon's comany-wide OCA. Can you please approve his OCA status? Thank you and best regards, Volker ------------- PR Comment: https://git.openjdk.org/jdk/pull/16424#issuecomment-1785759972 From duke at openjdk.org Fri Nov 3 18:35:11 2023 From: duke at openjdk.org (Yakov Shafranovich) Date: Fri, 3 Nov 2023 18:35:11 GMT Subject: RFR: JDK-8319122: Improve documentation of various Zip-file related APIs Message-ID: <8vEqyECjMkTfesVmL3X0dN4Yu8JShPiUdsKpmEz1WV0=.1b541f77-a05f-490b-aaf1-f6b7456c6d77@github.com> The various Zip/Jar-file related Java APIs have some long-standing differences or peculiarities with respect to the ZIP-file specification or compared to other implementations which should be documented in the API-doc. This documents the following: - Cache of JAR files in JarURLConnection class - Cache of JAR/ZIP files in JarFile and ZipFile classes - Unexpected behavior when parsing ZIP files with duplicate entries in JarFile and ZipFile classes, as well as the zipfs provider - Directories and filenames with the same name considered to be the same in ZipFile class - Possible issues when local and central headers conflict in ZipInputStream class Related JBS report: https://bugs.openjdk.org/browse/JDK-8319122 ------------- Commit messages: - document patch for JDK-8319122 Changes: https://git.openjdk.org/jdk/pull/16424/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16424&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8319122 Stats: 41 lines in 5 files changed: 38 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/16424.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16424/head:pull/16424 PR: https://git.openjdk.org/jdk/pull/16424 From erikj at openjdk.org Fri Nov 3 18:35:12 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Fri, 3 Nov 2023 18:35:12 GMT Subject: RFR: JDK-8319122: Improve documentation of various Zip-file related APIs In-Reply-To: <4Qn3IP1g-qcRgpk0l-bPN1-MIaMf-Zct6Fzg1AvzPQQ=.6646b6c2-197e-4cdd-bc18-05beb1da004f@github.com> References: <8vEqyECjMkTfesVmL3X0dN4Yu8JShPiUdsKpmEz1WV0=.1b541f77-a05f-490b-aaf1-f6b7456c6d77@github.com> <4Qn3IP1g-qcRgpk0l-bPN1-MIaMf-Zct6Fzg1AvzPQQ=.6646b6c2-197e-4cdd-bc18-05beb1da004f@github.com> Message-ID: On Mon, 30 Oct 2023 17:54:13 GMT, Volker Simonis wrote: >> The various Zip/Jar-file related Java APIs have some long-standing differences or peculiarities with respect to the ZIP-file specification or compared to other implementations which should be documented in the API-doc. This documents the following: >> - Cache of JAR files in JarURLConnection class >> - Cache of JAR/ZIP files in JarFile and ZipFile classes >> - Unexpected behavior when parsing ZIP files with duplicate entries in JarFile and ZipFile classes, as well as the zipfs provider >> - Directories and filenames with the same name considered to be the same in ZipFile class >> - Possible issues when local and central headers conflict in ZipInputStream class >> >> Related JBS report: >> https://bugs.openjdk.org/browse/JDK-8319122 > > @robilad, Yakov Shafranovich is covered by Amazon's comany-wide OCA. Can you please approve his OCA status? > > Thank you and best regards, > Volker @simonis Only the author of a PR can issue oca related commands. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16424#issuecomment-1791377895 From lancea at openjdk.org Fri Nov 3 18:47:05 2023 From: lancea at openjdk.org (Lance Andersen) Date: Fri, 3 Nov 2023 18:47:05 GMT Subject: RFR: 8303920: Avoid calling out to python in DataDescriptorSignatureMissing test [v9] In-Reply-To: References: Message-ID: <78Imgp5_LcnlmPoWrqUcE7DYnbnvTeB0r7yyF8O2THE=.2abd5fe3-02a8-4bf0-9f08-27d8664446e4@github.com> On Mon, 30 Oct 2023 17:48:48 GMT, Eirik Bjorsnos wrote: >> Please review this PR which brings the DataDescriptorSignatureMissing test back to life. >> >> This test currently calls out to Python to create a test vector ZIP with a Data Descriptor without the recommended but optional signature. The Python dependency has turned out to be very brittle, so the test is currently marked with `@ignore` >> >> The PR replaces Python callouts with directly creating the test vector ZIP in the test itself. We can then remove the `@ignore`tag and run this useful test automatically. > > Eirik Bjorsnos has updated the pull request incrementally with three additional commits since the last revision: > > - Describe the structure of Data Descriptors using an example > - Extend the comment of `makeZipWithSignaturelessDescriptor` with some background info on (signature-less) data descriptors, for the benefit of future maintainers. > - Convert test from testng to junit I think you are in a good place with the test clean up. Thanks for your efforts here I can kick of a test run internally next week or perhaps Sunday ------------- Marked as reviewed by lancea (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/12959#pullrequestreview-1713371131 From lancea at openjdk.org Fri Nov 3 18:47:07 2023 From: lancea at openjdk.org (Lance Andersen) Date: Fri, 3 Nov 2023 18:47:07 GMT Subject: RFR: 8303920: Avoid calling out to python in DataDescriptorSignatureMissing test [v8] In-Reply-To: References: <--iBU8TPNfvfxtOg2suRlEq1wFf55iFZCE_4N9hw9Ww=.52d201f9-89dc-441b-a260-53d5a8f49ef4@github.com> Message-ID: On Mon, 30 Oct 2023 17:57:23 GMT, Eirik Bjorsnos wrote: >> This way of updating the copyright was suggested by @jaikiran in the March 10th comment above. Would be nice to get this clarified, yes. > > There is actually very little left of Martin's code after my rewrite, besides whitespace, some curly braces and a couple of imports. Hardly defensible IP, but then I Am Not a Lawyer :-) I exchanged messages with Iris and she is comfortable with the updates to the copyright ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/12959#discussion_r1382103154 From rgiulietti at openjdk.org Fri Nov 3 19:14:18 2023 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Fri, 3 Nov 2023 19:14:18 GMT Subject: RFR: 8319174: Enhance robustness of some j.m.BigInteger constructors [v5] In-Reply-To: <0iccBwbAhAmIPGxnz1bhry2Sj_Kz2xngZmb2lPFCUpU=.c2b7c8ef-4e77-4c8f-a7ec-7c5c0980e59e@github.com> References: <0iccBwbAhAmIPGxnz1bhry2Sj_Kz2xngZmb2lPFCUpU=.c2b7c8ef-4e77-4c8f-a7ec-7c5c0980e59e@github.com> Message-ID: <8sscQFpSGhptxc9OJVvOAJHkV8U8j-_RmIMg-ZxZz-E=.9b651b5f-a894-45c9-9a59-16332c1cb69c@github.com> > Enhance `java.math.BigInteger` constructors taking a `byte[]` argument by improving guarantees of internal invariants. Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: Changed behavior on len == 0. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16449/files - new: https://git.openjdk.org/jdk/pull/16449/files/eafa99c1..57043db1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16449&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16449&range=03-04 Stats: 8 lines in 1 file changed: 5 ins; 1 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/16449.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16449/head:pull/16449 PR: https://git.openjdk.org/jdk/pull/16449 From rgiulietti at openjdk.org Fri Nov 3 19:17:04 2023 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Fri, 3 Nov 2023 19:17:04 GMT Subject: RFR: 8319174: Enhance robustness of some j.m.BigInteger constructors [v3] In-Reply-To: References: <0iccBwbAhAmIPGxnz1bhry2Sj_Kz2xngZmb2lPFCUpU=.c2b7c8ef-4e77-4c8f-a7ec-7c5c0980e59e@github.com> <5cQfuCE-3mwLfGSanw9OTraCquw3Oh3x5BuUPkXZu50=.c484f3da-ac91-40c0-a097-7979febcdc39@github.com> Message-ID: On Fri, 3 Nov 2023 09:01:48 GMT, Raffaello Giulietti wrote: >> src/java.base/share/classes/java/math/BigInteger.java line 344: >> >>> 342: * @param len the number of bytes to use. >>> 343: * @throws NumberFormatException {@code val} is zero bytes long, >>> 344: * or {@code len} is zero. >> >> I would be concerned about the compatibility impact on existing applications. >> Though (very) uncommon, an existing application be using a non-zero length array and a len of zero to represent zero. >> With this change it will throw an unexpected exception. > > A zero `len` is meant to indicate an empty range, whether the `val` array is empty or not. > So, from a logical perspective, both cases `val.length == 0` or `len == 0` should either both throw, or both should return `BigInteger` 0. > I choose the former, but the latter is a consistent choice as well. > > What I find unpleasant is the current behavior: it throws on `val.length == 0` (even if `len == 0`), but curiously returns 0 when it is non-zero and `len == 0`. I find this rather inconsistent. The `len == 0` -> 0 behavior has been recovered. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16449#discussion_r1382113596 From duke at openjdk.org Fri Nov 3 19:21:18 2023 From: duke at openjdk.org (duke) Date: Fri, 3 Nov 2023 19:21:18 GMT Subject: Withdrawn: 8311500: StackWalker.getCallerClass() throws UOE if invoked reflectively In-Reply-To: References: Message-ID: On Wed, 5 Jul 2023 11:45:59 GMT, Volker Simonis wrote: > As the included jtreg test demonstrates, `StackWalker.getCallerClass()` can throw an `UnsupportedOperationException` if called reflectively. Currently this only happens if we invoke `StackWalker.getCallerClass()` recursively reflectively, but this issue will become more prominent once we fix [JDK-8285447](https://bugs.openjdk.org/browse/JDK-8285447). The gory details follow below: > > The protocol between the Java API and the JVM for `StackWalker.getCallerClass()/walk()` is as follows: > - On the Java side, `StackWalker` calls into `StackStreamFactory` for the real work. > - For `StackWalker.getCallerClass()` `StackStreamFactory` basically creates a `Class[]` which will be passed down and filled in the JVM. For `StackWalker.walk()` it will normally be a `StackFrameInfo[]` (or a `LiveStackFrameInfo[]` if the internal `ExtendedOption.LOCALS_AND_OPERANDS` option was used). > - The default size of this arrays is currently `StackStreamFactory.SMALL_BATCH` which is 8 (but see [JDK-8285447](https://bugs.openjdk.org/browse/JDK-8285447)). > - `StackStreamFactory` than calls `AbstractStackWalker.callStackWalk()` which is a natively implemented in the VM by `JVM_CallStackWalk()`. > - `JVM_CallStackWalk()` calls `StackWalk::walk()` which calls `StackWalk::fetchFirstBatch()` which calls `StackWalk::fill_in_frames()` which walks the stack and fills in the available class/stackframe slots in the passed in array until the array is full or there are no more stack frames, > - Once `StackWalk::fill_in_frames()` returns, `StackWalk::fetchFirstBatch()` calls back to Java by invoking `AbstractStackWalker::doStackWalk()` to consume the result. > - `AbstractStackWalker::doStackWalk()` calls `consumeFrames()` (which is overridden depending on whether we initially called `getCallerClass()` or `walk()`) which consumes the frames until it either finishes (e.g. finds the caller class) or until there are no more frames. > - In the latter case `consumeFrames()` will call into the the VM again by calling `AbstractStackWalker.fetchStackFrames()` to fetch additional frames from the stack. > - `AbstractStackWalker.fetchStackFrames()` is implemented by `JVM_MoreStackWalk()` which calls `StackWalk::fetchNextBatch()` which calls `StackWalk::fill_in_frames()` (the same method that already fetched the initial batch of frames). > > Following is a stacktrace of what I've explained so far: > > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > V [libjvm.so+0x143a96a] StackWalk::fill_in_frames... This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/14773 From iris at openjdk.org Fri Nov 3 19:47:05 2023 From: iris at openjdk.org (Iris Clark) Date: Fri, 3 Nov 2023 19:47:05 GMT Subject: RFR: 8303920: Avoid calling out to python in DataDescriptorSignatureMissing test [v9] In-Reply-To: References: Message-ID: On Mon, 30 Oct 2023 17:48:48 GMT, Eirik Bjorsnos wrote: >> Please review this PR which brings the DataDescriptorSignatureMissing test back to life. >> >> This test currently calls out to Python to create a test vector ZIP with a Data Descriptor without the recommended but optional signature. The Python dependency has turned out to be very brittle, so the test is currently marked with `@ignore` >> >> The PR replaces Python callouts with directly creating the test vector ZIP in the test itself. We can then remove the `@ignore`tag and run this useful test automatically. > > Eirik Bjorsnos has updated the pull request incrementally with three additional commits since the last revision: > > - Describe the structure of Data Descriptors using an example > - Extend the comment of `makeZipWithSignaturelessDescriptor` with some background info on (signature-less) data descriptors, for the benefit of future maintainers. > - Convert test from testng to junit Marked as reviewed by iris (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/12959#pullrequestreview-1713426994 From duke at openjdk.org Fri Nov 3 20:16:34 2023 From: duke at openjdk.org (Eirik Bjorsnos) Date: Fri, 3 Nov 2023 20:16:34 GMT Subject: RFR: 8303920: Avoid calling out to python in DataDescriptorSignatureMissing test [v9] In-Reply-To: <78Imgp5_LcnlmPoWrqUcE7DYnbnvTeB0r7yyF8O2THE=.2abd5fe3-02a8-4bf0-9f08-27d8664446e4@github.com> References: <78Imgp5_LcnlmPoWrqUcE7DYnbnvTeB0r7yyF8O2THE=.2abd5fe3-02a8-4bf0-9f08-27d8664446e4@github.com> Message-ID: On Fri, 3 Nov 2023 18:43:31 GMT, Lance Andersen wrote: > I can kick of a test run internally next week or perhaps Sunday Thanks for your reviews, Lance and Iris! FWIW, the test ran fine on Github Actions, including on `linux-x86` (which is 32-bit, right?): TEST: java/util/zip/DataDescriptorSignatureMissing.java build: 0.081 seconds compile: 0.081 seconds junit: 0.055 seconds TEST RESULT: Passed. Execution successful https://github.com/eirbjo/jdk/actions/runs/6696663322/job/18196803138 ------------- PR Comment: https://git.openjdk.org/jdk/pull/12959#issuecomment-1793024736 From rriggs at openjdk.org Fri Nov 3 20:33:47 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 3 Nov 2023 20:33:47 GMT Subject: RFR: 8317742: ISO Standard Date Format implementation consistency on DateTimeFormatter and String.format [v3] In-Reply-To: References: Message-ID: On Mon, 16 Oct 2023 20:52:10 GMT, Shaojin Wen wrote: >> j.u.Formatter now prints "%tF" (iso standard date) and the result is incorrect when processing year < 0 or year > 9999 > > Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: > > fix typo Please separate out the change to be locale-independent from the fix for the original issue. The compatibility risk may have an unknown impact on existing applications and needs further consideration. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16033#issuecomment-1793059304 From jlu at openjdk.org Fri Nov 3 20:49:17 2023 From: jlu at openjdk.org (Justin Lu) Date: Fri, 3 Nov 2023 20:49:17 GMT Subject: RFR: 8319378: Spec for j.util.Timer::purge and j.util.Timer::cancel could be improved Message-ID: Please review this PR which clarifies the definition of a _cancelled_ task in _j.util.Timer::purge_ and _j.util.Timer::cancel_. Timer::purge claims that its return value is the number of tasks in the queue that were cancelled. This can be misleading, as a user can call Timer::cancel, thinking the rest of the tasks in the queue will be canceled (which should be the return value of Timer::purge). In actuality, Timer::cancel _discards_ all of the tasks in the queue. For a task to have been _cancelled_, the task itself must have called TimerTask::cancel. This change emphasizes the difference between _discarding_ and _cancelling_ a task. Additionally, this change also includes a drive-by update to use an _apiNote_ and _implNote_ tag in the class description. ------------- Commit messages: - init Changes: https://git.openjdk.org/jdk/pull/16503/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16503&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8319378 Stats: 21 lines in 1 file changed: 7 ins; 2 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/16503.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16503/head:pull/16503 PR: https://git.openjdk.org/jdk/pull/16503 From redestad at openjdk.org Fri Nov 3 21:01:45 2023 From: redestad at openjdk.org (Claes Redestad) Date: Fri, 3 Nov 2023 21:01:45 GMT Subject: RFR: 8319423: Improve Year.isLeap by checking divisibility by 16 Message-ID: https://github.com/cassioneri/eaf suggest this code for leap year calculation: public static boolean isLeap(long year) { int d = year % 100 != 0 ? 4 : 16; return (year & (d - 1)) == 0; } .. with a claim this would compile down to branchless, easily pipelined code. This doesn't currently happen with C2. In the meantime I think we can improve the current code in `Year.isLeap` and `IsoChronology.isLeapYear` by leveraging the fact that the `% 100` check is only needed if `(year & 15) != 0`: public static boolean isLeap(long year) { return (year & 15) == 0 ? (year & 3) == 0 : (year & 3) == 0 && year % 100 != 0; } Mac M1: Name Cnt Base Error Test Error Unit Change LeapYearBench.isLeapYear 15 0,743 ? 0,009 0,994 ? 0,005 ops/us 1,34x (p = 0,000*) LeapYearBench.isLeapYearChrono 15 0,748 ? 0,006 0,991 ? 0,003 ops/us 1,32x (p = 0,000*) LeapYearBench.isLeapYearNS 15 0,558 ? 0,026 0,552 ? 0,033 ops/us 0,99x (p = 0,602 ) * = significant Linux x64: Name Cnt Base Error Test Error Unit Change LeapYearBench.isLeapYear 15 0.534 ? 0.001 0.765 ? 0.004 ops/us 1.43x (p = 0.000*) LeapYearBench.isLeapYearChrono 15 0.535 ? 0.000 0.753 ? 0.040 ops/us 1.41x (p = 0.000*) LeapYearBench.isLeapYearNS 15 0.352 ? 0.000 0.351 ? 0.001 ops/us 1.00x (p = 0.000*) * = significant 30% higher throughput on M1, 40% on x64. `isLeapYearNS` runs a variant of the code from https://github.com/cassioneri/eaf ported to java - perhaps the JIT can be improved to do whatever clang/gcc does here and achieve an even better speed-up. Testing: so far only java/time/tck/java/time locally, will run a few tiers before filing an enhancement and opening the PR for review. ------------- Commit messages: - Add comment - Delegate IsoChronology.isLeapYear to Year.isLeap (both specified to behave identically), add microbenchmark testing the variant that optimize well with gcc - Merge branch 'master' into leapyear - Leap year optimization inspired by Neri & Schneider Changes: https://git.openjdk.org/jdk/pull/16491/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16491&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8319423 Stats: 101 lines in 3 files changed: 99 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/16491.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16491/head:pull/16491 PR: https://git.openjdk.org/jdk/pull/16491 From rriggs at openjdk.org Fri Nov 3 21:01:45 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 3 Nov 2023 21:01:45 GMT Subject: RFR: 8319423: Improve Year.isLeap by checking divisibility by 16 In-Reply-To: References: Message-ID: <9rkJo2eaipAf-s54hk34o_UxUkzjsKii21xn7L1sRj8=.9229dc7e-381f-4132-977e-2e13bf420d3a@github.com> On Fri, 3 Nov 2023 12:03:24 GMT, Claes Redestad wrote: > https://github.com/cassioneri/eaf suggest this code for leap year calculation: > > public static boolean isLeap(long year) { > int d = year % 100 != 0 ? 4 : 16; > return (year & (d - 1)) == 0; > } > > .. with a claim this would compile down to branchless, easily pipelined code. > > This doesn't currently happen with C2. In the meantime I think we can improve the current code in `Year.isLeap` and `IsoChronology.isLeapYear` by leveraging the fact that the `% 100` check is only needed if `(year & 15) != 0`: > > > public static boolean isLeap(long year) { > return (year & 15) == 0 ? (year & 3) == 0 : (year & 3) == 0 && year % 100 != 0; > } > > > Mac M1: > > Name Cnt Base Error Test Error Unit Change > LeapYearBench.isLeapYear 15 0,743 ? 0,009 0,994 ? 0,005 ops/us 1,34x (p = 0,000*) > LeapYearBench.isLeapYearChrono 15 0,748 ? 0,006 0,991 ? 0,003 ops/us 1,32x (p = 0,000*) > LeapYearBench.isLeapYearNS 15 0,558 ? 0,026 0,552 ? 0,033 ops/us 0,99x (p = 0,602 ) > * = significant > > > Linux x64: > > Name Cnt Base Error Test Error Unit Change > LeapYearBench.isLeapYear 15 0.534 ? 0.001 0.765 ? 0.004 ops/us 1.43x (p = 0.000*) > LeapYearBench.isLeapYearChrono 15 0.535 ? 0.000 0.753 ? 0.040 ops/us 1.41x (p = 0.000*) > LeapYearBench.isLeapYearNS 15 0.352 ? 0.000 0.351 ? 0.001 ops/us 1.00x (p = 0.000*) > * = significant > > > 30% higher throughput on M1, 40% on x64. `isLeapYearNS` runs a variant of the code from https://github.com/cassioneri/eaf ported to java - perhaps the JIT can be improved to do whatever clang/gcc does here and achieve an even better speed-up. > > Testing: so far only java/time/tck/java/time locally, will run a few tiers before filing an enhancement and opening the PR for review. Looks good. It probably needs a comment explaining why or a reference; otherwise it looks mysterious. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16491#issuecomment-1792984156 From sviswanathan at openjdk.org Fri Nov 3 21:27:14 2023 From: sviswanathan at openjdk.org (Sandhya Viswanathan) Date: Fri, 3 Nov 2023 21:27:14 GMT Subject: RFR: 8318650: Optimized subword gather for x86 targets. [v3] In-Reply-To: References: Message-ID: On Tue, 31 Oct 2023 07:19:55 GMT, Jatin Bhateja wrote: >> Hi All, >> >> This patch optimizes sub-word gather operation for x86 targets with AVX2 and AVX512 features. >> >> Following is the summary of changes:- >> >> 1) Intrinsify sub-word gather with high performance backend implementation based on hybrid algorithm which initially partially unrolls scalar loop to accumulates values from gather indices into a quadword(64bit) slice followed by vector permutation to place the slice into appropriate vector lanes, it prevents code bloating and generates compact >> JIT sequence. This coupled with savings from expansive array allocation in existing java implementation translates into significant performance of 1.3-5x gains with included micro. >> >> >> ![image](https://github.com/openjdk/jdk/assets/59989778/e25ba4ad-6a61-42fa-9566-452f741a9c6d) >> >> >> 2) Patch was also compared against modified java fallback implementation by replacing temporary array allocation with zero initialized vector and a scalar loops which inserts gathered values into vector. But, vector insert operation in higher vector lanes is a three step process which first extracts the upper vector 128 bit lane, updates it with gather subword value and then inserts the lane back to its original position. This makes inserts into higher order lanes costly w.r.t to proposed solution. In addition generated JIT code for modified fallback implementation was very bulky. This may impact in-lining decisions into caller contexts. >> >> 3) Some minor adjustments in existing gather instruction pattens for double/quad words. >> >> >> Kindly review and share your feedback. >> >> >> Best Regards, >> Jatin > > Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: > > Restricting masked sub-word gather to AVX512 target to align with integral gather support. src/hotspot/cpu/x86/assembler_x86.cpp line 13565: > 13563: void Assembler::bt(Register dst, Register src) { > 13564: int encode = prefixq_and_encode(src->encoding(), dst->encoding()); > 13565: emit_int24(0x0F, 0xA3, (encode | 0xC0)); (unsigned char)0xA3 would be better. src/hotspot/cpu/x86/x86.ad line 1921: > 1919: case Op_LoadVectorGatherMasked: > 1920: if (!is_subword_type(bt) && size_in_bits < 512 && !VM_Version::supports_avx512vl()) { > 1921: return false; Also need to return false when size_in_bits == 64 for non subword types. src/hotspot/cpu/x86/x86.ad line 1939: > 1937: // fallthrough > 1938: case Op_LoadVectorGather: > 1939: if (!is_subword_type(bt) && size_in_bits == 64 ) { Since this is a fallthrough case, the change also applies to StoreVectorScatter*. The !is_subword_type() is needed only for LoadVectorGather. src/hotspot/cpu/x86/x86.ad line 4074: > 4072: BasicType elem_bt = Matcher::vector_element_basic_type(this); > 4073: assert(!is_subword_type(elem_bt), "sanity"); // T_INT, T_LONG, T_FLOAT, T_DOUBLE > 4074: __ vpcmpeqd($mask$$XMMRegister, $mask$$XMMRegister, $mask$$XMMRegister, vlen_enc); vpcmpeqd is expensive instruction as compared to movdqu and also unrelated to subword type support. src/hotspot/share/opto/matcher.cpp line 2495: > 2493: n->del_req(MemNode::ValueIn+1); > 2494: break; > 2495: } The "break;" should be after the "}". src/hotspot/share/opto/vectorIntrinsics.cpp line 1507: > 1505: > 1506: // Check that the vector holding indices is supported by architecture > 1507: if (!is_subword_type(elem_bt) && !arch_supports_vector(Op_LoadVector, num_elem, T_INT, VecMaskNotUsed)) { A comment here would be good to indicate why we are not doing this check for subword type. Also as argument(8) is passed as null in this case so instead of checking !is_subword_type we could check for argument(8) to be not null. src/hotspot/share/opto/vectorIntrinsics.cpp line 1551: > 1549: Node* index_vect = nullptr; > 1550: const TypeInstPtr* vbox_idx_type = TypeInstPtr::make_exact(TypePtr::NotNull, vbox_idx_klass); > 1551: if (!is_subword_type(elem_bt)) { This could check for argument(8) to be not null instead. src/hotspot/share/opto/vectorIntrinsics.cpp line 1579: > 1577: Node* index = argument(11); > 1578: Node* indexMap = argument(12); > 1579: Node* indexM = argument(13); Could be renamed as follows for better understanding: index -> offset, indexM -> indexOffset. Also this should be moved under else part of if (is_scatter). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16354#discussion_r1382214927 PR Review Comment: https://git.openjdk.org/jdk/pull/16354#discussion_r1382184378 PR Review Comment: https://git.openjdk.org/jdk/pull/16354#discussion_r1382180358 PR Review Comment: https://git.openjdk.org/jdk/pull/16354#discussion_r1382188204 PR Review Comment: https://git.openjdk.org/jdk/pull/16354#discussion_r1382147380 PR Review Comment: https://git.openjdk.org/jdk/pull/16354#discussion_r1382152327 PR Review Comment: https://git.openjdk.org/jdk/pull/16354#discussion_r1382155655 PR Review Comment: https://git.openjdk.org/jdk/pull/16354#discussion_r1382168104 From naoto at openjdk.org Fri Nov 3 21:33:16 2023 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 3 Nov 2023 21:33:16 GMT Subject: RFR: 8319423: Improve Year.isLeap by checking divisibility by 16 In-Reply-To: References: Message-ID: On Fri, 3 Nov 2023 12:03:24 GMT, Claes Redestad wrote: > https://github.com/cassioneri/eaf suggest this code for leap year calculation: > > public static boolean isLeap(long year) { > int d = year % 100 != 0 ? 4 : 16; > return (year & (d - 1)) == 0; > } > > .. with a claim this would compile down to branchless, easily pipelined code. > > This doesn't currently happen with C2. In the meantime I think we can improve the current code in `Year.isLeap` and `IsoChronology.isLeapYear` by leveraging the fact that the `% 100` check is only needed if `(year & 15) != 0`: > > > public static boolean isLeap(long year) { > return (year & 15) == 0 ? (year & 3) == 0 : (year & 3) == 0 && year % 100 != 0; > } > > > Mac M1: > > Name Cnt Base Error Test Error Unit Change > LeapYearBench.isLeapYear 15 0,743 ? 0,009 0,994 ? 0,005 ops/us 1,34x (p = 0,000*) > LeapYearBench.isLeapYearChrono 15 0,748 ? 0,006 0,991 ? 0,003 ops/us 1,32x (p = 0,000*) > LeapYearBench.isLeapYearNS 15 0,558 ? 0,026 0,552 ? 0,033 ops/us 0,99x (p = 0,602 ) > * = significant > > > Linux x64: > > Name Cnt Base Error Test Error Unit Change > LeapYearBench.isLeapYear 15 0.534 ? 0.001 0.765 ? 0.004 ops/us 1.43x (p = 0.000*) > LeapYearBench.isLeapYearChrono 15 0.535 ? 0.000 0.753 ? 0.040 ops/us 1.41x (p = 0.000*) > LeapYearBench.isLeapYearNS 15 0.352 ? 0.000 0.351 ? 0.001 ops/us 1.00x (p = 0.000*) > * = significant > > > 30% higher throughput on M1, 40% on x64. `isLeapYearNS` runs a variant of the code from https://github.com/cassioneri/eaf ported to java - perhaps the JIT can be improved to do whatever clang/gcc does here and achieve an even better speed-up. > > Testing: so far only java/time/tck/java/time locally, will run a few tiers before filing an enhancement and opening the PR for review. LGTM. The logic can also apply to `GregorianCalendar.isLeapYear()`. ------------- Marked as reviewed by naoto (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16491#pullrequestreview-1713559141 From naoto at openjdk.org Fri Nov 3 21:34:11 2023 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 3 Nov 2023 21:34:11 GMT Subject: RFR: 8319378: Spec for j.util.Timer::purge and j.util.Timer::cancel could be improved In-Reply-To: References: Message-ID: <2mammvfWoHw3O1aIYCTEaQ4ubfdtF_YmWoNpjiADYf8=.6dd463fd-99d6-406c-9157-95dedc16784e@github.com> On Fri, 3 Nov 2023 20:40:11 GMT, Justin Lu wrote: > Please review this PR which clarifies the definition of a _cancelled_ task in _j.util.Timer::purge_ and _j.util.Timer::cancel_. > > Timer::purge claims that its return value is the number of tasks in the queue that were cancelled. This can be misleading, as a user can call Timer::cancel, thinking the rest of the tasks in the queue will be canceled (which should be the return value of Timer::purge). > > In actuality, Timer::cancel _discards_ all of the tasks in the queue. For a task to have been _cancelled_, the task itself must have called TimerTask::cancel. > > This change emphasizes the difference between _discarding_ and _cancelling_ a task. > Additionally, this change also includes a drive-by update to use an _apiNote_ and _implNote_ tag in the class description. LGTM ------------- Marked as reviewed by naoto (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16503#pullrequestreview-1713559821 From msheppar at openjdk.org Fri Nov 3 22:01:11 2023 From: msheppar at openjdk.org (Mark Sheppard) Date: Fri, 3 Nov 2023 22:01:11 GMT Subject: RFR: 8319200: Don't use test thread factory in ProcessTools.createLimitedTestJavaProcessBuilder() In-Reply-To: <3damdMQpRBrkUN2S32tBD0Tmrl2tmSqA31NniV8FzHU=.d3a36aa7-d5f4-4a63-b2ff-8b9b616a9637@github.com> References: <3damdMQpRBrkUN2S32tBD0Tmrl2tmSqA31NniV8FzHU=.d3a36aa7-d5f4-4a63-b2ff-8b9b616a9637@github.com> Message-ID: On Wed, 1 Nov 2023 00:06:35 GMT, Leonid Mesnik wrote: > Test thread factory is a mode similar to VM flags and should not be used in ProcessTools.createLimitedTestJavaProcessBuilder(). Only createTestJavaProcessBuilder() should use it like jtreg VM options. > > Adding the test thread factory requires the injection of arguments in the middle of the list. I don't think it makes sense to modify arguments in several places so I replaced it with the flag isLimited and moved all modifications in createJavaProcessBuilder(). > > Testing tier1-5. test/lib/jdk/test/lib/process/ProcessTools.java line 451: > 449: * @return The ProcessBuilder instance representing the java command. > 450: */ > 451: private static ProcessBuilder createJavaProcessBuilder(boolean isLimited, String... command) { addThreadFactory might be a more appropriate name However, Stefan has a more SOLID suggestion ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16442#discussion_r1382236083 From duke at openjdk.org Fri Nov 3 22:40:08 2023 From: duke at openjdk.org (Andriy Plokhotnyuk) Date: Fri, 3 Nov 2023 22:40:08 GMT Subject: RFR: 8319423: Improve Year.isLeap by checking divisibility by 16 In-Reply-To: References: Message-ID: <7sPh8yJBlQDNu8Zap4QJ0ZTbu8EEUeo5xFFZSxA7GV0=.f5ed3466-83d4-4f58-9727-46d35e640c73@github.com> On Fri, 3 Nov 2023 12:03:24 GMT, Claes Redestad wrote: > https://github.com/cassioneri/eaf suggest this code for leap year calculation: > > public static boolean isLeap(long year) { > int d = year % 100 != 0 ? 4 : 16; > return (year & (d - 1)) == 0; > } > > .. with a claim this would compile down to branchless, easily pipelined code. > > This doesn't currently happen with C2. In the meantime I think we can improve the current code in `Year.isLeap` and `IsoChronology.isLeapYear` by leveraging the fact that the `% 100` check is only needed if `(year & 15) != 0`: > > > public static boolean isLeap(long year) { > return (year & 15) == 0 ? (year & 3) == 0 : (year & 3) == 0 && year % 100 != 0; > } > > > Mac M1: > > Name Cnt Base Error Test Error Unit Change > LeapYearBench.isLeapYear 15 0,743 ? 0,009 0,994 ? 0,005 ops/us 1,34x (p = 0,000*) > LeapYearBench.isLeapYearChrono 15 0,748 ? 0,006 0,991 ? 0,003 ops/us 1,32x (p = 0,000*) > LeapYearBench.isLeapYearNS 15 0,558 ? 0,026 0,552 ? 0,033 ops/us 0,99x (p = 0,602 ) > * = significant > > > Linux x64: > > Name Cnt Base Error Test Error Unit Change > LeapYearBench.isLeapYear 15 0.534 ? 0.001 0.765 ? 0.004 ops/us 1.43x (p = 0.000*) > LeapYearBench.isLeapYearChrono 15 0.535 ? 0.000 0.753 ? 0.040 ops/us 1.41x (p = 0.000*) > LeapYearBench.isLeapYearNS 15 0.352 ? 0.000 0.351 ? 0.001 ops/us 1.00x (p = 0.000*) > * = significant > > > 30% higher throughput on M1, 40% on x64. `isLeapYearNS` runs a variant of the code from https://github.com/cassioneri/eaf ported to java - perhaps the JIT can be improved to do whatever clang/gcc does here and achieve an even better speed-up. > > Testing: so far only java/time/tck/java/time locally, will run a few tiers before filing an enhancement and opening the PR for review. @cl4es Could you please test [this](https://github.com/plokhotnyuk/jsoniter-scala/blob/ba6f4f80deaf0e7a1a95787321de3cc2a232d66d/jsoniter-scala-core/jvm/src/main/scala/com/github/plokhotnyuk/jsoniter_scala/core/JsonReader.scala#L3687) function too? It seems that when testing divisibility by 100 we can use just one multiplication operation. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16491#issuecomment-1793199019 From redestad at openjdk.org Fri Nov 3 23:22:27 2023 From: redestad at openjdk.org (Claes Redestad) Date: Fri, 3 Nov 2023 23:22:27 GMT Subject: RFR: 8319423: Improve Year.isLeap by checking divisibility by 16 [v2] In-Reply-To: References: Message-ID: > https://github.com/cassioneri/eaf suggest this code for leap year calculation: > > public static boolean isLeap(long year) { > int d = year % 100 != 0 ? 4 : 16; > return (year & (d - 1)) == 0; > } > > .. with a claim this would compile down to branchless, easily pipelined code. > > This doesn't currently happen with C2. In the meantime I think we can improve the current code in `Year.isLeap` and `IsoChronology.isLeapYear` by leveraging the fact that the `% 100` check is only needed if `(year & 15) != 0`: > > > public static boolean isLeap(long year) { > return (year & 15) == 0 ? (year & 3) == 0 : (year & 3) == 0 && year % 100 != 0; > } > > > Mac M1: > > Name Cnt Base Error Test Error Unit Change > LeapYearBench.isLeapYear 15 0,743 ? 0,009 0,994 ? 0,005 ops/us 1,34x (p = 0,000*) > LeapYearBench.isLeapYearChrono 15 0,748 ? 0,006 0,991 ? 0,003 ops/us 1,32x (p = 0,000*) > LeapYearBench.isLeapYearNS 15 0,558 ? 0,026 0,552 ? 0,033 ops/us 0,99x (p = 0,602 ) > * = significant > > > Linux x64: > > Name Cnt Base Error Test Error Unit Change > LeapYearBench.isLeapYear 15 0.534 ? 0.001 0.765 ? 0.004 ops/us 1.43x (p = 0.000*) > LeapYearBench.isLeapYearChrono 15 0.535 ? 0.000 0.753 ? 0.040 ops/us 1.41x (p = 0.000*) > LeapYearBench.isLeapYearNS 15 0.352 ? 0.000 0.351 ? 0.001 ops/us 1.00x (p = 0.000*) > * = significant > > > 30% higher throughput on M1, 40% on x64. `isLeapYearNS` runs a variant of the code from https://github.com/cassioneri/eaf ported to java - perhaps the JIT can be improved to do whatever clang/gcc does here and achieve an even better speed-up. > > Testing: so far only java/time/tck/java/time locally, will run a few tiers before filing an enhancement and opening the PR for review. Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: Apply similar optimization to GregorianCalendar, sun.util.calendar ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16491/files - new: https://git.openjdk.org/jdk/pull/16491/files/e4612018..6ad562cc Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16491&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16491&range=00-01 Stats: 24 lines in 4 files changed: 19 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/16491.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16491/head:pull/16491 PR: https://git.openjdk.org/jdk/pull/16491 From sviswanathan at openjdk.org Fri Nov 3 23:37:14 2023 From: sviswanathan at openjdk.org (Sandhya Viswanathan) Date: Fri, 3 Nov 2023 23:37:14 GMT Subject: RFR: 8318650: Optimized subword gather for x86 targets. [v3] In-Reply-To: References: Message-ID: On Tue, 31 Oct 2023 07:19:55 GMT, Jatin Bhateja wrote: >> Hi All, >> >> This patch optimizes sub-word gather operation for x86 targets with AVX2 and AVX512 features. >> >> Following is the summary of changes:- >> >> 1) Intrinsify sub-word gather with high performance backend implementation based on hybrid algorithm which initially partially unrolls scalar loop to accumulates values from gather indices into a quadword(64bit) slice followed by vector permutation to place the slice into appropriate vector lanes, it prevents code bloating and generates compact >> JIT sequence. This coupled with savings from expansive array allocation in existing java implementation translates into significant performance of 1.3-5x gains with included micro. >> >> >> ![image](https://github.com/openjdk/jdk/assets/59989778/e25ba4ad-6a61-42fa-9566-452f741a9c6d) >> >> >> 2) Patch was also compared against modified java fallback implementation by replacing temporary array allocation with zero initialized vector and a scalar loops which inserts gathered values into vector. But, vector insert operation in higher vector lanes is a three step process which first extracts the upper vector 128 bit lane, updates it with gather subword value and then inserts the lane back to its original position. This makes inserts into higher order lanes costly w.r.t to proposed solution. In addition generated JIT code for modified fallback implementation was very bulky. This may impact in-lining decisions into caller contexts. >> >> 3) Some minor adjustments in existing gather instruction pattens for double/quad words. >> >> >> Kindly review and share your feedback. >> >> >> Best Regards, >> Jatin > > Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: > > Restricting masked sub-word gather to AVX512 target to align with integral gather support. src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 1576: > 1574: Label* larr[] = { &case0, &case1, &case2, &case3, &case4, &case5, &case6, &case7 }; > 1575: for (int i = 0; i < 8; i++) { > 1576: bt(mask, midx); Could we not use smaller length bt and inc instructions (e.g. 32 bit one) here as we know that we dont need 64 bits of mask here? That way we will have smaller instruction encoding. src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 1606: > 1604: void C2_MacroAssembler::vpgather8b_offset(BasicType elem_bt, XMMRegister dst, Register base, Register idx_base, > 1605: Register offset, Register rtmp, int vlen_enc) { > 1606: vpxor(dst, dst, dst, vlen_enc); Why the vpxor here and in vpgather8b. These are not masked gathers. src/hotspot/cpu/x86/x86.ad line 4133: > 4131: %} > 4132: > 4133: instruct vgather_subwordGT8B(vec dst, memory mem, rRegP idx, immI_0 offset, rRegP tmp, rRegP idx_base_temp, We need to add rFlagsReg as being killed in many of these new instructs where implementation uses add instruction etc. src/hotspot/cpu/x86/x86.ad line 4152: > 4150: > 4151: instruct vgather_subwordLE8B_off(vec dst, memory mem, rRegP idx, rRegI offset, rRegP tmp, rRegI rtmp) %{ > 4152: predicate(is_subword_type(Matcher::vector_element_basic_type(n)) && Matcher::vector_length_in_bytes(n) <= 8); !VM_Version::supports_avx512bw() is missing for non avx3 cases. src/hotspot/cpu/x86/x86.ad line 4258: > 4256: __ kmovql($rtmp2$$Register, $mask$$KRegister); > 4257: __ vgather_subword(elem_bt, $dst$$XMMRegister, $tmp$$Register, $idx_base_temp$$Register, $offset$$Register, $rtmp2$$Register, $xtmp1$$XMMRegister, > 4258: $xtmp2$$XMMRegister, $xtmp3$$XMMRegister, $rtmp$$Register, $midx$$Register, $length$$Register, vector_len, vlen_enc); The naming vpgather vs vgather could be made consistent. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16354#discussion_r1382282928 PR Review Comment: https://git.openjdk.org/jdk/pull/16354#discussion_r1382278440 PR Review Comment: https://git.openjdk.org/jdk/pull/16354#discussion_r1382277389 PR Review Comment: https://git.openjdk.org/jdk/pull/16354#discussion_r1382270171 PR Review Comment: https://git.openjdk.org/jdk/pull/16354#discussion_r1382270783 From redestad at openjdk.org Fri Nov 3 23:37:14 2023 From: redestad at openjdk.org (Claes Redestad) Date: Fri, 3 Nov 2023 23:37:14 GMT Subject: RFR: 8319423: Improve Year.isLeap by checking divisibility by 16 In-Reply-To: <7sPh8yJBlQDNu8Zap4QJ0ZTbu8EEUeo5xFFZSxA7GV0=.f5ed3466-83d4-4f58-9727-46d35e640c73@github.com> References: <7sPh8yJBlQDNu8Zap4QJ0ZTbu8EEUeo5xFFZSxA7GV0=.f5ed3466-83d4-4f58-9727-46d35e640c73@github.com> Message-ID: On Fri, 3 Nov 2023 22:37:40 GMT, Andriy Plokhotnyuk wrote: > @cl4es Could you please test [this](https://github.com/plokhotnyuk/jsoniter-scala/blob/ba6f4f80deaf0e7a1a95787321de3cc2a232d66d/jsoniter-scala-core/jvm/src/main/scala/com/github/plokhotnyuk/jsoniter_scala/core/JsonReader.scala#L3687) function too? It seems that when testing divisibility by 100 we can use just one multiplication operation. For int values it seems that makes it a few percent faster (1,061 ? 0,017 ops/us), though we need a variant that works for longs (`GregorianCalendar` could use this as-is, but not `Year`). Do you have a reference to how they arrived at these numbers? It might be straightforward to extend it to long values, and it'd be good to have the theory to reference either way. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16491#issuecomment-1793241302 From liach at openjdk.org Fri Nov 3 23:44:08 2023 From: liach at openjdk.org (Chen Liang) Date: Fri, 3 Nov 2023 23:44:08 GMT Subject: RFR: 8294980: test/jdk/java/lang/invoke 15 test classes use experimental bytecode library [v2] In-Reply-To: References: <-JRa1cWErB4H5zW-TqhXXd1y3TchfIXPMinb-CJ4OUE=.96cb1861-cb27-4030-a8a0-f90df924f041@github.com> <4nlCKLh6pbazTpYjBzDvzC8cClZvgOHDtQ9VNNDjkiI=.c86cff2c-f7d8-456b-8d1a-5844b1321841@github.com> Message-ID: On Wed, 25 Oct 2023 12:36:40 GMT, Mourad Abbay wrote: >> test/jdk/java/lang/invoke/common/test/java/lang/invoke/lib/InstructionHelper.java line 71: >> >>> 69: for (int i = 0; i < type.parameterCount(); i++) { >>> 70: codeBuilder.loadInstruction(TypeKind.fromDescriptor( >>> 71: type.parameterType(i).descriptorString()), i); >> >> You can just use `TypeKind.from(type.parameterType(i))` > > I can't see such as method. It is declared as `public static TypeKind from(TypeDescriptor.OfField descriptor)` so that you can pass either `Class` or `ClassDesc` in. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16268#discussion_r1382289383 From liach at openjdk.org Fri Nov 3 23:53:06 2023 From: liach at openjdk.org (Chen Liang) Date: Fri, 3 Nov 2023 23:53:06 GMT Subject: RFR: 8318144: Match on enum constants with body compiles but fails with MatchException In-Reply-To: References: Message-ID: On Fri, 3 Nov 2023 16:26:49 GMT, Jan Lahoda wrote: > For code like: > > enum E {A {}, B {} } > Object o = E.A; > switch (o) { > case E.A -> System.err.println(o); > default -> System.err.println("default"); > } > > > The result is `default`, not `A`, due to incorrect classes being compared. Thanks for @liach for noting the solution here: > https://github.com/openjdk/jdk/pull/16489#discussion_r1381411165 Marked as reviewed by liach (Author). src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 399: > 397: Class clazz = label.constantType().resolveConstantDesc(lookup); > 398: > 399: if (!(value instanceof Enum enumValue) || Minor comment: If we are more concerned about performance when the enum is in a mix-and-match with other types (say primitives etc.), we can move the `instanceof` test before the `constantType().resolveConstantDesc()` to avoid a Class lookup. ------------- PR Review: https://git.openjdk.org/jdk/pull/16499#pullrequestreview-1713656471 PR Review Comment: https://git.openjdk.org/jdk/pull/16499#discussion_r1382291935 From liach at openjdk.org Sat Nov 4 00:14:17 2023 From: liach at openjdk.org (Chen Liang) Date: Sat, 4 Nov 2023 00:14:17 GMT Subject: RFR: 8311906: Race condition in String constructor In-Reply-To: References: Message-ID: <-QeIkq9XXU_tdY3nxpoIoWq1MoG-yEYuneoxxaoufA0=.1a161237-5889-408a-bf63-d0ae7302896b@github.com> 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. Closing in favor of #16425. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15902#issuecomment-1793259842 From liach at openjdk.org Sat Nov 4 00:14:18 2023 From: liach at openjdk.org (Chen Liang) Date: Sat, 4 Nov 2023 00:14:18 GMT Subject: Withdrawn: 8311906: Race condition in String constructor In-Reply-To: References: Message-ID: <6LEqP86EYeI3oRQ6q4kTcRJaGUmdN6E6a3G5Bgyq2oA=.67ff478a-6bf9-4c92-8341-9dfd754a04ce@github.com> 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. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/15902 From duke at openjdk.org Sat Nov 4 00:35:09 2023 From: duke at openjdk.org (Andriy Plokhotnyuk) Date: Sat, 4 Nov 2023 00:35:09 GMT Subject: RFR: 8319423: Improve Year.isLeap by checking divisibility by 16 In-Reply-To: References: <7sPh8yJBlQDNu8Zap4QJ0ZTbu8EEUeo5xFFZSxA7GV0=.f5ed3466-83d4-4f58-9727-46d35e640c73@github.com> Message-ID: <7BNLNtW7NZukTDS0n8M7HN8khMhRWn8iHMTGPmbSzAs=.c71facaa-c518-4b5e-8146-23d952512fcc@github.com> On Fri, 3 Nov 2023 23:34:49 GMT, Claes Redestad wrote: > > @cl4es Could you please test [this](https://github.com/plokhotnyuk/jsoniter-scala/blob/ba6f4f80deaf0e7a1a95787321de3cc2a232d66d/jsoniter-scala-core/jvm/src/main/scala/com/github/plokhotnyuk/jsoniter_scala/core/JsonReader.scala#L3687) function too? It seems that when testing divisibility by 100 we can use just one multiplication operation. > > For int values it seems that makes it a few percent faster (1,061 ? 0,017 ops/us), though we need a variant that works for longs (`GregorianCalendar` could use this as-is, but not `Year`). Do you have a reference to how they arrived at these numbers? It might be straightforward to extend it to long values, and it'd be good to have the theory to reference either way. Thanks for trying and giving the honest feedback! I don't recall exactly but it seems was a kind of playing with `bool f(int n) { return n % 100 == 0; }` on the https://godbolt.org to see assembly generated by latest c++ compilers with `-O3` option and then brute force squeezing a redundant shift operation. I'm not sure that similar is possible for `long` values, so probably it worth to have 2 different methods for `long` and `int` types. I'm even not sure if that function would work for negative `int` values. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16491#issuecomment-1793267652 From qamai at openjdk.org Sat Nov 4 04:50:12 2023 From: qamai at openjdk.org (Quan Anh Mai) Date: Sat, 4 Nov 2023 04:50:12 GMT Subject: RFR: 8319423: Improve Year.isLeap by checking divisibility by 16 [v2] In-Reply-To: References: Message-ID: <69FxOQAdsoxFlD8rScEqMUMxctv_H6t27NHA8SOZVd4=.453e9165-a523-40b5-bad5-f3b2d88a1ec0@github.com> On Fri, 3 Nov 2023 23:22:27 GMT, Claes Redestad wrote: >> https://github.com/cassioneri/eaf suggest this code for leap year calculation: >> >> public static boolean isLeap(long year) { >> int d = year % 100 != 0 ? 4 : 16; >> return (year & (d - 1)) == 0; >> } >> >> .. with a claim this would compile down to branchless, easily pipelined code. >> >> This doesn't currently happen with C2. In the meantime I think we can improve the current code in `Year.isLeap` and `IsoChronology.isLeapYear` by leveraging the fact that the `% 100` check is only needed if `(year & 15) != 0`: >> >> >> public static boolean isLeap(long year) { >> return (year & 15) == 0 ? (year & 3) == 0 : (year & 3) == 0 && year % 100 != 0; >> } >> >> >> Mac M1: >> >> Name Cnt Base Error Test Error Unit Change >> LeapYearBench.isLeapYear 15 0,743 ? 0,009 0,994 ? 0,005 ops/us 1,34x (p = 0,000*) >> LeapYearBench.isLeapYearChrono 15 0,748 ? 0,006 0,991 ? 0,003 ops/us 1,32x (p = 0,000*) >> LeapYearBench.isLeapYearNS 15 0,558 ? 0,026 0,552 ? 0,033 ops/us 0,99x (p = 0,602 ) >> * = significant >> >> >> Linux x64: >> >> Name Cnt Base Error Test Error Unit Change >> LeapYearBench.isLeapYear 15 0.534 ? 0.001 0.765 ? 0.004 ops/us 1.43x (p = 0.000*) >> LeapYearBench.isLeapYearChrono 15 0.535 ? 0.000 0.753 ? 0.040 ops/us 1.41x (p = 0.000*) >> LeapYearBench.isLeapYearNS 15 0.352 ? 0.000 0.351 ? 0.001 ops/us 1.00x (p = 0.000*) >> * = significant >> >> >> 30% higher throughput on M1, 40% on x64. `isLeapYearNS` runs a variant of the code from https://github.com/cassioneri/eaf ported to java - perhaps the JIT can be improved to do whatever clang/gcc does here and achieve an even better speed-up. >> >> Testing: so far only java/time/tck/java/time locally, will run a few tiers before filing an enhancement and opening the PR for review. > > Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: > > Apply similar optimization to GregorianCalendar, sun.util.calendar I believe [this](https://lemire.me/blog/2019/02/08/faster-remainders-when-the-divisor-is-a-constant-beating-compilers-and-libdivide/) is the theory, the formula there is not actually `(x % 100) == 0` but `(x % 25) == 0`. For `long` values, the formula for `(x % 25) == 0` would be `x * -8116567392432202711 + 368934881474191032 u< 737869762948382064`. As presented [here](https://godbolt.org/z/GG89eW4fs). ------------- PR Comment: https://git.openjdk.org/jdk/pull/16491#issuecomment-1793338604 From qamai at openjdk.org Sat Nov 4 05:01:08 2023 From: qamai at openjdk.org (Quan Anh Mai) Date: Sat, 4 Nov 2023 05:01:08 GMT Subject: RFR: 8319423: Improve Year.isLeap by checking divisibility by 16 [v2] In-Reply-To: References: Message-ID: On Fri, 3 Nov 2023 23:22:27 GMT, Claes Redestad wrote: >> https://github.com/cassioneri/eaf suggest this code for leap year calculation: >> >> public static boolean isLeap(long year) { >> int d = year % 100 != 0 ? 4 : 16; >> return (year & (d - 1)) == 0; >> } >> >> .. with a claim this would compile down to branchless, easily pipelined code. >> >> This doesn't currently happen with C2. In the meantime I think we can improve the current code in `Year.isLeap` and `IsoChronology.isLeapYear` by leveraging the fact that the `% 100` check is only needed if `(year & 15) != 0`: >> >> >> public static boolean isLeap(long year) { >> return (year & 15) == 0 ? (year & 3) == 0 : (year & 3) == 0 && year % 100 != 0; >> } >> >> >> Mac M1: >> >> Name Cnt Base Error Test Error Unit Change >> LeapYearBench.isLeapYear 15 0,743 ? 0,009 0,994 ? 0,005 ops/us 1,34x (p = 0,000*) >> LeapYearBench.isLeapYearChrono 15 0,748 ? 0,006 0,991 ? 0,003 ops/us 1,32x (p = 0,000*) >> LeapYearBench.isLeapYearNS 15 0,558 ? 0,026 0,552 ? 0,033 ops/us 0,99x (p = 0,602 ) >> * = significant >> >> >> Linux x64: >> >> Name Cnt Base Error Test Error Unit Change >> LeapYearBench.isLeapYear 15 0.534 ? 0.001 0.765 ? 0.004 ops/us 1.43x (p = 0.000*) >> LeapYearBench.isLeapYearChrono 15 0.535 ? 0.000 0.753 ? 0.040 ops/us 1.41x (p = 0.000*) >> LeapYearBench.isLeapYearNS 15 0.352 ? 0.000 0.351 ? 0.001 ops/us 1.00x (p = 0.000*) >> * = significant >> >> >> 30% higher throughput on M1, 40% on x64. `isLeapYearNS` runs a variant of the code from https://github.com/cassioneri/eaf ported to java - perhaps the JIT can be improved to do whatever clang/gcc does here and achieve an even better speed-up. >> >> Testing: so far only java/time/tck/java/time locally, will run a few tiers before filing an enhancement and opening the PR for review. > > Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: > > Apply similar optimization to GregorianCalendar, sun.util.calendar src/java.base/share/classes/java/time/Year.java line 321: > 319: // So for a year that's divisible by 4, checking that it's also divisible by 16 > 320: // is sufficient to determine it must be a leap year. > 321: return (year & 15) == 0 ? (year & 3) == 0 : (year & 3) == 0 && year % 100 != 0; I think `(year & 3) == 0 && ((year & 15) == 0) || (year % 25) != 0` would be better simply because the common path will be a little bit shorter. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16491#discussion_r1382334608 From alanb at openjdk.org Sat Nov 4 07:29:07 2023 From: alanb at openjdk.org (Alan Bateman) Date: Sat, 4 Nov 2023 07:29:07 GMT Subject: RFR: JDK-8319122: Improve documentation of various Zip-file related APIs In-Reply-To: <8vEqyECjMkTfesVmL3X0dN4Yu8JShPiUdsKpmEz1WV0=.1b541f77-a05f-490b-aaf1-f6b7456c6d77@github.com> References: <8vEqyECjMkTfesVmL3X0dN4Yu8JShPiUdsKpmEz1WV0=.1b541f77-a05f-490b-aaf1-f6b7456c6d77@github.com> Message-ID: On Mon, 30 Oct 2023 17:26:53 GMT, Yakov Shafranovich wrote: > The various Zip/Jar-file related Java APIs have some long-standing differences or peculiarities with respect to the ZIP-file specification or compared to other implementations which should be documented in the API-doc. This documents the following: > - Cache of JAR files in JarURLConnection class > - Cache of JAR/ZIP files in JarFile and ZipFile classes > - Unexpected behavior when parsing ZIP files with duplicate entries in JarFile and ZipFile classes, as well as the zipfs provider > - Directories and filenames with the same name considered to be the same in ZipFile class > - Possible issues when local and central headers conflict in ZipInputStream class > > Related JBS report: > https://bugs.openjdk.org/browse/JDK-8319122 @yakovsh I think this one will take a lot of effort from Reviewers. From a quick look, I think almost all of it is going to require significant editing/re-work. There are a few things that may require input from the security areas. There are issues with terminology and formatting too but they are easier to fix. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16424#issuecomment-1793369837 From alanb at openjdk.org Sat Nov 4 13:31:11 2023 From: alanb at openjdk.org (Alan Bateman) Date: Sat, 4 Nov 2023 13:31:11 GMT Subject: RFR: JDK-8315457 Implementation of String Templates (Second Preview) [v4] In-Reply-To: References: Message-ID: On Fri, 3 Nov 2023 15:29:25 GMT, Jim Laskey wrote: >> Update String Templates for a second preview. With the addition of >> >> - Expression type and throws are determined from the `process` method of the processor type and not the processor type. >> >> - Qualified `STR` and `RAW` are treated the same as unqualified `STR` and `RAW` . >> >> - Raw (generic) process types are no longer an error. > > Jim Laskey has updated the pull request with a new target base 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 remote-tracking branch 'upstream/master' into 8315457 > - Cache process method type in JCStringTemplate > - Revert source > - Revert @since 22 > - Accept qualified STR and RAW > - String Templates (second preview) Marked as reviewed by alanb (Reviewer). src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java line 424: > 422: * @since 21 > 423: */ > 424: @PreviewFeature(feature=PreviewFeature.Feature.STRING_TEMPLATES) I think you can drop both `@since` and `@PreviewFeature` from these methods. This in an internal interface, used for shared secrets, there is a lot of churn in JLA in each release. ------------- PR Review: https://git.openjdk.org/jdk/pull/16202#pullrequestreview-1713768565 PR Review Comment: https://git.openjdk.org/jdk/pull/16202#discussion_r1382392709 From alanb at openjdk.org Sat Nov 4 13:31:12 2023 From: alanb at openjdk.org (Alan Bateman) Date: Sat, 4 Nov 2023 13:31:12 GMT Subject: RFR: JDK-8315457 Implementation of String Templates (Second Preview) [v4] In-Reply-To: References: Message-ID: On Mon, 16 Oct 2023 14:31:46 GMT, Jim Laskey wrote: > Wasn't sure about that. Thx. When in doubt, JEP 12. Alex provided good guidance for API authors on how `@since` should be used with preview APIs. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16202#discussion_r1382392982 From redestad at openjdk.org Sat Nov 4 16:04:08 2023 From: redestad at openjdk.org (Claes Redestad) Date: Sat, 4 Nov 2023 16:04:08 GMT Subject: RFR: 8319423: Improve Year.isLeap by checking divisibility by 16 [v2] In-Reply-To: References: Message-ID: On Sat, 4 Nov 2023 04:57:11 GMT, Quan Anh Mai wrote: >> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: >> >> Apply similar optimization to GregorianCalendar, sun.util.calendar > > src/java.base/share/classes/java/time/Year.java line 321: > >> 319: // So for a year that's divisible by 4, checking that it's also divisible by 16 >> 320: // is sufficient to determine it must be a leap year. >> 321: return (year & 15) == 0 ? (year & 3) == 0 : (year & 3) == 0 && year % 100 != 0; > > I think `(year & 3) == 0 && ((year & 15) == 0) || (year % 25) != 0` would be better simply because the common path will be a little bit shorter. Benchmark Mode Cnt Score Error Units LeapYearBench.isLeapYear thrpt 15 0,735 ? 0,004 ops/us LeapYearBench.isLeapYearChrono thrpt 15 0,734 ? 0,006 ops/us So equal to or even slightly worse than baseline. I tested a few variants before submitting the PR - some that looked simpler or better - but the ternary variant in this PR always came out on top. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16491#discussion_r1382422589 From duke at openjdk.org Sat Nov 4 16:57:21 2023 From: duke at openjdk.org (duke) Date: Sat, 4 Nov 2023 16:57:21 GMT Subject: Withdrawn: 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: <94M8AbzuJyKRyLOrmYKW96r_lzRwV_P5Y8dGPDWLF00=.0d06306c-df90-479c-8d3d-d46ff5d8db7c@github.com> 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 This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/15308 From duke at openjdk.org Sat Nov 4 20:59:07 2023 From: duke at openjdk.org (Cassio Neri) Date: Sat, 4 Nov 2023 20:59:07 GMT Subject: RFR: 8319423: Improve Year.isLeap by checking divisibility by 16 [v2] In-Reply-To: References: Message-ID: <8DH1fENul54QDoQwh1dFeaaKPVkp3Ze3756O0XCJUyQ=.e8607dcc-8ce2-4466-b32e-02bb96ddaed6@github.com> On Fri, 3 Nov 2023 23:22:27 GMT, Claes Redestad wrote: >> https://github.com/cassioneri/eaf suggest this code for leap year calculation: >> >> public static boolean isLeap(long year) { >> int d = year % 100 != 0 ? 4 : 16; >> return (year & (d - 1)) == 0; >> } >> >> .. with a claim this would compile down to branchless, easily pipelined code. >> >> This doesn't currently happen with C2. In the meantime I think we can improve the current code in `Year.isLeap` and `IsoChronology.isLeapYear` by leveraging the fact that the `% 100` check is only needed if `(year & 15) != 0`: >> >> >> public static boolean isLeap(long year) { >> return (year & 15) == 0 ? (year & 3) == 0 : (year & 3) == 0 && year % 100 != 0; >> } >> >> >> Mac M1: >> >> Name Cnt Base Error Test Error Unit Change >> LeapYearBench.isLeapYear 15 0,743 ? 0,009 0,994 ? 0,005 ops/us 1,34x (p = 0,000*) >> LeapYearBench.isLeapYearChrono 15 0,748 ? 0,006 0,991 ? 0,003 ops/us 1,32x (p = 0,000*) >> LeapYearBench.isLeapYearNS 15 0,558 ? 0,026 0,552 ? 0,033 ops/us 0,99x (p = 0,602 ) >> * = significant >> >> >> Linux x64: >> >> Name Cnt Base Error Test Error Unit Change >> LeapYearBench.isLeapYear 15 0.534 ? 0.001 0.765 ? 0.004 ops/us 1.43x (p = 0.000*) >> LeapYearBench.isLeapYearChrono 15 0.535 ? 0.000 0.753 ? 0.040 ops/us 1.41x (p = 0.000*) >> LeapYearBench.isLeapYearNS 15 0.352 ? 0.000 0.351 ? 0.001 ops/us 1.00x (p = 0.000*) >> * = significant >> >> >> 30% higher throughput on M1, 40% on x64. `isLeapYearNS` runs a variant of the code from https://github.com/cassioneri/eaf ported to java - perhaps the JIT can be improved to do whatever clang/gcc does here and achieve an even better speed-up. >> >> Testing: so far only java/time/tck/java/time locally, will run a few tiers before filing an enhancement and opening the PR for review. > > Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: > > Apply similar optimization to GregorianCalendar, sun.util.calendar Thanks for your interest in my work. I'd love to assist porting our algorithms to Java. Notice, however, that I'm not a Java programmer and I don't have the complete picture of what goes on in the JVM. What follows is based on my experience with C/C++ compilers but, I reckon, most of it might apply to Java as well. When determining if `year` is leap or not it's very reasonable to believe that checking divisibility by 4 first is the best strategy. As I told in [my talk](https://www.youtube.com/watch?v=0s9F4QWAl-E), virtually every implementation that I found made that assumption. However, this is not the case thanks to modern branch predictors, at least for x86_64 CPUs. My experiments showed that checking divisibility by 100 first is the best way: if (year % 100 != 0) return year % 4 == 0; return year % 400 == 0; Maths results show that, in calculations of leap year, it's correct to replace `year % 400 == 0` by the cheaper expression `y % 16 == 0`. Except for [compiler bugs](https://bugs.llvm.org/show_bug.cgi?id=50334), this should always be done. Hence, the implementation that @cl4es mentioned: public static boolean isLeap(long year) { int d = year % 100 != 0 ? 4 : 16; return (year & (d - 1)) == 0; } In my talk I also said that I did other optimisations around `year % 100 == 0` but that was another story. Let me tell this story. Similar mathematical arguments as above show that it's also correct to replace `year % 100 == 0` with `year % 25 == 0` and [the latter requires one fewer assembly instruction](https://godbolt.org/z/zKza1Yc83). (I've also discussed this topic in a [PR](https://github.com/nakedible/datealgo-rs/discussions/21#discussioncomment-6907992) for the Rust implementation.) However, contrary to the case of 400-and-16, it's not always profitable to replace `year % 100 == 0` with `year % 25 == 0`. It depends on whether the code executed by the CPU contains branches or not. (Despite the usage of the ternary operator `?`, some CPUs support conditional moves which allow the elimination of some branches.) If there's no branch, then this is probably be the best option: public static boolean is_leap_v0(long year) { int d = year % 25 != 0 ? 4 : 16; return (year & (d - 1)) == 0; } If there's a branch, then I'd expect this to perform better: public static boolean is_leap_v0(long year) { int d = year % 100 != 0 ? 4 : 16; return (year & (d - 1)) == 0; } The reason is hinted in my talk: If there's a branch, the branch predictor can do a better job when execution is split into paths with (1/100, 99/100) = (1%, 99%) probability distribution than when the distribution is (1/25, 24/25) = (4%, 96%). [Looking at byte-code](https://godbolt.org/z/MEq9c5hef) for the 4 different implementations floated in this discussion, I see some `goto`s but I can't tell if, in assembly, they translate to branches or conditional moves. With more knowledgeable eyes, the [C versions](https://godbolt.org/z/xTGKh5x4h) of the same implementations suggest me that the branchless `is_leap_v0` is the best. But, I ask you, to not trust in my eyes or my intuition and, instead, measure the performance of the several alternatives. This old [SO post](https://stackoverflow.com/a/60646967/1137388) might also be helpful. I can also shed some light on the magical numbers that appear in the code that check divisibility by 100 and 25 by pointing to my series of article on this topic: * Quick Modular Calculations (Part 1) https://accu.org/journals/overload/27/154/overload154.pdf#page=13 * Quick Modular Calculations (Part 2) https://accu.org/journals/overload/28/155/overload155.pdf#page=16 * Quick Modular Calculations (Part 3) https://accu.org/journals/overload/28/156/overload156.pdf#page=12 I hope this helps. Cassio. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16491#issuecomment-1793544215 From duke at openjdk.org Sat Nov 4 21:38:08 2023 From: duke at openjdk.org (Cassio Neri) Date: Sat, 4 Nov 2023 21:38:08 GMT Subject: RFR: 8319423: Improve Year.isLeap by checking divisibility by 16 [v2] In-Reply-To: References: Message-ID: <9jCLKXIKTqhHn4PhJ_kBwrXWX-catwHmWxknBenrDQ0=.26b3f608-3402-4986-a22d-70083cff7331@github.com> On Sat, 4 Nov 2023 16:01:44 GMT, Claes Redestad wrote: >> src/java.base/share/classes/java/time/Year.java line 321: >> >>> 319: // So for a year that's divisible by 4, checking that it's also divisible by 16 >>> 320: // is sufficient to determine it must be a leap year. >>> 321: return (year & 15) == 0 ? (year & 3) == 0 : (year & 3) == 0 && year % 100 != 0; >> >> I think `(year & 3) == 0 && ((year & 15) == 0) || (year % 25) != 0` would be better simply because the common path will be a little bit shorter. > > Benchmark Mode Cnt Score Error Units > LeapYearBench.isLeapYear thrpt 15 0,735 ? 0,004 ops/us > LeapYearBench.isLeapYearChrono thrpt 15 0,734 ? 0,006 ops/us > > > So equal to or even slightly worse than baseline. I tested a few variants before submitting the PR - some that looked simpler or better - but the ternary variant in this PR always came out on top. On top of my general comments made earlier, let me give my two cents on this line: return (year & 15) == 0 ? (year & 3) == 0 : (year & 3) == 0 && year % 100 != 0; If `(year & 15) == 0`, then the last *four* bits of `year` are zeros. In particular, the last *two* bits of `year` are zeros, that is, `(year & 3) == 0`. The same conclusion can be obtained in terms of divisibility: if `year % 16 == 0`, i.e., `year` is a multiple of 16, then `year % 4 == 0`, i.e., `year` is multiple of 4. What I'm trying to say is that the line above can be simplified to: return (year & 15) == 0 ? true : (year & 3) == 0 && year % 100 != 0; But now it becomes clear that the above is also equivalent to: return (year & 15) == 0 || ((year & 3) == 0 && year % 100 != 0); Which is the simplest form of all the above. It's possible, but I'm not sure, that the Java compiler makes this simplification for you. (FWIW: the GCC C compiler does. Indeed, as seen [here](https://godbolt.org/z/P8sMv3Yno) the three expressions above generate exactly the same assembly instructions.) As I explained in my earlier post, for this particular expression a further simplification, that makes the compiler (at least the C compiler [above](https://godbolt.org/z/P8sMv3Yno)) to save one instruction (`ror edi 2`) is replacing 100 by 25: return (year & 15) == 0 || ((year & 3) == 0 && year % 25 != 0); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16491#discussion_r1382469177 From duke at openjdk.org Sat Nov 4 21:41:07 2023 From: duke at openjdk.org (Cassio Neri) Date: Sat, 4 Nov 2023 21:41:07 GMT Subject: RFR: 8319423: Improve Year.isLeap by checking divisibility by 16 [v2] In-Reply-To: References: Message-ID: <16Gxs0oCYpkazByvckBexYEpLZc_a8bDdmkY0AGKk8s=.642cfb29-b91e-4e98-aa3c-1c163e97ec2f@github.com> On Fri, 3 Nov 2023 23:22:27 GMT, Claes Redestad wrote: >> https://github.com/cassioneri/eaf suggest this code for leap year calculation: >> >> public static boolean isLeap(long year) { >> int d = year % 100 != 0 ? 4 : 16; >> return (year & (d - 1)) == 0; >> } >> >> .. with a claim this would compile down to branchless, easily pipelined code. >> >> This doesn't currently happen with C2. In the meantime I think we can improve the current code in `Year.isLeap` and `IsoChronology.isLeapYear` by leveraging the fact that the `% 100` check is only needed if `(year & 15) != 0`: >> >> >> public static boolean isLeap(long year) { >> return (year & 15) == 0 ? (year & 3) == 0 : (year & 3) == 0 && year % 100 != 0; >> } >> >> >> Mac M1: >> >> Name Cnt Base Error Test Error Unit Change >> LeapYearBench.isLeapYear 15 0,743 ? 0,009 0,994 ? 0,005 ops/us 1,34x (p = 0,000*) >> LeapYearBench.isLeapYearChrono 15 0,748 ? 0,006 0,991 ? 0,003 ops/us 1,32x (p = 0,000*) >> LeapYearBench.isLeapYearNS 15 0,558 ? 0,026 0,552 ? 0,033 ops/us 0,99x (p = 0,602 ) >> * = significant >> >> >> Linux x64: >> >> Name Cnt Base Error Test Error Unit Change >> LeapYearBench.isLeapYear 15 0.534 ? 0.001 0.765 ? 0.004 ops/us 1.43x (p = 0.000*) >> LeapYearBench.isLeapYearChrono 15 0.535 ? 0.000 0.753 ? 0.040 ops/us 1.41x (p = 0.000*) >> LeapYearBench.isLeapYearNS 15 0.352 ? 0.000 0.351 ? 0.001 ops/us 1.00x (p = 0.000*) >> * = significant >> >> >> 30% higher throughput on M1, 40% on x64. `isLeapYearNS` runs a variant of the code from https://github.com/cassioneri/eaf ported to java - perhaps the JIT can be improved to do whatever clang/gcc does here and achieve an even better speed-up. >> >> Testing: so far only java/time/tck/java/time locally, will run a few tiers before filing an enhancement and opening the PR for review. > > Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: > > Apply similar optimization to GregorianCalendar, sun.util.calendar src/java.base/share/classes/sun/util/calendar/CalendarUtils.java line 48: > 46: return (gregorianYear & 15) == 0 > 47: ? (gregorianYear & 3) == 0 > 48: : (gregorianYear & 3) == 0 && gregorianYear % 100 != 0; Similarly, Suggestion: return ((gregorianYear & 15) == 0) || ((gregorianYear & 3) == 0 && gregorianYear % 25 != 0); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16491#discussion_r1382469433 From jbhateja at openjdk.org Sun Nov 5 13:05:17 2023 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Sun, 5 Nov 2023 13:05:17 GMT Subject: RFR: 8318650: Optimized subword gather for x86 targets. [v4] In-Reply-To: References: Message-ID: > Hi All, > > This patch optimizes sub-word gather operation for x86 targets with AVX2 and AVX512 features. > > Following is the summary of changes:- > > 1) Intrinsify sub-word gather with high performance backend implementation based on hybrid algorithm which initially partially unrolls scalar loop to accumulates values from gather indices into a quadword(64bit) slice followed by vector permutation to place the slice into appropriate vector lanes, it prevents code bloating and generates compact > JIT sequence. This coupled with savings from expansive array allocation in existing java implementation translates into significant performance of 1.3-5x gains with included micro. > > > ![image](https://github.com/openjdk/jdk/assets/59989778/e25ba4ad-6a61-42fa-9566-452f741a9c6d) > > > 2) Patch was also compared against modified java fallback implementation by replacing temporary array allocation with zero initialized vector and a scalar loops which inserts gathered values into vector. But, vector insert operation in higher vector lanes is a three step process which first extracts the upper vector 128 bit lane, updates it with gather subword value and then inserts the lane back to its original position. This makes inserts into higher order lanes costly w.r.t to proposed solution. In addition generated JIT code for modified fallback implementation was very bulky. This may impact in-lining decisions into caller contexts. > > 3) Some minor adjustments in existing gather instruction pattens for double/quad words. > > > Kindly review and share your feedback. > > > Best Regards, > Jatin Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: Review comments resolutions. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16354/files - new: https://git.openjdk.org/jdk/pull/16354/files/86783403..67a60cd8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16354&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16354&range=02-03 Stats: 52 lines in 14 files changed: 4 ins; 12 del; 36 mod Patch: https://git.openjdk.org/jdk/pull/16354.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16354/head:pull/16354 PR: https://git.openjdk.org/jdk/pull/16354 From jbhateja at openjdk.org Sun Nov 5 13:05:23 2023 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Sun, 5 Nov 2023 13:05:23 GMT Subject: RFR: 8318650: Optimized subword gather for x86 targets. [v3] In-Reply-To: References: Message-ID: On Fri, 3 Nov 2023 23:07:44 GMT, Sandhya Viswanathan wrote: >> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: >> >> Restricting masked sub-word gather to AVX512 target to align with integral gather support. > > src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 1606: > >> 1604: void C2_MacroAssembler::vpgather8b_offset(BasicType elem_bt, XMMRegister dst, Register base, Register idx_base, >> 1605: Register offset, Register rtmp, int vlen_enc) { >> 1606: vpxor(dst, dst, dst, vlen_enc); > > Why the vpxor here and in vpgather8b. These are not masked gathers. This is to clear the vector gathering 8 subwords with each iteration. > src/hotspot/cpu/x86/x86.ad line 1921: > >> 1919: case Op_LoadVectorGatherMasked: >> 1920: if (!is_subword_type(bt) && size_in_bits < 512 && !VM_Version::supports_avx512vl()) { >> 1921: return false; > > Also need to return false when size_in_bits == 64 for non subword types. match_rule_supported_vector called in the beginning will enforce these checks. > src/hotspot/cpu/x86/x86.ad line 1939: > >> 1937: // fallthrough >> 1938: case Op_LoadVectorGather: >> 1939: if (!is_subword_type(bt) && size_in_bits == 64 ) { > > Since this is a fallthrough case, the change also applies to StoreVectorScatter*. The !is_subword_type() is needed only for LoadVectorGather. We do not intrinsify sub-word scatter operations currently. > src/hotspot/cpu/x86/x86.ad line 4074: > >> 4072: BasicType elem_bt = Matcher::vector_element_basic_type(this); >> 4073: assert(!is_subword_type(elem_bt), "sanity"); // T_INT, T_LONG, T_FLOAT, T_DOUBLE >> 4074: __ vpcmpeqd($mask$$XMMRegister, $mask$$XMMRegister, $mask$$XMMRegister, vlen_enc); > > vpcmpeqd is expensive instruction as compared to movdqu and also unrelated to subword type support. compare instruction here does not access a memory operand, hence its cheaper compared to memory loads. > src/hotspot/share/opto/vectorIntrinsics.cpp line 1579: > >> 1577: Node* index = argument(11); >> 1578: Node* indexMap = argument(12); >> 1579: Node* indexM = argument(13); > > Could be renamed as follows for better understanding: index -> offset, indexM -> indexOffset. Also this should be moved under else part of if (is_scatter). Naming scheme is based on the actual names used in intrinsic entry point for these arguments. > src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ByteVector.java line 3830: > >> 3828: // Check indices are within array bounds. >> 3829: // FIXME: Check index under mask controlling. >> 3830: for (int i = 0; i < vsp.length(); i += lsp.length()) { > > The check (i < vsp.length() ) could instead be (i + lsp.length() <= vsp.length()). Bit sizes of vector shape is multiple of 128 and we do not support NPOT sizes. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16354#discussion_r1382571225 PR Review Comment: https://git.openjdk.org/jdk/pull/16354#discussion_r1382571157 PR Review Comment: https://git.openjdk.org/jdk/pull/16354#discussion_r1382571152 PR Review Comment: https://git.openjdk.org/jdk/pull/16354#discussion_r1382571178 PR Review Comment: https://git.openjdk.org/jdk/pull/16354#discussion_r1382571683 PR Review Comment: https://git.openjdk.org/jdk/pull/16354#discussion_r1382571546 From jbhateja at openjdk.org Sun Nov 5 13:05:24 2023 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Sun, 5 Nov 2023 13:05:24 GMT Subject: RFR: 8318650: Optimized subword gather for x86 targets. [v3] In-Reply-To: References: Message-ID: On Sun, 5 Nov 2023 12:58:33 GMT, Jatin Bhateja wrote: >> src/hotspot/cpu/x86/x86.ad line 4074: >> >>> 4072: BasicType elem_bt = Matcher::vector_element_basic_type(this); >>> 4073: assert(!is_subword_type(elem_bt), "sanity"); // T_INT, T_LONG, T_FLOAT, T_DOUBLE >>> 4074: __ vpcmpeqd($mask$$XMMRegister, $mask$$XMMRegister, $mask$$XMMRegister, vlen_enc); >> >> vpcmpeqd is expensive instruction as compared to movdqu and also unrelated to subword type support. > > compare instruction here does not access a memory operand, hence its cheaper compared to memory loads. compare instruction here does not access a memory operand, hence its cheaper compared to memory loads. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16354#discussion_r1382571224 From jbhateja at openjdk.org Sun Nov 5 13:12:10 2023 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Sun, 5 Nov 2023 13:12:10 GMT Subject: RFR: 8318650: Optimized subword gather for x86 targets. [v3] In-Reply-To: References: Message-ID: <_TDPAokC-12bTyj19419ge8uQFFEZf3cPNgNNY8jFpI=.6a2de9f2-f278-49f2-949c-4d1bc31fc60f@github.com> On Fri, 3 Nov 2023 20:00:30 GMT, Sandhya Viswanathan wrote: >> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: >> >> Restricting masked sub-word gather to AVX512 target to align with integral gather support. > > src/hotspot/share/opto/matcher.cpp line 2495: > >> 2493: n->del_req(MemNode::ValueIn+1); >> 2494: break; >> 2495: } > > The "break;" should be after the "}". Its placed appropriately, we intend take fall-through path for non sub-word case. > src/hotspot/share/opto/vectorIntrinsics.cpp line 1551: > >> 1549: Node* index_vect = nullptr; >> 1550: const TypeInstPtr* vbox_idx_type = TypeInstPtr::make_exact(TypePtr::NotNull, vbox_idx_klass); >> 1551: if (!is_subword_type(elem_bt)) { > > This could check for argument(8) to be not null instead. Sub-word type check makes the intent more explicit. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16354#discussion_r1382572989 PR Review Comment: https://git.openjdk.org/jdk/pull/16354#discussion_r1382572622 From jbhateja at openjdk.org Sun Nov 5 13:17:13 2023 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Sun, 5 Nov 2023 13:17:13 GMT Subject: RFR: 8318650: Optimized subword gather for x86 targets. [v3] In-Reply-To: References: Message-ID: On Fri, 3 Nov 2023 23:20:49 GMT, Sandhya Viswanathan wrote: >> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: >> >> Restricting masked sub-word gather to AVX512 target to align with integral gather support. > > src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 1576: > >> 1574: Label* larr[] = { &case0, &case1, &case2, &case3, &case4, &case5, &case6, &case7 }; >> 1575: for (int i = 0; i < 8; i++) { >> 1576: bt(mask, midx); > > Could we not use smaller length bt and inc instructions (e.g. 32 bit one) here as we know that we dont need 64 bits of mask here? That way we will have smaller instruction encoding. I get your point it may save prefix byte for short vectors in one case, but REX2 may not be avoidable if allocator picks a register from higher register bank (r8-15), mask corresponding to Byte64 does need 64 bits. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16354#discussion_r1382573870 From jbhateja at openjdk.org Sun Nov 5 13:20:12 2023 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Sun, 5 Nov 2023 13:20:12 GMT Subject: RFR: 8318650: Optimized subword gather for x86 targets. [v3] In-Reply-To: <0Y-DxdTBq9CTvVXyYLQ9KpwU5ms0QdGrwanGkfUfmpQ=.ad118e8d-551f-430d-9040-a10b1366924d@github.com> References: <0Y-DxdTBq9CTvVXyYLQ9KpwU5ms0QdGrwanGkfUfmpQ=.ad118e8d-551f-430d-9040-a10b1366924d@github.com> Message-ID: On Fri, 3 Nov 2023 00:22:55 GMT, Sandhya Viswanathan wrote: >> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: >> >> Restricting masked sub-word gather to AVX512 target to align with integral gather support. > > src/hotspot/share/opto/vectornode.hpp line 886: > >> 884: init_class_id(Class_LoadVectorGather); >> 885: add_req(indices); >> 886: assert(req() == MemNode::ValueIn + 1, "match_edge expects that index input is in MemNode::ValueIn"); > > The assert message in "" is questionable. For subword types match_edge expects last input in MemNode::ValueIn+1. I think the assert needs to move in if/else below with correct message. Its placed appropriately before adding offset edge, I have added other assertion to check for offset. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16354#discussion_r1382574475 From jpai at openjdk.org Sun Nov 5 13:24:05 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Sun, 5 Nov 2023 13:24:05 GMT Subject: RFR: 8319378: Spec for j.util.Timer::purge and j.util.Timer::cancel could be improved In-Reply-To: References: Message-ID: On Fri, 3 Nov 2023 20:40:11 GMT, Justin Lu wrote: > Please review this PR which clarifies the definition of a _cancelled_ task in _j.util.Timer::purge_ and _j.util.Timer::cancel_. > > Timer::purge claims that its return value is the number of tasks in the queue that were cancelled. This can be misleading, as a user can call Timer::cancel, thinking the rest of the tasks in the queue will be canceled (which should be the return value of Timer::purge). > > In actuality, Timer::cancel _discards_ all of the tasks in the queue. For a task to have been _cancelled_, the task itself must have called TimerTask::cancel. > > This change emphasizes the difference between _discarding_ and _cancelling_ a task. > Additionally, this change also includes a drive-by update to use an _apiNote_ and _implNote_ tag in the class description. The proposed text looks good to me. ------------- Marked as reviewed by jpai (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16503#pullrequestreview-1713984867 From redestad at openjdk.org Sun Nov 5 22:18:09 2023 From: redestad at openjdk.org (Claes Redestad) Date: Sun, 5 Nov 2023 22:18:09 GMT Subject: RFR: 8319423: Improve Year.isLeap by checking divisibility by 16 [v2] In-Reply-To: <8DH1fENul54QDoQwh1dFeaaKPVkp3Ze3756O0XCJUyQ=.e8607dcc-8ce2-4466-b32e-02bb96ddaed6@github.com> References: <8DH1fENul54QDoQwh1dFeaaKPVkp3Ze3756O0XCJUyQ=.e8607dcc-8ce2-4466-b32e-02bb96ddaed6@github.com> Message-ID: On Sat, 4 Nov 2023 20:12:58 GMT, Cassio Neri wrote: >> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: >> >> Apply similar optimization to GregorianCalendar, sun.util.calendar > > Thanks for your interest in my work. I'd love to assist porting our algorithms to Java. Notice, however, that I'm not a Java programmer and I don't have the complete picture of what goes on in the JVM. What follows is based on my experience with C/C++ compilers but, I reckon, most of it might apply to Java as well. > > When determining if `year` is leap or not it's very reasonable to believe that checking divisibility by 4 first is the best strategy. As I told in [my talk](https://www.youtube.com/watch?v=0s9F4QWAl-E), virtually every implementation that I found made that assumption. However, this is not the case thanks to modern branch predictors, at least for x86_64 CPUs. My experiments showed that checking divisibility by 100 first is the best way: > > if (year % 100 != 0) > return year % 4 == 0; > return year % 400 == 0; > > Maths results show that, in calculations of leap year, it's correct to replace `year % 400 == 0` by the cheaper expression `y % 16 == 0`. Except for [compiler bugs](https://bugs.llvm.org/show_bug.cgi?id=50334), this should always be done. Hence, the implementation that @cl4es mentioned: > > public static boolean isLeap(long year) { > int d = year % 100 != 0 ? 4 : 16; > return (year & (d - 1)) == 0; > } > > In my talk I also said that I did other optimisations around `year % 100 == 0` but that was another story. Let me tell this story. > > Similar mathematical arguments as above show that it's also correct to replace `year % 100 == 0` with `year % 25 == 0` and [the latter requires one fewer assembly instruction](https://godbolt.org/z/zKza1Yc83). (I've also discussed this topic in a [PR](https://github.com/nakedible/datealgo-rs/discussions/21#discussioncomment-6907992) for the Rust implementation.) However, contrary to the case of 400-and-16, it's not always profitable to replace `year % 100 == 0` with `year % 25 == 0`. It depends on whether the code executed by the CPU contains branches or not. (Despite the usage of the ternary operator `?`, some CPUs support conditional moves which allow the elimination of some branches.) > > If there's no branch, then this is probably be the best option: > > public static boolean is_leap_v0(long year) { > int d = year % 25 != 0 ? 4 : 16; > return (year & (d - 1)) == 0; > } > > > If there's a branch, then I'd expect this to perform better: > > public static boolean is_leap_v0(long year) { > int d = year % 100 != 0 ? 4 : 16; > return (year & (d - 1)) == 0; > } > > The reason is... Thank you for your comments, @cassioneri For reference I included the following variant in the `isLeapYearNS` microbenchmark: int d = year % 100 != 0 ? 4 : 16; return (year & (d - 1)) == 0; and as shown above this underperforms even the baseline implementation when executed on the HotSpot JVM with C2: `0,558 ? 0,026 ops/us` vs `0,743 ? 0,009` for the baseline implementation. My experiments then explored how we could trick the C2 JIT to improve over the baseline, and the patch suggested in this PR is what I ended up with. This might suggest a deficiency in the C2 JIT rather than an issue with your code. But let's dig a bit deeper and analyze the ASM generated on x86. With `isLeapYearNS` we seem to generate something like this for the actual calculation: ... 0.88% ? ??? ?????? 0x00007f603062d39c: movabs $0xa3d70a3d70a3d70b,%rax 1.47% ? ??? ?????? 0x00007f603062d3a6: imul %rbp 1.29% ? ??? ?????? 0x00007f603062d3a9: add %rbp,%rdx 1.23% ? ??? ?????? 0x00007f603062d3ac: mov %rbp,%rcx 0.41% ? ??? ?????? 0x00007f603062d3af: sar $0x3f,%rcx 0.43% ? ??? ?????? 0x00007f603062d3b3: sar $0x6,%rdx 1.63% ? ??? ?????? 0x00007f603062d3b7: sub %rcx,%rdx 2.70% ? ??? ?????? 0x00007f603062d3ba: imul $0x64,%rdx,%rcx 9.91% ? ??? ?????? 0x00007f603062d3be: sub %rcx,%rbp ... .. so, some sequence of multiplications, shifts and subtractions, not dissimilar to the code you'd expect from Lemire's calculus. Testing the PR under test then the inner calculation becomes... exactly the same? 0.70% ? ??? ?????? 0x00007f8fe062ad1c: movabs $0xa3d70a3d70a3d70b,%rax 1.37% ? ??? ?????? 0x00007f8fe062ad26: imul %rbp 2.03% ? ??? ?????? 0x00007f8fe062ad29: add %rbp,%rdx 1.80% ? ??? ?????? 0x00007f8fe062ad2c: mov %rbp,%rcx 0.59% ? ??? ?????? 0x00007f8fe062ad2f: sar $0x3f,%rcx 0.66% ? ??? ?????? 0x00007f8fe062ad33: sar $0x6,%rdx 1.66% ? ??? ?????? 0x00007f8fe062ad37: sub %rcx,%rdx 2.27% ? ??? ?????? 0x00007f8fe062ad3a: imul $0x64,%rdx,%rcx 10.05% ? ??? ?????? 0x00007f8fe062ad3e: sub %rcx,%rbp Yet faster... The difference seem to boil down to how the JIT is better able to unroll and vectorize the benchmark loop with my PR'd code. While not an irrelevant property, this means the improvement I'm seeing might be a bit overstated for more typical cases, and I'll need to see if what happens if I set the microbenchmark up not to inline and unroll heavily. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16491#issuecomment-1793862266 From duke at openjdk.org Sun Nov 5 23:36:07 2023 From: duke at openjdk.org (Cassio Neri) Date: Sun, 5 Nov 2023 23:36:07 GMT Subject: RFR: 8319423: Improve Year.isLeap by checking divisibility by 16 [v2] In-Reply-To: References: <8DH1fENul54QDoQwh1dFeaaKPVkp3Ze3756O0XCJUyQ=.e8607dcc-8ce2-4466-b32e-02bb96ddaed6@github.com> Message-ID: On Sun, 5 Nov 2023 22:14:50 GMT, Claes Redestad wrote: >> Thanks for your interest in my work. I'd love to assist porting our algorithms to Java. Notice, however, that I'm not a Java programmer and I don't have the complete picture of what goes on in the JVM. What follows is based on my experience with C/C++ compilers but, I reckon, most of it might apply to Java as well. >> >> When determining if `year` is leap or not it's very reasonable to believe that checking divisibility by 4 first is the best strategy. As I told in [my talk](https://www.youtube.com/watch?v=0s9F4QWAl-E), virtually every implementation that I found made that assumption. However, this is not the case thanks to modern branch predictors, at least for x86_64 CPUs. My experiments showed that checking divisibility by 100 first is the best way: >> >> if (year % 100 != 0) >> return year % 4 == 0; >> return year % 400 == 0; >> >> Maths results show that, in calculations of leap year, it's correct to replace `year % 400 == 0` by the cheaper expression `y % 16 == 0`. Except for [compiler bugs](https://bugs.llvm.org/show_bug.cgi?id=50334), this should always be done. Hence, the implementation that @cl4es mentioned: >> >> public static boolean isLeap(long year) { >> int d = year % 100 != 0 ? 4 : 16; >> return (year & (d - 1)) == 0; >> } >> >> In my talk I also said that I did other optimisations around `year % 100 == 0` but that was another story. Let me tell this story. >> >> Similar mathematical arguments as above show that it's also correct to replace `year % 100 == 0` with `year % 25 == 0` and [the latter requires one fewer assembly instruction](https://godbolt.org/z/zKza1Yc83). (I've also discussed this topic in a [PR](https://github.com/nakedible/datealgo-rs/discussions/21#discussioncomment-6907992) for the Rust implementation.) However, contrary to the case of 400-and-16, it's not always profitable to replace `year % 100 == 0` with `year % 25 == 0`. It depends on whether the code executed by the CPU contains branches or not. (Despite the usage of the ternary operator `?`, some CPUs support conditional moves which allow the elimination of some branches.) >> >> If there's no branch, then this is probably be the best option: >> >> public static boolean is_leap_v0(long year) { >> int d = year % 25 != 0 ? 4 : 16; >> return (year & (d - 1)) == 0; >> } >> >> >> If there's a branch, then I'd expect this to perform better: >> >> public static boolean is_leap_v0(long year) { >> int d = year % 100 != 0 ? 4 ... > > Thank you for your comments, @cassioneri > > For reference I included the following variant in the `isLeapYearNS` microbenchmark: > > int d = year % 100 != 0 ? 4 : 16; > return (year & (d - 1)) == 0; > > and as shown above this underperforms even the baseline implementation when executed on the HotSpot JVM with C2: `0,558 ? 0,026 ops/us` vs `0,743 ? 0,009` for the baseline implementation. My experiments then explored how we could trick the C2 JIT to improve over the baseline, and the patch suggested in this PR is what I ended up with. > > This might suggest a deficiency in the C2 JIT rather than an issue with your code. But let's dig a bit deeper and analyze the ASM generated on x86. > > With `isLeapYearNS` we seem to generate something like this for the actual calculation: > > ... > 0.88% ? ??? ?????? 0x00007f603062d39c: movabs $0xa3d70a3d70a3d70b,%rax > 1.47% ? ??? ?????? 0x00007f603062d3a6: imul %rbp > 1.29% ? ??? ?????? 0x00007f603062d3a9: add %rbp,%rdx > 1.23% ? ??? ?????? 0x00007f603062d3ac: mov %rbp,%rcx > 0.41% ? ??? ?????? 0x00007f603062d3af: sar $0x3f,%rcx > 0.43% ? ??? ?????? 0x00007f603062d3b3: sar $0x6,%rdx > 1.63% ? ??? ?????? 0x00007f603062d3b7: sub %rcx,%rdx > 2.70% ? ??? ?????? 0x00007f603062d3ba: imul $0x64,%rdx,%rcx > 9.91% ? ??? ?????? 0x00007f603062d3be: sub %rcx,%rbp > ... > > .. so, some sequence of multiplications, shifts and subtractions, not dissimilar to the code you'd expect from Lemire's calculus. > > Testing the PR under test then the inner calculation becomes... exactly the same? > > 0.70% ? ??? ?????? 0x00007f8fe062ad1c: movabs $0xa3d70a3d70a3d70b,%rax > 1.37% ? ??? ?????? 0x00007f8fe062ad26: imul %rbp > 2.03% ? ??? ?????? 0x00007f8fe062ad29: add %rbp,%rdx > 1.80% ? ??? ?????? 0x00007f8fe062ad2c: mov %rbp,%rcx > 0.59% ? ??? ?????? 0x00007f8fe062ad2f: sar $0x3f,%rcx > 0.66% ? ??? ?????? 0x00007f8fe062ad33: sar $0x6,%rdx > 1.66% ? ??? ?????? 0x00007f8fe062ad37: sub %rcx,%rdx > 2.27% ? ??? ?????? 0x00007f8fe062ad3a: imul $0x64,%rdx,%rcx > 10.05% ? ??? ?????? 0x00007f8fe062ad3e: sub %rcx,%rbp > > > Yet faster... The difference seem to boil down to how the JIT is better able to unroll and vectorize the benchmark loop with my PR'd code. While not an irrelevant property, this means the improvement I'm seeing might be a bit overstated for more typical cases, and I'll need t... Thanks @cl4es for the ASM listing. Now I can understand better what is going on at the very low level. The compiler is replacing `y % 100 == 0` with `y == 100 * (y / 100)` and is using the traditional Granlund-Montgomery (GM) optimisation for the quotient `q = y / 100`, that is, `q` is obtained as `(y * M) >> 70` where `M = ceil(2^70/100)`. This is confirmed by the appearance of the hex constant `0xa3d70a3d70a3d70b` (this is `M`) and the two `imul` instructions (`y * M` and `100 * q`). (This is not Daniel Lemire's technique but related.) There's a more recent technique that can give `y % 100 == 0` with just one multiplication (again, it's not Daniel Lemire's) which gcc started using in v9. See the difference [here](https://godbolt.org/z/48YP1Ynv4). This is what I called "minverse" in my first article on quick modular calculations (previously referred). I think it would be very useful if the Java compiler also implemented this technique. Not only for this piece of code but for any time that `n % d == 0` with constant `d` appears in source code. For this particular piece of code though, one could manually perform the minverse optimisation. Recall from my previous posts that in leap year calculation, one can replace `100` by `25`. This is helpful since, as seen in the link above, the latter doesn't need the `ror` instruction (which doesn't have an equivalent in C/C++ and, I suppose, Java.) Hence, `y % 100 == 0` can be replace by `y % 25 == 0` which, in turn, can be replaced by (y * 0x8F5C28F5C28F5C29 + 0x51EB851EB851EB8) < 0xA3D70A3D70A3D70. (I'm deducing this code from the godbolt link and I hope I got it right but, if you're interested I can double check another time.) It's **very important** for the calculations above to be done in unsigned arithmetic. I don't know how this is done in Java but, FWIW, in C it would be: (((uint64_t) y) * 0x8F5C28F5C28F5C29ull + 0x51EB851EB851EB8ull) < 0xA3D70A3D70A3D70ull; ------------- PR Comment: https://git.openjdk.org/jdk/pull/16491#issuecomment-1793882054 From redestad at openjdk.org Mon Nov 6 00:53:09 2023 From: redestad at openjdk.org (Claes Redestad) Date: Mon, 6 Nov 2023 00:53:09 GMT Subject: RFR: 8319423: Improve Year.isLeap by checking divisibility by 16 [v2] In-Reply-To: References: Message-ID: On Fri, 3 Nov 2023 23:22:27 GMT, Claes Redestad wrote: >> https://github.com/cassioneri/eaf suggest this code for leap year calculation: >> >> public static boolean isLeap(long year) { >> int d = year % 100 != 0 ? 4 : 16; >> return (year & (d - 1)) == 0; >> } >> >> .. with a claim this would compile down to branchless, easily pipelined code. >> >> This doesn't currently happen with C2. In the meantime I think we can improve the current code in `Year.isLeap` and `IsoChronology.isLeapYear` by leveraging the fact that the `% 100` check is only needed if `(year & 15) != 0`: >> >> >> public static boolean isLeap(long year) { >> return (year & 15) == 0 ? (year & 3) == 0 : (year & 3) == 0 && year % 100 != 0; >> } >> >> >> Mac M1: >> >> Name Cnt Base Error Test Error Unit Change >> LeapYearBench.isLeapYear 15 0,743 ? 0,009 0,994 ? 0,005 ops/us 1,34x (p = 0,000*) >> LeapYearBench.isLeapYearChrono 15 0,748 ? 0,006 0,991 ? 0,003 ops/us 1,32x (p = 0,000*) >> LeapYearBench.isLeapYearNS 15 0,558 ? 0,026 0,552 ? 0,033 ops/us 0,99x (p = 0,602 ) >> * = significant >> >> >> Linux x64: >> >> Name Cnt Base Error Test Error Unit Change >> LeapYearBench.isLeapYear 15 0.534 ? 0.001 0.765 ? 0.004 ops/us 1.43x (p = 0.000*) >> LeapYearBench.isLeapYearChrono 15 0.535 ? 0.000 0.753 ? 0.040 ops/us 1.41x (p = 0.000*) >> LeapYearBench.isLeapYearNS 15 0.352 ? 0.000 0.351 ? 0.001 ops/us 1.00x (p = 0.000*) >> * = significant >> >> >> 30% higher throughput on M1, 40% on x64. `isLeapYearNS` runs a variant of the code from https://github.com/cassioneri/eaf ported to java - perhaps the JIT can be improved to do whatever clang/gcc does here and achieve an even better speed-up. >> >> Testing: so far only java/time/tck/java/time locally, will run a few tiers before filing an enhancement and opening the PR for review. > > Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: > > Apply similar optimization to GregorianCalendar, sun.util.calendar Yes, seems Granlund & Montgomery is used, see https://github.com/openjdk/jdk/blob/01c0d5dd0a4f7587288219bad8ed4648f4e456ce/src/hotspot/share/opto/divnode.cpp#L161 I explored some more with micros that don't loop over different values but instead test all the year variants of interest in isolation: Benchmark (year) Mode Cnt Score Error Units LeapYearBench.Single.isLeapYear 2000 avgt 15 0,590 ? 0,053 ns/op LeapYearBench.Single.isLeapYear 2017 avgt 15 0,586 ? 0,030 ns/op LeapYearBench.Single.isLeapYear 2004 avgt 15 0,936 ? 0,002 ns/op LeapYearBench.Single.isLeapYear 2100 avgt 15 0,937 ? 0,002 ns/op LeapYearBench.Single.isLeapYearNS 2000 avgt 15 2,117 ? 0,028 ns/op LeapYearBench.Single.isLeapYearNS 2017 avgt 15 2,114 ? 0,025 ns/op LeapYearBench.Single.isLeapYearNS 2004 avgt 15 2,115 ? 0,019 ns/op LeapYearBench.Single.isLeapYearNS 2100 avgt 15 2,111 ? 0,019 ns/op When isolating like this the suggested `(v & 15) == 0`-first approach still wins, and the generated code across the tests appear to be about as branchy. I suggest we go ahead and integrate this, file an RFE to re-examine the division-by-constant in C2, then re-evaluate these `isLeapYear` micros in that new environment. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16491#issuecomment-1793913973 From liach at openjdk.org Mon Nov 6 01:39:11 2023 From: liach at openjdk.org (Chen Liang) Date: Mon, 6 Nov 2023 01:39:11 GMT Subject: RFR: 8180892: Correct handling of annotations on parameters [v2] In-Reply-To: References: Message-ID: <_O-Ci8YJkk2y8kuyWR5bVUyetGJHLbdNNkvsTASeRiM=.65b7b3d6-b61c-4357-b60d-e18e327ba6df@github.com> On Sun, 8 Oct 2023 17:01:37 GMT, Joe Darcy wrote: >> @liach , thank you for working on this fix. I've given the changes an initial skim, but will need to do a more thorough review before approving or offering suggestions for changes. My top priority for the next few weeks will be JDK 21 CSRs so it may take a while for me to circle back to this PR. > >> @jddarcy Joe, can you take a look at this patch where annotation handling on parameters now uses available `MethodParameters` attribute to match from explicit formal parameter indices to implicit formal parameter indices? > > @liach sorry for the delays. > > I'll be attending to some other matters in the immediate future; please ping me again in a few weeks if I don't reply first. Hello Joe @jddarcy, is there anything that I need to do to move this patch forward? Should I file a CSR for the behavior change to `getAnnotatedParameterTypes()` and `getParameters()[i].getAnnotatedType()` due to this bugfix, as it now annotates correctly? ------------- PR Comment: https://git.openjdk.org/jdk/pull/13664#issuecomment-1793946590 From qamai at openjdk.org Mon Nov 6 02:37:09 2023 From: qamai at openjdk.org (Quan Anh Mai) Date: Mon, 6 Nov 2023 02:37:09 GMT Subject: RFR: 8319423: Improve Year.isLeap by checking divisibility by 16 [v2] In-Reply-To: References: Message-ID: On Fri, 3 Nov 2023 23:22:27 GMT, Claes Redestad wrote: >> https://github.com/cassioneri/eaf suggest this code for leap year calculation: >> >> public static boolean isLeap(long year) { >> int d = year % 100 != 0 ? 4 : 16; >> return (year & (d - 1)) == 0; >> } >> >> .. with a claim this would compile down to branchless, easily pipelined code. >> >> This doesn't currently happen with C2. In the meantime I think we can improve the current code in `Year.isLeap` and `IsoChronology.isLeapYear` by leveraging the fact that the `% 100` check is only needed if `(year & 15) != 0`: >> >> >> public static boolean isLeap(long year) { >> return (year & 15) == 0 ? (year & 3) == 0 : (year & 3) == 0 && year % 100 != 0; >> } >> >> >> Mac M1: >> >> Name Cnt Base Error Test Error Unit Change >> LeapYearBench.isLeapYear 15 0,743 ? 0,009 0,994 ? 0,005 ops/us 1,34x (p = 0,000*) >> LeapYearBench.isLeapYearChrono 15 0,748 ? 0,006 0,991 ? 0,003 ops/us 1,32x (p = 0,000*) >> LeapYearBench.isLeapYearNS 15 0,558 ? 0,026 0,552 ? 0,033 ops/us 0,99x (p = 0,602 ) >> * = significant >> >> >> Linux x64: >> >> Name Cnt Base Error Test Error Unit Change >> LeapYearBench.isLeapYear 15 0.534 ? 0.001 0.765 ? 0.004 ops/us 1.43x (p = 0.000*) >> LeapYearBench.isLeapYearChrono 15 0.535 ? 0.000 0.753 ? 0.040 ops/us 1.41x (p = 0.000*) >> LeapYearBench.isLeapYearNS 15 0.352 ? 0.000 0.351 ? 0.001 ops/us 1.00x (p = 0.000*) >> * = significant >> >> >> 30% higher throughput on M1, 40% on x64. `isLeapYearNS` runs a variant of the code from https://github.com/cassioneri/eaf ported to java - perhaps the JIT can be improved to do whatever clang/gcc does here and achieve an even better speed-up. >> >> Testing: so far only java/time/tck/java/time locally, will run a few tiers before filing an enhancement and opening the PR for review. > > Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: > > Apply similar optimization to GregorianCalendar, sun.util.calendar > .. with a claim this would compile down to branchless, easily pipelined code. > > This doesn't currently happen with C2. I have filed [JDK-8319451](https://bugs.openjdk.org/projects/JDK/issues/JDK-8319451). I would suggest waiting for this bug to be resolved before proceeding with this PR. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16491#issuecomment-1793991053 From liach at openjdk.org Mon Nov 6 06:05:27 2023 From: liach at openjdk.org (Chen Liang) Date: Mon, 6 Nov 2023 06:05:27 GMT Subject: RFR: 8319462: Signature.ClassTypeSig::classDesc() incorrect for inner class types Message-ID: Observed this erroneous implementation while browsing, and included a quick test against javac output class file to confirm the correct implementation. @asotona Please take a look. ------------- Commit messages: - 8319462: Signature.ClassTypeSig::classDesc() incorrect for inner class types Changes: https://git.openjdk.org/jdk/pull/16513/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16513&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8319462 Stats: 25 lines in 2 files changed: 22 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/16513.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16513/head:pull/16513 PR: https://git.openjdk.org/jdk/pull/16513 From liach at openjdk.org Mon Nov 6 06:47:30 2023 From: liach at openjdk.org (Chen Liang) Date: Mon, 6 Nov 2023 06:47:30 GMT Subject: RFR: 8319463: ClassSignature should have superclass and superinterfaces as ClassTypeSig Message-ID: <2MCObzp9MbPwugbIm1pP80wU0OXlmrQMr7CRsgxah7s=.78d4b9a3-9f19-4bcf-ad03-58fb6faa64fb@github.com> Discovered while writing a test for #16513 that `ClassSignature.superclassSignature()` does not return a `ClassTypeSig`, yet [JVM Spec](https://docs.oracle.com/javase/specs/jvms/se21/html/jvms-4.html#jvms-4.7.9.1-4100) requires it to be one. This patch adds such a requirement to the accessors, factories, and the parsing logic. ------------- Commit messages: - 8319463: ClassSignature should have superclass and superinterfaces as ClassTypeSig Changes: https://git.openjdk.org/jdk/pull/16514/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16514&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8319463 Stats: 22 lines in 3 files changed: 8 ins; 0 del; 14 mod Patch: https://git.openjdk.org/jdk/pull/16514.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16514/head:pull/16514 PR: https://git.openjdk.org/jdk/pull/16514 From jlahoda at openjdk.org Mon Nov 6 07:34:38 2023 From: jlahoda at openjdk.org (Jan Lahoda) Date: Mon, 6 Nov 2023 07:34:38 GMT Subject: RFR: 8318144: Match on enum constants with body compiles but fails with MatchException [v2] In-Reply-To: References: Message-ID: > For code like: > > enum E {A {}, B {} } > Object o = E.A; > switch (o) { > case E.A -> System.err.println(o); > default -> System.err.println("default"); > } > > > The result is `default`, not `A`, due to incorrect classes being compared. Thanks for @liach for noting the solution here: > https://github.com/openjdk/jdk/pull/16489#discussion_r1381411165 Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: Re-ordering tests as suggested. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16499/files - new: https://git.openjdk.org/jdk/pull/16499/files/cd27e6e9..5f40a8eb Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16499&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16499&range=00-01 Stats: 6 lines in 1 file changed: 4 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/16499.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16499/head:pull/16499 PR: https://git.openjdk.org/jdk/pull/16499 From pminborg at openjdk.org Mon Nov 6 07:46:20 2023 From: pminborg at openjdk.org (Per Minborg) Date: Mon, 6 Nov 2023 07:46:20 GMT Subject: RFR: 8319324: FFM: Reformat javadocs Message-ID: <-CK9Ln5FZQ2oX4RZ04Ltx1mzgxdt8qDnaY_Wte_B6CQ=.588bdde5-55c2-476e-8024-8c6b34c72f82@github.com> This PR proposes to reformat all the JavaDocs for the FFM API. This would bring the FFM API docs more in line with the existing Java documentation (see below). Occasional drive-by fixes are also included in this PR (such as spelling and capitalization). I am aware this PR will (if approved) make a significant mark in the change logs which is regrettable. Background: Older classes like `Object` and `List` have a maximum line length of 80 characters whereas newer classes like `ScopedValue` have a maximum line length of 90 characters. The FFM API currently has javadoc lines that exceed 135 characters per line. It is also customary to use double spaces when starting a new sentence. ------------- Commit messages: - Reformat javadocs - FFM: Harmonize the @throws tags in the javadocs - Merge branch 'master' into javadoc-throws - Harmonize some of the javadoc throws Changes: https://git.openjdk.org/jdk/pull/16518/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16518&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8319324 Stats: 2970 lines in 15 files changed: 850 ins; 11 del; 2109 mod Patch: https://git.openjdk.org/jdk/pull/16518.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16518/head:pull/16518 PR: https://git.openjdk.org/jdk/pull/16518 From pminborg at openjdk.org Mon Nov 6 08:08:34 2023 From: pminborg at openjdk.org (Per Minborg) Date: Mon, 6 Nov 2023 08:08:34 GMT Subject: RFR: 8319324: FFM: Reformat javadocs [v2] In-Reply-To: <-CK9Ln5FZQ2oX4RZ04Ltx1mzgxdt8qDnaY_Wte_B6CQ=.588bdde5-55c2-476e-8024-8c6b34c72f82@github.com> References: <-CK9Ln5FZQ2oX4RZ04Ltx1mzgxdt8qDnaY_Wte_B6CQ=.588bdde5-55c2-476e-8024-8c6b34c72f82@github.com> Message-ID: > This PR proposes to reformat all the JavaDocs for the FFM API. This would bring the FFM API docs more in line with the existing Java documentation (see below). Occasional drive-by fixes are also included in this PR (such as spelling and capitalization). > > I am aware this PR will (if approved) make a significant mark in the change logs which is regrettable. > > Background: > > Older classes like `Object` and `List` have a maximum line length of 80 characters whereas newer classes like `ScopedValue` have a maximum line length of 90 characters. > > The FFM API currently has javadoc lines that exceed 135 characters per line. It is also customary to use double spaces when starting a new sentence. 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 master - Reformat javadocs - FFM: Harmonize the @throws tags in the javadocs - Merge branch 'master' into javadoc-throws - Harmonize some of the javadoc throws ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16518/files - new: https://git.openjdk.org/jdk/pull/16518/files/5da69f89..d0fddb0f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16518&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16518&range=00-01 Stats: 7264 lines in 172 files changed: 2735 ins; 2345 del; 2184 mod Patch: https://git.openjdk.org/jdk/pull/16518.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16518/head:pull/16518 PR: https://git.openjdk.org/jdk/pull/16518 From liach at openjdk.org Mon Nov 6 08:19:19 2023 From: liach at openjdk.org (Chen Liang) Date: Mon, 6 Nov 2023 08:19:19 GMT Subject: RFR: 8316641: VarHandle template classes can share code in the base class [v8] In-Reply-To: References: Message-ID: <1GUypj2LaeTALx4trbeWcbY8JsAZFcx04hX1Mxp_Da8=.c6b9142c-5544-40b9-a7b5-5c0ac95976e7@github.com> > 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 two commits: - Merge branch 'master' of https://github.com/openjdk/jdk into cleanup/vh-template-share - 8316641: VarHandle template classes can share code in the base class ------------- Changes: https://git.openjdk.org/jdk/pull/15854/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15854&range=07 Stats: 200 lines in 7 files changed: 57 ins; 79 del; 64 mod Patch: https://git.openjdk.org/jdk/pull/15854.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15854/head:pull/15854 PR: https://git.openjdk.org/jdk/pull/15854 From mcimadamore at openjdk.org Mon Nov 6 08:57:15 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 6 Nov 2023 08:57:15 GMT Subject: RFR: 8319324: FFM: Reformat javadocs [v2] In-Reply-To: References: <-CK9Ln5FZQ2oX4RZ04Ltx1mzgxdt8qDnaY_Wte_B6CQ=.588bdde5-55c2-476e-8024-8c6b34c72f82@github.com> Message-ID: On Mon, 6 Nov 2023 08:08:34 GMT, Per Minborg wrote: >> This PR proposes to reformat all the JavaDocs for the FFM API. This would bring the FFM API docs more in line with the existing Java documentation (see below). Occasional drive-by fixes are also included in this PR (such as spelling and capitalization). >> >> I am aware this PR will (if approved) make a significant mark in the change logs which is regrettable. >> >> Background: >> >> Older classes like `Object` and `List` have a maximum line length of 80 characters whereas newer classes like `ScopedValue` have a maximum line length of 90 characters. >> >> The FFM API currently has javadoc lines that exceed 135 characters per line. It is also customary to use double spaces when starting a new sentence. > > 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 master > - Reformat javadocs > - FFM: Harmonize the @throws tags in the javadocs > - Merge branch 'master' into javadoc-throws > - Harmonize some of the javadoc throws src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 1630: > 1628: * Writes a boolean into this segment at the given offset, with the given layout. > 1629: * > 1630: * @param offset offset in bytes (relative to this segment address) at which this The first `@param` (layout) here has been deleted? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16518#discussion_r1382955037 From mcimadamore at openjdk.org Mon Nov 6 08:57:16 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 6 Nov 2023 08:57:16 GMT Subject: RFR: 8319324: FFM: Reformat javadocs [v2] In-Reply-To: References: <-CK9Ln5FZQ2oX4RZ04Ltx1mzgxdt8qDnaY_Wte_B6CQ=.588bdde5-55c2-476e-8024-8c6b34c72f82@github.com> Message-ID: <08jI0K5SF4JH-hW9aDVW_DXFicDUdnf_y3jkMmbLz9k=.a4150480-82be-47ce-9b78-a2700469d03c@github.com> On Mon, 6 Nov 2023 08:53:55 GMT, Maurizio Cimadamore 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 master >> - Reformat javadocs >> - FFM: Harmonize the @throws tags in the javadocs >> - Merge branch 'master' into javadoc-throws >> - Harmonize some of the javadoc throws > > src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 1630: > >> 1628: * Writes a boolean into this segment at the given offset, with the given layout. >> 1629: * >> 1630: * @param offset offset in bytes (relative to this segment address) at which this > > The first `@param` (layout) here has been deleted? Not just here - happened elsewhere too ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16518#discussion_r1382956428 From mcimadamore at openjdk.org Mon Nov 6 09:04:12 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 6 Nov 2023 09:04:12 GMT Subject: RFR: 8319324: FFM: Reformat javadocs [v2] In-Reply-To: References: <-CK9Ln5FZQ2oX4RZ04Ltx1mzgxdt8qDnaY_Wte_B6CQ=.588bdde5-55c2-476e-8024-8c6b34c72f82@github.com> Message-ID: <6Kyvb6MTt8M7w9OO9YXEXKrKCdRZvge8Mp0CX2XnMA8=.22730935-4876-452b-9273-5ff4d1d229b9@github.com> On Mon, 6 Nov 2023 08:08:34 GMT, Per Minborg wrote: >> This PR proposes to reformat all the JavaDocs for the FFM API. This would bring the FFM API docs more in line with the existing Java documentation (see below). Occasional drive-by fixes are also included in this PR (such as spelling and capitalization). >> >> I am aware this PR will (if approved) make a significant mark in the change logs which is regrettable. >> >> Background: >> >> Older classes like `Object` and `List` have a maximum line length of 80 characters whereas newer classes like `ScopedValue` have a maximum line length of 90 characters. >> >> The FFM API currently has javadoc lines that exceed 135 characters per line. It is also customary to use double spaces when starting a new sentence. > > 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 master > - Reformat javadocs > - FFM: Harmonize the @throws tags in the javadocs > - Merge branch 'master' into javadoc-throws > - Harmonize some of the javadoc throws src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 1910: > 1908: * in the provided layout > 1909: * @throws IndexOutOfBoundsException if {@code offset > byteSize() - layout.byteSize()} > 1910: * @throws UnsupportedOperationException if this segment is one `UOE` went missing ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16518#discussion_r1382966088 From mcimadamore at openjdk.org Mon Nov 6 09:08:10 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 6 Nov 2023 09:08:10 GMT Subject: RFR: 8319324: FFM: Reformat javadocs [v2] In-Reply-To: References: <-CK9Ln5FZQ2oX4RZ04Ltx1mzgxdt8qDnaY_Wte_B6CQ=.588bdde5-55c2-476e-8024-8c6b34c72f82@github.com> Message-ID: <8rrlPyPuKkfNxOGbCdDN-rRxvMwr3ANT8t4ag2S6f_Q=.8a4d9bf3-61ec-4106-bdb1-7586abba9359@github.com> On Mon, 6 Nov 2023 08:08:34 GMT, Per Minborg wrote: >> This PR proposes to reformat all the JavaDocs for the FFM API. This would bring the FFM API docs more in line with the existing Java documentation (see below). Occasional drive-by fixes are also included in this PR (such as spelling and capitalization). >> >> I am aware this PR will (if approved) make a significant mark in the change logs which is regrettable. >> >> Background: >> >> Older classes like `Object` and `List` have a maximum line length of 80 characters whereas newer classes like `ScopedValue` have a maximum line length of 90 characters. >> >> The FFM API currently has javadoc lines that exceed 135 characters per line. It is also customary to use double spaces when starting a new sentence. > > 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 master > - Reformat javadocs > - FFM: Harmonize the @throws tags in the javadocs > - Merge branch 'master' into javadoc-throws > - Harmonize some of the javadoc throws Generally looks good (I've been relying a lot on github diff annotations, so I hope those are accurate :-) ). There seem to be a couple of issues with deleted text. ------------- PR Review: https://git.openjdk.org/jdk/pull/16518#pullrequestreview-1714576629 From duke at openjdk.org Mon Nov 6 09:56:37 2023 From: duke at openjdk.org (Ryan Wallace) Date: Mon, 6 Nov 2023 09:56:37 GMT Subject: RFR: 8318971: jar v17 should either exit on error immediately or create archive as jar v1.8 did Message-ID: Hi all, Please review this fix for jar tool not producing archive if there is a missing file supplied. Fix is to throw an exception and exit processing when a missing file is supplied. Current behaviour will recognise missing file as an error but continue processing and not produce the archive. Updated ClassPath test to verify jar is not created. Thanks, Ryan. ------------- Commit messages: - 8318971: jar v17 should either exit on error immediately or create archive as jar v1.8 did - 8318971: jar v17 should either exit on error immediately or create archive as jar v1.8 did Changes: https://git.openjdk.org/jdk/pull/16423/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16423&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8318971 Stats: 8 lines in 2 files changed: 5 ins; 1 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/16423.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16423/head:pull/16423 PR: https://git.openjdk.org/jdk/pull/16423 From redestad at openjdk.org Mon Nov 6 10:04:12 2023 From: redestad at openjdk.org (Claes Redestad) Date: Mon, 6 Nov 2023 10:04:12 GMT Subject: RFR: 8319423: Improve Year.isLeap by checking divisibility by 16 [v2] In-Reply-To: References: Message-ID: On Mon, 6 Nov 2023 02:34:21 GMT, Quan Anh Mai wrote: > > > > I have filed [JDK-8319451](https://bugs.openjdk.org/projects/JDK/issues/JDK-8319451). I would suggest waiting for this bug to be resolved before proceeding with this PR. Nice analysis! While I'm sure we need to re-evaluate this enhancement after JDK-8319451 is resolved, I'm not a fan of blocking library enhancements on improvements to the runtime/compiler (as it's impossible to know up front if this is something we can fix in the next couple of days/weeks, or need to staff, plan and evaluate over a longer cycle). I included the Neri-Schneider variant in the microbenchmark here to make it easy to assess if an optimization such as JDK-8319451 would turn things around. We should file an enhancement to re-visit the Granlund & Montgomery/Hacker's delight division. Improving this should benefit either variant, and might be needed together with JDK-8319451 for the `isLeapYearNS` test to win. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16491#issuecomment-1794464999 From alanb at openjdk.org Mon Nov 6 10:08:13 2023 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 6 Nov 2023 10:08:13 GMT Subject: RFR: 8318971: jar v17 should either exit on error immediately or create archive as jar v1.8 did In-Reply-To: References: Message-ID: On Mon, 30 Oct 2023 16:16:52 GMT, Ryan Wallace wrote: > Hi all, > > Please review this fix for jar tool not producing archive if there is a missing file supplied. Fix is to throw an exception and exit processing when a missing file is supplied. Current behaviour will recognise missing file as an error but continue processing and not produce the archive. Updated ClassPath test to verify jar is not created. > > Thanks, > Ryan. This one probably needs discussion to decide if the JDK 8 or current behavior is the right behavior. Once agreed then we will need to add tests to ensure that the behavior doesn't change, and maybe an update to docs too. Have you dug into the history to see if this behavior change was deliberate or just not noticed before now? ------------- PR Comment: https://git.openjdk.org/jdk/pull/16423#issuecomment-1794474588 From pminborg at openjdk.org Mon Nov 6 10:10:41 2023 From: pminborg at openjdk.org (Per Minborg) Date: Mon, 6 Nov 2023 10:10:41 GMT Subject: RFR: 8319324: FFM: Reformat javadocs [v3] In-Reply-To: <-CK9Ln5FZQ2oX4RZ04Ltx1mzgxdt8qDnaY_Wte_B6CQ=.588bdde5-55c2-476e-8024-8c6b34c72f82@github.com> References: <-CK9Ln5FZQ2oX4RZ04Ltx1mzgxdt8qDnaY_Wte_B6CQ=.588bdde5-55c2-476e-8024-8c6b34c72f82@github.com> Message-ID: > This PR proposes to reformat all the JavaDocs for the FFM API. This would bring the FFM API docs more in line with the existing Java documentation (see below). Occasional drive-by fixes are also included in this PR (such as spelling and capitalization). > > I am aware this PR will (if approved) make a significant mark in the change logs which is regrettable. > > Background: > > Older classes like `Object` and `List` have a maximum line length of 80 characters whereas newer classes like `ScopedValue` have a maximum line length of 90 characters. > > The FFM API currently has javadoc lines that exceed 135 characters per line. It is also customary to use double spaces when starting a new sentence. Per Minborg has updated the pull request incrementally with one additional commit since the last revision: Update after review ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16518/files - new: https://git.openjdk.org/jdk/pull/16518/files/d0fddb0f..0c379b4a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16518&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16518&range=01-02 Stats: 15 lines in 2 files changed: 10 ins; 1 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/16518.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16518/head:pull/16518 PR: https://git.openjdk.org/jdk/pull/16518 From pminborg at openjdk.org Mon Nov 6 10:16:11 2023 From: pminborg at openjdk.org (Per Minborg) Date: Mon, 6 Nov 2023 10:16:11 GMT Subject: RFR: 8319316: Clarify text around which layouts a linker supports [v3] In-Reply-To: <_XYcFubf7GVQZ4lYLhXch2XFBKR7nVxJwZAXxWPHGTY=.4032095b-9a89-4090-b58a-51556c16bfd5@github.com> References: <59YZ3CcJ5Sfx40UWGpeCLk2Y4ThCocl48YIMEsC8_Qk=.900ebd34-73ed-46a7-aa4e-94f13249273d@github.com> <_XYcFubf7GVQZ4lYLhXch2XFBKR7nVxJwZAXxWPHGTY=.4032095b-9a89-4090-b58a-51556c16bfd5@github.com> Message-ID: On Fri, 3 Nov 2023 18:16:17 GMT, Jorn Vernee wrote: >> - Add linker note about packed structs. >> - Relax language a bit to avoid implying that only listed layouts are supported. > > Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: > > Add 'strict' > > Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com> Can we reformat the new improved text so it will fit in col <= 90? ------------- PR Comment: https://git.openjdk.org/jdk/pull/16485#issuecomment-1794487546 From asotona at openjdk.org Mon Nov 6 10:17:09 2023 From: asotona at openjdk.org (Adam Sotona) Date: Mon, 6 Nov 2023 10:17:09 GMT Subject: RFR: 8319462: Signature.ClassTypeSig::classDesc() incorrect for inner class types In-Reply-To: References: Message-ID: <0mLbTHWnyE6EeF63mygA4p4aHW1zUIHGqg-vQ6wo0gA=.1f62aae5-51d8-4477-9c7e-c39626f039af@github.com> On Mon, 6 Nov 2023 06:00:20 GMT, Chen Liang wrote: > Observed this erroneous implementation while browsing, and included a quick test against javac output class file to confirm the correct implementation. @asotona Please take a look. Good catch, thanks for the fix. ------------- Marked as reviewed by asotona (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16513#pullrequestreview-1714726678 From duke at openjdk.org Mon Nov 6 11:31:10 2023 From: duke at openjdk.org (Ryan Wallace) Date: Mon, 6 Nov 2023 11:31:10 GMT Subject: RFR: 8318971: jar v17 should either exit on error immediately or create archive as jar v1.8 did In-Reply-To: References: Message-ID: On Mon, 30 Oct 2023 16:16:52 GMT, Ryan Wallace wrote: > Hi all, > > Please review this fix for jar tool not producing archive if there is a missing file supplied. Fix is to throw an exception and exit processing when a missing file is supplied. Current behaviour will recognise missing file as an error but continue processing and not produce the archive. Updated ClassPath test to verify jar is not created. > > Thanks, > Ryan. I had a look and its been in since JDK 9 (https://bugs.openjdk.org/browse/JDK-8158295) but haven?t found any mention of this as a specific desired behaviour so I am going with just noticed now. Its not a major blocker as the user can either make sure the missing file is in place or exclude it from being added to the archive and rerun. I agree it will need some thought, I was of the opinion that we should fail upfront and notify the user of why. The JDK 8 behaviour doesn?t make sense as the state is recognised as an error and there are tests to validate this, but they do not validate the archive has not been created, in my opinion we shouldn?t continue on and create it. There are other areas in the jar tool in 8 that will clean up (delete) the archive that has been created if there is an error, this case just seems to fall through the cracks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16423#issuecomment-1794612971 From redestad at openjdk.org Mon Nov 6 11:33:11 2023 From: redestad at openjdk.org (Claes Redestad) Date: Mon, 6 Nov 2023 11:33:11 GMT Subject: RFR: 8319423: Improve Year.isLeap by checking divisibility by 16 [v2] In-Reply-To: References: Message-ID: On Fri, 3 Nov 2023 23:22:27 GMT, Claes Redestad wrote: >> https://github.com/cassioneri/eaf suggest this code for leap year calculation: >> >> public static boolean isLeap(long year) { >> int d = year % 100 != 0 ? 4 : 16; >> return (year & (d - 1)) == 0; >> } >> >> .. with a claim this would compile down to branchless, easily pipelined code. >> >> This doesn't currently happen with C2. In the meantime I think we can improve the current code in `Year.isLeap` and `IsoChronology.isLeapYear` by leveraging the fact that the `% 100` check is only needed if `(year & 15) != 0`: >> >> >> public static boolean isLeap(long year) { >> return (year & 15) == 0 ? (year & 3) == 0 : (year & 3) == 0 && year % 100 != 0; >> } >> >> >> Mac M1: >> >> Name Cnt Base Error Test Error Unit Change >> LeapYearBench.isLeapYear 15 0,743 ? 0,009 0,994 ? 0,005 ops/us 1,34x (p = 0,000*) >> LeapYearBench.isLeapYearChrono 15 0,748 ? 0,006 0,991 ? 0,003 ops/us 1,32x (p = 0,000*) >> LeapYearBench.isLeapYearNS 15 0,558 ? 0,026 0,552 ? 0,033 ops/us 0,99x (p = 0,602 ) >> * = significant >> >> >> Linux x64: >> >> Name Cnt Base Error Test Error Unit Change >> LeapYearBench.isLeapYear 15 0.534 ? 0.001 0.765 ? 0.004 ops/us 1.43x (p = 0.000*) >> LeapYearBench.isLeapYearChrono 15 0.535 ? 0.000 0.753 ? 0.040 ops/us 1.41x (p = 0.000*) >> LeapYearBench.isLeapYearNS 15 0.352 ? 0.000 0.351 ? 0.001 ops/us 1.00x (p = 0.000*) >> * = significant >> >> >> 30% higher throughput on M1, 40% on x64. `isLeapYearNS` runs a variant of the code from https://github.com/cassioneri/eaf ported to java - perhaps the JIT can be improved to do whatever clang/gcc does here and achieve an even better speed-up. >> >> Testing: so far only java/time/tck/java/time locally, will run a few tiers before filing an enhancement and opening the PR for review. > > Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: > > Apply similar optimization to GregorianCalendar, sun.util.calendar Filed https://bugs.openjdk.org/browse/JDK-8319526 to re-examine the integer remainder optimization in C2. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16491#issuecomment-1794616062 From mcimadamore at openjdk.org Mon Nov 6 11:44:10 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 6 Nov 2023 11:44:10 GMT Subject: RFR: 8319324: FFM: Reformat javadocs [v3] In-Reply-To: References: <-CK9Ln5FZQ2oX4RZ04Ltx1mzgxdt8qDnaY_Wte_B6CQ=.588bdde5-55c2-476e-8024-8c6b34c72f82@github.com> Message-ID: On Mon, 6 Nov 2023 10:10:41 GMT, Per Minborg wrote: >> This PR proposes to reformat all the JavaDocs for the FFM API. This would bring the FFM API docs more in line with the existing Java documentation (see below). Occasional drive-by fixes are also included in this PR (such as spelling and capitalization). >> >> I am aware this PR will (if approved) make a significant mark in the change logs which is regrettable. >> >> Background: >> >> Older classes like `Object` and `List` have a maximum line length of 80 characters whereas newer classes like `ScopedValue` have a maximum line length of 90 characters. >> >> The FFM API currently has javadoc lines that exceed 135 characters per line. It is also customary to use double spaces when starting a new sentence. > > Per Minborg has updated the pull request incrementally with one additional commit since the last revision: > > Update after review You might also want to look into the MethodHandles XYZCoordinates combinators (as they have also been added as part of FFM). And, also, `ModuleLayer::Controller::enableNativeAccess`, `Module::isNativeAccessEnabled` and `FileChannel::map(... Arena)`. ------------- PR Review: https://git.openjdk.org/jdk/pull/16518#pullrequestreview-1714934553 From alanb at openjdk.org Mon Nov 6 12:09:09 2023 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 6 Nov 2023 12:09:09 GMT Subject: RFR: 8318971: jar v17 should either exit on error immediately or create archive as jar v1.8 did In-Reply-To: References: Message-ID: <_oOL_YIlhoyaWX5jQbP_uCnC52MIpXPB_aYECH-m5hg=.dcd75a71-943a-4e59-b64a-94e3443bd519@github.com> On Mon, 30 Oct 2023 16:16:52 GMT, Ryan Wallace wrote: > Hi all, > > Please review this fix for jar tool not producing archive if there is a missing file supplied. Fix is to throw an exception and exit processing when a missing file is supplied. Current behaviour will recognise missing file as an error but continue processing and not produce the archive. Updated ClassPath test to verify jar is not created. > > Thanks, > Ryan. Thanks for checking the history. A plus to going back to JDK 8 behavior is that it make the `@contents` consistent with the file1, file2, file3 case where one/more of the files doesn't exist or a bad file path is specified. It also means that bugs/issues will be detected quicker. So I think it has positives, it's just that it's changing 6+ year old behavior so we have to be sure. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16423#issuecomment-1794678429 From jlaskey at openjdk.org Mon Nov 6 12:51:34 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Mon, 6 Nov 2023 12:51:34 GMT Subject: RFR: JDK-8315457 Implementation of String Templates (Second Preview) [v5] In-Reply-To: References: Message-ID: <9uwfuPjY_0dSLi2a52bsIoRswDtAH5-ILNQm6wm1Zjs=.b4222a67-f020-40b8-b5c6-cbdb26f46116@github.com> > Update String Templates for a second preview. With the addition of > > - Expression type and throws are determined from the `process` method of the processor type and not the processor type. > > - Qualified `STR` and `RAW` are treated the same as unqualified `STR` and `RAW` . > > - Raw (generic) process types are no longer an error. Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: Remove preview from JavaLangAccess ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16202/files - new: https://git.openjdk.org/jdk/pull/16202/files/2afadc69..4641ec05 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16202&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16202&range=03-04 Stats: 8 lines in 1 file changed: 0 ins; 7 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/16202.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16202/head:pull/16202 PR: https://git.openjdk.org/jdk/pull/16202 From jlaskey at openjdk.org Mon Nov 6 12:51:39 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Mon, 6 Nov 2023 12:51:39 GMT Subject: RFR: JDK-8315457 Implementation of String Templates (Second Preview) [v4] In-Reply-To: References: Message-ID: <6mtIcg0H0wbOwcAzlmWG9thAjUpDCzQe55aLQDGA33Q=.deaada83-150c-4e1d-85c3-c07c61ff62a5@github.com> On Sat, 4 Nov 2023 13:26:04 GMT, Alan Bateman wrote: >> Jim Laskey has updated the pull request with a new target base 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 remote-tracking branch 'upstream/master' into 8315457 >> - Cache process method type in JCStringTemplate >> - Revert source >> - Revert @since 22 >> - Accept qualified STR and RAW >> - String Templates (second preview) > > src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java line 424: > >> 422: * @since 21 >> 423: */ >> 424: @PreviewFeature(feature=PreviewFeature.Feature.STRING_TEMPLATES) > > I think you can drop both `@since` and `@PreviewFeature` from these methods. This in an internal interface, used for shared secrets, there is a lot of churn in JLA in each release. Removed ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16202#discussion_r1383275177 From jlahoda at openjdk.org Mon Nov 6 12:58:25 2023 From: jlahoda at openjdk.org (Jan Lahoda) Date: Mon, 6 Nov 2023 12:58:25 GMT Subject: RFR: JDK-8315458 Implementation of Implicitly Declared Classes and Instance Main Method (Second Preview) [v12] In-Reply-To: References: Message-ID: <6gX1AIFAraJXNagvz0R81ffShpGYy8NAuEx3LVel_cE=.534fbf76-a97b-4610-a672-09f5f0b14569@github.com> On Fri, 3 Nov 2023 12:40:48 GMT, Jim Laskey wrote: >> Address changes from JEP 445 to JEP 463. >> >> - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. >> >> - Don't mark class on read. >> >> - Remove reflection and annotation processing related to unnamed classes. >> >> - Simplify main method search. > > Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since the last revision: > > - Merge remote-tracking branch 'upstream/master' into 8315458 > - Don't get args unless necessary > - Remove unnamed classes from examples.not-yet.txt > - Requested corrections > - Changes recommended by Jan > - Revised implicit class test > - Don't store main method info globally. Use addition calls to fetch info. > - Update JEP number in PreviewFeature > - Remove MANDATED flag from implicit classes > - Remove .orig files > - ... and 2 more: https://git.openjdk.org/jdk/compare/caa2870d...0bd5b477 javac changes look reasonable to me. ------------- Marked as reviewed by jlahoda (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16461#pullrequestreview-1715097616 From jvernee at openjdk.org Mon Nov 6 13:25:10 2023 From: jvernee at openjdk.org (Jorn Vernee) Date: Mon, 6 Nov 2023 13:25:10 GMT Subject: RFR: 8319316: Clarify text around which layouts a linker supports [v3] In-Reply-To: References: <59YZ3CcJ5Sfx40UWGpeCLk2Y4ThCocl48YIMEsC8_Qk=.900ebd34-73ed-46a7-aa4e-94f13249273d@github.com> <_XYcFubf7GVQZ4lYLhXch2XFBKR7nVxJwZAXxWPHGTY=.4032095b-9a89-4090-b58a-51556c16bfd5@github.com> Message-ID: On Mon, 6 Nov 2023 10:13:14 GMT, Per Minborg wrote: >> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: >> >> Add 'strict' >> >> Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com> > > Can we reformat the new improved text so it will fit in col <= 90? @minborg Shouldn't we do that as part of: https://github.com/openjdk/jdk/pull/16518 ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/16485#issuecomment-1794815716 From simonis at openjdk.org Mon Nov 6 13:29:10 2023 From: simonis at openjdk.org (Volker Simonis) Date: Mon, 6 Nov 2023 13:29:10 GMT Subject: RFR: JDK-8319122: Improve documentation of various Zip-file related APIs In-Reply-To: <8vEqyECjMkTfesVmL3X0dN4Yu8JShPiUdsKpmEz1WV0=.1b541f77-a05f-490b-aaf1-f6b7456c6d77@github.com> References: <8vEqyECjMkTfesVmL3X0dN4Yu8JShPiUdsKpmEz1WV0=.1b541f77-a05f-490b-aaf1-f6b7456c6d77@github.com> Message-ID: <2cmj66SGApybxAzgif834DGMbICt1PPMs42Prf8XWIQ=.9ce00433-ce48-4446-bf0b-2f874bbb3d89@github.com> On Mon, 30 Oct 2023 17:26:53 GMT, Yakov Shafranovich wrote: > The various Zip/Jar-file related Java APIs have some long-standing differences or peculiarities with respect to the ZIP-file specification or compared to other implementations which should be documented in the API-doc. This documents the following: > - Cache of JAR files in JarURLConnection class > - Cache of JAR/ZIP files in JarFile and ZipFile classes > - Unexpected behavior when parsing ZIP files with duplicate entries in JarFile and ZipFile classes, as well as the zipfs provider > - Directories and filenames with the same name considered to be the same in ZipFile class > - Possible issues when local and central headers conflict in ZipInputStream class > > Related JBS report: > https://bugs.openjdk.org/browse/JDK-8319122 I will create the CSR once there's agreement on the exact wording of the proposed API-doc changes. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16424#issuecomment-1794822606 From jvernee at openjdk.org Mon Nov 6 13:30:14 2023 From: jvernee at openjdk.org (Jorn Vernee) Date: Mon, 6 Nov 2023 13:30:14 GMT Subject: RFR: 8319324: FFM: Reformat javadocs [v3] In-Reply-To: References: <-CK9Ln5FZQ2oX4RZ04Ltx1mzgxdt8qDnaY_Wte_B6CQ=.588bdde5-55c2-476e-8024-8c6b34c72f82@github.com> Message-ID: <0WJK2JjPMbdNnuhrfEZV976iHm9EtWum-v7IHKcOGrA=.a957353a-fccd-4ca9-8926-bf1c529e2fed@github.com> On Mon, 6 Nov 2023 10:10:41 GMT, Per Minborg wrote: >> This PR proposes to reformat all the JavaDocs for the FFM API. This would bring the FFM API docs more in line with the existing Java documentation (see below). Occasional drive-by fixes are also included in this PR (such as spelling and capitalization). >> >> I am aware this PR will (if approved) make a significant mark in the change logs which is regrettable. >> >> Background: >> >> Older classes like `Object` and `List` have a maximum line length of 80 characters whereas newer classes like `ScopedValue` have a maximum line length of 90 characters. >> >> The FFM API currently has javadoc lines that exceed 135 characters per line. It is also customary to use double spaces when starting a new sentence. > > Per Minborg has updated the pull request incrementally with one additional commit since the last revision: > > Update after review FWIW, I've been sticking to a 120 character limit per line when writing javadoc. Why should we use 90 columns specifically? > It is also customary to use double spaces when starting a new sentence. I thought this was the exception rather than the rule, to be honest. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16518#issuecomment-1794824402 From lkorinth at openjdk.org Mon Nov 6 13:35:22 2023 From: lkorinth at openjdk.org (Leo Korinth) Date: Mon, 6 Nov 2023 13:35:22 GMT Subject: Integrated: 8319153: Fix: Class is a raw type in ProcessTools In-Reply-To: References: Message-ID: <8B0lDeT0ZPbSZa1aWJIXLAbUEKmxpdl9pK0p2REyWBQ=.4d45742b-7b74-45f1-9b83-719899933b4c@github.com> On Tue, 31 Oct 2023 07:43:43 GMT, Leo Korinth wrote: > Changing from `Class c` to `Class c` removes two warnings. This pull request has now been integrated. Changeset: 1c2ea1d2 Author: Leo Korinth URL: https://git.openjdk.org/jdk/commit/1c2ea1d27b1895dca3b30073e3516978083dc70a Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8319153: Fix: Class is a raw type in ProcessTools Reviewed-by: dholmes, mli, lmesnik, jpai ------------- PR: https://git.openjdk.org/jdk/pull/16431 From lkorinth at openjdk.org Mon Nov 6 13:35:22 2023 From: lkorinth at openjdk.org (Leo Korinth) Date: Mon, 6 Nov 2023 13:35:22 GMT Subject: RFR: 8319153: Fix: Class is a raw type in ProcessTools In-Reply-To: References: Message-ID: On Tue, 31 Oct 2023 07:43:43 GMT, Leo Korinth wrote: > Changing from `Class c` to `Class c` removes two warnings. Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/16431#issuecomment-1794831441 From mcimadamore at openjdk.org Mon Nov 6 13:56:27 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 6 Nov 2023 13:56:27 GMT Subject: RFR: JDK-8315458 Implementation of Implicitly Declared Classes and Instance Main Method (Second Preview) [v12] In-Reply-To: References: Message-ID: On Fri, 3 Nov 2023 12:40:48 GMT, Jim Laskey wrote: >> Address changes from JEP 445 to JEP 463. >> >> - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. >> >> - Don't mark class on read. >> >> - Remove reflection and annotation processing related to unnamed classes. >> >> - Simplify main method search. > > Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since the last revision: > > - Merge remote-tracking branch 'upstream/master' into 8315458 > - Don't get args unless necessary > - Remove unnamed classes from examples.not-yet.txt > - Requested corrections > - Changes recommended by Jan > - Revised implicit class test > - Don't store main method info globally. Use addition calls to fetch info. > - Update JEP number in PreviewFeature > - Remove MANDATED flag from implicit classes > - Remove .orig files > - ... and 2 more: https://git.openjdk.org/jdk/compare/baf8d59f...0bd5b477 Javac changes look good ------------- Marked as reviewed by mcimadamore (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16461#pullrequestreview-1715227587 From cstein at openjdk.org Mon Nov 6 13:56:28 2023 From: cstein at openjdk.org (Christian Stein) Date: Mon, 6 Nov 2023 13:56:28 GMT Subject: RFR: JDK-8315458 Implementation of Implicitly Declared Classes and Instance Main Method (Second Preview) [v12] In-Reply-To: References: Message-ID: On Fri, 3 Nov 2023 12:40:48 GMT, Jim Laskey wrote: >> Address changes from JEP 445 to JEP 463. >> >> - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. >> >> - Don't mark class on read. >> >> - Remove reflection and annotation processing related to unnamed classes. >> >> - Simplify main method search. > > Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since the last revision: > > - Merge remote-tracking branch 'upstream/master' into 8315458 > - Don't get args unless necessary > - Remove unnamed classes from examples.not-yet.txt > - Requested corrections > - Changes recommended by Jan > - Revised implicit class test > - Don't store main method info globally. Use addition calls to fetch info. > - Update JEP number in PreviewFeature > - Remove MANDATED flag from implicit classes > - Remove .orig files > - ... and 2 more: https://git.openjdk.org/jdk/compare/baf8d59f...0bd5b477 Changes in the two source launcher files `Main.java` and `SourceLauncherTest.java` look good to me - less code is more! ------------- PR Review: https://git.openjdk.org/jdk/pull/16461#pullrequestreview-1715230089 From vromero at openjdk.org Mon Nov 6 14:54:44 2023 From: vromero at openjdk.org (Vicente Romero) Date: Mon, 6 Nov 2023 14:54:44 GMT Subject: RFR: JDK-8315458 Implementation of Implicitly Declared Classes and Instance Main Method (Second Preview) [v12] In-Reply-To: References: Message-ID: On Fri, 3 Nov 2023 12:40:48 GMT, Jim Laskey wrote: >> Address changes from JEP 445 to JEP 463. >> >> - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. >> >> - Don't mark class on read. >> >> - Remove reflection and annotation processing related to unnamed classes. >> >> - Simplify main method search. > > Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since the last revision: > > - Merge remote-tracking branch 'upstream/master' into 8315458 > - Don't get args unless necessary > - Remove unnamed classes from examples.not-yet.txt > - Requested corrections > - Changes recommended by Jan > - Revised implicit class test > - Don't store main method info globally. Use addition calls to fetch info. > - Update JEP number in PreviewFeature > - Remove MANDATED flag from implicit classes > - Remove .orig files > - ... and 2 more: https://git.openjdk.org/jdk/compare/8e9e3542...0bd5b477 lgtm ------------- Marked as reviewed by vromero (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16461#pullrequestreview-1715396892 From duke at openjdk.org Mon Nov 6 14:55:54 2023 From: duke at openjdk.org (Shaojin Wen) Date: Mon, 6 Nov 2023 14:55:54 GMT Subject: RFR: 8317742: ISO Standard Date Format implementation consistency on DateTimeFormatter and String.format [v4] In-Reply-To: References: Message-ID: > j.u.Formatter now prints "%tF" (iso standard date) and the result is incorrect when processing year < 0 or year > 9999 Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: revert localize change ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16033/files - new: https://git.openjdk.org/jdk/pull/16033/files/8b31e875..b6313fc0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16033&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16033&range=02-03 Stats: 31 lines in 2 files changed: 0 ins; 27 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/16033.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16033/head:pull/16033 PR: https://git.openjdk.org/jdk/pull/16033 From pminborg at openjdk.org Mon Nov 6 14:59:20 2023 From: pminborg at openjdk.org (Per Minborg) Date: Mon, 6 Nov 2023 14:59:20 GMT Subject: RFR: 8319324: FFM: Reformat javadocs [v3] In-Reply-To: <0WJK2JjPMbdNnuhrfEZV976iHm9EtWum-v7IHKcOGrA=.a957353a-fccd-4ca9-8926-bf1c529e2fed@github.com> References: <-CK9Ln5FZQ2oX4RZ04Ltx1mzgxdt8qDnaY_Wte_B6CQ=.588bdde5-55c2-476e-8024-8c6b34c72f82@github.com> <0WJK2JjPMbdNnuhrfEZV976iHm9EtWum-v7IHKcOGrA=.a957353a-fccd-4ca9-8926-bf1c529e2fed@github.com> Message-ID: On Mon, 6 Nov 2023 13:27:40 GMT, Jorn Vernee wrote: > FWIW, I've been sticking to a soft 120 character limit per line when writing javadoc. Why should we use 90 columns specifically? > > > It is also customary to use double spaces when starting a new sentence. > > I thought this was the exception rather than the rule, to be honest. We should try to get some clarity on this. I've sampled a handful of prominent Java classes and they have the style as in this PR. If we can find support that other styles are to be preferred, I am happy to update accordingly. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16518#issuecomment-1795020671 From pminborg at openjdk.org Mon Nov 6 15:05:38 2023 From: pminborg at openjdk.org (Per Minborg) Date: Mon, 6 Nov 2023 15:05:38 GMT Subject: RFR: 8319324: FFM: Reformat javadocs [v4] In-Reply-To: <-CK9Ln5FZQ2oX4RZ04Ltx1mzgxdt8qDnaY_Wte_B6CQ=.588bdde5-55c2-476e-8024-8c6b34c72f82@github.com> References: <-CK9Ln5FZQ2oX4RZ04Ltx1mzgxdt8qDnaY_Wte_B6CQ=.588bdde5-55c2-476e-8024-8c6b34c72f82@github.com> Message-ID: <9a_K5IayKXAd0C11OuN3ypucQMhXaIKc3BirDwFf0J0=.2d75dbf1-b194-49b6-927b-3eaecbda9fc6@github.com> > This PR proposes to reformat all the JavaDocs for the FFM API. This would bring the FFM API docs more in line with the existing Java documentation (see below). Occasional drive-by fixes are also included in this PR (such as spelling and capitalization). > > I am aware this PR will (if approved) make a significant mark in the change logs which is regrettable. > > Background: > > Older classes like `Object` and `List` have a maximum line length of 80 characters whereas newer classes like `ScopedValue` have a maximum line length of 90 characters. > > The FFM API currently has javadoc lines that exceed 135 characters per line. It is also customary to use double spaces when starting a new sentence. Per Minborg has updated the pull request incrementally with one additional commit since the last revision: Review classes not in the foreign package ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16518/files - new: https://git.openjdk.org/jdk/pull/16518/files/0c379b4a..b37bd31c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16518&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16518&range=02-03 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/16518.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16518/head:pull/16518 PR: https://git.openjdk.org/jdk/pull/16518 From pminborg at openjdk.org Mon Nov 6 15:05:40 2023 From: pminborg at openjdk.org (Per Minborg) Date: Mon, 6 Nov 2023 15:05:40 GMT Subject: RFR: 8319324: FFM: Reformat javadocs [v3] In-Reply-To: References: <-CK9Ln5FZQ2oX4RZ04Ltx1mzgxdt8qDnaY_Wte_B6CQ=.588bdde5-55c2-476e-8024-8c6b34c72f82@github.com> Message-ID: On Mon, 6 Nov 2023 11:41:23 GMT, Maurizio Cimadamore wrote: > You might also want to look into the MethodHandles XYZCoordinates combinators (as they have also been added as part of FFM). And, also, `ModuleLayer::Controller::enableNativeAccess`, `Module::isNativeAccessEnabled` and `FileChannel::map(... Arena)`. These are checked now. Only FileChannel needed a very small adjustment. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16518#issuecomment-1795032761 From jvernee at openjdk.org Mon Nov 6 15:12:31 2023 From: jvernee at openjdk.org (Jorn Vernee) Date: Mon, 6 Nov 2023 15:12:31 GMT Subject: Integrated: 8319316: Clarify text around which layouts a linker supports In-Reply-To: <59YZ3CcJ5Sfx40UWGpeCLk2Y4ThCocl48YIMEsC8_Qk=.900ebd34-73ed-46a7-aa4e-94f13249273d@github.com> References: <59YZ3CcJ5Sfx40UWGpeCLk2Y4ThCocl48YIMEsC8_Qk=.900ebd34-73ed-46a7-aa4e-94f13249273d@github.com> Message-ID: <7i7spca4wsGUTma362AMoKjsfk2sl3_e468voZa38yE=.d8a48077-2129-4b15-a0bc-fc0f2c869935@github.com> On Fri, 3 Nov 2023 00:10:48 GMT, Jorn Vernee wrote: > - Add linker note about packed structs. > - Relax language a bit to avoid implying that only listed layouts are supported. This pull request has now been integrated. Changeset: cdf33735 Author: Jorn Vernee URL: https://git.openjdk.org/jdk/commit/cdf337357a62dd52c00e56e75912565e15b6adfd Stats: 18 lines in 1 file changed: 16 ins; 0 del; 2 mod 8319316: Clarify text around which layouts a linker supports Reviewed-by: mcimadamore ------------- PR: https://git.openjdk.org/jdk/pull/16485 From lancea at openjdk.org Mon Nov 6 15:21:15 2023 From: lancea at openjdk.org (Lance Andersen) Date: Mon, 6 Nov 2023 15:21:15 GMT Subject: RFR: 8318971: jar v17 should either exit on error immediately or create archive as jar v1.8 did In-Reply-To: References: Message-ID: On Mon, 6 Nov 2023 11:28:23 GMT, Ryan Wallace wrote: > I had a look and its been in since JDK 9 (https://bugs.openjdk.org/browse/JDK-8158295) but haven?t found any mention of this as a specific desired behaviour so I am going with just noticed now. Its not a major blocker as the user can either make sure the missing file is in place or exclude it from being added to the archive and rerun. > > I agree it will need some thought, I was of the opinion that we should fail upfront and notify the user of why. The JDK 8 behaviour doesn?t make sense as the state is recognised as an error and there are tests to validate this, but they do not validate the archive has not been created, in my opinion we shouldn?t continue on and create it. There are other areas in the jar tool in 8 that will clean up (delete) the archive that has been created if there is an error, this case just seems to fall through the cracks. As part of the decision process, we should consider the behavior of what simillar tools do in this area. We may also want to discuss the merits of whether there should be an option to toggle the behavior ------------- PR Comment: https://git.openjdk.org/jdk/pull/16423#issuecomment-1795072524 From egahlin at openjdk.org Mon Nov 6 15:30:33 2023 From: egahlin at openjdk.org (Erik Gahlin) Date: Mon, 6 Nov 2023 15:30:33 GMT Subject: RFR: 8319374: JFR: Remove instrumentation for exception events Message-ID: Could I have a review of a PR that removes the bytecode instrumentation for the exception events. Testing: jdk/jdk/jfr + tier1 + tier2 ------------- Commit messages: - Remove Throwable and Error from instrumentation list - Initial Changes: https://git.openjdk.org/jdk/pull/16493/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16493&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8319374 Stats: 560 lines in 19 files changed: 268 ins; 281 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/16493.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16493/head:pull/16493 PR: https://git.openjdk.org/jdk/pull/16493 From alanb at openjdk.org Mon Nov 6 15:52:11 2023 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 6 Nov 2023 15:52:11 GMT Subject: RFR: 8319374: JFR: Remove instrumentation for exception events In-Reply-To: References: Message-ID: On Fri, 3 Nov 2023 12:19:07 GMT, Erik Gahlin wrote: > Could I have a review of a PR that removes the bytecode instrumentation for the exception events. > > Testing: jdk/jdk/jfr + tier1 + tier2 src/java.base/share/classes/jdk/internal/event/ThrowableTracer.java line 37: > 35: private static final AtomicLong numThrowables = new AtomicLong(); > 36: > 37: public static void enable() throws NoSuchFieldException, SecurityException, IllegalArgumentException, IllegalAccessException { SecurityException and IllegaArgumentException are unchecked so don't need them in the throws declaration. src/java.base/share/classes/jdk/internal/event/ThrowableTracer.java line 44: > 42: > 43: public static void traceError(Class clazz, String message) { > 44: if (OutOfMemoryError.class.isAssignableFrom(clazz)) { StackOverflowError is likely problematic too, maybe it should be VirtualMachineError. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16493#discussion_r1383552825 PR Review Comment: https://git.openjdk.org/jdk/pull/16493#discussion_r1383552352 From dnsimon at openjdk.org Mon Nov 6 16:05:12 2023 From: dnsimon at openjdk.org (Doug Simon) Date: Mon, 6 Nov 2023 16:05:12 GMT Subject: RFR: 8315680: java/lang/ref/ReachabilityFenceTest.java should run with -Xbatch In-Reply-To: References: Message-ID: On Tue, 3 Oct 2023 07:47:30 GMT, Gerg? Barany wrote: > This test requires certain methods to be compiled, but without `-Xbatch` the compiler races against the test code, which can lead to intermittent failures. Marked as reviewed by dnsimon (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/16023#pullrequestreview-1715574295 From never at openjdk.org Mon Nov 6 16:05:12 2023 From: never at openjdk.org (Tom Rodriguez) Date: Mon, 6 Nov 2023 16:05:12 GMT Subject: RFR: 8315680: java/lang/ref/ReachabilityFenceTest.java should run with -Xbatch In-Reply-To: References: Message-ID: On Tue, 3 Oct 2023 07:47:30 GMT, Gerg? Barany wrote: > This test requires certain methods to be compiled, but without `-Xbatch` the compiler races against the test code, which can lead to intermittent failures. Marked as reviewed by never (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/16023#pullrequestreview-1715579342 From rriggs at openjdk.org Mon Nov 6 16:18:19 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Mon, 6 Nov 2023 16:18:19 GMT Subject: RFR: 8319423: Improve Year.isLeap by checking divisibility by 16 [v2] In-Reply-To: References: Message-ID: On Fri, 3 Nov 2023 23:22:27 GMT, Claes Redestad wrote: >> https://github.com/cassioneri/eaf suggest this code for leap year calculation: >> >> public static boolean isLeap(long year) { >> int d = year % 100 != 0 ? 4 : 16; >> return (year & (d - 1)) == 0; >> } >> >> .. with a claim this would compile down to branchless, easily pipelined code. >> >> This doesn't currently happen with C2. In the meantime I think we can improve the current code in `Year.isLeap` and `IsoChronology.isLeapYear` by leveraging the fact that the `% 100` check is only needed if `(year & 15) != 0`: >> >> >> public static boolean isLeap(long year) { >> return (year & 15) == 0 ? (year & 3) == 0 : (year & 3) == 0 && year % 100 != 0; >> } >> >> >> Mac M1: >> >> Name Cnt Base Error Test Error Unit Change >> LeapYearBench.isLeapYear 15 0,743 ? 0,009 0,994 ? 0,005 ops/us 1,34x (p = 0,000*) >> LeapYearBench.isLeapYearChrono 15 0,748 ? 0,006 0,991 ? 0,003 ops/us 1,32x (p = 0,000*) >> LeapYearBench.isLeapYearNS 15 0,558 ? 0,026 0,552 ? 0,033 ops/us 0,99x (p = 0,602 ) >> * = significant >> >> >> Linux x64: >> >> Name Cnt Base Error Test Error Unit Change >> LeapYearBench.isLeapYear 15 0.534 ? 0.001 0.765 ? 0.004 ops/us 1.43x (p = 0.000*) >> LeapYearBench.isLeapYearChrono 15 0.535 ? 0.000 0.753 ? 0.040 ops/us 1.41x (p = 0.000*) >> LeapYearBench.isLeapYearNS 15 0.352 ? 0.000 0.351 ? 0.001 ops/us 1.00x (p = 0.000*) >> * = significant >> >> >> 30% higher throughput on M1, 40% on x64. `isLeapYearNS` runs a variant of the code from https://github.com/cassioneri/eaf ported to java - perhaps the JIT can be improved to do whatever clang/gcc does here and achieve an even better speed-up. >> >> Testing: so far only java/time/tck/java/time locally, will run a few tiers before filing an enhancement and opening the PR for review. > > Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: > > Apply similar optimization to GregorianCalendar, sun.util.calendar Marked as reviewed by rriggs (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/16491#pullrequestreview-1715613111 From rriggs at openjdk.org Mon Nov 6 16:18:21 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Mon, 6 Nov 2023 16:18:21 GMT Subject: RFR: 8319423: Improve Year.isLeap by checking divisibility by 16 [v2] In-Reply-To: References: Message-ID: On Mon, 6 Nov 2023 00:50:22 GMT, Claes Redestad wrote: > I suggest we go ahead and integrate this, file an RFE to re-examine the division-by-constant in C2, then re-evaluate these `isLeapYear` micros in that new environment. These are good improvements and are beneficial with or without other fixes, so should go ahead independently. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16491#issuecomment-1795320991 From pminborg at openjdk.org Mon Nov 6 16:18:29 2023 From: pminborg at openjdk.org (Per Minborg) Date: Mon, 6 Nov 2023 16:18:29 GMT Subject: RFR: 8319324: FFM: Reformat javadocs [v5] In-Reply-To: <-CK9Ln5FZQ2oX4RZ04Ltx1mzgxdt8qDnaY_Wte_B6CQ=.588bdde5-55c2-476e-8024-8c6b34c72f82@github.com> References: <-CK9Ln5FZQ2oX4RZ04Ltx1mzgxdt8qDnaY_Wte_B6CQ=.588bdde5-55c2-476e-8024-8c6b34c72f82@github.com> Message-ID: > This PR proposes to reformat all the JavaDocs for the FFM API. This would bring the FFM API docs more in line with the existing Java documentation (see below). Occasional drive-by fixes are also included in this PR (such as spelling and capitalization). > > I am aware this PR will (if approved) make a significant mark in the change logs which is regrettable. > > Background: > > Older classes like `Object` and `List` have a maximum line length of 80 characters whereas newer classes like `ScopedValue` have a maximum line length of 90 characters. > > The FFM API currently has javadoc lines that exceed 135 characters per line. It is also customary to use double spaces when starting a new sentence. Per Minborg has updated the pull request incrementally with one additional commit since the last revision: Remove double spaces after full stops ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16518/files - new: https://git.openjdk.org/jdk/pull/16518/files/b37bd31c..a24344fb Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16518&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16518&range=03-04 Stats: 390 lines in 13 files changed: 0 ins; 0 del; 390 mod Patch: https://git.openjdk.org/jdk/pull/16518.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16518/head:pull/16518 PR: https://git.openjdk.org/jdk/pull/16518 From rriggs at openjdk.org Mon Nov 6 16:28:22 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Mon, 6 Nov 2023 16:28:22 GMT Subject: RFR: 8311906: Improve robustness of String constructors with mutable array inputs Message-ID: <6SKlGLh5MmxoEx07wHCCUc8KWbbhcspLJmcc1uxQ_FI=.ca33bfb4-fa5c-45f0-b49f-ee6c5c6b68b4@github.com> Strings, after construction, are immutable but may be constructed from mutable arrays of bytes, characters, or integers. The string constructors should guard against the effects of mutating the arrays during construction that might invalidate internal invariants for the correct behavior of operations on the resulting strings. In particular, a number of operations have optimizations for operations on pairs of latin1 strings and pairs of non-latin1 strings, while operations between latin1 and non-latin1 strings use a more general implementation. The changes include: - Adding a warning to each constructor with an array as an argument to indicate that the results are indeterminate if the input array is modified before the constructor returns. The resulting string may contain any combination of characters sampled from the input array. - Ensure that strings that are represented as non-latin1 contain at least one non-latin1 character. For latin1 inputs, whether the arrays contain ASCII, ISO-8859-1, UTF8, or another encoding decoded to latin1 the scanning and compression is unchanged. If a non-latin1 character is found, the string is represented as non-latin1 with the added verification that a non-latin1 character is present at the same index. If that character is found to be latin1, then the input array has been modified and the result of the scan may be incorrect. Though a ConcurrentModificationException could be thrown, the risk to an existing application of an unexpected exception should be avoided. Instead, the non-latin1 copy of the input is re-scanned and compressed; that scan determines whether the latin1 or the non-latin1 representation is returned. - The methods that scan for non-latin1 characters and their intrinsic implementations are updated to return the index of the non-latin1 character. - String construction from StringBuilder and CharSequence must also be guarded as their contents may be modified during construction. ------------- Commit messages: - Cleanup javadoc, whitespace, and formatting in the JMH benchmark - Update RiscV implementation of intrinsic for java.lang.StringUTF16.compress - Javadoc formatting - 8311906: Improve robustness of String constructors with mutable array arguments Changes: https://git.openjdk.org/jdk/pull/16425/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16425&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8311906 Stats: 1057 lines in 11 files changed: 859 ins; 82 del; 116 mod Patch: https://git.openjdk.org/jdk/pull/16425.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16425/head:pull/16425 PR: https://git.openjdk.org/jdk/pull/16425 From jpai at openjdk.org Mon Nov 6 16:28:22 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 6 Nov 2023 16:28:22 GMT Subject: RFR: 8311906: Improve robustness of String constructors with mutable array inputs In-Reply-To: <6SKlGLh5MmxoEx07wHCCUc8KWbbhcspLJmcc1uxQ_FI=.ca33bfb4-fa5c-45f0-b49f-ee6c5c6b68b4@github.com> References: <6SKlGLh5MmxoEx07wHCCUc8KWbbhcspLJmcc1uxQ_FI=.ca33bfb4-fa5c-45f0-b49f-ee6c5c6b68b4@github.com> Message-ID: On Mon, 30 Oct 2023 18:34:44 GMT, Roger Riggs wrote: > Strings, after construction, are immutable but may be constructed from mutable arrays of bytes, characters, or integers. > The string constructors should guard against the effects of mutating the arrays during construction that might invalidate internal invariants for the correct behavior of operations on the resulting strings. In particular, a number of operations have optimizations for operations on pairs of latin1 strings and pairs of non-latin1 strings, while operations between latin1 and non-latin1 strings use a more general implementation. > > The changes include: > > - Adding a warning to each constructor with an array as an argument to indicate that the results are indeterminate > if the input array is modified before the constructor returns. > The resulting string may contain any combination of characters sampled from the input array. > > - Ensure that strings that are represented as non-latin1 contain at least one non-latin1 character. > For latin1 inputs, whether the arrays contain ASCII, ISO-8859-1, UTF8, or another encoding decoded to latin1 the scanning and compression is unchanged. > If a non-latin1 character is found, the string is represented as non-latin1 with the added verification that a non-latin1 character is present at the same index. > If that character is found to be latin1, then the input array has been modified and the result of the scan may be incorrect. > Though a ConcurrentModificationException could be thrown, the risk to an existing application of an unexpected exception should be avoided. > Instead, the non-latin1 copy of the input is re-scanned and compressed; that scan determines whether the latin1 or the non-latin1 representation is returned. > > - The methods that scan for non-latin1 characters and their intrinsic implementations are updated to return the index of the non-latin1 character. > > - String construction from StringBuilder and CharSequence must also be guarded as their contents may be modified during construction. Hello Roger, it looks like there are some whitespace related issues in the changes which jcheck has caught https://github.com/openjdk/jdk/pull/16425/checks?check_run_id=18357062638 and thus hasn't created a RFR for this yet. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16425#issuecomment-1793738211 From duke at openjdk.org Mon Nov 6 16:28:25 2023 From: duke at openjdk.org (ExE Boss) Date: Mon, 6 Nov 2023 16:28:25 GMT Subject: RFR: 8311906: Improve robustness of String constructors with mutable array inputs In-Reply-To: <6SKlGLh5MmxoEx07wHCCUc8KWbbhcspLJmcc1uxQ_FI=.ca33bfb4-fa5c-45f0-b49f-ee6c5c6b68b4@github.com> References: <6SKlGLh5MmxoEx07wHCCUc8KWbbhcspLJmcc1uxQ_FI=.ca33bfb4-fa5c-45f0-b49f-ee6c5c6b68b4@github.com> Message-ID: On Mon, 30 Oct 2023 18:34:44 GMT, Roger Riggs wrote: > Strings, after construction, are immutable but may be constructed from mutable arrays of bytes, characters, or integers. > The string constructors should guard against the effects of mutating the arrays during construction that might invalidate internal invariants for the correct behavior of operations on the resulting strings. In particular, a number of operations have optimizations for operations on pairs of latin1 strings and pairs of non-latin1 strings, while operations between latin1 and non-latin1 strings use a more general implementation. > > The changes include: > > - Adding a warning to each constructor with an array as an argument to indicate that the results are indeterminate > if the input array is modified before the constructor returns. > The resulting string may contain any combination of characters sampled from the input array. > > - Ensure that strings that are represented as non-latin1 contain at least one non-latin1 character. > For latin1 inputs, whether the arrays contain ASCII, ISO-8859-1, UTF8, or another encoding decoded to latin1 the scanning and compression is unchanged. > If a non-latin1 character is found, the string is represented as non-latin1 with the added verification that a non-latin1 character is present at the same index. > If that character is found to be latin1, then the input array has been modified and the result of the scan may be incorrect. > Though a ConcurrentModificationException could be thrown, the risk to an existing application of an unexpected exception should be avoided. > Instead, the non-latin1 copy of the input is re-scanned and compressed; that scan determines whether the latin1 or the non-latin1 representation is returned. > > - The methods that scan for non-latin1 characters and their intrinsic implementations are updated to return the index of the non-latin1 character. > > - String construction from StringBuilder and CharSequence must also be guarded as their contents may be modified during construction. src/java.base/share/classes/java/lang/String.java line 566: > 564: } > 565: // Decode with a stable copy, to be the result if the decoded length is the same > 566: byte[] latin1 = Arrays.copyOfRange(bytes, offset, offset + length); This?has to?be?moved before?the?`if (dp == length) { ? }` check, as?that also?does a?copy: // Decode with a stable copy, to be the result if the decoded length is the same byte[] latin1 = Arrays.copyOfRange(bytes, offset, offset + length); int dp = StringCoding.countPositives(latin1, offset, length); if (dp == length) { this.value = latin1; this.coder = LATIN1; return; } ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16425#discussion_r1382576891 From rriggs at openjdk.org Mon Nov 6 16:28:25 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Mon, 6 Nov 2023 16:28:25 GMT Subject: RFR: 8311906: Improve robustness of String constructors with mutable array inputs In-Reply-To: References: <6SKlGLh5MmxoEx07wHCCUc8KWbbhcspLJmcc1uxQ_FI=.ca33bfb4-fa5c-45f0-b49f-ee6c5c6b68b4@github.com> Message-ID: <8XE-J0reitsGrDsDulsRZfbzrDEKGNFpGKHoC0xdZC4=.ccd97d94-7453-44ae-ba25-c2a5d41affab@github.com> On Sun, 5 Nov 2023 13:32:20 GMT, ExE Boss wrote: >> Strings, after construction, are immutable but may be constructed from mutable arrays of bytes, characters, or integers. >> The string constructors should guard against the effects of mutating the arrays during construction that might invalidate internal invariants for the correct behavior of operations on the resulting strings. In particular, a number of operations have optimizations for operations on pairs of latin1 strings and pairs of non-latin1 strings, while operations between latin1 and non-latin1 strings use a more general implementation. >> >> The changes include: >> >> - Adding a warning to each constructor with an array as an argument to indicate that the results are indeterminate >> if the input array is modified before the constructor returns. >> The resulting string may contain any combination of characters sampled from the input array. >> >> - Ensure that strings that are represented as non-latin1 contain at least one non-latin1 character. >> For latin1 inputs, whether the arrays contain ASCII, ISO-8859-1, UTF8, or another encoding decoded to latin1 the scanning and compression is unchanged. >> If a non-latin1 character is found, the string is represented as non-latin1 with the added verification that a non-latin1 character is present at the same index. >> If that character is found to be latin1, then the input array has been modified and the result of the scan may be incorrect. >> Though a ConcurrentModificationException could be thrown, the risk to an existing application of an unexpected exception should be avoided. >> Instead, the non-latin1 copy of the input is re-scanned and compressed; that scan determines whether the latin1 or the non-latin1 representation is returned. >> >> - The methods that scan for non-latin1 characters and their intrinsic implementations are updated to return the index of the non-latin1 character. >> >> - String construction from StringBuilder and CharSequence must also be guarded as their contents may be modified during construction. > > src/java.base/share/classes/java/lang/String.java line 566: > >> 564: } >> 565: // Decode with a stable copy, to be the result if the decoded length is the same >> 566: byte[] latin1 = Arrays.copyOfRange(bytes, offset, offset + length); > > This?has to?be?moved before?the?`if (dp == length) { ? }` check, as?that also?does a?copy: > > // Decode with a stable copy, to be the result if the decoded length is the same > byte[] latin1 = Arrays.copyOfRange(bytes, offset, offset + length); > int dp = StringCoding.countPositives(latin1, offset, length); > if (dp == length) { > this.value = latin1; > this.coder = LATIN1; > return; > } That may look like an improvement, to share common code, but it results in a performance hit in the normal case. The best performing case is to copy and return immediately. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16425#discussion_r1383539522 From liach at openjdk.org Mon Nov 6 16:28:27 2023 From: liach at openjdk.org (Chen Liang) Date: Mon, 6 Nov 2023 16:28:27 GMT Subject: RFR: 8311906: Improve robustness of String constructors with mutable array inputs In-Reply-To: <6SKlGLh5MmxoEx07wHCCUc8KWbbhcspLJmcc1uxQ_FI=.ca33bfb4-fa5c-45f0-b49f-ee6c5c6b68b4@github.com> References: <6SKlGLh5MmxoEx07wHCCUc8KWbbhcspLJmcc1uxQ_FI=.ca33bfb4-fa5c-45f0-b49f-ee6c5c6b68b4@github.com> Message-ID: <6Z8gWGyohCB0dp1gfe7-K-HDFpYHtn7jjwTsNt0XujY=.d756475b-6a44-44fc-854c-a5bd5290eb1c@github.com> On Mon, 30 Oct 2023 18:34:44 GMT, Roger Riggs wrote: > Strings, after construction, are immutable but may be constructed from mutable arrays of bytes, characters, or integers. > The string constructors should guard against the effects of mutating the arrays during construction that might invalidate internal invariants for the correct behavior of operations on the resulting strings. In particular, a number of operations have optimizations for operations on pairs of latin1 strings and pairs of non-latin1 strings, while operations between latin1 and non-latin1 strings use a more general implementation. > > The changes include: > > - Adding a warning to each constructor with an array as an argument to indicate that the results are indeterminate > if the input array is modified before the constructor returns. > The resulting string may contain any combination of characters sampled from the input array. > > - Ensure that strings that are represented as non-latin1 contain at least one non-latin1 character. > For latin1 inputs, whether the arrays contain ASCII, ISO-8859-1, UTF8, or another encoding decoded to latin1 the scanning and compression is unchanged. > If a non-latin1 character is found, the string is represented as non-latin1 with the added verification that a non-latin1 character is present at the same index. > If that character is found to be latin1, then the input array has been modified and the result of the scan may be incorrect. > Though a ConcurrentModificationException could be thrown, the risk to an existing application of an unexpected exception should be avoided. > Instead, the non-latin1 copy of the input is re-scanned and compressed; that scan determines whether the latin1 or the non-latin1 representation is returned. > > - The methods that scan for non-latin1 characters and their intrinsic implementations are updated to return the index of the non-latin1 character. > > - String construction from StringBuilder and CharSequence must also be guarded as their contents may be modified during construction. src/java.base/share/classes/java/lang/StringUTF16.java line 202: > 200: @ForceInline > 201: public static byte[] compress(final char[] val, final int off, final int count) { > 202: byte[] latin1 = new byte[count]; Will this redundant array allocation be costly if we are working with mostly-utf16 strings, such as CJK strings with no latin characters? I suggest we can use a heuristic to read the initial char; if it's utf16 then we skip the latin-1 process altogether (and we can assign the utf16 value to the initial index to ensure it's non-latin-1 compressible. src/java.base/share/classes/java/lang/StringUTF16.java line 411: > 409: return 2; > 410: } else > 411: throw new IllegalArgumentException(Integer.toString(codePoint)); `toHexString` might be more informative. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16425#discussion_r1382296222 PR Review Comment: https://git.openjdk.org/jdk/pull/16425#discussion_r1382304769 From rriggs at openjdk.org Mon Nov 6 16:28:28 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Mon, 6 Nov 2023 16:28:28 GMT Subject: RFR: 8311906: Improve robustness of String constructors with mutable array inputs In-Reply-To: <6Z8gWGyohCB0dp1gfe7-K-HDFpYHtn7jjwTsNt0XujY=.d756475b-6a44-44fc-854c-a5bd5290eb1c@github.com> References: <6SKlGLh5MmxoEx07wHCCUc8KWbbhcspLJmcc1uxQ_FI=.ca33bfb4-fa5c-45f0-b49f-ee6c5c6b68b4@github.com> <6Z8gWGyohCB0dp1gfe7-K-HDFpYHtn7jjwTsNt0XujY=.d756475b-6a44-44fc-854c-a5bd5290eb1c@github.com> Message-ID: On Sat, 4 Nov 2023 00:07:33 GMT, Chen Liang wrote: >> Strings, after construction, are immutable but may be constructed from mutable arrays of bytes, characters, or integers. >> The string constructors should guard against the effects of mutating the arrays during construction that might invalidate internal invariants for the correct behavior of operations on the resulting strings. In particular, a number of operations have optimizations for operations on pairs of latin1 strings and pairs of non-latin1 strings, while operations between latin1 and non-latin1 strings use a more general implementation. >> >> The changes include: >> >> - Adding a warning to each constructor with an array as an argument to indicate that the results are indeterminate >> if the input array is modified before the constructor returns. >> The resulting string may contain any combination of characters sampled from the input array. >> >> - Ensure that strings that are represented as non-latin1 contain at least one non-latin1 character. >> For latin1 inputs, whether the arrays contain ASCII, ISO-8859-1, UTF8, or another encoding decoded to latin1 the scanning and compression is unchanged. >> If a non-latin1 character is found, the string is represented as non-latin1 with the added verification that a non-latin1 character is present at the same index. >> If that character is found to be latin1, then the input array has been modified and the result of the scan may be incorrect. >> Though a ConcurrentModificationException could be thrown, the risk to an existing application of an unexpected exception should be avoided. >> Instead, the non-latin1 copy of the input is re-scanned and compressed; that scan determines whether the latin1 or the non-latin1 representation is returned. >> >> - The methods that scan for non-latin1 characters and their intrinsic implementations are updated to return the index of the non-latin1 character. >> >> - String construction from StringBuilder and CharSequence must also be guarded as their contents may be modified during construction. > > src/java.base/share/classes/java/lang/StringUTF16.java line 202: > >> 200: @ForceInline >> 201: public static byte[] compress(final char[] val, final int off, final int count) { >> 202: byte[] latin1 = new byte[count]; > > Will this redundant array allocation be costly if we are working with mostly-utf16 strings, such as CJK strings with no latin characters? > > I suggest we can use a heuristic to read the initial char; if it's utf16 then we skip the latin-1 process altogether (and we can assign the utf16 value to the initial index to ensure it's non-latin-1 compressible. We can reconsider this design as a separate PR. Every additional check has a performance impact and in this bug the goal is to avoid any regression. We'll need to gain some insight into the distribution of strings when used in a non-latin1 application. How many of the strings are latin1 vs non-latin1, what is the distribution of string lengths and which APIs are in use in the applications. The implementation is already pretty good about working with strings of different coders but there may be some different choices when converting between char arrays and int arrays and strings. > src/java.base/share/classes/java/lang/StringUTF16.java line 411: > >> 409: return 2; >> 410: } else >> 411: throw new IllegalArgumentException(Integer.toString(codePoint)); > > `toHexString` might be more informative. Perhaps, but changing the exception text is out scope for this PR; it has been decimal since JDK 9 (2015). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16425#discussion_r1383521445 PR Review Comment: https://git.openjdk.org/jdk/pull/16425#discussion_r1383527621 From pminborg at openjdk.org Mon Nov 6 16:55:22 2023 From: pminborg at openjdk.org (Per Minborg) Date: Mon, 6 Nov 2023 16:55:22 GMT Subject: RFR: 8319324: FFM: Reformat javadocs [v6] In-Reply-To: <-CK9Ln5FZQ2oX4RZ04Ltx1mzgxdt8qDnaY_Wte_B6CQ=.588bdde5-55c2-476e-8024-8c6b34c72f82@github.com> References: <-CK9Ln5FZQ2oX4RZ04Ltx1mzgxdt8qDnaY_Wte_B6CQ=.588bdde5-55c2-476e-8024-8c6b34c72f82@github.com> Message-ID: <09NPsuw-EJDoBQGe7ge6-QTnF6CV3i_07oklMRGE71o=.d227a484-b75a-40e9-a00a-bec7ab302439@github.com> > This PR proposes to reformat all the JavaDocs for the FFM API. This would bring the FFM API docs more in line with the existing Java documentation (see below). Occasional drive-by fixes are also included in this PR (such as spelling and capitalization). > > I am aware this PR will (if approved) make a significant mark in the change logs which is regrettable. > > Background: > > Older classes like `Object` and `List` have a maximum line length of 80 characters whereas newer classes like `ScopedValue` have a maximum line length of 90 characters. > > The FFM API currently has javadoc lines that exceed 135 characters per line. It is also customary to use double spaces when starting a new sentence. Per Minborg has updated the pull request incrementally with one additional commit since the last revision: Harmonize the use of full stops in tags ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16518/files - new: https://git.openjdk.org/jdk/pull/16518/files/a24344fb..114ba07d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16518&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16518&range=04-05 Stats: 381 lines in 11 files changed: 5 ins; 1 del; 375 mod Patch: https://git.openjdk.org/jdk/pull/16518.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16518/head:pull/16518 PR: https://git.openjdk.org/jdk/pull/16518 From pminborg at openjdk.org Mon Nov 6 17:23:18 2023 From: pminborg at openjdk.org (Per Minborg) Date: Mon, 6 Nov 2023 17:23:18 GMT Subject: RFR: 8319324: FFM: Reformat javadocs [v7] In-Reply-To: <-CK9Ln5FZQ2oX4RZ04Ltx1mzgxdt8qDnaY_Wte_B6CQ=.588bdde5-55c2-476e-8024-8c6b34c72f82@github.com> References: <-CK9Ln5FZQ2oX4RZ04Ltx1mzgxdt8qDnaY_Wte_B6CQ=.588bdde5-55c2-476e-8024-8c6b34c72f82@github.com> Message-ID: > This PR proposes to reformat all the JavaDocs for the FFM API. This would bring the FFM API docs more in line with the existing Java documentation (see below). Occasional drive-by fixes are also included in this PR (such as spelling and capitalization). > > I am aware this PR will (if approved) make a significant mark in the change logs which is regrettable. > > Background: > > Older classes like `Object` and `List` have a maximum line length of 80 characters whereas newer classes like `ScopedValue` have a maximum line length of 90 characters. > > The FFM API currently has javadoc lines that exceed 135 characters per line. It is also customary to use double spaces when starting a new sentence. Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits: - Merge master and update Linker formatting - Harmonize the use of full stops in tags - Remove double spaces after full stops - Review classes not in the foreign package - Update after review - Merge master - Reformat javadocs - FFM: Harmonize the @throws tags in the javadocs - Merge branch 'master' into javadoc-throws - Harmonize some of the javadoc throws ------------- Changes: https://git.openjdk.org/jdk/pull/16518/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16518&range=06 Stats: 3021 lines in 16 files changed: 868 ins; 18 del; 2135 mod Patch: https://git.openjdk.org/jdk/pull/16518.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16518/head:pull/16518 PR: https://git.openjdk.org/jdk/pull/16518 From pminborg at openjdk.org Mon Nov 6 17:35:31 2023 From: pminborg at openjdk.org (Per Minborg) Date: Mon, 6 Nov 2023 17:35:31 GMT Subject: RFR: 8319324: FFM: Reformat javadocs [v8] In-Reply-To: <-CK9Ln5FZQ2oX4RZ04Ltx1mzgxdt8qDnaY_Wte_B6CQ=.588bdde5-55c2-476e-8024-8c6b34c72f82@github.com> References: <-CK9Ln5FZQ2oX4RZ04Ltx1mzgxdt8qDnaY_Wte_B6CQ=.588bdde5-55c2-476e-8024-8c6b34c72f82@github.com> Message-ID: > This PR proposes to reformat all the JavaDocs for the FFM API. This would bring the FFM API docs more in line with the existing Java documentation (see below). Occasional drive-by fixes are also included in this PR (such as spelling and capitalization). > > I am aware this PR will (if approved) make a significant mark in the change logs which is regrettable. > > Background: > > Older classes like `Object` and `List` have a maximum line length of 80 characters whereas newer classes like `ScopedValue` have a maximum line length of 90 characters. > > The FFM API currently has javadoc lines that exceed 135 characters per line. It is also customary to use double spaces when starting a new sentence. Per Minborg has updated the pull request incrementally with one additional commit since the last revision: Remove additional redundant full stops ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16518/files - new: https://git.openjdk.org/jdk/pull/16518/files/1cbb951f..94518ac5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16518&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16518&range=06-07 Stats: 34 lines in 6 files changed: 0 ins; 0 del; 34 mod Patch: https://git.openjdk.org/jdk/pull/16518.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16518/head:pull/16518 PR: https://git.openjdk.org/jdk/pull/16518 From mcimadamore at openjdk.org Mon Nov 6 17:49:43 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 6 Nov 2023 17:49:43 GMT Subject: RFR: 8319324: FFM: Reformat javadocs [v8] In-Reply-To: References: <-CK9Ln5FZQ2oX4RZ04Ltx1mzgxdt8qDnaY_Wte_B6CQ=.588bdde5-55c2-476e-8024-8c6b34c72f82@github.com> Message-ID: On Mon, 6 Nov 2023 17:35:31 GMT, Per Minborg wrote: >> This PR proposes to reformat all the JavaDocs for the FFM API. This would bring the FFM API docs more in line with the existing Java documentation (see below). Occasional drive-by fixes are also included in this PR (such as spelling and capitalization). >> >> I am aware this PR will (if approved) make a significant mark in the change logs which is regrettable. >> >> Background: >> >> Older classes like `Object` and `List` have a maximum line length of 80 characters whereas newer classes like `ScopedValue` have a maximum line length of 90 characters. >> >> The FFM API currently has javadoc lines that exceed 135 characters per line. It is also customary to use double spaces when starting a new sentence. > > Per Minborg has updated the pull request incrementally with one additional commit since the last revision: > > Remove additional redundant full stops src/java.base/share/classes/java/lang/foreign/MemoryLayout.java line 510: > 508: * the given alignment constraint (in bytes)} > 509: * > 510: * @param byteAlignment the layout alignment constraint, expressed in bytes. period? src/java.base/share/classes/java/lang/foreign/MemoryLayout.java line 848: > 846: > 847: /** > 848: * Returns a path element which selects a member layout with the given name in a It feels like the javadoc of the methods in here can be tightened using `{@return}`. Maybe for another PR. src/java.base/share/classes/java/lang/foreign/MemoryLayout.java line 1017: > 1015: * @param elementCount the sequence element count > 1016: * @param elementLayout the sequence element layout > 1017: * @return the new sequence layout with the given element layout and size. period? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16518#discussion_r1383726736 PR Review Comment: https://git.openjdk.org/jdk/pull/16518#discussion_r1383728935 PR Review Comment: https://git.openjdk.org/jdk/pull/16518#discussion_r1383729384 From mcimadamore at openjdk.org Mon Nov 6 18:07:05 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 6 Nov 2023 18:07:05 GMT Subject: RFR: 8319324: FFM: Reformat javadocs [v8] In-Reply-To: References: <-CK9Ln5FZQ2oX4RZ04Ltx1mzgxdt8qDnaY_Wte_B6CQ=.588bdde5-55c2-476e-8024-8c6b34c72f82@github.com> Message-ID: On Mon, 6 Nov 2023 17:35:31 GMT, Per Minborg wrote: >> This PR proposes to reformat all the JavaDocs for the FFM API. This would bring the FFM API docs more in line with the existing Java documentation (see below). Occasional drive-by fixes are also included in this PR (such as spelling and capitalization). >> >> I am aware this PR will (if approved) make a significant mark in the change logs which is regrettable. >> >> Background: >> >> Older classes like `Object` and `List` have a maximum line length of 80 characters whereas newer classes like `ScopedValue` have a maximum line length of 90 characters. >> >> The FFM API currently has javadoc lines that exceed 135 characters per line. It is also customary to use double spaces when starting a new sentence. > > Per Minborg has updated the pull request incrementally with one additional commit since the last revision: > > Remove additional redundant full stops Looks good. I found some (few) sentences that still have a full stop in `@param`/`@throws` src/java.base/share/classes/java/nio/channels/FileChannel.java line 1072: > 1070: * @throws WrongThreadException > 1071: * If {@code arena} is a confined scoped arena, and this method is called > 1072: * from a thread {@code T}, other than the scoped arena's owner thread. period? ------------- PR Review: https://git.openjdk.org/jdk/pull/16518#pullrequestreview-1715840997 PR Review Comment: https://git.openjdk.org/jdk/pull/16518#discussion_r1383737974 From vromero at openjdk.org Mon Nov 6 18:15:02 2023 From: vromero at openjdk.org (Vicente Romero) Date: Mon, 6 Nov 2023 18:15:02 GMT Subject: RFR: 8318144: Match on enum constants with body compiles but fails with MatchException [v2] In-Reply-To: References: Message-ID: On Mon, 6 Nov 2023 07:34:38 GMT, Jan Lahoda wrote: >> For code like: >> >> enum E {A {}, B {} } >> Object o = E.A; >> switch (o) { >> case E.A -> System.err.println(o); >> default -> System.err.println("default"); >> } >> >> >> The result is `default`, not `A`, due to incorrect classes being compared. Thanks for @liach for noting the solution here: >> https://github.com/openjdk/jdk/pull/16489#discussion_r1381411165 > > Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: > > Re-ordering tests as suggested. src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 397: > 395: > 396: try { > 397: if (!(value instanceof Enum enumValue)) { this code seems to be here with the only purpose of casting `value` to `Enum`, if this is the case shouldn't this intention be more explicit? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16499#discussion_r1383763927 From serb at openjdk.org Mon Nov 6 18:54:53 2023 From: serb at openjdk.org (Sergey Bylokhov) Date: Mon, 6 Nov 2023 18:54:53 GMT Subject: RFR: 8318364: Add an FFM-based implementation of harfbuzz OpenType layout [v4] In-Reply-To: References: Message-ID: On Wed, 25 Oct 2023 23:42:08 GMT, Phil Race wrote: >> 8318364: Add an FFM-based implementation of harfbuzz OpenType layout > > Phil Race has updated the pull request incrementally with one additional commit since the last revision: > > indentation Since we plan to import it into jdk22, do you have some performance data to share? any positive or negative effects of this migration? ------------- PR Comment: https://git.openjdk.org/jdk/pull/15476#issuecomment-1795927326 From jlahoda at openjdk.org Mon Nov 6 18:54:51 2023 From: jlahoda at openjdk.org (Jan Lahoda) Date: Mon, 6 Nov 2023 18:54:51 GMT Subject: RFR: 8318144: Match on enum constants with body compiles but fails with MatchException [v2] In-Reply-To: References: Message-ID: <0I_yxepKVfvHRnAq5kgoadx_192mKjY6_EueJ8unkAw=.5929d59c-34e7-4a75-a29c-18b9b4f8f4e0@github.com> On Mon, 6 Nov 2023 18:12:10 GMT, Vicente Romero wrote: >> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: >> >> Re-ordering tests as suggested. > > src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 397: > >> 395: >> 396: try { >> 397: if (!(value instanceof Enum enumValue)) { > > this code seems to be here with the only purpose of casting `value` to `Enum`, if this is the case shouldn't this intention be more explicit? This method is also used in the `typeSwitch` (i.e. ordinary pattern matching switch, which may contain qualified enum constants intermixed with patterns), and so the `value` may be any object. If it is not an Enum, we can avoid the potential costly resolution. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16499#discussion_r1383814245 From sviswanathan at openjdk.org Mon Nov 6 18:58:47 2023 From: sviswanathan at openjdk.org (Sandhya Viswanathan) Date: Mon, 6 Nov 2023 18:58:47 GMT Subject: RFR: 8318650: Optimized subword gather for x86 targets. [v3] In-Reply-To: References: Message-ID: <7zOPXh6t5kkVls4Ug4jnNjETSJOLifZQrxfipQu-jiQ=.78bad780-b885-4043-8004-a883108a5a23@github.com> On Sun, 5 Nov 2023 12:58:57 GMT, Jatin Bhateja wrote: >> src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 1606: >> >>> 1604: void C2_MacroAssembler::vpgather8b_offset(BasicType elem_bt, XMMRegister dst, Register base, Register idx_base, >>> 1605: Register offset, Register rtmp, int vlen_enc) { >>> 1606: vpxor(dst, dst, dst, vlen_enc); >> >> Why the vpxor here and in vpgather8b. These are not masked gathers. > > This is to clear the vector gathering 8 subwords with each iteration. This is not a masked operation so every lane of dst will be written through pinsrw/pinsrb. An vpxor before is not required. >> src/hotspot/cpu/x86/x86.ad line 1921: >> >>> 1919: case Op_LoadVectorGatherMasked: >>> 1920: if (!is_subword_type(bt) && size_in_bits < 512 && !VM_Version::supports_avx512vl()) { >>> 1921: return false; >> >> Also need to return false when size_in_bits == 64 for non subword types. > > match_rule_supported_vector called in the beginning will enforce these checks. This method is match_rule_support_vector and it is not enforcing this check now. It was doing so before through fall through. >> src/hotspot/cpu/x86/x86.ad line 1939: >> >>> 1937: // fallthrough >>> 1938: case Op_LoadVectorGather: >>> 1939: if (!is_subword_type(bt) && size_in_bits == 64 ) { >> >> Since this is a fallthrough case, the change also applies to StoreVectorScatter*. The !is_subword_type() is needed only for LoadVectorGather. > > We do not intrinsify sub-word scatter operations currently. The StoreVectorScatter* should return false when size_in_bits == 64 irrespective of subword. It was doing so before and is not doing so now. >> src/hotspot/share/opto/vectorIntrinsics.cpp line 1579: >> >>> 1577: Node* index = argument(11); >>> 1578: Node* indexMap = argument(12); >>> 1579: Node* indexM = argument(13); >> >> Could be renamed as follows for better understanding: index -> offset, indexM -> indexOffset. Also this should be moved under else part of if (is_scatter). > > Naming scheme is based on the actual names used in intrinsic entry point for these arguments. How about moving this to else part as we are not using these for Scatter? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16354#discussion_r1383795523 PR Review Comment: https://git.openjdk.org/jdk/pull/16354#discussion_r1383799090 PR Review Comment: https://git.openjdk.org/jdk/pull/16354#discussion_r1383803037 PR Review Comment: https://git.openjdk.org/jdk/pull/16354#discussion_r1383818954 From sviswanathan at openjdk.org Mon Nov 6 18:58:50 2023 From: sviswanathan at openjdk.org (Sandhya Viswanathan) Date: Mon, 6 Nov 2023 18:58:50 GMT Subject: RFR: 8318650: Optimized subword gather for x86 targets. [v3] In-Reply-To: References: Message-ID: On Fri, 3 Nov 2023 22:44:39 GMT, Sandhya Viswanathan wrote: >> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: >> >> Restricting masked sub-word gather to AVX512 target to align with integral gather support. > > src/hotspot/cpu/x86/x86.ad line 4152: > >> 4150: >> 4151: instruct vgather_subwordLE8B_off(vec dst, memory mem, rRegP idx, rRegI offset, rRegP tmp, rRegI rtmp) %{ >> 4152: predicate(is_subword_type(Matcher::vector_element_basic_type(n)) && Matcher::vector_length_in_bytes(n) <= 8); > > !VM_Version::supports_avx512bw() is missing for non avx3 cases. This comment is still pending? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16354#discussion_r1383806980 From vromero at openjdk.org Mon Nov 6 19:04:29 2023 From: vromero at openjdk.org (Vicente Romero) Date: Mon, 6 Nov 2023 19:04:29 GMT Subject: RFR: 8318144: Match on enum constants with body compiles but fails with MatchException [v2] In-Reply-To: <0I_yxepKVfvHRnAq5kgoadx_192mKjY6_EueJ8unkAw=.5929d59c-34e7-4a75-a29c-18b9b4f8f4e0@github.com> References: <0I_yxepKVfvHRnAq5kgoadx_192mKjY6_EueJ8unkAw=.5929d59c-34e7-4a75-a29c-18b9b4f8f4e0@github.com> Message-ID: On Mon, 6 Nov 2023 18:51:59 GMT, Jan Lahoda wrote: >> src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 397: >> >>> 395: >>> 396: try { >>> 397: if (!(value instanceof Enum enumValue)) { >> >> this code seems to be here with the only purpose of casting `value` to `Enum`, if this is the case shouldn't this intention be more explicit? > > This method is also used in the `typeSwitch` (i.e. ordinary pattern matching switch, which may contain qualified enum constants intermixed with patterns), and so the `value` may be any object. If it is not an Enum, we can avoid the potential costly resolution. I see shouldn't we then have a test that stresses this code? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16499#discussion_r1383825208 From mchung at openjdk.org Mon Nov 6 19:19:05 2023 From: mchung at openjdk.org (Mandy Chung) Date: Mon, 6 Nov 2023 19:19:05 GMT Subject: RFR: 8319436: Proxy.newProxyInstance throws NPE if loader is null and interface not visible from class loader Message-ID: <3c9I42wkqwb6gtNvw3bowtyt4APRYb_L0DfscYe6KqU=.57b69660-b3f1-4d70-9189-8ad2601ab712@github.com> This is a regression caused by JDK-8302791. IAE should be thrown when an interface is not visible to the given class loader but NPE is thrown instead when the loader is null. The boot loader has no name and so the fix will print `null` in the exception message. `test/jdk/java/lang/reflect/Proxy/ClassRestrictions.java` is converted to junit and updated to test IAE thrown because proxy interface is not visible to null loader. ------------- Commit messages: - 8319436: Proxy.newProxyInstance throws NPE if loader is null and interface not visible from class loader Changes: https://git.openjdk.org/jdk/pull/16525/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16525&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8319436 Stats: 184 lines in 2 files changed: 63 ins; 96 del; 25 mod Patch: https://git.openjdk.org/jdk/pull/16525.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16525/head:pull/16525 PR: https://git.openjdk.org/jdk/pull/16525 From mchung at openjdk.org Mon Nov 6 19:32:56 2023 From: mchung at openjdk.org (Mandy Chung) Date: Mon, 6 Nov 2023 19:32:56 GMT Subject: RFR: 8187655: jdk.lambda.vm.InterfaceAccessFlagsTest.testPrivateMethodCall needs update after nestmates support Message-ID: `jdk.lambda.vm.InterfaceAccessFlagsTest` uses `ClassToInterfaceConverter` to mechanically convert a classfile for a Class into an in-memory class representation of an equivalent Interface. `testPrivateMethodCall` tests to invoke a private method. Before nestmates, invoking a private class method and a private interface method both use `Invokespecial`. With the nestmate changes, the class uses `invokevirtual` but the interface must use `invokeinterface` but this conversion is not handled by the existing `ClassToInterfaceConverter`. This fix converts `ClassToInterfaceConverter` to use the Class-File API to properly convert a classfile from a class to an interface including method invocation from `invokevirtual` to `invokeinterface`. The old custom bytecode manipulation code can be dropped. ------------- Commit messages: - 8187655: InterfaceAccessFlagsTest.testPrivateMethodCall needs update after nestmates support Changes: https://git.openjdk.org/jdk/pull/16526/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16526&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8187655 Stats: 594 lines in 5 files changed: 5 ins; 538 del; 51 mod Patch: https://git.openjdk.org/jdk/pull/16526.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16526/head:pull/16526 PR: https://git.openjdk.org/jdk/pull/16526 From jlaskey at openjdk.org Mon Nov 6 19:53:03 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Mon, 6 Nov 2023 19:53:03 GMT Subject: RFR: JDK-8315458 Implementation of Implicitly Declared Classes and Instance Main Method (Second Preview) [v13] In-Reply-To: References: Message-ID: > Address changes from JEP 445 to JEP 463. > > - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. > > - Don't mark class on read. > > - Remove reflection and annotation processing related to unnamed classes. > > - Simplify main method search. Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: Rename unnamed class tests and examples ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16461/files - new: https://git.openjdk.org/jdk/pull/16461/files/0bd5b477..3ffff0db Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16461&range=12 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16461&range=11-12 Stats: 24 lines in 8 files changed: 12 ins; 12 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/16461.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16461/head:pull/16461 PR: https://git.openjdk.org/jdk/pull/16461 From duke at openjdk.org Mon Nov 6 19:55:47 2023 From: duke at openjdk.org (null) Date: Mon, 6 Nov 2023 19:55:47 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: <8tfan-xBAwQ3hIY60I-sgQ11o5-cZRc0JktyuZuS9-4=.acf64231-1a14-4ad0-bc3d-7d86afb0684e@github.com> On Sun, 12 Mar 2023 21:28:59 GMT, null 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 > > null 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 will resolve merge conflicts ------------- PR Comment: https://git.openjdk.org/jdk/pull/3938#issuecomment-1796241336 From alanb at openjdk.org Mon Nov 6 19:56:30 2023 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 6 Nov 2023 19:56:30 GMT Subject: RFR: 8319436: Proxy.newProxyInstance throws NPE if loader is null and interface not visible from class loader In-Reply-To: <3c9I42wkqwb6gtNvw3bowtyt4APRYb_L0DfscYe6KqU=.57b69660-b3f1-4d70-9189-8ad2601ab712@github.com> References: <3c9I42wkqwb6gtNvw3bowtyt4APRYb_L0DfscYe6KqU=.57b69660-b3f1-4d70-9189-8ad2601ab712@github.com> Message-ID: <01b6Ld8gfAkVwto2OW9FTnUqXTpO2DoPuKNGjLQax7A=.9c87b4d3-2bb6-4fd9-a4b8-c633fa7098e0@github.com> On Mon, 6 Nov 2023 19:12:28 GMT, Mandy Chung wrote: > This is a regression caused by JDK-8302791. IAE should be thrown when an interface is not visible to the given class loader but NPE is thrown instead when the loader is null. The boot loader has no name and so the fix will print `null` in the exception message. `test/jdk/java/lang/reflect/Proxy/ClassRestrictions.java` is converted to junit and updated to test IAE thrown because proxy interface is not visible to null loader. test/jdk/java/lang/reflect/Proxy/ClassRestrictions.java line 61: > 59: } > 60: > 61: static Stream proxyInterfaces() { These are cases where IAE is expected so maybe the method source should be badProxyInterfaces to make it clearer that they are expected to fail? test/jdk/java/lang/reflect/Proxy/ClassRestrictions.java line 90: > 88: } catch (IllegalArgumentException e) { > 89: System.err.println(e.getMessage()); > 90: // assume exception is for intended failure The "throw new Error(message)" should be replaced with fail(message) or use assertThrows(IllegalArgument.class, () -> Proxy.getProxyClass(...)). test/jdk/java/lang/reflect/Proxy/ClassRestrictions.java line 105: > 103: if (Modifier.isPublic(nonPublic2.getModifiers())) { > 104: throw new Error("Interface " + nonPublicIntrfaceName + > 105: " is public and need to be changed!"); You could use assertEquals here, or at least replace the throw new Error with fail, up to you. test/jdk/java/lang/reflect/Proxy/ClassRestrictions.java line 125: > 123: > 124: private static final String[] CPATHS = System.getProperty("test.classes", ".") > 125: .split(File.pathSeparator); It might be a bit clearer to define TEST_CLASSES to be the value System.getProperty("test.classes", "."), and split it in testNonVisibleInterface. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16525#discussion_r1383882661 PR Review Comment: https://git.openjdk.org/jdk/pull/16525#discussion_r1383885042 PR Review Comment: https://git.openjdk.org/jdk/pull/16525#discussion_r1383886740 PR Review Comment: https://git.openjdk.org/jdk/pull/16525#discussion_r1383896386 From rriggs at openjdk.org Mon Nov 6 20:01:43 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Mon, 6 Nov 2023 20:01:43 GMT Subject: RFR: JDK-8315458 Implementation of Implicitly Declared Classes and Instance Main Method (Second Preview) [v13] In-Reply-To: References: Message-ID: On Mon, 6 Nov 2023 19:53:03 GMT, Jim Laskey wrote: >> Address changes from JEP 445 to JEP 463. >> >> - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. >> >> - Don't mark class on read. >> >> - Remove reflection and annotation processing related to unnamed classes. >> >> - Simplify main method search. > > Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: > > Rename unnamed class tests and examples Look good. Thanks ------------- Marked as reviewed by rriggs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16461#pullrequestreview-1716139190 From mchung at openjdk.org Mon Nov 6 20:02:29 2023 From: mchung at openjdk.org (Mandy Chung) Date: Mon, 6 Nov 2023 20:02:29 GMT Subject: RFR: 8319436: Proxy.newProxyInstance throws NPE if loader is null and interface not visible from class loader In-Reply-To: <01b6Ld8gfAkVwto2OW9FTnUqXTpO2DoPuKNGjLQax7A=.9c87b4d3-2bb6-4fd9-a4b8-c633fa7098e0@github.com> References: <3c9I42wkqwb6gtNvw3bowtyt4APRYb_L0DfscYe6KqU=.57b69660-b3f1-4d70-9189-8ad2601ab712@github.com> <01b6Ld8gfAkVwto2OW9FTnUqXTpO2DoPuKNGjLQax7A=.9c87b4d3-2bb6-4fd9-a4b8-c633fa7098e0@github.com> Message-ID: On Mon, 6 Nov 2023 19:46:40 GMT, Alan Bateman wrote: >> This is a regression caused by JDK-8302791. IAE should be thrown when an interface is not visible to the given class loader but NPE is thrown instead when the loader is null. The boot loader has no name and so the fix will print `null` in the exception message. `test/jdk/java/lang/reflect/Proxy/ClassRestrictions.java` is converted to junit and updated to test IAE thrown because proxy interface is not visible to null loader. > > test/jdk/java/lang/reflect/Proxy/ClassRestrictions.java line 90: > >> 88: } catch (IllegalArgumentException e) { >> 89: System.err.println(e.getMessage()); >> 90: // assume exception is for intended failure > > The "throw new Error(message)" could be replaced with fail(message) or use assertThrows(IllegalArgument.class, () -> Proxy.getProxyClass(...)). Will do. I should clean up more of the existing code. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16525#discussion_r1383905730 From pminborg at openjdk.org Mon Nov 6 20:08:45 2023 From: pminborg at openjdk.org (Per Minborg) Date: Mon, 6 Nov 2023 20:08:45 GMT Subject: RFR: 8319324: FFM: Reformat javadocs [v9] In-Reply-To: <-CK9Ln5FZQ2oX4RZ04Ltx1mzgxdt8qDnaY_Wte_B6CQ=.588bdde5-55c2-476e-8024-8c6b34c72f82@github.com> References: <-CK9Ln5FZQ2oX4RZ04Ltx1mzgxdt8qDnaY_Wte_B6CQ=.588bdde5-55c2-476e-8024-8c6b34c72f82@github.com> Message-ID: <5SR41-WFqAzy2p0W2vsgpbUM2uFesXOiatj3d4v1cmQ=.9b07412a-209c-45a6-9cb8-15957a6cd309@github.com> > This PR proposes to reformat all the JavaDocs for the FFM API. This would bring the FFM API docs more in line with the existing Java documentation (see below). Occasional drive-by fixes are also included in this PR (such as spelling and capitalization). > > I am aware this PR will (if approved) make a significant mark in the change logs which is regrettable. > > Background: > > Older classes like `Object` and `List` have a maximum line length of 80 characters whereas newer classes like `ScopedValue` have a maximum line length of 90 characters. > > The FFM API currently has javadoc lines that exceed 135 characters per line. It is also customary to use double spaces when starting a new sentence. Per Minborg has updated the pull request incrementally with one additional commit since the last revision: Update after additional reviews ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16518/files - new: https://git.openjdk.org/jdk/pull/16518/files/94518ac5..eef52287 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16518&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16518&range=07-08 Stats: 36 lines in 2 files changed: 0 ins; 10 del; 26 mod Patch: https://git.openjdk.org/jdk/pull/16518.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16518/head:pull/16518 PR: https://git.openjdk.org/jdk/pull/16518 From mchung at openjdk.org Mon Nov 6 20:22:43 2023 From: mchung at openjdk.org (Mandy Chung) Date: Mon, 6 Nov 2023 20:22:43 GMT Subject: RFR: 8319436: Proxy.newProxyInstance throws NPE if loader is null and interface not visible from class loader [v2] In-Reply-To: <3c9I42wkqwb6gtNvw3bowtyt4APRYb_L0DfscYe6KqU=.57b69660-b3f1-4d70-9189-8ad2601ab712@github.com> References: <3c9I42wkqwb6gtNvw3bowtyt4APRYb_L0DfscYe6KqU=.57b69660-b3f1-4d70-9189-8ad2601ab712@github.com> Message-ID: > This is a regression caused by JDK-8302791. IAE should be thrown when an interface is not visible to the given class loader but NPE is thrown instead when the loader is null. The boot loader has no name and so the fix will print `null` in the exception message. `test/jdk/java/lang/reflect/Proxy/ClassRestrictions.java` is converted to junit and updated to test IAE thrown because proxy interface is not visible to null loader. 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/16525/files - new: https://git.openjdk.org/jdk/pull/16525/files/5fef84a4..4be40b5d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16525&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16525&range=00-01 Stats: 65 lines in 1 file changed: 10 ins; 34 del; 21 mod Patch: https://git.openjdk.org/jdk/pull/16525.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16525/head:pull/16525 PR: https://git.openjdk.org/jdk/pull/16525 From jlahoda at openjdk.org Mon Nov 6 20:47:06 2023 From: jlahoda at openjdk.org (Jan Lahoda) Date: Mon, 6 Nov 2023 20:47:06 GMT Subject: RFR: 8318144: Match on enum constants with body compiles but fails with MatchException [v3] In-Reply-To: References: Message-ID: > For code like: > > enum E {A {}, B {} } > Object o = E.A; > switch (o) { > case E.A -> System.err.println(o); > default -> System.err.println("default"); > } > > > The result is `default`, not `A`, due to incorrect classes being compared. Thanks for @liach for noting the solution here: > https://github.com/openjdk/jdk/pull/16489#discussion_r1381411165 Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: Adding tests as suggested. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16499/files - new: https://git.openjdk.org/jdk/pull/16499/files/5f40a8eb..cbc9cb56 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16499&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16499&range=01-02 Stats: 12 lines in 2 files changed: 10 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/16499.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16499/head:pull/16499 PR: https://git.openjdk.org/jdk/pull/16499 From jlahoda at openjdk.org Mon Nov 6 20:47:06 2023 From: jlahoda at openjdk.org (Jan Lahoda) Date: Mon, 6 Nov 2023 20:47:06 GMT Subject: RFR: 8318144: Match on enum constants with body compiles but fails with MatchException [v2] In-Reply-To: References: <0I_yxepKVfvHRnAq5kgoadx_192mKjY6_EueJ8unkAw=.5929d59c-34e7-4a75-a29c-18b9b4f8f4e0@github.com> Message-ID: On Mon, 6 Nov 2023 19:01:38 GMT, Vicente Romero wrote: >> This method is also used in the `typeSwitch` (i.e. ordinary pattern matching switch, which may contain qualified enum constants intermixed with patterns), and so the `value` may be any object. If it is not an Enum, we can avoid the potential costly resolution. > > I see shouldn't we have a test that stresses this code? I mean that we are returning `false` for cases that are not enums? I thought there's quite a few such tests, but turns out there's just a few (or maybe only one). So adding some more: [cbc9cb5](https://github.com/openjdk/jdk/pull/16499/commits/cbc9cb569b06c2f3d5e503519082c6243b51f9c8). Thanks! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16499#discussion_r1383960309 From vromero at openjdk.org Mon Nov 6 21:04:32 2023 From: vromero at openjdk.org (Vicente Romero) Date: Mon, 6 Nov 2023 21:04:32 GMT Subject: RFR: 8318144: Match on enum constants with body compiles but fails with MatchException [v3] In-Reply-To: References: Message-ID: <0mHtAUXulQC-Wtq7GZEEBRPjhhEAFZRMAlSt6ottxwQ=.2ec4dfa2-4084-4962-9ec8-cef7cdb055f7@github.com> On Mon, 6 Nov 2023 20:47:06 GMT, Jan Lahoda wrote: >> For code like: >> >> enum E {A {}, B {} } >> Object o = E.A; >> switch (o) { >> case E.A -> System.err.println(o); >> default -> System.err.println("default"); >> } >> >> >> The result is `default`, not `A`, due to incorrect classes being compared. Thanks for @liach for noting the solution here: >> https://github.com/openjdk/jdk/pull/16489#discussion_r1381411165 > > Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: > > Adding tests as suggested. lgtm, thanks! ------------- Marked as reviewed by vromero (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16499#pullrequestreview-1716233470 From pminborg at openjdk.org Mon Nov 6 21:06:37 2023 From: pminborg at openjdk.org (Per Minborg) Date: Mon, 6 Nov 2023 21:06:37 GMT Subject: RFR: 8319560: Reformat method parameters in the FFM API Message-ID: This PR proposes to reformat some method parameters in the FFM API. The proposed changes are a bit opinion based eve though there are some underlying principles. ------------- Commit messages: - Harmonize method parameter layouts Changes: https://git.openjdk.org/jdk/pull/16527/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16527&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8319560 Stats: 28 lines in 4 files changed: 15 ins; 0 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/16527.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16527/head:pull/16527 PR: https://git.openjdk.org/jdk/pull/16527 From pminborg at openjdk.org Mon Nov 6 21:12:53 2023 From: pminborg at openjdk.org (Per Minborg) Date: Mon, 6 Nov 2023 21:12:53 GMT Subject: RFR: 8319556: Harmonize interface formatting in the FFM API Message-ID: This PR proposes to remove two `permits` declarations where the line overflows the stipulated maximum column with. Also, it proposes to harmonize the layout of `permit` formatting so they are the the same throughout the API. This PR might be perceived as over worked but I think it nice to get consistency across the API now that we go final. ------------- Commit messages: - Reformat interface permit declarations Changes: https://git.openjdk.org/jdk/pull/16528/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16528&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8319556 Stats: 44 lines in 11 files changed: 21 ins; 0 del; 23 mod Patch: https://git.openjdk.org/jdk/pull/16528.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16528/head:pull/16528 PR: https://git.openjdk.org/jdk/pull/16528 From pminborg at openjdk.org Mon Nov 6 21:13:44 2023 From: pminborg at openjdk.org (Per Minborg) Date: Mon, 6 Nov 2023 21:13:44 GMT Subject: RFR: 8319563: Reformat code in the FFM API Message-ID: <87jkoBHzhAxl9-lBhphlkaX66Lq18mo-cLpqW8z_tQk=.21fc7d4c-4bfb-4b32-9315-386bc8ddf935@github.com> This PR proposes to reformat a small number of code line for better appearance. ------------- Commit messages: - Reformat some code Changes: https://git.openjdk.org/jdk/pull/16529/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16529&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8319563 Stats: 12 lines in 3 files changed: 7 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/16529.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16529/head:pull/16529 PR: https://git.openjdk.org/jdk/pull/16529 From mcimadamore at openjdk.org Mon Nov 6 22:01:30 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 6 Nov 2023 22:01:30 GMT Subject: RFR: 8319324: FFM: Reformat javadocs [v9] In-Reply-To: <5SR41-WFqAzy2p0W2vsgpbUM2uFesXOiatj3d4v1cmQ=.9b07412a-209c-45a6-9cb8-15957a6cd309@github.com> References: <-CK9Ln5FZQ2oX4RZ04Ltx1mzgxdt8qDnaY_Wte_B6CQ=.588bdde5-55c2-476e-8024-8c6b34c72f82@github.com> <5SR41-WFqAzy2p0W2vsgpbUM2uFesXOiatj3d4v1cmQ=.9b07412a-209c-45a6-9cb8-15957a6cd309@github.com> Message-ID: On Mon, 6 Nov 2023 20:08:45 GMT, Per Minborg wrote: >> This PR proposes to reformat all the JavaDocs for the FFM API. This would bring the FFM API docs more in line with the existing Java documentation (see below). Occasional drive-by fixes are also included in this PR (such as spelling and capitalization). >> >> I am aware this PR will (if approved) make a significant mark in the change logs which is regrettable. >> >> Background: >> >> Older classes like `Object` and `List` have a maximum line length of 80 characters whereas newer classes like `ScopedValue` have a maximum line length of 90 characters. >> >> The FFM API currently has javadoc lines that exceed 135 characters per line. It is also customary to use double spaces when starting a new sentence. > > Per Minborg has updated the pull request incrementally with one additional commit since the last revision: > > Update after additional reviews src/java.base/share/classes/java/lang/foreign/MemoryLayout.java line 913: > 911: * @param step the step factor at which subsequence sequence elements are to be > 912: * selected > 913: * @return a path element which selects the sequence element layout in the Good catch! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16518#discussion_r1384074887 From bhuang at openjdk.org Mon Nov 6 22:33:54 2023 From: bhuang at openjdk.org (Bill Huang) Date: Mon, 6 Nov 2023 22:33:54 GMT Subject: RFR: JDK-8311961 Update Manual Test Groups for ATR JDK22 Message-ID: Updated jdk_core_manual test groups. ------------- Commit messages: - JDK-8311961 Update Manual Test Groups for ATR JDK22 Changes: https://git.openjdk.org/jdk/pull/16531/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16531&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8311961 Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/16531.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16531/head:pull/16531 PR: https://git.openjdk.org/jdk/pull/16531 From bpb at openjdk.org Mon Nov 6 22:36:50 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Mon, 6 Nov 2023 22:36:50 GMT Subject: RFR: 6478546: FileInputStream.read() throws OutOfMemoryError when there is plenty available [v6] In-Reply-To: References: Message-ID: > Limit native memory allocation and move write loop from the native layer into Java. This change should make the OOME reported in the issue much less likely. Brian Burkhalter has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision: - Merge - Merge - 6478546: do-while -> while-do in writeBytes; remove NULL and bounds checks in native - 6478546: Move buffer clamping up to Java layer; correct read behavior to match legacy - 6478546: Decrease malloc limit to 1.5 MB - 6478546: Minor refactoring - 6478546: Prevent short read - 6478546: FileInputStream.read() throws OutOfMemoryError when there is plenty available ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14981/files - new: https://git.openjdk.org/jdk/pull/14981/files/3a016a72..408e2df6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14981&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14981&range=04-05 Stats: 69129 lines in 2383 files changed: 38779 ins; 14073 del; 16277 mod Patch: https://git.openjdk.org/jdk/pull/14981.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14981/head:pull/14981 PR: https://git.openjdk.org/jdk/pull/14981 From egahlin at openjdk.org Mon Nov 6 22:44:30 2023 From: egahlin at openjdk.org (Erik Gahlin) Date: Mon, 6 Nov 2023 22:44:30 GMT Subject: RFR: 8319374: JFR: Remove instrumentation for exception events In-Reply-To: References: Message-ID: On Mon, 6 Nov 2023 15:49:02 GMT, Alan Bateman wrote: >> Could I have a review of a PR that removes the bytecode instrumentation for the exception events. >> >> Testing: jdk/jdk/jfr + tier1 + tier2 > > src/java.base/share/classes/jdk/internal/event/ThrowableTracer.java line 37: > >> 35: private static final AtomicLong numThrowables = new AtomicLong(); >> 36: >> 37: public static void enable() throws NoSuchFieldException, SecurityException, IllegalArgumentException, IllegalAccessException { > > SecurityException and IllegaArgumentException are unchecked so don't need them in the throws declaration. Will fix. > src/java.base/share/classes/jdk/internal/event/ThrowableTracer.java line 44: > >> 42: >> 43: public static void traceError(Class clazz, String message) { >> 44: if (OutOfMemoryError.class.isAssignableFrom(clazz)) { > > StackOverflowError is likely problematic too, maybe it should be VirtualMachineError. I remember asking the same question ten years ago, when Nils did the original implementation, but I think it was only needed for OOM, because it creates an infinite loop when the event object was allocated, which resulted in a StackOverflowError instead OOM. Some OOM tests failed with JFR enabled. The event object allocation has been removed, but I think we can run into the allocation recursion by other means. I looked into it a few years ago, but I don't remember exactly why it failed. If a SOE happens, I think we are fine. There is something that prevents infinite recursion when the SOE object is created. Perhaps it is preallocated? I prefer to not change the behavior, at least not in this PR. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16493#discussion_r1384124648 PR Review Comment: https://git.openjdk.org/jdk/pull/16493#discussion_r1384124213 From egahlin at openjdk.org Mon Nov 6 22:52:50 2023 From: egahlin at openjdk.org (Erik Gahlin) Date: Mon, 6 Nov 2023 22:52:50 GMT Subject: RFR: 8319374: JFR: Remove instrumentation for exception events [v2] In-Reply-To: References: Message-ID: > Could I have a review of a PR that removes the bytecode instrumentation for the exception events. > > Testing: jdk/jdk/jfr + tier1 + tier2 Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision: Remove SecurityException and IllegalArgumentException from throws clause ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16493/files - new: https://git.openjdk.org/jdk/pull/16493/files/95a54349..23a07a18 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16493&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16493&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/16493.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16493/head:pull/16493 PR: https://git.openjdk.org/jdk/pull/16493 From rriggs at openjdk.org Mon Nov 6 22:55:10 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Mon, 6 Nov 2023 22:55:10 GMT Subject: RFR: 8319378: Spec for j.util.Timer::purge and j.util.Timer::cancel could be improved In-Reply-To: References: Message-ID: On Fri, 3 Nov 2023 20:40:11 GMT, Justin Lu wrote: > Please review this PR which clarifies the definition of a _cancelled_ task in _j.util.Timer::purge_ and _j.util.Timer::cancel_. > > Timer::purge claims that its return value is the number of tasks in the queue that were cancelled. This can be misleading, as a user can call Timer::cancel, thinking the rest of the tasks in the queue will be canceled (which should be the return value of Timer::purge). > > In actuality, Timer::cancel _discards_ all of the tasks in the queue. For a task to have been _cancelled_, the task itself must have called TimerTask::cancel. > > This change emphasizes the difference between _discarding_ and _cancelling_ a task. > Additionally, this change also includes a drive-by update to use an _apiNote_ and _implNote_ tag in the class description. LGTM ------------- Marked as reviewed by rriggs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16503#pullrequestreview-1716478291 From prr at openjdk.org Mon Nov 6 23:32:39 2023 From: prr at openjdk.org (Phil Race) Date: Mon, 6 Nov 2023 23:32:39 GMT Subject: RFR: 8318364: Add an FFM-based implementation of harfbuzz OpenType layout [v4] In-Reply-To: References: Message-ID: On Mon, 6 Nov 2023 18:52:05 GMT, Sergey Bylokhov wrote: > Since we plan to import it into jdk22, do you have some performance data to share? any positive or negative effects of this migration? There's three phases - (1) startup, (2) warmup and (3) warmed up performance. JNI has minimal startup / warmup cost, getting to warmed up performance right away. So if your app starts up and makes just one call to layout, JNI wins easily. But if it keeps going, then FFM comes out ahead, even counting that startup /warmup cost. There's a cost to the first time some code in JDK initialises the core FFM. If that code happens to be this layout code, it'll see that overhead. That was somewhere around 75ms on my Mac. On top of that there's the cost of creating the specific method handles and var handles I have 11 of these, and the total there is about 35-40ms. So we have somewhere around a fixed 125ms startup cost for the FFM case - as measured on my Mac, but only 35-40ms of that is attributable to the specific needs of layout. And there is some potential for that code to get faster some day Also if any of the techniques such as AppCDS, or some day, Leyden condensers, are used then there is also potential to eliminate much of the warmup cost. The FFM path then needs to be warmed. Once warmed up, FFM is always as fast or faster than JNI. 20% faster is typical as measured by a small test that just calls layout in a loop. It was tried with varying lengths of string. For just a single char, FFM was only a little faster, but gets better for longer strings. Once we start to use layout, we use it a lot, so you reach many thousands of calls very quickly. Just resizing your UI window causes that. It doesn't take long for FFM to become an overall win. That includes amortizing the cost of the startup / warmup time. As well as a microbenchmark, I looked at what it does in an app consisting of a Swing JTextArea displaying a decent amount of Hindi using an OpenType Indic font on Mac. That takes just over 16,000 (!) calls to layout to get to fully displayed. Then if you just resize back and forth in just a few seconds FFM catches up and overtakes I'll show numbers below - this measure all the FFM+layout costs but nothing else in the app. It bears out what I said about startup. "layoutCnt" is the number of calls to the method to do layout on a single run of text. The numbers look like a lot of calls to layout and you might think that took hours but this really is just about 20-30 secs of manual resizing to get to one million calls. JNI == layoutCnt=1 total=3ms <<< JNI very fast to start up layoutCnt=2 total=3ms layoutCnt=3 total=3ms layoutCnt=4 total=4ms layoutCnt=5 total=4ms layoutCnt=1000 total=31ms layoutCnt=2000 total=40ms << 9-10ms per thousand calls (40-31) layoutCnt=3000 total=51ms layoutCnt=4000 total=61ms layoutCnt=5000 total=69ms layoutCnt=6000 total=77ms layoutCnt=7000 total=90ms layoutCnt=8000 total=100ms layoutCnt=9000 total=113ms layoutCnt=10000 total=122ms layoutCnt=11000 total=134ms layoutCnt=12000 total=150ms layoutCnt=13000 total=157ms layoutCnt=14000 total=169ms layoutCnt=15000 total=181ms layoutCnt=16000 total=193ms <<< app fully displayed ... layoutCnt=250000 total=2450ms <<< rough point at which they are equal ... layoutCnt=1000000 total=9115ms <<< after 1 million calls FFM is clearly behind layoutCnt=1001000 total=9124ms << STILL 9-10ms per thousand calls (9124-9115) FFM === layoutCnt=1 total=186ms << // FFM slow to start up, includes 75ms core FFM, 35-40 varhandles + no JIT yet layoutCnt=2 total=188ms layoutCnt=3 total=189ms layoutCnt=4 total=195ms layoutCnt=5 total=195ms layoutCnt=1000 total=269ms layoutCnt=2000 total=284ms << 15 ms per thousand calls (284-269) layoutCnt=3000 total=301ms layoutCnt=4000 total=317ms layoutCnt=5000 total=333ms layoutCnt=6000 total=348ms layoutCnt=7000 total=365ms layoutCnt=8000 total=376ms layoutCnt=9000 total=388ms layoutCnt=10000 total=397ms layoutCnt=11000 total=407ms layoutCnt=12000 total=419ms layoutCnt=13000 total=425ms layoutCnt=14000 total=435ms layoutCnt=15000 total=444ms layoutCnt=16000 total=453ms <<< app fully displayed ... layoutCnt=250000 total=2426ms <<< rough point at which they are equal ... layoutCnt=1000000 total=8489ms <<< after 1 million calls FFM is clearly ahead layoutCnt=1001000 total=8496ms << now about 7 ms per thousand calls (8496-8489) ------------- PR Comment: https://git.openjdk.org/jdk/pull/15476#issuecomment-1797025476 From joehw at openjdk.org Mon Nov 6 23:33:07 2023 From: joehw at openjdk.org (Joe Wang) Date: Mon, 6 Nov 2023 23:33:07 GMT Subject: RFR: 8305814: Update Xalan Java to 2.7.3 Message-ID: Xalan 2.7.3: merge minor changes from the upstream project. Test: existing XML tests pass ------------- Commit messages: - 8305814: Update Xalan Java to 2.7.3 Changes: https://git.openjdk.org/jdk/pull/16532/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16532&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8305814 Stats: 66 lines in 4 files changed: 19 ins; 22 del; 25 mod Patch: https://git.openjdk.org/jdk/pull/16532.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16532/head:pull/16532 PR: https://git.openjdk.org/jdk/pull/16532 From serb at openjdk.org Tue Nov 7 00:00:29 2023 From: serb at openjdk.org (Sergey Bylokhov) Date: Tue, 7 Nov 2023 00:00:29 GMT Subject: RFR: 8318364: Add an FFM-based implementation of harfbuzz OpenType layout [v4] In-Reply-To: References: Message-ID: On Mon, 6 Nov 2023 23:28:30 GMT, Phil Race wrote: >So we have somewhere around a fixed 125ms startup cost for the FFM case - as measured on my Mac, but only 35-40ms of that is attributable to the specific needs of layout. That looks unfortunate. I guess if we will start to use ffm in other places we can easily spend of 1 second budget on startup=( > layoutCnt=16000 total=193ms <<< app fully displayed vs > layoutCnt=16000 total=453ms <<< app fully displayed It looks strange that 16000 calls are not enough to warmup, and the difference is so large. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15476#issuecomment-1797052585 From naoto at openjdk.org Tue Nov 7 00:03:31 2023 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 7 Nov 2023 00:03:31 GMT Subject: RFR: 8317742: ISO Standard Date Format implementation consistency on DateTimeFormatter and String.format [v4] In-Reply-To: References: Message-ID: <7wlZslqihB6PE5hFT9I_j8GvRTPTNBJMHCdzK1xsapo=.b47e0d2c-5def-4cba-98d0-c7254263e30a@github.com> On Mon, 6 Nov 2023 14:55:54 GMT, Shaojin Wen wrote: >> j.u.Formatter now prints "%tF" (iso standard date) and the result is incorrect when processing year < 0 or year > 9999 > > Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: > > revert localize change src/java.base/share/classes/java/util/Formatter.java line 4495: > 4493: int year = t.get(ChronoField.YEAR); > 4494: if (year < 0) { > 4495: sb.append('-'); Some locales use a different code point to express negative numbers from `hyphen-minus`, such as `minus sign` (U+2212). I'd suggest getting it from `DecimalFormatSymbols.getMinusSign()` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16033#discussion_r1384186755 From iris at openjdk.org Tue Nov 7 00:22:28 2023 From: iris at openjdk.org (Iris Clark) Date: Tue, 7 Nov 2023 00:22:28 GMT Subject: RFR: 8305814: Update Xalan Java to 2.7.3 In-Reply-To: References: Message-ID: <7V9SGdKBI1msM86V3bCXhL91InuOuoJKvPX1ZX1_DL8=.16d45f8c-637f-42a3-9335-1e3a33fea495@github.com> On Mon, 6 Nov 2023 22:52:47 GMT, Joe Wang wrote: > Xalan 2.7.3: merge minor changes from the upstream project. > > Test: existing XML tests pass Marked as reviewed by iris (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/16532#pullrequestreview-1716553613 From prr at openjdk.org Tue Nov 7 00:40:28 2023 From: prr at openjdk.org (Phil Race) Date: Tue, 7 Nov 2023 00:40:28 GMT Subject: RFR: 8318364: Add an FFM-based implementation of harfbuzz OpenType layout [v4] In-Reply-To: References: Message-ID: <0NrUdOATwm9ckjU4JesHN7RnvxUtHm7ugDpJ1GAanUA=.63031f7a-1d91-477d-ac64-63a830c2fba6@github.com> On Mon, 6 Nov 2023 23:58:11 GMT, Sergey Bylokhov wrote: > > So we have somewhere around a fixed 125ms startup cost for the FFM case - as measured on my Mac, > > but only 35-40ms of that is attributable to the specific needs of layout. > > That looks unfortunate. I guess if we will start to use ffm in other places we can easily spend of 1 second budget on startup=( Yes, this case is sufficiently uncommon, that it is OK, and is a decent way to help us track improvements to FFM. But it would be another matter to have to do it for however many of our core software loops and AWT window manager interaction calls we need to get running for a minimal app. > > > layoutCnt=16000 total=193ms <<< app fully displayed > > vs > > layoutCnt=16000 total=453ms <<< app fully displayed > > It looks strange that 16000 calls are not enough to warmup, and the difference is so large. I am not a C2 expert, (not even an amateur), I just assume that it takes a lot of calls to be fully optimized. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15476#issuecomment-1797086938 From jbhateja at openjdk.org Tue Nov 7 01:13:34 2023 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Tue, 7 Nov 2023 01:13:34 GMT Subject: RFR: 8318650: Optimized subword gather for x86 targets. [v3] In-Reply-To: <7zOPXh6t5kkVls4Ug4jnNjETSJOLifZQrxfipQu-jiQ=.78bad780-b885-4043-8004-a883108a5a23@github.com> References: <7zOPXh6t5kkVls4Ug4jnNjETSJOLifZQrxfipQu-jiQ=.78bad780-b885-4043-8004-a883108a5a23@github.com> Message-ID: On Mon, 6 Nov 2023 18:33:46 GMT, Sandhya Viswanathan wrote: > This is not a masked operation so every lane of dst will be written through pinsrw/pinsrb. An vpxor before is not required. xor here clears the intermediate vector after each iteration, this is eventually ORs with destination. Checkout line https://github.com/openjdk/jdk/pull/16354/files/86783403c453d329e33d94f787a5709ec35f7099#diff-318d0e76b9a97e8cf8936be1de34e52735c4d947a77cac38babbbf9a081d16fcR1644 https://github.com/openjdk/jdk/pull/16354/files/86783403c453d329e33d94f787a5709ec35f7099#diff-318d0e76b9a97e8cf8936be1de34e52735c4d947a77cac38babbbf9a081d16fcR1651 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16354#discussion_r1384225640 From duke at openjdk.org Tue Nov 7 01:31:03 2023 From: duke at openjdk.org (Shaojin Wen) Date: Tue, 7 Nov 2023 01:31:03 GMT Subject: RFR: 8317742: ISO Standard Date Format implementation consistency on DateTimeFormatter and String.format [v5] In-Reply-To: References: Message-ID: > j.u.Formatter now prints "%tF" (iso standard date) and the result is incorrect when processing year < 0 or year > 9999 Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: use DecimalFormatSymbols#getMinusSign ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16033/files - new: https://git.openjdk.org/jdk/pull/16033/files/b6313fc0..7051ad51 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16033&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16033&range=03-04 Stats: 8 lines in 2 files changed: 7 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/16033.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16033/head:pull/16033 PR: https://git.openjdk.org/jdk/pull/16033 From lancea at openjdk.org Tue Nov 7 01:46:28 2023 From: lancea at openjdk.org (Lance Andersen) Date: Tue, 7 Nov 2023 01:46:28 GMT Subject: RFR: 8305814: Update Xalan Java to 2.7.3 In-Reply-To: References: Message-ID: On Mon, 6 Nov 2023 22:52:47 GMT, Joe Wang wrote: > Xalan 2.7.3: merge minor changes from the upstream project. > > Test: existing XML tests pass src/java.xml/share/classes/com/sun/org/apache/xalan/internal/lib/ExsltDatetime.java line 104: > 102: buff.append(posneg).append(formatDigits(hrs)).append(':').append(formatDigits(min)); > 103: } > 104: return buff.toString();*/ This commented out block is difficult to see given Can we clean this up or better yet remove this code if not needed? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16532#discussion_r1384244649 From egahlin at openjdk.org Tue Nov 7 02:16:30 2023 From: egahlin at openjdk.org (Erik Gahlin) Date: Tue, 7 Nov 2023 02:16:30 GMT Subject: RFR: 8319374: JFR: Remove instrumentation for exception events [v2] In-Reply-To: References: Message-ID: <9R1w6cnpjXpgrqZUJFRRzTEDcGWW_JFFVbrfqoly2fk=.d5062d80-75be-46ed-a541-59b12ab6d6be@github.com> On Mon, 6 Nov 2023 22:41:17 GMT, Erik Gahlin wrote: >> src/java.base/share/classes/jdk/internal/event/ThrowableTracer.java line 44: >> >>> 42: >>> 43: public static void traceError(Class clazz, String message) { >>> 44: if (OutOfMemoryError.class.isAssignableFrom(clazz)) { >> >> StackOverflowError is likely problematic too, maybe it should be VirtualMachineError. > > I remember asking the same question ten years ago, when Nils did the original implementation, but I think it was only needed for OOM, because it creates an infinite loop when the event object was allocated, which resulted in a StackOverflowError instead OOM. > > Some OOM tests failed with JFR enabled. > > The event object allocation has been removed, but I think we can run into the allocation recursion by other means. I looked into it a few years ago, but I don't remember exactly why it failed. > > If a SOE happens, I think we are fine. There is something that prevents infinite recursion when the SOE object is created. Perhaps it is preallocated? I prefer to not change the behavior, at least not in this PR. I filed an issue to investigate if there is a problem with SOE, or if the OOM check is really needed now. https://bugs.openjdk.org/browse/JDK-8319579 Regardless of outcome, It would be good to document the results of the investigation in the code. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16493#discussion_r1384263589 From liach at openjdk.org Tue Nov 7 02:42:29 2023 From: liach at openjdk.org (Chen Liang) Date: Tue, 7 Nov 2023 02:42:29 GMT Subject: RFR: 8187655: jdk.lambda.vm.InterfaceAccessFlagsTest.testPrivateMethodCall needs update after nestmates support In-Reply-To: References: Message-ID: <-yaR2kFSAwM0hbBaX8aWTRvhnV4HJDuJbV8EU6cHPMo=.adb7d03c-292b-4a15-873a-01fc7b6638e1@github.com> On Mon, 6 Nov 2023 19:26:26 GMT, Mandy Chung wrote: > `jdk.lambda.vm.InterfaceAccessFlagsTest` uses `ClassToInterfaceConverter` to mechanically convert a classfile for a Class into an in-memory class representation of an equivalent Interface. `testPrivateMethodCall` tests to invoke a private method. Before nestmates, invoking a private class method and a private interface method both use `Invokespecial`. With the nestmate changes, the class uses `invokevirtual` but the interface must use `invokeinterface` but this conversion is not handled by the existing `ClassToInterfaceConverter`. > > This fix converts `ClassToInterfaceConverter` to use the Class-File API to properly convert a classfile from a class to an interface including method invocation from `invokevirtual` to `invokeinterface`. The old custom bytecode manipulation code can be dropped. test/jdk/jdk/lambda/separate/ClassToInterfaceConverter.java line 39: > 37: > 38: private byte[] convertToInterface(ClassModel classModel) { > 39: return Classfile.of().build(classModel.thisClass().asSymbol(), You can use `transform` to transform a class instead of `build`. test/jdk/jdk/lambda/separate/ClassToInterfaceConverter.java line 43: > 41: for (ClassElement ce : classModel) { > 42: if (ce instanceof AccessFlags accessFlags) { > 43: classBuilder.withFlags(0x0601); // ACC_INTERFACE | ACC_ABSTRACT | ACC_PUBLIC); We can just use `withFlags(Classfile.ACC_INTERFACE | Classfile.ACC_ABSTRACT | Classfile.ACC_PUBLIC)` as it's a constant expression and inlined by javac. And the `accessFlags` variable above appears unused. test/jdk/jdk/lambda/separate/ClassToInterfaceConverter.java line 52: > 50: // by other methods in the interface, convert it to InterfaceMethodref and > 51: // if opcode is invokevirtual, convert it to invokeinterface > 52: classBuilder.withMethod(mm.methodName().stringValue(), Same remark, use `classBuilder.transformMethod(mm, MethodTransform.transformCode((codeBuilder, e) -> {}))` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16526#discussion_r1384280905 PR Review Comment: https://git.openjdk.org/jdk/pull/16526#discussion_r1384279751 PR Review Comment: https://git.openjdk.org/jdk/pull/16526#discussion_r1384284062 From mchung at openjdk.org Tue Nov 7 03:22:28 2023 From: mchung at openjdk.org (Mandy Chung) Date: Tue, 7 Nov 2023 03:22:28 GMT Subject: RFR: 8187655: jdk.lambda.vm.InterfaceAccessFlagsTest.testPrivateMethodCall needs update after nestmates support In-Reply-To: <-yaR2kFSAwM0hbBaX8aWTRvhnV4HJDuJbV8EU6cHPMo=.adb7d03c-292b-4a15-873a-01fc7b6638e1@github.com> References: <-yaR2kFSAwM0hbBaX8aWTRvhnV4HJDuJbV8EU6cHPMo=.adb7d03c-292b-4a15-873a-01fc7b6638e1@github.com> Message-ID: On Tue, 7 Nov 2023 02:30:55 GMT, Chen Liang wrote: >> `jdk.lambda.vm.InterfaceAccessFlagsTest` uses `ClassToInterfaceConverter` to mechanically convert a classfile for a Class into an in-memory class representation of an equivalent Interface. `testPrivateMethodCall` tests to invoke a private method. Before nestmates, invoking a private class method and a private interface method both use `Invokespecial`. With the nestmate changes, the class uses `invokevirtual` but the interface must use `invokeinterface` but this conversion is not handled by the existing `ClassToInterfaceConverter`. >> >> This fix converts `ClassToInterfaceConverter` to use the Class-File API to properly convert a classfile from a class to an interface including method invocation from `invokevirtual` to `invokeinterface`. The old custom bytecode manipulation code can be dropped. > > test/jdk/jdk/lambda/separate/ClassToInterfaceConverter.java line 43: > >> 41: for (ClassElement ce : classModel) { >> 42: if (ce instanceof AccessFlags accessFlags) { >> 43: classBuilder.withFlags(0x0601); // ACC_INTERFACE | ACC_ABSTRACT | ACC_PUBLIC); > > We can just use `withFlags(Classfile.ACC_INTERFACE | Classfile.ACC_ABSTRACT | Classfile.ACC_PUBLIC)` as it's a constant expression and inlined by javac. And the `accessFlags` variable above appears unused. I have same thought too. I have that changed in my local repo but not have the chance to push it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16526#discussion_r1384326189 From asemenyuk at openjdk.org Tue Nov 7 03:26:21 2023 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Tue, 7 Nov 2023 03:26:21 GMT Subject: RFR: 8319338: tools/jpackage/share/RuntimeImageTest.java fails with -XX:+UseZGC Message-ID: Remove `-Xmx512m` from the jtreg `@run` command as @AlanBateman suggested ------------- Commit messages: - 8319338: tools/jpackage/share/RuntimeImageTest.java fails with -XX:+UseZGC Changes: https://git.openjdk.org/jdk/pull/16535/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16535&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8319338 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/16535.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16535/head:pull/16535 PR: https://git.openjdk.org/jdk/pull/16535 From asemenyuk at openjdk.org Tue Nov 7 03:30:28 2023 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Tue, 7 Nov 2023 03:30:28 GMT Subject: RFR: 8319338: tools/jpackage/share/RuntimeImageTest.java fails with -XX:+UseZGC In-Reply-To: References: Message-ID: On Tue, 7 Nov 2023 03:20:45 GMT, Alexey Semenyuk wrote: > Remove `-Xmx512m` from the jtreg `@run` command as @AlanBateman suggested @sashamatveev , @AlanBateman please review ------------- PR Comment: https://git.openjdk.org/jdk/pull/16535#issuecomment-1797631432 From almatvee at openjdk.org Tue Nov 7 03:39:27 2023 From: almatvee at openjdk.org (Alexander Matveev) Date: Tue, 7 Nov 2023 03:39:27 GMT Subject: RFR: 8319338: tools/jpackage/share/RuntimeImageTest.java fails with -XX:+UseZGC In-Reply-To: References: Message-ID: On Tue, 7 Nov 2023 03:20:45 GMT, Alexey Semenyuk wrote: > Remove `-Xmx512m` from the jtreg `@run` command as @AlanBateman suggested Looks good. ------------- Marked as reviewed by almatvee (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16535#pullrequestreview-1716751895 From joehw at openjdk.org Tue Nov 7 05:43:06 2023 From: joehw at openjdk.org (Joe Wang) Date: Tue, 7 Nov 2023 05:43:06 GMT Subject: RFR: 8305814: Update Xalan Java to 2.7.3 [v2] In-Reply-To: References: Message-ID: <1goSZ17pk6T4dzDeArDGT0SOLdRRh0ZVYGqoelze4Nw=.45046606-8d71-478d-9b88-d2fb7a1f4e75@github.com> > Xalan 2.7.3: merge minor changes from the upstream project. > > Test: existing XML tests pass Joe Wang has updated the pull request incrementally with one additional commit since the last revision: remove commented out block in ExsltDatetime ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16532/files - new: https://git.openjdk.org/jdk/pull/16532/files/06535c4a..0d13a5a5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16532&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16532&range=00-01 Stats: 23 lines in 1 file changed: 0 ins; 23 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/16532.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16532/head:pull/16532 PR: https://git.openjdk.org/jdk/pull/16532 From joehw at openjdk.org Tue Nov 7 05:43:06 2023 From: joehw at openjdk.org (Joe Wang) Date: Tue, 7 Nov 2023 05:43:06 GMT Subject: RFR: 8305814: Update Xalan Java to 2.7.3 [v2] In-Reply-To: References: Message-ID: On Tue, 7 Nov 2023 01:43:21 GMT, Lance Andersen wrote: >> Joe Wang has updated the pull request incrementally with one additional commit since the last revision: >> >> remove commented out block in ExsltDatetime > > src/java.xml/share/classes/com/sun/org/apache/xalan/internal/lib/ExsltDatetime.java line 104: > >> 102: buff.append(posneg).append(formatDigits(hrs)).append(':').append(formatDigits(min)); >> 103: } >> 104: return buff.toString();*/ > > This commented out block is difficult to see given Can we clean this up or better yet remove this code if not needed? Thanks. Removed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16532#discussion_r1384406645 From alanb at openjdk.org Tue Nov 7 06:24:27 2023 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 7 Nov 2023 06:24:27 GMT Subject: RFR: 8319338: tools/jpackage/share/RuntimeImageTest.java fails with -XX:+UseZGC In-Reply-To: References: Message-ID: On Tue, 7 Nov 2023 03:20:45 GMT, Alexey Semenyuk wrote: > Remove `-Xmx512m` from the jtreg `@run` command as @AlanBateman suggested Can you confirm that debug builds are passing with -XX:+UseZGC now? ------------- PR Comment: https://git.openjdk.org/jdk/pull/16535#issuecomment-1797889256 From jpai at openjdk.org Tue Nov 7 07:52:30 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 7 Nov 2023 07:52:30 GMT Subject: RFR: 8318971: jar v17 should either exit on error immediately or create archive as jar v1.8 did In-Reply-To: References: Message-ID: <-QZ9xPRrv02N3BZBi2U2jblEHAhWkvmYCzMT8HSLhDI=.b4451c95-2895-456f-b4b9-f28ff40319e7@github.com> On Mon, 30 Oct 2023 16:16:52 GMT, Ryan Wallace wrote: > Hi all, > > Please review this fix for jar tool not producing archive if there is a missing file supplied. Fix is to throw an exception and exit processing when a missing file is supplied. Current behaviour will recognise missing file as an error but continue processing and not produce the archive. Updated ClassPath test to verify jar is not created. > > Thanks, > Ryan. Hello Ryan, I ran a few experiments and I am unsure if we should be doing this change. Please consider this following scenario, when using the current implementation in mainline: echo "hello" > hello.txt jar -cf foo.jar missing.txt missing2.txt hello.txt ------------- PR Comment: https://git.openjdk.org/jdk/pull/16423#issuecomment-1797979185 From alanb at openjdk.org Tue Nov 7 07:56:35 2023 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 7 Nov 2023 07:56:35 GMT Subject: RFR: 8319436: Proxy.newProxyInstance throws NPE if loader is null and interface not visible from class loader [v2] In-Reply-To: References: <3c9I42wkqwb6gtNvw3bowtyt4APRYb_L0DfscYe6KqU=.57b69660-b3f1-4d70-9189-8ad2601ab712@github.com> Message-ID: On Mon, 6 Nov 2023 20:22:43 GMT, Mandy Chung wrote: >> This is a regression caused by JDK-8302791. IAE should be thrown when an interface is not visible to the given class loader but NPE is thrown instead when the loader is null. The boot loader has no name and so the fix will print `null` in the exception message. `test/jdk/java/lang/reflect/Proxy/ClassRestrictions.java` is converted to junit and updated to test IAE thrown because proxy interface is not visible to null loader. > > Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: > > Review feedback The fix to getLoaderNameID looks fine, the update and conversion of the test looks okay too. ------------- Marked as reviewed by alanb (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16525#pullrequestreview-1717031599 From prappo at openjdk.org Tue Nov 7 07:58:40 2023 From: prappo at openjdk.org (Pavel Rappo) Date: Tue, 7 Nov 2023 07:58:40 GMT Subject: RFR: 8310813: Simplify and modernize equals, hashCode, and compareTo for BigInteger [v8] 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 15 additional commits since the last revision: - Merge branch 'master' into 8310813 - 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 - ... and 5 more: https://git.openjdk.org/jdk/compare/16651ffc...155fedba ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14630/files - new: https://git.openjdk.org/jdk/pull/14630/files/77bfab34..155fedba Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14630&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14630&range=06-07 Stats: 111587 lines in 3212 files changed: 64533 ins; 24863 del; 22191 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 prappo at openjdk.org Tue Nov 7 08:00:24 2023 From: prappo at openjdk.org (Pavel Rappo) Date: Tue, 7 Nov 2023 08:00:24 GMT Subject: RFR: 8311864: Add ArraysSupport.hashCode(int[] a, fromIndex, length, initialValue) [v2] In-Reply-To: References: Message-ID: > This PR adds an internal method to calculate hash code from the provided integer array, offset and length into that array, and the initial hash code value. > > Current options for calculating a hash code for int[] are inflexible. It's either ArraysSupport.vectorizedHashCode with an offset, length and initial value, or Arrays.hashCode with just an array. > > For an arbitrary int[], unconditional vectorization might be unwarranted or puzzling. Unfortunately, it's the only hash code method that operates on an array subrange or accepts the initial hash code value. > > A more convenient method could be added and then used, for example, here: > > * https://github.com/openjdk/jdk/blob/0ef03f122866f010ebf50683097e9b92e41cdaad/src/java.base/share/classes/java/util/concurrent/CopyOnWriteArrayList.java#L1076-L1083 > > * https://github.com/openjdk/jdk/blob/0ef03f122866f010ebf50683097e9b92e41cdaad/src/java.base/share/classes/java/util/ArrayList.java#L669-L680 > > * https://github.com/openjdk/jdk/blob/0ef03f122866f010ebf50683097e9b92e41cdaad/src/java.base/share/classes/sun/security/pkcs10/PKCS10.java#L356-L362 > > This PR adds such a method and provides tests for it. Additionally, this PR adds tests for `null` passed to `java.util.Arrays.hashCode` overloads, behaviour which was specified but untested. 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 two additional commits since the last revision: - Merge branch 'master' into 8311864 - Initial commit ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14831/files - new: https://git.openjdk.org/jdk/pull/14831/files/a92c5c31..f874f161 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14831&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14831&range=00-01 Stats: 314754 lines in 7332 files changed: 162080 ins; 80999 del; 71675 mod Patch: https://git.openjdk.org/jdk/pull/14831.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14831/head:pull/14831 PR: https://git.openjdk.org/jdk/pull/14831 From alanb at openjdk.org Tue Nov 7 09:27:30 2023 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 7 Nov 2023 09:27:30 GMT Subject: RFR: 8319374: JFR: Remove instrumentation for exception events [v2] In-Reply-To: References: Message-ID: On Mon, 6 Nov 2023 22:52:50 GMT, Erik Gahlin wrote: >> Could I have a review of a PR that removes the bytecode instrumentation for the exception events. >> >> Testing: jdk/jdk/jfr + tier1 + tier2 > > Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision: > > Remove SecurityException and IllegalArgumentException from throws clause src/java.base/share/classes/java/lang/Throwable.java line 125: > 123: * Flag that determines if exceptions should be traced by JFR > 124: */ > 125: static volatile boolean tracing; The use-sites in Error check Throwable.tracing so not immediately obvious that it's JFR tracing. Maybe it should be renamed to jfrTracing or an accessor of that name added so it's a bit clearer at the use-sites. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16493#discussion_r1384612334 From alanb at openjdk.org Tue Nov 7 09:30:29 2023 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 7 Nov 2023 09:30:29 GMT Subject: RFR: 8319374: JFR: Remove instrumentation for exception events [v2] In-Reply-To: <9R1w6cnpjXpgrqZUJFRRzTEDcGWW_JFFVbrfqoly2fk=.d5062d80-75be-46ed-a541-59b12ab6d6be@github.com> References: <9R1w6cnpjXpgrqZUJFRRzTEDcGWW_JFFVbrfqoly2fk=.d5062d80-75be-46ed-a541-59b12ab6d6be@github.com> Message-ID: <9wSlgTqUQBzVaZgyIwvGe4KOikMoE7GxaS0KqDiEXTA=.2c4be523-1786-4880-8146-b9a476ab25a7@github.com> On Tue, 7 Nov 2023 02:10:29 GMT, Erik Gahlin wrote: > I filed an issue to investigate if there is a problem with SOE, or if the OOM check is really needed now. https://bugs.openjdk.org/browse/JDK-8319579 > > Regardless of outcome, It would be good to document the results of the investigation in the code. Okay, the scenario I was wondering about is where traceError fails with SOE and whether that could trigger a loop too. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16493#discussion_r1384617053 From pminborg at openjdk.org Tue Nov 7 09:36:38 2023 From: pminborg at openjdk.org (Per Minborg) Date: Tue, 7 Nov 2023 09:36:38 GMT Subject: RFR: 8319607: FFM: Review the language in the FFM documentation Message-ID: This PR proposes to improve the language used in the FFM specification. There is a relatively small number of corrections. One peculiarity with the English language is the distinction between "that" (to be used in a restrictive clause) and "which" (to be used in a non-restrictive clause). Here is a reference: https://preply.com/en/blog/when-to-use-which-or-that-the-most-common-cases Another source for updates is the difference between BE and AE where most of us Europeans were taught BE but we should use AE in the specifications. ------------- Commit messages: - Change to AE in a word - Improve language in the FFM specification Changes: https://git.openjdk.org/jdk/pull/16536/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16536&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8319607 Stats: 128 lines in 12 files changed: 0 ins; 0 del; 128 mod Patch: https://git.openjdk.org/jdk/pull/16536.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16536/head:pull/16536 PR: https://git.openjdk.org/jdk/pull/16536 From pminborg at openjdk.org Tue Nov 7 09:49:47 2023 From: pminborg at openjdk.org (Per Minborg) Date: Tue, 7 Nov 2023 09:49:47 GMT Subject: Integrated: 8318678: Vector access on heap MemorySegments only works for byte[] In-Reply-To: References: Message-ID: <-vYeD6QBKbfgEtU8MfMzl5HfMVCMPQelMLDB_N1O080=.0fbae1ef-0376-4df4-b6c6-72331700a4cf@github.com> On Wed, 25 Oct 2023 13:08:06 GMT, Per Minborg wrote: > This PR proposes removing the restriction that only heap `MemorySegment` wrapping a `byte` array can be accessed by Vectors. Now any array type can be used provided the element alignment constraints are respected. This pull request has now been integrated. Changeset: 74f1889b Author: Per Minborg URL: https://git.openjdk.org/jdk/commit/74f1889b58c6ad1cdc7401e7cbb9f614acf0c171 Stats: 503 lines in 12 files changed: 443 ins; 44 del; 16 mod 8318678: Vector access on heap MemorySegments only works for byte[] Reviewed-by: chegar, mcimadamore, psandoz ------------- PR: https://git.openjdk.org/jdk/pull/16360 From egahlin at openjdk.org Tue Nov 7 10:39:31 2023 From: egahlin at openjdk.org (Erik Gahlin) Date: Tue, 7 Nov 2023 10:39:31 GMT Subject: RFR: 8319374: JFR: Remove instrumentation for exception events [v2] In-Reply-To: References: Message-ID: On Tue, 7 Nov 2023 09:24:20 GMT, Alan Bateman wrote: >> Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove SecurityException and IllegalArgumentException from throws clause > > src/java.base/share/classes/java/lang/Throwable.java line 125: > >> 123: * Flag that determines if exceptions should be traced by JFR >> 124: */ >> 125: static volatile boolean tracing; > > The use-sites in Error check Throwable.tracing so not immediately obvious that it's JFR tracing. Maybe it should be renamed to jfrTracing or an accessor of that name added so it's a bit clearer at the use-sites. Will change ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16493#discussion_r1384714812 From egahlin at openjdk.org Tue Nov 7 10:39:33 2023 From: egahlin at openjdk.org (Erik Gahlin) Date: Tue, 7 Nov 2023 10:39:33 GMT Subject: RFR: 8319374: JFR: Remove instrumentation for exception events [v2] In-Reply-To: <9wSlgTqUQBzVaZgyIwvGe4KOikMoE7GxaS0KqDiEXTA=.2c4be523-1786-4880-8146-b9a476ab25a7@github.com> References: <9R1w6cnpjXpgrqZUJFRRzTEDcGWW_JFFVbrfqoly2fk=.d5062d80-75be-46ed-a541-59b12ab6d6be@github.com> <9wSlgTqUQBzVaZgyIwvGe4KOikMoE7GxaS0KqDiEXTA=.2c4be523-1786-4880-8146-b9a476ab25a7@github.com> Message-ID: <0afwCsl4VMJkrRhqtR9Hzf16bVjKK08V7eoHFhSwYys=.19a98d83-bee6-4aed-b9e4-188e62dd879b@github.com> On Tue, 7 Nov 2023 09:27:51 GMT, Alan Bateman wrote: >> I filed an issue to investigate if there is a problem with SOE, or if the OOM check is really needed now. >> https://bugs.openjdk.org/browse/JDK-8319579 >> >> Regardless of outcome, It would be good to document the results of the investigation in the code. > >> I filed an issue to investigate if there is a problem with SOE, or if the OOM check is really needed now. https://bugs.openjdk.org/browse/JDK-8319579 >> >> Regardless of outcome, It would be good to document the results of the investigation in the code. > > Okay, the scenario I was wondering about is where traceError fails with SOE and whether that could trigger a loop too. I understand. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16493#discussion_r1384714404 From pminborg at openjdk.org Tue Nov 7 10:44:38 2023 From: pminborg at openjdk.org (Per Minborg) Date: Tue, 7 Nov 2023 10:44:38 GMT Subject: RFR: 8319613: Complier error in benchmark TestLoadSegmentVarious Message-ID: This PR proposes to fix a compilation error in the TestLoadSegmentVarious class ------------- Commit messages: - Fix compiler error in benchmark Changes: https://git.openjdk.org/jdk/pull/16537/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16537&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8319613 Stats: 3 lines in 1 file changed: 0 ins; 3 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/16537.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16537/head:pull/16537 PR: https://git.openjdk.org/jdk/pull/16537 From jpai at openjdk.org Tue Nov 7 10:44:39 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 7 Nov 2023 10:44:39 GMT Subject: RFR: 8319613: Complier error in benchmark TestLoadSegmentVarious In-Reply-To: References: Message-ID: On Tue, 7 Nov 2023 10:36:00 GMT, Per Minborg wrote: > This PR proposes to fix a compilation error in the TestLoadSegmentVarious class The change looks OK to me. ------------- Marked as reviewed by jpai (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16537#pullrequestreview-1717369232 From stefank at openjdk.org Tue Nov 7 10:44:39 2023 From: stefank at openjdk.org (Stefan Karlsson) Date: Tue, 7 Nov 2023 10:44:39 GMT Subject: RFR: 8319613: Complier error in benchmark TestLoadSegmentVarious In-Reply-To: References: Message-ID: <-tz3lh1-La3CpV_bpQtFsyCyo2JMGAItefQIOFd_8Q4=.8d8f8813-27f7-4949-a563-54809a9c3a02@github.com> On Tue, 7 Nov 2023 10:36:00 GMT, Per Minborg wrote: > This PR proposes to fix a compilation error in the TestLoadSegmentVarious class Marked as reviewed by stefank (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/16537#pullrequestreview-1717370876 From duke at openjdk.org Tue Nov 7 11:06:30 2023 From: duke at openjdk.org (Ryan Wallace) Date: Tue, 7 Nov 2023 11:06:30 GMT Subject: RFR: 8318971: jar v17 should either exit on error immediately or create archive as jar v1.8 did In-Reply-To: References: Message-ID: On Mon, 30 Oct 2023 16:16:52 GMT, Ryan Wallace wrote: > Hi all, > > Please review this fix for jar tool not producing archive if there is a missing file supplied. Fix is to throw an exception and exit processing when a missing file is supplied. Current behaviour will recognise missing file as an error but continue processing and not produce the archive. Updated ClassPath test to verify jar is not created. > > Thanks, > Ryan. Thanks [jaikiran](https://github.com/jaikiran), the issue with the current functionality on the mainline is that the jar tool is still processing and creating the temp jar file, it just doesn't move it to the working directory where the tool was ran from because there was a missing file supplied and then deletes the temp jar. If you were to run this with many/larger files that causes the jartool to take more time it is more noticeable. Maybe it is better to follow the JDK 8 JarTool behaviour and still produce a jar file without the missing files as we are providing a warning to notify that there were missing files not included in the jar. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16423#issuecomment-1798286718 From pminborg at openjdk.org Tue Nov 7 11:08:12 2023 From: pminborg at openjdk.org (Per Minborg) Date: Tue, 7 Nov 2023 11:08:12 GMT Subject: Integrated: 8319613: Complier error in benchmark TestLoadSegmentVarious In-Reply-To: References: Message-ID: On Tue, 7 Nov 2023 10:36:00 GMT, Per Minborg wrote: > This PR proposes to fix a compilation error in the TestLoadSegmentVarious class This pull request has now been integrated. Changeset: ac0ee20a Author: Per Minborg URL: https://git.openjdk.org/jdk/commit/ac0ee20a383d04126b771884387f84b27cd08637 Stats: 3 lines in 1 file changed: 0 ins; 3 del; 0 mod 8319613: Complier error in benchmark TestLoadSegmentVarious Reviewed-by: jpai, stefank ------------- PR: https://git.openjdk.org/jdk/pull/16537 From egahlin at openjdk.org Tue Nov 7 11:11:31 2023 From: egahlin at openjdk.org (Erik Gahlin) Date: Tue, 7 Nov 2023 11:11:31 GMT Subject: RFR: 8319374: JFR: Remove instrumentation for exception events [v3] In-Reply-To: References: Message-ID: > Could I have a review of a PR that removes the bytecode instrumentation for the exception events. > > Testing: jdk/jdk/jfr + tier1 + tier2 Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision: Rename field from tracing to jfrTracing ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16493/files - new: https://git.openjdk.org/jdk/pull/16493/files/23a07a18..195c1086 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16493&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16493&range=01-02 Stats: 12 lines in 3 files changed: 0 ins; 0 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/16493.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16493/head:pull/16493 PR: https://git.openjdk.org/jdk/pull/16493 From mcimadamore at openjdk.org Tue Nov 7 11:13:33 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Tue, 7 Nov 2023 11:13:33 GMT Subject: RFR: 8319607: FFM: Review the language in the FFM documentation In-Reply-To: References: Message-ID: On Tue, 7 Nov 2023 09:31:11 GMT, Per Minborg wrote: > This PR proposes to improve the language used in the FFM specification. There is a relatively small number of corrections. > > One peculiarity with the English language is the distinction between "that" (to be used in a restrictive clause) and "which" (to be used in a non-restrictive clause). Here is a reference: https://preply.com/en/blog/when-to-use-which-or-that-the-most-common-cases > > Another source for updates is the difference between BE and AE where most of us Europeans were taught BE but we should use AE in the specifications. src/java.base/share/classes/java/lang/foreign/Linker.java line 249: > 247: * Linker implementations may optionally support additional layouts, such as packed struct layouts. > 248: * A packed struct is a struct in which there is at least one member layout {@code L} that has an alignment > 249: * constraint less strict than its natural alignment. This allows for avoiding padding between member layouts, IMHO this should be "allows to avoid" - it reads wrong like this :-) src/java.base/share/classes/java/lang/foreign/Linker.java line 346: > 344: * } > 345: * > 346: * The {@code malloc} function allocates a region of memory of a given size, I'd suggest replacing "of a given size" with "with the given size" ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16536#discussion_r1384754894 PR Review Comment: https://git.openjdk.org/jdk/pull/16536#discussion_r1384755615 From mcimadamore at openjdk.org Tue Nov 7 11:16:29 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Tue, 7 Nov 2023 11:16:29 GMT Subject: RFR: 8319607: FFM: Review the language in the FFM documentation In-Reply-To: References: Message-ID: On Tue, 7 Nov 2023 09:31:11 GMT, Per Minborg wrote: > This PR proposes to improve the language used in the FFM specification. There is a relatively small number of corrections. > > One peculiarity with the English language is the distinction between "that" (to be used in a restrictive clause) and "which" (to be used in a non-restrictive clause). Here is a reference: https://preply.com/en/blog/when-to-use-which-or-that-the-most-common-cases > > Another source for updates is the difference between BE and AE where most of us Europeans were taught BE but we should use AE in the specifications. src/java.base/share/classes/java/lang/foreign/MemoryLayout.java line 188: > 186: * } > 187: * > 188: * This layout is a struct layout that describe a rectangle. It contains a single field, namely {@code points}, "that describeS" ? Or, "describing"... ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16536#discussion_r1384758701 From lancea at openjdk.org Tue Nov 7 11:24:31 2023 From: lancea at openjdk.org (Lance Andersen) Date: Tue, 7 Nov 2023 11:24:31 GMT Subject: RFR: 8305814: Update Xalan Java to 2.7.3 [v2] In-Reply-To: <1goSZ17pk6T4dzDeArDGT0SOLdRRh0ZVYGqoelze4Nw=.45046606-8d71-478d-9b88-d2fb7a1f4e75@github.com> References: <1goSZ17pk6T4dzDeArDGT0SOLdRRh0ZVYGqoelze4Nw=.45046606-8d71-478d-9b88-d2fb7a1f4e75@github.com> Message-ID: On Tue, 7 Nov 2023 05:43:06 GMT, Joe Wang wrote: >> Xalan 2.7.3: merge minor changes from the upstream project. >> >> Test: existing XML tests pass > > Joe Wang has updated the pull request incrementally with one additional commit since the last revision: > > remove commented out block in ExsltDatetime Marked as reviewed by lancea (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/16532#pullrequestreview-1717450671 From pminborg at openjdk.org Tue Nov 7 11:28:09 2023 From: pminborg at openjdk.org (Per Minborg) Date: Tue, 7 Nov 2023 11:28:09 GMT Subject: RFR: 8319607: FFM: Review the language in the FFM documentation [v2] In-Reply-To: References: Message-ID: > This PR proposes to improve the language used in the FFM specification. There is a relatively small number of corrections. > > One peculiarity with the English language is the distinction between "that" (to be used in a restrictive clause) and "which" (to be used in a non-restrictive clause). Here is a reference: https://preply.com/en/blog/when-to-use-which-or-that-the-most-common-cases > > Another source for updates is the difference between BE and AE where most of us Europeans were taught BE but we should use AE in the specifications. Per Minborg has updated the pull request incrementally with one additional commit since the last revision: Fix after comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16536/files - new: https://git.openjdk.org/jdk/pull/16536/files/387d5929..315162e8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16536&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16536&range=00-01 Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/16536.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16536/head:pull/16536 PR: https://git.openjdk.org/jdk/pull/16536 From mcimadamore at openjdk.org Tue Nov 7 11:28:09 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Tue, 7 Nov 2023 11:28:09 GMT Subject: RFR: 8319607: FFM: Review the language in the FFM documentation [v2] In-Reply-To: References: Message-ID: On Tue, 7 Nov 2023 11:23:58 GMT, Per Minborg wrote: >> This PR proposes to improve the language used in the FFM specification. There is a relatively small number of corrections. >> >> One peculiarity with the English language is the distinction between "that" (to be used in a restrictive clause) and "which" (to be used in a non-restrictive clause). Here is a reference: https://preply.com/en/blog/when-to-use-which-or-that-the-most-common-cases >> >> Another source for updates is the difference between BE and AE where most of us Europeans were taught BE but we should use AE in the specifications. > > Per Minborg has updated the pull request incrementally with one additional commit since the last revision: > > Fix after comments Looks good - left some minor comments ------------- Marked as reviewed by mcimadamore (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16536#pullrequestreview-1717449516 From mcimadamore at openjdk.org Tue Nov 7 11:28:30 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Tue, 7 Nov 2023 11:28:30 GMT Subject: RFR: 8319560: Reformat method parameters in the FFM API In-Reply-To: References: Message-ID: On Mon, 6 Nov 2023 21:00:10 GMT, Per Minborg wrote: > This PR proposes to reformat some method parameters in the FFM API. The proposed changes are a bit opinion based eve though there are some underlying principles. Marked as reviewed by mcimadamore (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/16527#pullrequestreview-1717457638 From mcimadamore at openjdk.org Tue Nov 7 11:30:29 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Tue, 7 Nov 2023 11:30:29 GMT Subject: RFR: 8319556: Harmonize interface formatting in the FFM API In-Reply-To: References: Message-ID: <8sIxFtb4ek6IuxOSnjtrGwXF5ZmyXddRAqhr_EMLxeE=.2d136e1e-b303-4754-b83a-8488ff3240c8@github.com> On Mon, 6 Nov 2023 21:05:58 GMT, Per Minborg wrote: > This PR proposes to remove two `permits` declarations where the line overflows the stipulated maximum column with. Also, it proposes to harmonize the layout of `permit` formatting so they are the the same throughout the API. > > This PR might be perceived as over worked but I think it nice to get consistency across the API now that we go final. I will prefer to see this done on a by-need basis. E.g. if the line fits in the 100 char margin, (as it seems the case in a lot of the changes here), I don't see an immediate need to make changes? ------------- PR Review: https://git.openjdk.org/jdk/pull/16528#pullrequestreview-1717460098 From mcimadamore at openjdk.org Tue Nov 7 11:31:31 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Tue, 7 Nov 2023 11:31:31 GMT Subject: RFR: 8319563: Reformat code in the FFM API In-Reply-To: <87jkoBHzhAxl9-lBhphlkaX66Lq18mo-cLpqW8z_tQk=.21fc7d4c-4bfb-4b32-9315-386bc8ddf935@github.com> References: <87jkoBHzhAxl9-lBhphlkaX66Lq18mo-cLpqW8z_tQk=.21fc7d4c-4bfb-4b32-9315-386bc8ddf935@github.com> Message-ID: On Mon, 6 Nov 2023 21:07:22 GMT, Per Minborg wrote: > This PR proposes to reformat a small number of code line for better appearance. Marked as reviewed by mcimadamore (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/16529#pullrequestreview-1717461495 From pminborg at openjdk.org Tue Nov 7 11:41:06 2023 From: pminborg at openjdk.org (Per Minborg) Date: Tue, 7 Nov 2023 11:41:06 GMT Subject: RFR: 8319556: Harmonize interface formatting in the FFM API [v2] In-Reply-To: References: Message-ID: > This PR proposes to remove two `permits` declarations where the line overflows the stipulated maximum column with. Also, it proposes to harmonize the layout of `permit` formatting so they are the the same throughout the API. > > This PR might be perceived as over worked but I think it nice to get consistency across the API now that we go final. Per Minborg has updated the pull request incrementally with two additional commits since the last revision: - Remove redundandt space - Use permits reformatting only when needed ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16528/files - new: https://git.openjdk.org/jdk/pull/16528/files/0d5774c8..bc07305d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16528&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16528&range=00-01 Stats: 16 lines in 7 files changed: 0 ins; 8 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/16528.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16528/head:pull/16528 PR: https://git.openjdk.org/jdk/pull/16528 From pminborg at openjdk.org Tue Nov 7 11:42:42 2023 From: pminborg at openjdk.org (Per Minborg) Date: Tue, 7 Nov 2023 11:42:42 GMT Subject: Integrated: 8319563: Reformat code in the FFM API In-Reply-To: <87jkoBHzhAxl9-lBhphlkaX66Lq18mo-cLpqW8z_tQk=.21fc7d4c-4bfb-4b32-9315-386bc8ddf935@github.com> References: <87jkoBHzhAxl9-lBhphlkaX66Lq18mo-cLpqW8z_tQk=.21fc7d4c-4bfb-4b32-9315-386bc8ddf935@github.com> Message-ID: On Mon, 6 Nov 2023 21:07:22 GMT, Per Minborg wrote: > This PR proposes to reformat a small number of code line for better appearance. This pull request has now been integrated. Changeset: 42f43c52 Author: Per Minborg URL: https://git.openjdk.org/jdk/commit/42f43c520c4a80aadd418ad45f2005af7685a4d5 Stats: 12 lines in 3 files changed: 7 ins; 0 del; 5 mod 8319563: Reformat code in the FFM API Reviewed-by: mcimadamore ------------- PR: https://git.openjdk.org/jdk/pull/16529 From mabbay at openjdk.org Tue Nov 7 12:04:09 2023 From: mabbay at openjdk.org (Mourad Abbay) Date: Tue, 7 Nov 2023 12:04:09 GMT Subject: RFR: 8294980: test/jdk/java/lang/invoke 15 test classes use experimental bytecode library [v3] In-Reply-To: <-JRa1cWErB4H5zW-TqhXXd1y3TchfIXPMinb-CJ4OUE=.96cb1861-cb27-4030-a8a0-f90df924f041@github.com> References: <-JRa1cWErB4H5zW-TqhXXd1y3TchfIXPMinb-CJ4OUE=.96cb1861-cb27-4030-a8a0-f90df924f041@github.com> Message-ID: > early experimental version of the bytecode library is bundled under: > test/jdk/lib/testlibrary/bytecode > > following tests reference it: > test/jdk/java/lang/invoke/common/test/java/lang/invoke/lib/InstructionHelper.java > test/jdk/java/lang/invoke/condy/CondyWithGarbageTest.java > test/jdk/java/lang/invoke/condy/CondyReturnPrimitiveTest.java > test/jdk/java/lang/invoke/condy/CondyWrongType.java > test/jdk/java/lang/invoke/condy/CondyNestedTest.java > test/jdk/java/lang/invoke/condy/CondyStaticArgumentsTest.java > test/jdk/java/lang/invoke/condy/BootstrapMethodJumboArgsTest.java > test/jdk/java/lang/invoke/condy/ConstantBootstrapsTest.java > test/jdk/java/lang/invoke/condy/CondyRepeatFailedResolution.java > test/jdk/java/lang/invoke/condy/CondyBSMInvocation.java > test/jdk/java/lang/invoke/condy/CondyTypeValidationTest.java > test/jdk/java/lang/invoke/condy/CondyBSMValidationTest.java > test/jdk/java/lang/invoke/condy/CondyNameValidationTest.java > test/jdk/java/lang/invoke/condy/CondyBSMException.java > test/jdk/java/lang/invoke/condy/CondyInterfaceWithOverpassMethods.java Mourad Abbay has updated the pull request with a new target base 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 branch 'master' into 8294980 - specify packages to export in jtreg tests. - Remove reference to old bytecode library. - Remove early experimental version of the bytecode library. - Convert CondyInterfaceWithOverpassMethods . - Convert CondyBSMException . - Convert CondyNameValidationTest . - Convert CondyBSMValidationTest . - Convert CondyTypeValidationTest . - Convert CondyBSMInvocation . - ... and 9 more: https://git.openjdk.org/jdk/compare/cd92451d...0d1c94a9 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16268/files - new: https://git.openjdk.org/jdk/pull/16268/files/96301a6d..0d1c94a9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16268&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16268&range=01-02 Stats: 86909 lines in 2809 files changed: 49167 ins; 17259 del; 20483 mod Patch: https://git.openjdk.org/jdk/pull/16268.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16268/head:pull/16268 PR: https://git.openjdk.org/jdk/pull/16268 From jpai at openjdk.org Tue Nov 7 12:09:32 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 7 Nov 2023 12:09:32 GMT Subject: RFR: 8318971: jar v17 should either exit on error immediately or create archive as jar v1.8 did In-Reply-To: References: Message-ID: On Tue, 7 Nov 2023 11:04:14 GMT, Ryan Wallace wrote: > the issue with the current functionality on the mainline is that the jar tool is still processing and creating the temp jar file, it just doesn't move it to the working directory where the tool was ran from because there was a missing file supplied and then deletes the temp jar. If you were to run this with many/larger files that causes the jartool to take more time it is more noticeable. Thank you for that detail. I now understand what we are attempting to improve. In that case, could you experiment by the changing the call sites of `expand(...)` method? Right now in mainline, `expand(...)` method is where we check if a file exists or not and when absent we write a error message and set the `ok = false`. The current proposed change in this PR throws an exception from here instead of writing the error message and setting `ok = false`. What we could do perhaps, is let expand(...) method continue to stay as-is and continue to write those error messages and set `ok = false`. Then at the call site(s) of expand() where we then create and write to the temporary jar file, we should probably first check if `ok = false` and if it is `false` then just return `false` from the `run()` method so that the temporary jar isn't created and the command exits with a non-zero exit code. That way we still report all missing files and don't end up creating the temporary jar. I haven't looked at the code in detail to see if this is feasible and/or if there are other issues this will show up. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16423#issuecomment-1798375151 From jlahoda at openjdk.org Tue Nov 7 12:09:46 2023 From: jlahoda at openjdk.org (Jan Lahoda) Date: Tue, 7 Nov 2023 12:09:46 GMT Subject: Integrated: 8318144: Match on enum constants with body compiles but fails with MatchException In-Reply-To: References: Message-ID: <5N26pFp5SYukkm-OA-oru3EWCajncfuoXwFg1LihgNs=.81ab9394-1ee3-4562-af7c-5638e6fed34a@github.com> On Fri, 3 Nov 2023 16:26:49 GMT, Jan Lahoda wrote: > For code like: > > enum E {A {}, B {} } > Object o = E.A; > switch (o) { > case E.A -> System.err.println(o); > default -> System.err.println("default"); > } > > > The result is `default`, not `A`, due to incorrect classes being compared. Thanks for @liach for noting the solution here: > https://github.com/openjdk/jdk/pull/16489#discussion_r1381411165 This pull request has now been integrated. Changeset: 541ff714 Author: Jan Lahoda URL: https://git.openjdk.org/jdk/commit/541ff7149f9c6480535219ab06a2576f8399703a Stats: 122 lines in 3 files changed: 120 ins; 0 del; 2 mod 8318144: Match on enum constants with body compiles but fails with MatchException Reviewed-by: liach, vromero ------------- PR: https://git.openjdk.org/jdk/pull/16499 From liach at openjdk.org Tue Nov 7 12:25:42 2023 From: liach at openjdk.org (Chen Liang) Date: Tue, 7 Nov 2023 12:25:42 GMT Subject: Integrated: 8319462: Signature.ClassTypeSig::classDesc() incorrect for inner class types In-Reply-To: References: Message-ID: On Mon, 6 Nov 2023 06:00:20 GMT, Chen Liang wrote: > Observed this erroneous implementation while browsing, and included a quick test against javac output class file to confirm the correct implementation. @asotona Please take a look. This pull request has now been integrated. Changeset: d22e368c Author: Chen Liang Committer: Adam Sotona URL: https://git.openjdk.org/jdk/commit/d22e368cb5dbd6812f1584c47c44b9b754a222af Stats: 25 lines in 2 files changed: 22 ins; 0 del; 3 mod 8319462: Signature.ClassTypeSig::classDesc() incorrect for inner class types Reviewed-by: asotona ------------- PR: https://git.openjdk.org/jdk/pull/16513 From jlaskey at openjdk.org Tue Nov 7 12:29:12 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Tue, 7 Nov 2023 12:29:12 GMT Subject: RFR: JDK-8315458 Implementation of Implicitly Declared Classes and Instance Main Method (Second Preview) [v14] In-Reply-To: References: Message-ID: > Address changes from JEP 445 to JEP 463. > > - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. > > - Don't mark class on read. > > - Remove reflection and annotation processing related to unnamed classes. > > - Simplify main method search. Jim Laskey has updated the pull request with a new target base 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 remote-tracking branch 'upstream/master' into 8315458 - Rename unnamed class tests and examples - Merge remote-tracking branch 'upstream/master' into 8315458 - Don't get args unless necessary - Remove unnamed classes from examples.not-yet.txt - Requested corrections - Changes recommended by Jan - Revised implicit class test - Don't store main method info globally. Use addition calls to fetch info. - Update JEP number in PreviewFeature - ... and 4 more: https://git.openjdk.org/jdk/compare/d2ff11e4...7effbcff ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16461/files - new: https://git.openjdk.org/jdk/pull/16461/files/3ffff0db..7effbcff Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16461&range=13 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16461&range=12-13 Stats: 2973 lines in 123 files changed: 1757 ins; 376 del; 840 mod Patch: https://git.openjdk.org/jdk/pull/16461.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16461/head:pull/16461 PR: https://git.openjdk.org/jdk/pull/16461 From jlaskey at openjdk.org Tue Nov 7 12:29:54 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Tue, 7 Nov 2023 12:29:54 GMT Subject: RFR: JDK-8315457 Implementation of String Templates (Second Preview) [v6] In-Reply-To: References: Message-ID: <3NHJ2yDj2dW6Y4qPF8FmBkqkXcG7l-BzQ3EKWYArZMI=.28885188-9e99-46e8-81bd-6234023c1b1f@github.com> > Update String Templates for a second preview. With the addition of > > - Expression type and throws are determined from the `process` method of the processor type and not the processor type. > > - Qualified `STR` and `RAW` are treated the same as unqualified `STR` and `RAW` . > > - Raw (generic) process types are no longer an error. Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision: - Merge remote-tracking branch 'upstream/master' into 8315457 - Remove preview from JavaLangAccess - Merge remote-tracking branch 'upstream/master' into 8315457 - Cache process method type in JCStringTemplate - Revert source - Revert @since 22 - Accept qualified STR and RAW - String Templates (second preview) ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16202/files - new: https://git.openjdk.org/jdk/pull/16202/files/4641ec05..c616f48e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16202&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16202&range=04-05 Stats: 2467 lines in 114 files changed: 1740 ins; 357 del; 370 mod Patch: https://git.openjdk.org/jdk/pull/16202.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16202/head:pull/16202 PR: https://git.openjdk.org/jdk/pull/16202 From mchhipa at openjdk.org Tue Nov 7 12:35:30 2023 From: mchhipa at openjdk.org (Mahendra Chhipa) Date: Tue, 7 Nov 2023 12:35:30 GMT Subject: RFR: JDK-8311961 Update Manual Test Groups for ATR JDK22 In-Reply-To: References: Message-ID: <4OQNrum3JWq7EySeCaODiFT4Qmx81vlg_DxbL1D-_bE=.92335c25-280d-44c0-b2f2-a4e7f0ebc41a@github.com> On Mon, 6 Nov 2023 22:25:46 GMT, Bill Huang wrote: > Updated jdk_core_manual test groups. LGTM ------------- PR Comment: https://git.openjdk.org/jdk/pull/16531#issuecomment-1798412093 From dnsimon at openjdk.org Tue Nov 7 13:00:31 2023 From: dnsimon at openjdk.org (Doug Simon) Date: Tue, 7 Nov 2023 13:00:31 GMT Subject: RFR: 8315680: java/lang/ref/ReachabilityFenceTest.java should run with -Xbatch In-Reply-To: References: Message-ID: On Tue, 3 Oct 2023 07:47:30 GMT, Gerg? Barany wrote: > This test requires certain methods to be compiled, but without `-Xbatch` the compiler races against the test code, which can lead to intermittent failures. @PaulSandoz do you see any problem with this change? Adding `-Xbatch` does not significantly increase the test run time. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16023#issuecomment-1798453055 From mgronlun at openjdk.org Tue Nov 7 13:28:31 2023 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Tue, 7 Nov 2023 13:28:31 GMT Subject: RFR: 8319374: JFR: Remove instrumentation for exception events [v3] In-Reply-To: References: Message-ID: On Tue, 7 Nov 2023 11:11:31 GMT, Erik Gahlin wrote: >> Could I have a review of a PR that removes the bytecode instrumentation for the exception events. >> >> Testing: jdk/jdk/jfr + tier1 + tier2 > > Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision: > > Rename field from tracing to jfrTracing Marked as reviewed by mgronlun (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/16493#pullrequestreview-1717679195 From naoto at openjdk.org Tue Nov 7 13:31:35 2023 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 7 Nov 2023 13:31:35 GMT Subject: RFR: 8317742: ISO Standard Date Format implementation consistency on DateTimeFormatter and String.format [v5] In-Reply-To: References: Message-ID: On Tue, 7 Nov 2023 01:31:03 GMT, Shaojin Wen wrote: >> j.u.Formatter now prints "%tF" (iso standard date) and the result is incorrect when processing year < 0 or year > 9999 > > Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: > > use DecimalFormatSymbols#getMinusSign src/java.base/share/classes/java/util/Formatter.java line 4495: > 4493: int year = t.get(ChronoField.YEAR); > 4494: if (year < 0) { > 4495: sb.append(DecimalFormatSymbols.getInstance(l).getMinusSign()); Instead of creating the instance each time, `getMinusSign(Locale)` can be defined, analogous to `getZero(Locale)` so that the cached instance is reused. test/jdk/java/util/Formatter/BasicDateTime.java line 473: > 471: "%tF", > 472: DecimalFormatSymbols.getInstance(localeEuES).getMinusSign() + "2023-01-13", > 473: LocalDate.of(-2023, 1, 13)); Needs some comments here, otherwise it would be a bit cryptic. Also, "eu-ES" locale using `\u2212` depends on the current CLDR implementation, so you might want to check all locales with `Locale.availableLocale()`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16033#discussion_r1384355166 PR Review Comment: https://git.openjdk.org/jdk/pull/16033#discussion_r1384915823 From redestad at openjdk.org Tue Nov 7 13:51:40 2023 From: redestad at openjdk.org (Claes Redestad) Date: Tue, 7 Nov 2023 13:51:40 GMT Subject: RFR: 8317742: ISO Standard Date Format implementation consistency on DateTimeFormatter and String.format [v5] In-Reply-To: References: Message-ID: On Tue, 7 Nov 2023 13:28:06 GMT, Naoto Sato wrote: >> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: >> >> use DecimalFormatSymbols#getMinusSign > > test/jdk/java/util/Formatter/BasicDateTime.java line 473: > >> 471: "%tF", >> 472: DecimalFormatSymbols.getInstance(localeEuES).getMinusSign() + "2023-01-13", >> 473: LocalDate.of(-2023, 1, 13)); > > Needs some comments here, otherwise it would be a bit cryptic. Also, "eu-ES" locale using `\u2212` depends on the current CLDR implementation, so you might want to check all locales with `Locale.availableLocale()`. While it might be reasonable to localize using `getMinusSign()` this will introduce a new inconsistency with `DateTimeFormatter` (which *does not* localize minus signs in front of years): int minus = DecimalFormatSymbols.getInstance(Locale.forLanguageTag("eu-ES")) .getMinusSign() minus ==> 8722 int first = DateTimeFormatter.ISO_DATE .withLocale(Locale.forLanguageTag("eu-ES")) .format(ZonedDateTime.now() .minus(4000, java.time.temporal.ChronoUnit.YEARS) .charAt(0) first ==> 45 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16033#discussion_r1384939609 From jlahoda at openjdk.org Tue Nov 7 14:18:41 2023 From: jlahoda at openjdk.org (Jan Lahoda) Date: Tue, 7 Nov 2023 14:18:41 GMT Subject: RFR: 8319220: Pattern matching switch with a lot of cases is unduly slow [v5] In-Reply-To: References: Message-ID: > Consider code like: > > void test(Object o) { > switch (o) { > case X1 -> {} > case X2 -> {} > ...(about 100 cases) > ``` > > javac will compile the switch into a switch whose selector is an indy invocation to `SwitchBootstraps.typeSwitch`, with static arguments being the types in the cases. > > `SwitchBootstraps.typeSwitch` will then create a chain of `MethodHandle`s performing `instanceof` checks between the switch's selector and the given case type. The problem is that when the number of cases is high enough, (more than ~40-50), the chain gets too long, and the tests won't inline anymore. This then leads to a very bad performance, when compared to manually written if-instanceof-else-if-instanceof- chain. > > The proposal herein is to use bytecode (written using the ClassFile API/library) instead of the `MethodHandle`s chain. The overall performance of this seems to be similar to the manually written if-instanceof-else-if-instanceof- chain. > > Using the benchmark from the bug, and this patch, I am getting: > > MyBenchmark.testIfElse100 thrpt 5 521826.326 ? 7510.042 ops/s > MyBenchmark.testSwitch100 thrpt 5 505440.170 ? 3757.178 ops/s > > > The most tricky part of this new way to generate the tests is handling of non-type case labels, and in particular cases with enum constant labels. The resolution of enum constants is deferred as much as possible, by using an indirection through the `ResolvedEnumLabels`. > > Further improvements may be possible, esp. for some specific cases (like all cases having a type, and the type being a final class). Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits: - Merge branch 'master' into JDK-8319220 - reflecting review comment: fixing letter case. - Reflecting review feedback. - Some more get->orElseThrow - Reflecting review feedback. - Avoiding generating dead code - review feedback. - Cleanup. - Attempting to speeding SwitchBootstraps. ------------- Changes: https://git.openjdk.org/jdk/pull/16489/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16489&range=04 Stats: 361 lines in 2 files changed: 241 ins; 94 del; 26 mod Patch: https://git.openjdk.org/jdk/pull/16489.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16489/head:pull/16489 PR: https://git.openjdk.org/jdk/pull/16489 From pminborg at openjdk.org Tue Nov 7 14:37:40 2023 From: pminborg at openjdk.org (Per Minborg) Date: Tue, 7 Nov 2023 14:37:40 GMT Subject: Integrated: 8319607: FFM: Review the language in the FFM documentation In-Reply-To: References: Message-ID: <8j9E2D6DZq2I9ryqAuGtmnz-0X0pnNSsOPmYSWbTydI=.84e9858c-46c6-4ef4-942f-7dc19b5fe229@github.com> On Tue, 7 Nov 2023 09:31:11 GMT, Per Minborg wrote: > This PR proposes to improve the language used in the FFM specification. There is a relatively small number of corrections. > > One peculiarity with the English language is the distinction between "that" (to be used in a restrictive clause) and "which" (to be used in a non-restrictive clause). Here is a reference: https://preply.com/en/blog/when-to-use-which-or-that-the-most-common-cases > > Another source for updates is the difference between BE and AE where most of us Europeans were taught BE but we should use AE in the specifications. This pull request has now been integrated. Changeset: ef8c8408 Author: Per Minborg URL: https://git.openjdk.org/jdk/commit/ef8c8408a6072153ba3ebd91915c84df5054d672 Stats: 128 lines in 12 files changed: 0 ins; 0 del; 128 mod 8319607: FFM: Review the language in the FFM documentation Reviewed-by: mcimadamore ------------- PR: https://git.openjdk.org/jdk/pull/16536 From pminborg at openjdk.org Tue Nov 7 15:04:55 2023 From: pminborg at openjdk.org (Per Minborg) Date: Tue, 7 Nov 2023 15:04:55 GMT Subject: RFR: 8319560: Reformat method parameters in the FFM API [v2] In-Reply-To: References: Message-ID: > This PR proposes to reformat some method parameters in the FFM API. The proposed changes are a bit opinion based eve though there are some underlying principles. Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits: - Merge master - Harmonize method parameter layouts ------------- Changes: https://git.openjdk.org/jdk/pull/16527/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16527&range=01 Stats: 26 lines in 4 files changed: 14 ins; 0 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/16527.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16527/head:pull/16527 PR: https://git.openjdk.org/jdk/pull/16527 From mcimadamore at openjdk.org Tue Nov 7 15:05:35 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Tue, 7 Nov 2023 15:05:35 GMT Subject: RFR: 8319556: Harmonize interface formatting in the FFM API [v2] In-Reply-To: References: Message-ID: On Tue, 7 Nov 2023 11:41:06 GMT, Per Minborg wrote: >> This PR proposes to remove two `permits` declarations where the line overflows the stipulated maximum column with. Also, it proposes to harmonize the layout of `permit` formatting so they are the the same throughout the API. >> >> This PR might be perceived as over worked but I think it nice to get consistency across the API now that we go final. > > Per Minborg has updated the pull request incrementally with two additional commits since the last revision: > > - Remove redundandt space > - Use permits reformatting only when needed There seems to be still changes that are not needed. E.g. `AddressLayout`, `GroupLayout` and all the nested classes inside `ValueLayout`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16528#issuecomment-1798789694 From rriggs at openjdk.org Tue Nov 7 15:06:36 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 7 Nov 2023 15:06:36 GMT Subject: RFR: 8317742: ISO Standard Date Format implementation consistency on DateTimeFormatter and String.format [v5] In-Reply-To: References: Message-ID: On Tue, 7 Nov 2023 13:45:54 GMT, Claes Redestad wrote: >> test/jdk/java/util/Formatter/BasicDateTime.java line 473: >> >>> 471: "%tF", >>> 472: DecimalFormatSymbols.getInstance(localeEuES).getMinusSign() + "2023-01-13", >>> 473: LocalDate.of(-2023, 1, 13)); >> >> Needs some comments here, otherwise it would be a bit cryptic. Also, "eu-ES" locale using `\u2212` depends on the current CLDR implementation, so you might want to check all locales with `Locale.availableLocale()`. > > While it might be reasonable to localize using `getMinusSign()` this will introduce a new inconsistency with `DateTimeFormatter` (which *does not* localize minus signs in front of years): > > int minus = DecimalFormatSymbols.getInstance(Locale.forLanguageTag("eu-ES")) > .getMinusSign() > minus ==> 8722 > > int first = DateTimeFormatter.ISO_DATE > .withLocale(Locale.forLanguageTag("eu-ES")) > .format(ZonedDateTime.now() > .minus(4000, java.time.temporal.ChronoUnit.YEARS) > .charAt(0) > first ==> 45 Within java.util.Formatter, the year formatter supports only the range [0,9999]. Only ISO_STANDARD_DATE has a ISO 8601 format defined for numbers outside that range. The formatting in java.time is defined over the full range of years. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16033#discussion_r1385067362 From pminborg at openjdk.org Tue Nov 7 15:07:40 2023 From: pminborg at openjdk.org (Per Minborg) Date: Tue, 7 Nov 2023 15:07:40 GMT Subject: Integrated: 8319560: Reformat method parameters in the FFM API In-Reply-To: References: Message-ID: <_ONYCczSdnRlqotSYjhjZDHtVaMYG1J-MEd8Hs_CR84=.92232bfd-edba-403c-a60f-3de31b5f7f69@github.com> On Mon, 6 Nov 2023 21:00:10 GMT, Per Minborg wrote: > This PR proposes to reformat some method parameters in the FFM API. The proposed changes are a bit opinion based eve though there are some underlying principles. This pull request has now been integrated. Changeset: 134c382d Author: Per Minborg URL: https://git.openjdk.org/jdk/commit/134c382d39c605352e422ccb2b7b26025bfe4c5b Stats: 26 lines in 4 files changed: 14 ins; 0 del; 12 mod 8319560: Reformat method parameters in the FFM API Reviewed-by: mcimadamore ------------- PR: https://git.openjdk.org/jdk/pull/16527 From pminborg at openjdk.org Tue Nov 7 15:14:31 2023 From: pminborg at openjdk.org (Per Minborg) Date: Tue, 7 Nov 2023 15:14:31 GMT Subject: RFR: 8319556: Harmonize interface formatting in the FFM API [v2] In-Reply-To: References: Message-ID: On Tue, 7 Nov 2023 11:41:06 GMT, Per Minborg wrote: >> This PR proposes to remove two `permits` declarations where the line overflows the stipulated maximum column with. Also, it proposes to harmonize the layout of `permit` formatting so they are the the same throughout the API. >> >> This PR might be perceived as over worked but I think it nice to get consistency across the API now that we go final. > > Per Minborg has updated the pull request incrementally with two additional commits since the last revision: > > - Remove redundandt space > - Use permits reformatting only when needed Hrmm. I reformatted all classes of the same category where at least one of them needed reformatting to make it more consistent. For example: `OfBoolean` overflows but not `OfByte`. So, all of the of* were consistently reformatted. So, let's pick a choice here: 1) Reformat only those specific classes needing it not bothering if similar classes look different 2) Keep it as it is. I am happy to do either. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16528#issuecomment-1798832942 From duke at openjdk.org Tue Nov 7 15:18:37 2023 From: duke at openjdk.org (Shaojin Wen) Date: Tue, 7 Nov 2023 15:18:37 GMT Subject: RFR: 8317742: ISO Standard Date Format implementation consistency on DateTimeFormatter and String.format [v5] In-Reply-To: References: Message-ID: On Tue, 7 Nov 2023 15:04:16 GMT, Roger Riggs wrote: >> While it might be reasonable to localize using `getMinusSign()` this will introduce a new inconsistency with `DateTimeFormatter` (which *does not* localize minus signs in front of years): >> >> int minus = DecimalFormatSymbols.getInstance(Locale.forLanguageTag("eu-ES")) >> .getMinusSign() >> minus ==> 8722 >> >> int first = DateTimeFormatter.ISO_DATE >> .withLocale(Locale.forLanguageTag("eu-ES")) >> .format(ZonedDateTime.now() >> .minus(4000, java.time.temporal.ChronoUnit.YEARS) >> .charAt(0) >> first ==> 45 > > Within java.util.Formatter, the year formatter supports only the range [0,9999]. > Only ISO_STANDARD_DATE has a ISO 8601 format defined for numbers outside that range. > The formatting in java.time is defined over the full range of years. I think it is more reasonable for ISO_STANDARD_DATE to be consistent with java.time.DateTimeFormatter, ISO 8601 format is not localized. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16033#discussion_r1385083995 From duke at openjdk.org Tue Nov 7 15:19:37 2023 From: duke at openjdk.org (Shaojin Wen) Date: Tue, 7 Nov 2023 15:19:37 GMT Subject: RFR: 8316704: Regex-free parsing of Formatter and FormatProcessor specifiers [v5] In-Reply-To: <4Svt2bqEKfvhgxaORRHwDTQQ7kqWN2UoD9pTusfZ0nM=.9c0cf5b5-201d-4fb5-ad70-5fedf512cdd8@github.com> References: <9UsU73B_0Tc03SRJoJFOxsQrmhTUdSPJAi-S0nTD_lk=.7b6782f9-b578-47a0-a0c6-a6f384f60785@github.com> <4Svt2bqEKfvhgxaORRHwDTQQ7kqWN2UoD9pTusfZ0nM=.9c0cf5b5-201d-4fb5-ad70-5fedf512cdd8@github.com> Message-ID: <4XL-3bbq5G_DRwxNZgSMrOWYiq7pUpT0O4mBaeeD9p0=.9613780d-e84a-4b86-a799-17cb2bfd9bca@github.com> On Sat, 21 Oct 2023 01:22:04 GMT, Shaojin Wen wrote: >> @cl4es made performance optimizations for the simple specifiers of String.format in PR https://github.com/openjdk/jdk/pull/2830. Based on the same idea, I continued to make improvements. I made patterns like %2d %02d also be optimized. >> >> The following are the test results based on MacBookPro M1 Pro: >> >> >> -Benchmark Mode Cnt Score Error Units >> -StringFormat.complexFormat avgt 15 1862.233 ? 217.479 ns/op >> -StringFormat.int02Format avgt 15 312.491 ? 26.021 ns/op >> -StringFormat.intFormat avgt 15 84.432 ? 4.145 ns/op >> -StringFormat.longFormat avgt 15 87.330 ? 6.111 ns/op >> -StringFormat.stringFormat avgt 15 63.985 ? 11.366 ns/op >> -StringFormat.stringIntFormat avgt 15 87.422 ? 0.147 ns/op >> -StringFormat.widthStringFormat avgt 15 250.740 ? 32.639 ns/op >> -StringFormat.widthStringIntFormat avgt 15 312.474 ? 16.309 ns/op >> >> +Benchmark Mode Cnt Score Error Units >> +StringFormat.complexFormat avgt 15 740.626 ? 66.671 ns/op (+151.45) >> +StringFormat.int02Format avgt 15 131.049 ? 0.432 ns/op (+138.46) >> +StringFormat.intFormat avgt 15 67.229 ? 4.155 ns/op (+25.59) >> +StringFormat.longFormat avgt 15 66.444 ? 0.614 ns/op (+31.44) >> +StringFormat.stringFormat avgt 15 62.619 ? 4.652 ns/op (+2.19) >> +StringFormat.stringIntFormat avgt 15 89.606 ? 13.966 ns/op (-2.44) >> +StringFormat.widthStringFormat avgt 15 52.462 ? 15.649 ns/op (+377.95) >> +StringFormat.widthStringIntFormat avgt 15 101.814 ? 3.147 ns/op (+206.91) > > Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: > > fix from @rgiulietti 's review Can anyone help me review this PR? ------------- PR Comment: https://git.openjdk.org/jdk/pull/15776#issuecomment-1798845212 From alanb at openjdk.org Tue Nov 7 15:23:32 2023 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 7 Nov 2023 15:23:32 GMT Subject: RFR: 8319374: JFR: Remove instrumentation for exception events [v3] In-Reply-To: References: Message-ID: On Tue, 7 Nov 2023 11:11:31 GMT, Erik Gahlin wrote: >> Could I have a review of a PR that removes the bytecode instrumentation for the exception events. >> >> Testing: jdk/jdk/jfr + tier1 + tier2 > > Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision: > > Rename field from tracing to jfrTracing The changes looks okay and will track the follow-on issue to look at SOE. ------------- Marked as reviewed by alanb (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16493#pullrequestreview-1717977940 From rriggs at openjdk.org Tue Nov 7 15:29:32 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 7 Nov 2023 15:29:32 GMT Subject: RFR: 8319174: Enhance robustness of some j.m.BigInteger constructors [v5] In-Reply-To: <8sscQFpSGhptxc9OJVvOAJHkV8U8j-_RmIMg-ZxZz-E=.9b651b5f-a894-45c9-9a59-16332c1cb69c@github.com> References: <0iccBwbAhAmIPGxnz1bhry2Sj_Kz2xngZmb2lPFCUpU=.c2b7c8ef-4e77-4c8f-a7ec-7c5c0980e59e@github.com> <8sscQFpSGhptxc9OJVvOAJHkV8U8j-_RmIMg-ZxZz-E=.9b651b5f-a894-45c9-9a59-16332c1cb69c@github.com> Message-ID: <4X9D7Cw2Aky7mKTuRsHDw7yrDEnXbPI_P4hdfg3etC8=.1ee9067c-6f34-45aa-ab3c-6437f8aaecde@github.com> On Fri, 3 Nov 2023 19:14:18 GMT, Raffaello Giulietti wrote: >> Enhance `java.math.BigInteger` constructors taking a `byte[]` argument by improving guarantees of internal invariants. > > Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: > > Changed behavior on len == 0. Looks good ------------- Marked as reviewed by rriggs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16449#pullrequestreview-1717994078 From alanb at openjdk.org Tue Nov 7 15:55:49 2023 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 7 Nov 2023 15:55:49 GMT Subject: RFR: JDK-8315458 Implementation of Implicitly Declared Classes and Instance Main Method (Second Preview) [v14] In-Reply-To: References: Message-ID: On Tue, 7 Nov 2023 12:29:12 GMT, Jim Laskey wrote: >> Address changes from JEP 445 to JEP 463. >> >> - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. >> >> - Don't mark class on read. >> >> - Remove reflection and annotation processing related to unnamed classes. >> >> - Simplify main method search. > > Jim Laskey has updated the pull request with a new target base 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 remote-tracking branch 'upstream/master' into 8315458 > - Rename unnamed class tests and examples > - Merge remote-tracking branch 'upstream/master' into 8315458 > - Don't get args unless necessary > - Remove unnamed classes from examples.not-yet.txt > - Requested corrections > - Changes recommended by Jan > - Revised implicit class test > - Don't store main method info globally. Use addition calls to fetch info. > - Update JEP number in PreviewFeature > - ... and 4 more: https://git.openjdk.org/jdk/compare/f006108e...7effbcff Launcher changes look okay. There are a few more upcalls to methods on the launcher helper now so I assume you'll run the startup benchmarks to make sure it doesn't have any impact. src/java.base/share/classes/sun/launcher/LauncherHelper.java line 899: > 897: /* > 898: * Return type so that launcher invokes the correct main > 899: */ If you are doing anymore edits then I think this method description could be improved to say that it returns the main method type. ------------- Marked as reviewed by alanb (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16461#pullrequestreview-1718039775 PR Review Comment: https://git.openjdk.org/jdk/pull/16461#discussion_r1385134339 From alanb at openjdk.org Tue Nov 7 15:55:50 2023 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 7 Nov 2023 15:55:50 GMT Subject: RFR: JDK-8315458 Implementation of Implicitly Declared Classes and Instance Main Method (Second Preview) [v14] In-Reply-To: References: Message-ID: On Tue, 7 Nov 2023 15:45:02 GMT, Alan Bateman wrote: >> Jim Laskey has updated the pull request with a new target base 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 remote-tracking branch 'upstream/master' into 8315458 >> - Rename unnamed class tests and examples >> - Merge remote-tracking branch 'upstream/master' into 8315458 >> - Don't get args unless necessary >> - Remove unnamed classes from examples.not-yet.txt >> - Requested corrections >> - Changes recommended by Jan >> - Revised implicit class test >> - Don't store main method info globally. Use addition calls to fetch info. >> - Update JEP number in PreviewFeature >> - ... and 4 more: https://git.openjdk.org/jdk/compare/f006108e...7effbcff > > src/java.base/share/classes/sun/launcher/LauncherHelper.java line 899: > >> 897: /* >> 898: * Return type so that launcher invokes the correct main >> 899: */ > > If you are doing anymore edits then I think this method description could be improved to say that it returns the main method type. Another suggestion, if you are editing more, is the description on LoadMainClass (in java.c) is confusingly worded, he currently says "Loads a class and verifies that the main class is present". It invokes the helper's checkAndLoadMain so maybe the comment could be adjusted to say that it calls checkAndLoadMain to load the main class. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16461#discussion_r1385150582 From mcimadamore at openjdk.org Tue Nov 7 16:10:29 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Tue, 7 Nov 2023 16:10:29 GMT Subject: RFR: 8319556: Harmonize interface formatting in the FFM API [v2] In-Reply-To: References: Message-ID: On Tue, 7 Nov 2023 15:11:25 GMT, Per Minborg wrote: > Hrmm. I reformatted all classes of the same category where at least one of them needed reformatting to make it more consistent. For example: `OfBoolean` overflows but not `OfByte`. So, all of the of* were consistently reformatted. So, let's pick a choice here: > > 1. Reformat only those specific classes needing it not bothering if similar classes look different > > 2. Keep it as it is. > > > I am happy to do either. I'm fine with value layout nested classes, but what about AddressLayout/GroupLayout? ------------- PR Comment: https://git.openjdk.org/jdk/pull/16528#issuecomment-1799040997 From jlaskey at openjdk.org Tue Nov 7 16:19:33 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Tue, 7 Nov 2023 16:19:33 GMT Subject: RFR: JDK-8315458 Implementation of Implicitly Declared Classes and Instance Main Method (Second Preview) [v15] In-Reply-To: References: Message-ID: > Address changes from JEP 445 to JEP 463. > > - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. > > - Don't mark class on read. > > - Remove reflection and annotation processing related to unnamed classes. > > - Simplify main method search. Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: Update launch comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16461/files - new: https://git.openjdk.org/jdk/pull/16461/files/7effbcff..d3581d89 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16461&range=14 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16461&range=13-14 Stats: 5 lines in 2 files changed: 2 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/16461.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16461/head:pull/16461 PR: https://git.openjdk.org/jdk/pull/16461 From jlaskey at openjdk.org Tue Nov 7 16:21:50 2023 From: jlaskey at openjdk.org (Jim Laskey) Date: Tue, 7 Nov 2023 16:21:50 GMT Subject: RFR: JDK-8315458 Implementation of Implicitly Declared Classes and Instance Main Method (Second Preview) [v14] In-Reply-To: References: Message-ID: On Tue, 7 Nov 2023 15:51:22 GMT, Alan Bateman wrote: >> src/java.base/share/classes/sun/launcher/LauncherHelper.java line 899: >> >>> 897: /* >>> 898: * Return type so that launcher invokes the correct main >>> 899: */ >> >> If you are doing anymore edits then I think this method description could be improved to say that it returns the main method type. > > Another suggestion, if you are editing more, is the description on LoadMainClass (in java.c) is confusingly worded, he currently says "Loads a class and verifies that the main class is present". It invokes the helper's checkAndLoadMain so maybe the comment could be adjusted to say that it calls checkAndLoadMain to load the main class. Updated ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16461#discussion_r1385191813 From pminborg at openjdk.org Tue Nov 7 16:32:43 2023 From: pminborg at openjdk.org (Per Minborg) Date: Tue, 7 Nov 2023 16:32:43 GMT Subject: RFR: 8319556: Harmonize interface formatting in the FFM API [v3] In-Reply-To: References: Message-ID: > This PR proposes to remove two `permits` declarations where the line overflows the stipulated maximum column with. Also, it proposes to harmonize the layout of `permit` formatting so they are the the same throughout the API. > > This PR might be perceived as over worked but I think it nice to get consistency across the API now that we go final. Per Minborg has updated the pull request incrementally with one additional commit since the last revision: Revert some foramtting ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16528/files - new: https://git.openjdk.org/jdk/pull/16528/files/bc07305d..14ed6c90 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16528&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16528&range=01-02 Stats: 22 lines in 4 files changed: 0 ins; 11 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/16528.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16528/head:pull/16528 PR: https://git.openjdk.org/jdk/pull/16528 From mcimadamore at openjdk.org Tue Nov 7 16:37:30 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Tue, 7 Nov 2023 16:37:30 GMT Subject: RFR: 8319556: Harmonize interface formatting in the FFM API [v3] In-Reply-To: References: Message-ID: On Tue, 7 Nov 2023 16:32:43 GMT, Per Minborg wrote: >> This PR proposes to remove two `permits` declarations where the line overflows the stipulated maximum column with. Also, it proposes to harmonize the layout of `permit` formatting so they are the the same throughout the API. >> >> This PR might be perceived as over worked but I think it nice to get consistency across the API now that we go final. > > Per Minborg has updated the pull request incrementally with one additional commit since the last revision: > > Revert some foramtting Marked as reviewed by mcimadamore (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/16528#pullrequestreview-1718171040 From dfenacci at openjdk.org Tue Nov 7 16:42:33 2023 From: dfenacci at openjdk.org (Damon Fenacci) Date: Tue, 7 Nov 2023 16:42:33 GMT Subject: RFR: 8311906: Improve robustness of String constructors with mutable array inputs In-Reply-To: <6SKlGLh5MmxoEx07wHCCUc8KWbbhcspLJmcc1uxQ_FI=.ca33bfb4-fa5c-45f0-b49f-ee6c5c6b68b4@github.com> References: <6SKlGLh5MmxoEx07wHCCUc8KWbbhcspLJmcc1uxQ_FI=.ca33bfb4-fa5c-45f0-b49f-ee6c5c6b68b4@github.com> Message-ID: On Mon, 30 Oct 2023 18:34:44 GMT, Roger Riggs wrote: > Strings, after construction, are immutable but may be constructed from mutable arrays of bytes, characters, or integers. > The string constructors should guard against the effects of mutating the arrays during construction that might invalidate internal invariants for the correct behavior of operations on the resulting strings. In particular, a number of operations have optimizations for operations on pairs of latin1 strings and pairs of non-latin1 strings, while operations between latin1 and non-latin1 strings use a more general implementation. > > The changes include: > > - Adding a warning to each constructor with an array as an argument to indicate that the results are indeterminate > if the input array is modified before the constructor returns. > The resulting string may contain any combination of characters sampled from the input array. > > - Ensure that strings that are represented as non-latin1 contain at least one non-latin1 character. > For latin1 inputs, whether the arrays contain ASCII, ISO-8859-1, UTF8, or another encoding decoded to latin1 the scanning and compression is unchanged. > If a non-latin1 character is found, the string is represented as non-latin1 with the added verification that a non-latin1 character is present at the same index. > If that character is found to be latin1, then the input array has been modified and the result of the scan may be incorrect. > Though a ConcurrentModificationException could be thrown, the risk to an existing application of an unexpected exception should be avoided. > Instead, the non-latin1 copy of the input is re-scanned and compressed; that scan determines whether the latin1 or the non-latin1 representation is returned. > > - The methods that scan for non-latin1 characters and their intrinsic implementations are updated to return the index of the non-latin1 character. > > - String construction from StringBuilder and CharSequence must also be guarded as their contents may be modified during construction. This PR includes changes to the `C2_MacroAssembler::char_array_compress_v` intrinsic for **RISCV** that we couldn't test. @RealFYang could you please test and review it? Thanks a lot! ------------- PR Comment: https://git.openjdk.org/jdk/pull/16425#issuecomment-1799144689 From naoto at openjdk.org Tue Nov 7 16:44:33 2023 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 7 Nov 2023 16:44:33 GMT Subject: RFR: 8317742: ISO Standard Date Format implementation consistency on DateTimeFormatter and String.format [v5] In-Reply-To: References: Message-ID: <6VnaPgf9pbpLauwPU_ixQGQXSK7Pz28xi2VyFYe2ATI=.cd8aeb2c-3fc6-4720-81ae-efa57eef571c@github.com> On Tue, 7 Nov 2023 15:15:19 GMT, Shaojin Wen wrote: >> Within java.util.Formatter, the year formatter supports only the range [0,9999]. >> Only ISO_STANDARD_DATE has a ISO 8601 format defined for numbers outside that range. >> The formatting in java.time is defined over the full range of years. > > I think it is more reasonable for ISO_STANDARD_DATE to be consistent with java.time.DateTimeFormatter, ISO 8601 format is not localized. IIUC, what we are trying to fix here is to align the weird *behavior* outside of 0-9999 in java.util.Formatter with java.time's, not how they are represented. j.u.Formatter already formats numbers in local digits, so I believe it is natural to use the localized negative prefix as well. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16033#discussion_r1385229360 From isipka at openjdk.org Tue Nov 7 16:46:30 2023 From: isipka at openjdk.org (Ivan =?UTF-8?B?xaBpcGth?=) Date: Tue, 7 Nov 2023 16:46:30 GMT Subject: RFR: JDK-8311961 Update Manual Test Groups for ATR JDK22 In-Reply-To: References: Message-ID: <2D16xNGo0N5mU9pIMkt-DvVe2sezmv0r7e-2lXQxsvE=.a5125265-a5af-4f39-9481-6cea420f4e64@github.com> On Mon, 6 Nov 2023 22:25:46 GMT, Bill Huang wrote: > Updated jdk_core_manual test groups. LGTM ------------- PR Comment: https://git.openjdk.org/jdk/pull/16531#issuecomment-1799175261 From lancea at openjdk.org Tue Nov 7 16:55:41 2023 From: lancea at openjdk.org (Lance Andersen) Date: Tue, 7 Nov 2023 16:55:41 GMT Subject: Integrated: 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 This pull request has now been integrated. Changeset: 82747132 Author: Lance Andersen URL: https://git.openjdk.org/jdk/commit/82747132b07e288c1e6c2ba3392748c7718e994a Stats: 1122 lines in 3 files changed: 1037 ins; 51 del; 34 mod 8314891: Additional Zip64 extra header validation Reviewed-by: coffeys ------------- PR: https://git.openjdk.org/jdk/pull/15650 From asemenyuk at openjdk.org Tue Nov 7 16:59:30 2023 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Tue, 7 Nov 2023 16:59:30 GMT Subject: RFR: 8319338: tools/jpackage/share/RuntimeImageTest.java fails with -XX:+UseZGC In-Reply-To: References: Message-ID: On Tue, 7 Nov 2023 06:21:24 GMT, Alan Bateman wrote: > Can you confirm that debug builds are passing with -XX:+UseZGC now? Yes, I can ------------- PR Comment: https://git.openjdk.org/jdk/pull/16535#issuecomment-1799203733 From mchung at openjdk.org Tue Nov 7 17:02:42 2023 From: mchung at openjdk.org (Mandy Chung) Date: Tue, 7 Nov 2023 17:02:42 GMT Subject: Integrated: 8319436: Proxy.newProxyInstance throws NPE if loader is null and interface not visible from class loader In-Reply-To: <3c9I42wkqwb6gtNvw3bowtyt4APRYb_L0DfscYe6KqU=.57b69660-b3f1-4d70-9189-8ad2601ab712@github.com> References: <3c9I42wkqwb6gtNvw3bowtyt4APRYb_L0DfscYe6KqU=.57b69660-b3f1-4d70-9189-8ad2601ab712@github.com> Message-ID: On Mon, 6 Nov 2023 19:12:28 GMT, Mandy Chung wrote: > This is a regression caused by JDK-8302791. IAE should be thrown when an interface is not visible to the given class loader but NPE is thrown instead when the loader is null. The boot loader has no name and so the fix will print `null` in the exception message. `test/jdk/java/lang/reflect/Proxy/ClassRestrictions.java` is converted to junit and updated to test IAE thrown because proxy interface is not visible to null loader. This pull request has now been integrated. Changeset: 8eb6f617 Author: Mandy Chung URL: https://git.openjdk.org/jdk/commit/8eb6f617b3f8e2a990e4244af4e56287f9741b20 Stats: 143 lines in 2 files changed: 20 ins; 77 del; 46 mod 8319436: Proxy.newProxyInstance throws NPE if loader is null and interface not visible from class loader Reviewed-by: alanb ------------- PR: https://git.openjdk.org/jdk/pull/16525 From alanb at openjdk.org Tue Nov 7 17:06:31 2023 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 7 Nov 2023 17:06:31 GMT Subject: RFR: 8319338: tools/jpackage/share/RuntimeImageTest.java fails with -XX:+UseZGC In-Reply-To: References: Message-ID: <2zt4ntyOTLKowQRtVAVCgfZqy4BHNWfWXcNIUr9yoe4=.efe13312-ca53-4fa6-8f83-472807d822be@github.com> On Tue, 7 Nov 2023 03:20:45 GMT, Alexey Semenyuk wrote: > Remove `-Xmx512m` from the jtreg `@run` command as @AlanBateman suggested Marked as reviewed by alanb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/16535#pullrequestreview-1718248698 From asemenyuk at openjdk.org Tue Nov 7 17:10:41 2023 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Tue, 7 Nov 2023 17:10:41 GMT Subject: Integrated: 8319338: tools/jpackage/share/RuntimeImageTest.java fails with -XX:+UseZGC In-Reply-To: References: Message-ID: On Tue, 7 Nov 2023 03:20:45 GMT, Alexey Semenyuk wrote: > Remove `-Xmx512m` from the jtreg `@run` command as @AlanBateman suggested This pull request has now been integrated. Changeset: e9eb8b98 Author: Alexey Semenyuk URL: https://git.openjdk.org/jdk/commit/e9eb8b98f4dd949c8a0f501189471e11b837d936 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8319338: tools/jpackage/share/RuntimeImageTest.java fails with -XX:+UseZGC Reviewed-by: almatvee, alanb ------------- PR: https://git.openjdk.org/jdk/pull/16535 From mabbay at openjdk.org Tue Nov 7 17:14:56 2023 From: mabbay at openjdk.org (Mourad Abbay) Date: Tue, 7 Nov 2023 17:14:56 GMT Subject: RFR: 8294980: test/jdk/java/lang/invoke 15 test classes use experimental bytecode library [v4] In-Reply-To: <-JRa1cWErB4H5zW-TqhXXd1y3TchfIXPMinb-CJ4OUE=.96cb1861-cb27-4030-a8a0-f90df924f041@github.com> References: <-JRa1cWErB4H5zW-TqhXXd1y3TchfIXPMinb-CJ4OUE=.96cb1861-cb27-4030-a8a0-f90df924f041@github.com> Message-ID: <9jpaJIlgccbUQCHeUJ_l3G1gUYG3qGVGCEqSRqXXC14=.d1f64a36-8819-4ce6-b11e-d11bd3c0f93a@github.com> > early experimental version of the bytecode library is bundled under: > test/jdk/lib/testlibrary/bytecode > > following tests reference it: > test/jdk/java/lang/invoke/common/test/java/lang/invoke/lib/InstructionHelper.java > test/jdk/java/lang/invoke/condy/CondyWithGarbageTest.java > test/jdk/java/lang/invoke/condy/CondyReturnPrimitiveTest.java > test/jdk/java/lang/invoke/condy/CondyWrongType.java > test/jdk/java/lang/invoke/condy/CondyNestedTest.java > test/jdk/java/lang/invoke/condy/CondyStaticArgumentsTest.java > test/jdk/java/lang/invoke/condy/BootstrapMethodJumboArgsTest.java > test/jdk/java/lang/invoke/condy/ConstantBootstrapsTest.java > test/jdk/java/lang/invoke/condy/CondyRepeatFailedResolution.java > test/jdk/java/lang/invoke/condy/CondyBSMInvocation.java > test/jdk/java/lang/invoke/condy/CondyTypeValidationTest.java > test/jdk/java/lang/invoke/condy/CondyBSMValidationTest.java > test/jdk/java/lang/invoke/condy/CondyNameValidationTest.java > test/jdk/java/lang/invoke/condy/CondyBSMException.java > test/jdk/java/lang/invoke/condy/CondyInterfaceWithOverpassMethods.java Mourad Abbay has updated the pull request incrementally with one additional commit since the last revision: Use TypeKind.from . ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16268/files - new: https://git.openjdk.org/jdk/pull/16268/files/0d1c94a9..878a8cc4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16268&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16268&range=02-03 Stats: 5 lines in 1 file changed: 0 ins; 2 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/16268.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16268/head:pull/16268 PR: https://git.openjdk.org/jdk/pull/16268 From naoto at openjdk.org Tue Nov 7 17:39:31 2023 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 7 Nov 2023 17:39:31 GMT Subject: RFR: 8305814: Update Xalan Java to 2.7.3 [v2] In-Reply-To: <1goSZ17pk6T4dzDeArDGT0SOLdRRh0ZVYGqoelze4Nw=.45046606-8d71-478d-9b88-d2fb7a1f4e75@github.com> References: <1goSZ17pk6T4dzDeArDGT0SOLdRRh0ZVYGqoelze4Nw=.45046606-8d71-478d-9b88-d2fb7a1f4e75@github.com> Message-ID: On Tue, 7 Nov 2023 05:43:06 GMT, Joe Wang wrote: >> Xalan 2.7.3: merge minor changes from the upstream project. >> >> Test: existing XML tests pass > > Joe Wang has updated the pull request incrementally with one additional commit since the last revision: > > remove commented out block in ExsltDatetime Marked as reviewed by naoto (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/16532#pullrequestreview-1718312476 From mchung at openjdk.org Tue Nov 7 17:46:46 2023 From: mchung at openjdk.org (Mandy Chung) Date: Tue, 7 Nov 2023 17:46:46 GMT Subject: RFR: JDK-8315458 Implementation of Implicitly Declared Classes and Instance Main Method (Second Preview) [v15] In-Reply-To: References: Message-ID: On Tue, 7 Nov 2023 16:19:33 GMT, Jim Laskey wrote: >> Address changes from JEP 445 to JEP 463. >> >> - Move from a SYNTHETIC unnamed class to a MANDATED implicit class. >> >> - Don't mark class on read. >> >> - Remove reflection and annotation processing related to unnamed classes. >> >> - Simplify main method search. > > Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: > > Update launch comments The changes in java.base looks fine. ------------- Marked as reviewed by mchung (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16461#pullrequestreview-1718330730 From psandoz at openjdk.org Tue Nov 7 17:48:31 2023 From: psandoz at openjdk.org (Paul Sandoz) Date: Tue, 7 Nov 2023 17:48:31 GMT Subject: RFR: 8315680: java/lang/ref/ReachabilityFenceTest.java should run with -Xbatch In-Reply-To: References: Message-ID: On Tue, 3 Oct 2023 07:47:30 GMT, Gerg? Barany wrote: > This test requires certain methods to be compiled, but without `-Xbatch` the compiler races against the test code, which can lead to intermittent failures. Marked as reviewed by psandoz (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/16023#pullrequestreview-1718335476 From psandoz at openjdk.org Tue Nov 7 17:48:32 2023 From: psandoz at openjdk.org (Paul Sandoz) Date: Tue, 7 Nov 2023 17:48:32 GMT Subject: RFR: 8315680: java/lang/ref/ReachabilityFenceTest.java should run with -Xbatch In-Reply-To: References: Message-ID: On Tue, 7 Nov 2023 17:45:36 GMT, Paul Sandoz wrote: >> This test requires certain methods to be compiled, but without `-Xbatch` the compiler races against the test code, which can lead to intermittent failures. > > Marked as reviewed by psandoz (Reviewer). > @PaulSandoz do you see any problem with this change? Adding `-Xbatch` does not significantly increase the test run time. Seems ok to me. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16023#issuecomment-1799331748 From rriggs at openjdk.org Tue Nov 7 17:55:31 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 7 Nov 2023 17:55:31 GMT Subject: RFR: 8311906: Improve robustness of String constructors with mutable array inputs In-Reply-To: <6SKlGLh5MmxoEx07wHCCUc8KWbbhcspLJmcc1uxQ_FI=.ca33bfb4-fa5c-45f0-b49f-ee6c5c6b68b4@github.com> References: <6SKlGLh5MmxoEx07wHCCUc8KWbbhcspLJmcc1uxQ_FI=.ca33bfb4-fa5c-45f0-b49f-ee6c5c6b68b4@github.com> Message-ID: <77-VU5TxUIOF1m0CJkL9BOoInaC-y_gFIKSl6bwqmq8=.c3fe0e09-19df-410c-89af-079bc5472ae6@github.com> On Mon, 30 Oct 2023 18:34:44 GMT, Roger Riggs wrote: > Strings, after construction, are immutable but may be constructed from mutable arrays of bytes, characters, or integers. > The string constructors should guard against the effects of mutating the arrays during construction that might invalidate internal invariants for the correct behavior of operations on the resulting strings. In particular, a number of operations have optimizations for operations on pairs of latin1 strings and pairs of non-latin1 strings, while operations between latin1 and non-latin1 strings use a more general implementation. > > The changes include: > > - Adding a warning to each constructor with an array as an argument to indicate that the results are indeterminate > if the input array is modified before the constructor returns. > The resulting string may contain any combination of characters sampled from the input array. > > - Ensure that strings that are represented as non-latin1 contain at least one non-latin1 character. > For latin1 inputs, whether the arrays contain ASCII, ISO-8859-1, UTF8, or another encoding decoded to latin1 the scanning and compression is unchanged. > If a non-latin1 character is found, the string is represented as non-latin1 with the added verification that a non-latin1 character is present at the same index. > If that character is found to be latin1, then the input array has been modified and the result of the scan may be incorrect. > Though a ConcurrentModificationException could be thrown, the risk to an existing application of an unexpected exception should be avoided. > Instead, the non-latin1 copy of the input is re-scanned and compressed; that scan determines whether the latin1 or the non-latin1 representation is returned. > > - The methods that scan for non-latin1 characters and their intrinsic implementations are updated to return the index of the non-latin1 character. > > - String construction from StringBuilder and CharSequence must also be guarded as their contents may be modified during construction. Damon Fenacci authored the updates to the hotspot intrinsics. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16425#issuecomment-1799341933 From rriggs at openjdk.org Tue Nov 7 18:10:35 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 7 Nov 2023 18:10:35 GMT Subject: RFR: 8311906: Improve robustness of String constructors with mutable array inputs In-Reply-To: <6SKlGLh5MmxoEx07wHCCUc8KWbbhcspLJmcc1uxQ_FI=.ca33bfb4-fa5c-45f0-b49f-ee6c5c6b68b4@github.com> References: <6SKlGLh5MmxoEx07wHCCUc8KWbbhcspLJmcc1uxQ_FI=.ca33bfb4-fa5c-45f0-b49f-ee6c5c6b68b4@github.com> Message-ID: On Mon, 30 Oct 2023 18:34:44 GMT, Roger Riggs wrote: > Strings, after construction, are immutable but may be constructed from mutable arrays of bytes, characters, or integers. > The string constructors should guard against the effects of mutating the arrays during construction that might invalidate internal invariants for the correct behavior of operations on the resulting strings. In particular, a number of operations have optimizations for operations on pairs of latin1 strings and pairs of non-latin1 strings, while operations between latin1 and non-latin1 strings use a more general implementation. > > The changes include: > > - Adding a warning to each constructor with an array as an argument to indicate that the results are indeterminate > if the input array is modified before the constructor returns. > The resulting string may contain any combination of characters sampled from the input array. > > - Ensure that strings that are represented as non-latin1 contain at least one non-latin1 character. > For latin1 inputs, whether the arrays contain ASCII, ISO-8859-1, UTF8, or another encoding decoded to latin1 the scanning and compression is unchanged. > If a non-latin1 character is found, the string is represented as non-latin1 with the added verification that a non-latin1 character is present at the same index. > If that character is found to be latin1, then the input array has been modified and the result of the scan may be incorrect. > Though a ConcurrentModificationException could be thrown, the risk to an existing application of an unexpected exception should be avoided. > Instead, the non-latin1 copy of the input is re-scanned and compressed; that scan determines whether the latin1 or the non-latin1 representation is returned. > > - The methods that scan for non-latin1 characters and their intrinsic implementations are updated to return the index of the non-latin1 character. > > - String construction from StringBuilder and CharSequence must also be guarded as their contents may be modified during construction. Remove the override. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16425#issuecomment-1799374280 From abimpoudis at openjdk.org Tue Nov 7 18:24:59 2023 From: abimpoudis at openjdk.org (Aggelos Biboudis) Date: Tue, 7 Nov 2023 18:24:59 GMT Subject: RFR: 8303374: Compiler Implementation for Primitive types in patterns, instanceof, and switch (Preview) [v29] In-Reply-To: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com> References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com> Message-ID: > This is the proposed patch for Primitive types in patterns, instanceof, and switch (Preview). > > Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/jep455-20231030/specs/instanceof-jls.html Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision: Small cleanup in PrimitivePatternsSwitch ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15638/files - new: https://git.openjdk.org/jdk/pull/15638/files/a7f778ca..e81f023a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=28 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=27-28 Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/15638.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15638/head:pull/15638 PR: https://git.openjdk.org/jdk/pull/15638 From mchung at openjdk.org Tue Nov 7 18:34:42 2023 From: mchung at openjdk.org (Mandy Chung) Date: Tue, 7 Nov 2023 18:34:42 GMT Subject: RFR: 8187655: jdk.lambda.vm.InterfaceAccessFlagsTest.testPrivateMethodCall needs update after nestmates support [v2] In-Reply-To: References: Message-ID: > `jdk.lambda.vm.InterfaceAccessFlagsTest` uses `ClassToInterfaceConverter` to mechanically convert a classfile for a Class into an in-memory class representation of an equivalent Interface. `testPrivateMethodCall` tests to invoke a private method. Before nestmates, invoking a private class method and a private interface method both use `Invokespecial`. With the nestmate changes, the class uses `invokevirtual` but the interface must use `invokeinterface` but this conversion is not handled by the existing `ClassToInterfaceConverter`. > > This fix converts `ClassToInterfaceConverter` to use the Class-File API to properly convert a classfile from a class to an interface including method invocation from `invokevirtual` to `invokeinterface`. The old custom bytecode manipulation code can be dropped. Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: Simplify the transformation code and easier to read ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16526/files - new: https://git.openjdk.org/jdk/pull/16526/files/8f4e9056..7feb2ffc Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16526&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16526&range=00-01 Stats: 40 lines in 1 file changed: 0 ins; 21 del; 19 mod Patch: https://git.openjdk.org/jdk/pull/16526.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16526/head:pull/16526 PR: https://git.openjdk.org/jdk/pull/16526 From rriggs at openjdk.org Tue Nov 7 18:44:31 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 7 Nov 2023 18:44:31 GMT Subject: RFR: 8318915: Enhance checks in BigDecimal.toPlainString() In-Reply-To: References: Message-ID: On Wed, 1 Nov 2023 17:40:04 GMT, Raffaello Giulietti wrote: > Prevent a `NegativeArraySizeException` in `BigDecimal.toPlainString()`, throwing `OutOfMemoryError` instead to indicate that the resulting `String` would be too large. src/java.base/share/classes/java/math/BigDecimal.java line 3518: > 3516: for (int i = 0; i < trailingZeros; i++) { > 3517: buf.append('0'); > 3518: } A bit more compact as: Suggestion: StringBuilder buf = new StringBuilder(len); buf.append(str); buf.repeat('0', trailingZeros); src/java.base/share/classes/java/math/BigDecimal.java line 3551: > 3549: for (int i = insertionPoint; i < 0; ++i) { > 3550: buf.append('0'); > 3551: } Would this be the same as: `buf.repeat('0', -i);` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16457#discussion_r1385363742 PR Review Comment: https://git.openjdk.org/jdk/pull/16457#discussion_r1385372642 From mabbay at openjdk.org Tue Nov 7 18:56:07 2023 From: mabbay at openjdk.org (Mourad Abbay) Date: Tue, 7 Nov 2023 18:56:07 GMT Subject: RFR: 8294980: test/jdk/java/lang/invoke 15 test classes use experimental bytecode library [v5] In-Reply-To: <-JRa1cWErB4H5zW-TqhXXd1y3TchfIXPMinb-CJ4OUE=.96cb1861-cb27-4030-a8a0-f90df924f041@github.com> References: <-JRa1cWErB4H5zW-TqhXXd1y3TchfIXPMinb-CJ4OUE=.96cb1861-cb27-4030-a8a0-f90df924f041@github.com> Message-ID: > early experimental version of the bytecode library is bundled under: > test/jdk/lib/testlibrary/bytecode > > following tests reference it: > test/jdk/java/lang/invoke/common/test/java/lang/invoke/lib/InstructionHelper.java > test/jdk/java/lang/invoke/condy/CondyWithGarbageTest.java > test/jdk/java/lang/invoke/condy/CondyReturnPrimitiveTest.java > test/jdk/java/lang/invoke/condy/CondyWrongType.java > test/jdk/java/lang/invoke/condy/CondyNestedTest.java > test/jdk/java/lang/invoke/condy/CondyStaticArgumentsTest.java > test/jdk/java/lang/invoke/condy/BootstrapMethodJumboArgsTest.java > test/jdk/java/lang/invoke/condy/ConstantBootstrapsTest.java > test/jdk/java/lang/invoke/condy/CondyRepeatFailedResolution.java > test/jdk/java/lang/invoke/condy/CondyBSMInvocation.java > test/jdk/java/lang/invoke/condy/CondyTypeValidationTest.java > test/jdk/java/lang/invoke/condy/CondyBSMValidationTest.java > test/jdk/java/lang/invoke/condy/CondyNameValidationTest.java > test/jdk/java/lang/invoke/condy/CondyBSMException.java > test/jdk/java/lang/invoke/condy/CondyInterfaceWithOverpassMethods.java Mourad Abbay has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 21 additional commits since the last revision: - Merge branch 'master' into 8294980 - Use TypeKind.from . - Merge branch 'master' into 8294980 - specify packages to export in jtreg tests. - Remove reference to old bytecode library. - Remove early experimental version of the bytecode library. - Convert CondyInterfaceWithOverpassMethods . - Convert CondyBSMException . - Convert CondyNameValidationTest . - Convert CondyBSMValidationTest . - ... and 11 more: https://git.openjdk.org/jdk/compare/b2166d74...c95c1e2f ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16268/files - new: https://git.openjdk.org/jdk/pull/16268/files/878a8cc4..c95c1e2f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16268&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16268&range=03-04 Stats: 2090 lines in 41 files changed: 1426 ins; 419 del; 245 mod Patch: https://git.openjdk.org/jdk/pull/16268.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16268/head:pull/16268 PR: https://git.openjdk.org/jdk/pull/16268 From duke at openjdk.org Tue Nov 7 19:14:12 2023 From: duke at openjdk.org (ExE Boss) Date: Tue, 7 Nov 2023 19:14:12 GMT Subject: RFR: 8187655: jdk.lambda.vm.InterfaceAccessFlagsTest.testPrivateMethodCall needs update after nestmates support [v2] In-Reply-To: References: Message-ID: On Tue, 7 Nov 2023 18:34:42 GMT, Mandy Chung wrote: >> `jdk.lambda.vm.InterfaceAccessFlagsTest` uses `ClassToInterfaceConverter` to mechanically convert a classfile for a Class into an in-memory class representation of an equivalent Interface. `testPrivateMethodCall` tests to invoke a private method. Before nestmates, invoking a private class method and a private interface method both use `Invokespecial`. With the nestmate changes, the class uses `invokevirtual` but the interface must use `invokeinterface` but this conversion is not handled by the existing `ClassToInterfaceConverter`. >> >> This fix converts `ClassToInterfaceConverter` to use the Class-File API to properly convert a classfile from a class to an interface including method invocation from `invokevirtual` to `invokeinterface`. The old custom bytecode manipulation code can be dropped. > > Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: > > Simplify the transformation code and easier to read test/jdk/jdk/lambda/separate/ClassToInterfaceConverter.java line 53: > 51: > 52: return Classfile.of().transform(classModel, > 53: ClassTransform.dropping(ce -> ce instanceof MethodModel mm && mm.methodName().stringValue().equals("")) `Utf8Entry::equalsString(?)` might?be more?efficient: Suggestion: ClassTransform.dropping(ce -> ce instanceof MethodModel mm && mm.methodName().equalsString("")) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16526#discussion_r1385431990 From rgiulietti at openjdk.org Tue Nov 7 19:17:03 2023 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Tue, 7 Nov 2023 19:17:03 GMT Subject: RFR: 8318915: Enhance checks in BigDecimal.toPlainString() [v2] In-Reply-To: References: Message-ID: > Prevent a `NegativeArraySizeException` in `BigDecimal.toPlainString()`, throwing `OutOfMemoryError` instead to indicate that the resulting `String` would be too large. Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: Using repeat() instead of loop. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16457/files - new: https://git.openjdk.org/jdk/pull/16457/files/cea48148..8a3c0a96 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16457&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16457&range=00-01 Stats: 9 lines in 1 file changed: 0 ins; 5 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/16457.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16457/head:pull/16457 PR: https://git.openjdk.org/jdk/pull/16457 From rgiulietti at openjdk.org Tue Nov 7 19:17:06 2023 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Tue, 7 Nov 2023 19:17:06 GMT Subject: RFR: 8318915: Enhance checks in BigDecimal.toPlainString() [v2] In-Reply-To: References: Message-ID: On Tue, 7 Nov 2023 18:22:08 GMT, Roger Riggs wrote: >> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: >> >> Using repeat() instead of loop. > > src/java.base/share/classes/java/math/BigDecimal.java line 3518: > >> 3516: for (int i = 0; i < trailingZeros; i++) { >> 3517: buf.append('0'); >> 3518: } > > A bit more compact as: > Suggestion: > > StringBuilder buf = new StringBuilder(len); > buf.append(str); > buf.repeat('0', trailingZeros); More compact and potentially faster. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16457#discussion_r1385435137 From joehw at openjdk.org Tue Nov 7 19:24:44 2023 From: joehw at openjdk.org (Joe Wang) Date: Tue, 7 Nov 2023 19:24:44 GMT Subject: Integrated: 8305814: Update Xalan Java to 2.7.3 In-Reply-To: References: Message-ID: On Mon, 6 Nov 2023 22:52:47 GMT, Joe Wang wrote: > Xalan 2.7.3: merge minor changes from the upstream project. > > Test: existing XML tests pass This pull request has now been integrated. Changeset: b1625af6 Author: Joe Wang URL: https://git.openjdk.org/jdk/commit/b1625af600c253e872232dc62bf353db88c97079 Stats: 77 lines in 4 files changed: 10 ins; 36 del; 31 mod 8305814: Update Xalan Java to 2.7.3 Reviewed-by: iris, lancea, naoto ------------- PR: https://git.openjdk.org/jdk/pull/16532 From gbarany at openjdk.org Tue Nov 7 19:28:20 2023 From: gbarany at openjdk.org (=?UTF-8?B?R2VyZ8O2?= Barany) Date: Tue, 7 Nov 2023 19:28:20 GMT Subject: Integrated: 8315680: java/lang/ref/ReachabilityFenceTest.java should run with -Xbatch In-Reply-To: References: Message-ID: On Tue, 3 Oct 2023 07:47:30 GMT, Gerg? Barany wrote: > This test requires certain methods to be compiled, but without `-Xbatch` the compiler races against the test code, which can lead to intermittent failures. This pull request has now been integrated. Changeset: a290256b Author: Gerg? Barany Committer: Doug Simon URL: https://git.openjdk.org/jdk/commit/a290256bbf85a52fbeab24dab5fbe195cf58750f Stats: 6 lines in 1 file changed: 0 ins; 0 del; 6 mod 8315680: java/lang/ref/ReachabilityFenceTest.java should run with -Xbatch Reviewed-by: dnsimon, never, psandoz ------------- PR: https://git.openjdk.org/jdk/pull/16023 From darcy at openjdk.org Tue Nov 7 19:48:49 2023 From: darcy at openjdk.org (Joe Darcy) Date: Tue, 7 Nov 2023 19:48:49 GMT Subject: RFR: JDK-8315458 Implementation of Implicitly Declared Classes and Instance Main Method (Second Preview) [v3] In-Reply-To: References: Message-ID: On Thu, 2 Nov 2023 11:58:23 GMT, Jim Laskey wrote: >> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove .orig files > > Re .orig. Thank you Alan. @JimLaskey , please "/issue add JDK-8319133" to include the annotation processing related changes. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16461#issuecomment-1799787133 From rriggs at openjdk.org Tue Nov 7 19:53:46 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 7 Nov 2023 19:53:46 GMT Subject: RFR: 8318915: Enhance checks in BigDecimal.toPlainString() [v2] In-Reply-To: References: Message-ID: On Tue, 7 Nov 2023 19:17:03 GMT, Raffaello Giulietti wrote: >> Prevent a `NegativeArraySizeException` in `BigDecimal.toPlainString()`, throwing `OutOfMemoryError` instead to indicate that the resulting `String` would be too large. > > Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: > > Using repeat() instead of loop. Looks good. Thanks ------------- Marked as reviewed by rriggs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16457#pullrequestreview-1718594344 From jlu at openjdk.org Tue Nov 7 21:36:05 2023 From: jlu at openjdk.org (Justin Lu) Date: Tue, 7 Nov 2023 21:36:05 GMT Subject: Integrated: 8319378: Spec for j.util.Timer::purge and j.util.Timer::cancel could be improved In-Reply-To: References: Message-ID: On Fri, 3 Nov 2023 20:40:11 GMT, Justin Lu wrote: > Please review this PR which clarifies the definition of a _cancelled_ task in _j.util.Timer::purge_ and _j.util.Timer::cancel_. > > Timer::purge claims that its return value is the number of tasks in the queue that were cancelled. This can be misleading, as a user can call Timer::cancel, thinking the rest of the tasks in the queue will be canceled (which should be the return value of Timer::purge). > > In actuality, Timer::cancel _discards_ all of the tasks in the queue. For a task to have been _cancelled_, the task itself must have called TimerTask::cancel. > > This change emphasizes the difference between _discarding_ and _cancelling_ a task. > Additionally, this change also includes a drive-by update to use an _apiNote_ and _implNote_ tag in the class description. This pull request has now been integrated. Changeset: cc4b0d92 Author: Justin Lu URL: https://git.openjdk.org/jdk/commit/cc4b0d9217ed27a9555dc82f0a4247bf9b703f2b Stats: 21 lines in 1 file changed: 7 ins; 2 del; 12 mod 8319378: Spec for j.util.Timer::purge and j.util.Timer::cancel could be improved Reviewed-by: naoto, jpai, rriggs ------------- PR: https://git.openjdk.org/jdk/pull/16503 From msheppar at openjdk.org Wed Nov 8 00:10:56 2023 From: msheppar at openjdk.org (Mark Sheppard) Date: Wed, 8 Nov 2023 00:10:56 GMT Subject: RFR: JDK-8311961 Update Manual Test Groups for ATR JDK22 In-Reply-To: References: Message-ID: On Mon, 6 Nov 2023 22:25:46 GMT, Bill Huang wrote: > Updated jdk_core_manual test groups. Marked as reviewed by msheppar (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/16531#pullrequestreview-1719065392 From bpb at openjdk.org Wed Nov 8 00:28:05 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 8 Nov 2023 00:28:05 GMT Subject: RFR: 8318915: Enhance checks in BigDecimal.toPlainString() [v2] In-Reply-To: References: Message-ID: On Tue, 7 Nov 2023 19:17:03 GMT, Raffaello Giulietti wrote: >> Prevent a `NegativeArraySizeException` in `BigDecimal.toPlainString()`, throwing `OutOfMemoryError` instead to indicate that the resulting `String` would be too large. > > Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: > > Using repeat() instead of loop. +1 The test might be a good candidate for conversion to JUnit 5, but that does not need to be part of this request. src/java.base/share/classes/java/math/BigDecimal.java line 3510: > 3508: : intVal.toString(); > 3509: int len = str.length() + trailingZeros; > 3510: if (len < 0) { One could use `Math.addExact`, which has an intrinsic, and convert any thrown `ArithmeticException` into an OOME but I am not sure it's worth it. ------------- Marked as reviewed by bpb (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16457#pullrequestreview-1719081771 PR Comment: https://git.openjdk.org/jdk/pull/16457#issuecomment-1800720638 PR Review Comment: https://git.openjdk.org/jdk/pull/16457#discussion_r1385790342 From liach at openjdk.org Wed Nov 8 00:34:00 2023 From: liach at openjdk.org (Chen Liang) Date: Wed, 8 Nov 2023 00:34:00 GMT Subject: RFR: 8187655: jdk.lambda.vm.InterfaceAccessFlagsTest.testPrivateMethodCall needs update after nestmates support [v2] In-Reply-To: References: Message-ID: On Tue, 7 Nov 2023 18:34:42 GMT, Mandy Chung wrote: >> `jdk.lambda.vm.InterfaceAccessFlagsTest` uses `ClassToInterfaceConverter` to mechanically convert a classfile for a Class into an in-memory class representation of an equivalent Interface. `testPrivateMethodCall` tests to invoke a private method. Before nestmates, invoking a private class method and a private interface method both use `Invokespecial`. With the nestmate changes, the class uses `invokevirtual` but the interface must use `invokeinterface` but this conversion is not handled by the existing `ClassToInterfaceConverter`. >> >> This fix converts `ClassToInterfaceConverter` to use the Class-File API to properly convert a classfile from a class to an interface including method invocation from `invokevirtual` to `invokeinterface`. The old custom bytecode manipulation code can be dropped. > > Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: > > Simplify the transformation code and easier to read test/jdk/jdk/lambda/separate/ClassToInterfaceConverter.java line 43: > 41: // convert it to invokeinterface > 42: CodeTransform ct = (b, e) -> { > 43: if (e instanceof InvokeInstruction i && i.owner() == classModel.thisClass()) { Suggestion: if (e instanceof InvokeInstruction i && i.owner().equals(classModel.thisClass())) { `ClassDesc` has to be compared by equality. This piece of code works accidentally due to Classfile API caching descriptor in CP objects, but if the `ClassDesc` is from a `DynamicConstantDesc`, then it breaks. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16526#discussion_r1385794688 From liach at openjdk.org Wed Nov 8 00:34:02 2023 From: liach at openjdk.org (Chen Liang) Date: Wed, 8 Nov 2023 00:34:02 GMT Subject: RFR: 8187655: jdk.lambda.vm.InterfaceAccessFlagsTest.testPrivateMethodCall needs update after nestmates support [v2] In-Reply-To: References: Message-ID: On Tue, 7 Nov 2023 19:10:18 GMT, ExE Boss wrote: >> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: >> >> Simplify the transformation code and easier to read > > test/jdk/jdk/lambda/separate/ClassToInterfaceConverter.java line 53: > >> 51: >> 52: return Classfile.of().transform(classModel, >> 53: ClassTransform.dropping(ce -> ce instanceof MethodModel mm && mm.methodName().stringValue().equals("")) > > `Utf8Entry::equalsString(?)` might?be more?efficient: > Suggestion: > > ClassTransform.dropping(ce -> ce instanceof MethodModel mm && mm.methodName().equalsString("")) Also can use `ConstantDescs.INIT_NAME` to indicate class initializers ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16526#discussion_r1385795131 From duke at openjdk.org Wed Nov 8 00:52:36 2023 From: duke at openjdk.org (Shaojin Wen) Date: Wed, 8 Nov 2023 00:52:36 GMT Subject: RFR: 8317742: ISO Standard Date Format implementation consistency on DateTimeFormatter and String.format [v6] In-Reply-To: References: Message-ID: > j.u.Formatter now prints "%tF" (iso standard date) and the result is incorrect when processing year < 0 or year > 9999 Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: Use minus sign from cached DecimalFormatSymbols and improved testcase ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16033/files - new: https://git.openjdk.org/jdk/pull/16033/files/7051ad51..47fc35f1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16033&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16033&range=04-05 Stats: 16 lines in 2 files changed: 10 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/16033.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16033/head:pull/16033 PR: https://git.openjdk.org/jdk/pull/16033 From lmesnik at openjdk.org Wed Nov 8 02:08:26 2023 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Wed, 8 Nov 2023 02:08:26 GMT Subject: RFR: 8319200: Don't use test thread factory in ProcessTools.createLimitedTestJavaProcessBuilder() [v2] In-Reply-To: <3damdMQpRBrkUN2S32tBD0Tmrl2tmSqA31NniV8FzHU=.d3a36aa7-d5f4-4a63-b2ff-8b9b616a9637@github.com> References: <3damdMQpRBrkUN2S32tBD0Tmrl2tmSqA31NniV8FzHU=.d3a36aa7-d5f4-4a63-b2ff-8b9b616a9637@github.com> Message-ID: > Test thread factory is a mode similar to VM flags and should not be used in ProcessTools.createLimitedTestJavaProcessBuilder(). Only createTestJavaProcessBuilder() should use it like jtreg VM options. > > Adding the test thread factory requires the injection of arguments in the middle of the list. I don't think it makes sense to modify arguments in several places so I replaced it with the flag isLimited and moved all modifications in createJavaProcessBuilder(). > > Testing tier1-5. Leonid Mesnik has updated the pull request with a new target base 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 8319200 - param removed - Moved ttf from limited builder. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16442/files - new: https://git.openjdk.org/jdk/pull/16442/files/0dcf3673..db069ace Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16442&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16442&range=00-01 Stats: 31452 lines in 728 files changed: 16977 ins; 6081 del; 8394 mod Patch: https://git.openjdk.org/jdk/pull/16442.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16442/head:pull/16442 PR: https://git.openjdk.org/jdk/pull/16442 From mchung at openjdk.org Wed Nov 8 02:18:00 2023 From: mchung at openjdk.org (Mandy Chung) Date: Wed, 8 Nov 2023 02:18:00 GMT Subject: RFR: 8187655: jdk.lambda.vm.InterfaceAccessFlagsTest.testPrivateMethodCall needs update after nestmates support [v2] In-Reply-To: References: Message-ID: <0YHuaOgOHANz8BllHsuqSpLPyjZ13gz_dG-dWO5eLAo=.90a6074e-8a07-4ea9-8632-1a9534e950bd@github.com> On Wed, 8 Nov 2023 00:30:05 GMT, Chen Liang wrote: >> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: >> >> Simplify the transformation code and easier to read > > test/jdk/jdk/lambda/separate/ClassToInterfaceConverter.java line 43: > >> 41: // convert it to invokeinterface >> 42: CodeTransform ct = (b, e) -> { >> 43: if (e instanceof InvokeInstruction i && i.owner() == classModel.thisClass()) { > > Suggestion: > > if (e instanceof InvokeInstruction i && i.owner().equals(classModel.thisClass())) { > > `ClassDesc` has to be compared by equality. This piece of code works accidentally due to Classfile API caching descriptor in CP objects, but if the `ClassDesc` is from a `DynamicConstantDesc`, then it breaks. `owner()` returns `ClassEntry` not `ClassDesc`. This is to compare the owner is `this_class`, i.e. `MethodRef` references a method in this class. This breaks only if the compiled code has multiple `CONSTANT_Class_info` entries pointing to the same name of this class. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16526#discussion_r1385873267 From lmesnik at openjdk.org Wed Nov 8 02:33:29 2023 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Wed, 8 Nov 2023 02:33:29 GMT Subject: RFR: 8319200: Don't use test thread factory in ProcessTools.createLimitedTestJavaProcessBuilder() [v3] In-Reply-To: <3damdMQpRBrkUN2S32tBD0Tmrl2tmSqA31NniV8FzHU=.d3a36aa7-d5f4-4a63-b2ff-8b9b616a9637@github.com> References: <3damdMQpRBrkUN2S32tBD0Tmrl2tmSqA31NniV8FzHU=.d3a36aa7-d5f4-4a63-b2ff-8b9b616a9637@github.com> Message-ID: > Test thread factory is a mode similar to VM flags and should not be used in ProcessTools.createLimitedTestJavaProcessBuilder(). Only createTestJavaProcessBuilder() should use it like jtreg VM options. > > Adding the test thread factory requires the injection of arguments in the middle of the list. I don't think it makes sense to modify arguments in several places so I replaced it with the flag isLimited and moved all modifications in createJavaProcessBuilder(). > > Testing tier1-5. Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: converted list to array. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16442/files - new: https://git.openjdk.org/jdk/pull/16442/files/db069ace..4ba1e85e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16442&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16442&range=01-02 Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/16442.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16442/head:pull/16442 PR: https://git.openjdk.org/jdk/pull/16442 From liach at openjdk.org Wed Nov 8 02:58:57 2023 From: liach at openjdk.org (Chen Liang) Date: Wed, 8 Nov 2023 02:58:57 GMT Subject: RFR: 8187655: jdk.lambda.vm.InterfaceAccessFlagsTest.testPrivateMethodCall needs update after nestmates support [v2] In-Reply-To: References: Message-ID: On Tue, 7 Nov 2023 18:34:42 GMT, Mandy Chung wrote: >> `jdk.lambda.vm.InterfaceAccessFlagsTest` uses `ClassToInterfaceConverter` to mechanically convert a classfile for a Class into an in-memory class representation of an equivalent Interface. `testPrivateMethodCall` tests to invoke a private method. Before nestmates, invoking a private class method and a private interface method both use `Invokespecial`. With the nestmate changes, the class uses `invokevirtual` but the interface must use `invokeinterface` but this conversion is not handled by the existing `ClassToInterfaceConverter`. >> >> This fix converts `ClassToInterfaceConverter` to use the Class-File API to properly convert a classfile from a class to an interface including method invocation from `invokevirtual` to `invokeinterface`. The old custom bytecode manipulation code can be dropped. > > Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: > > Simplify the transformation code and easier to read Marked as reviewed by liach (Author). test/jdk/jdk/lambda/separate/ClassToInterfaceConverter.java line 51: > 49: } > 50: }; > 51: Suggestion: ------------- PR Review: https://git.openjdk.org/jdk/pull/16526#pullrequestreview-1719235277 PR Review Comment: https://git.openjdk.org/jdk/pull/16526#discussion_r1385900181 From dholmes at openjdk.org Wed Nov 8 05:15:57 2023 From: dholmes at openjdk.org (David Holmes) Date: Wed, 8 Nov 2023 05:15:57 GMT Subject: RFR: 8319374: JFR: Remove instrumentation for exception events [v3] In-Reply-To: References: Message-ID: On Tue, 7 Nov 2023 11:11:31 GMT, Erik Gahlin wrote: >> Could I have a review of a PR that removes the bytecode instrumentation for the exception events. >> >> Testing: jdk/jdk/jfr + tier1 + tier2 > > Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision: > > Rename field from tracing to jfrTracing src/java.base/share/classes/jdk/internal/event/ThrowableTracer.java line 62: > 60: if (ExceptionThrownEvent.enabled()) { > 61: long timestamp = ExceptionThrownEvent.timestamp(); > 62: ExceptionThrownEvent.commit(timestamp, message, clazz); Just a drive-by observation, but now you get the timestamp from the event it seems strange to pull it out and then pass it back to commit, instead of having a version of commit that automatically uses the internal timestamp. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16493#discussion_r1385990281 From lmesnik at openjdk.org Wed Nov 8 05:35:59 2023 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Wed, 8 Nov 2023 05:35:59 GMT Subject: RFR: 8319200: Don't use test thread factory in ProcessTools.createLimitedTestJavaProcessBuilder() [v3] In-Reply-To: References: <3damdMQpRBrkUN2S32tBD0Tmrl2tmSqA31NniV8FzHU=.d3a36aa7-d5f4-4a63-b2ff-8b9b616a9637@github.com> Message-ID: On Wed, 8 Nov 2023 02:33:29 GMT, Leonid Mesnik wrote: >> Test thread factory is a mode similar to VM flags and should not be used in ProcessTools.createLimitedTestJavaProcessBuilder(). Only createTestJavaProcessBuilder() should use it like jtreg VM options. >> >> Adding the test thread factory requires the injection of arguments in the middle of the list. I don't think it makes sense to modify arguments in several places so I replaced it with the flag isLimited and moved all modifications in createJavaProcessBuilder(). >> >> Testing tier1-5. > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > converted list to array. Moved the threadFactory injection to createTestJavaProcessBuilder. I think that it is more logical to don't set it for limited version of process builder. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16442#issuecomment-1801121241 From egahlin at openjdk.org Wed Nov 8 05:38:58 2023 From: egahlin at openjdk.org (Erik Gahlin) Date: Wed, 8 Nov 2023 05:38:58 GMT Subject: RFR: 8319374: JFR: Remove instrumentation for exception events [v3] In-Reply-To: References: Message-ID: On Wed, 8 Nov 2023 05:13:04 GMT, David Holmes wrote: >> Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision: >> >> Rename field from tracing to jfrTracing > > src/java.base/share/classes/jdk/internal/event/ThrowableTracer.java line 62: > >> 60: if (ExceptionThrownEvent.enabled()) { >> 61: long timestamp = ExceptionThrownEvent.timestamp(); >> 62: ExceptionThrownEvent.commit(timestamp, message, clazz); > > Just a drive-by observation, but now you get the timestamp from the event it seems strange to pull it out and then pass it back to commit, instead of having a version of commit that automatically uses the internal timestamp. I agree, and I have looked into it, but I think it's better to do that refactorization separately as it will impact other events. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16493#discussion_r1386016878 From pminborg at openjdk.org Wed Nov 8 06:15:06 2023 From: pminborg at openjdk.org (Per Minborg) Date: Wed, 8 Nov 2023 06:15:06 GMT Subject: Integrated: 8319556: Harmonize interface formatting in the FFM API In-Reply-To: References: Message-ID: On Mon, 6 Nov 2023 21:05:58 GMT, Per Minborg wrote: > This PR proposes to remove two `permits` declarations where the line overflows the stipulated maximum column with. Also, it proposes to harmonize the layout of `permit` formatting so they are the the same throughout the API. > > This PR might be perceived as over worked but I think it nice to get consistency across the API now that we go final. This pull request has now been integrated. Changeset: 73c5f60f Author: Per Minborg URL: https://git.openjdk.org/jdk/commit/73c5f60f4151447847f7c28709fa61589a6677bf Stats: 6 lines in 2 files changed: 2 ins; 0 del; 4 mod 8319556: Harmonize interface formatting in the FFM API Reviewed-by: mcimadamore ------------- PR: https://git.openjdk.org/jdk/pull/16528 From pminborg at openjdk.org Wed Nov 8 09:03:12 2023 From: pminborg at openjdk.org (Per Minborg) Date: Wed, 8 Nov 2023 09:03:12 GMT Subject: RFR: 8319324: FFM: Reformat javadocs [v10] In-Reply-To: <-CK9Ln5FZQ2oX4RZ04Ltx1mzgxdt8qDnaY_Wte_B6CQ=.588bdde5-55c2-476e-8024-8c6b34c72f82@github.com> References: <-CK9Ln5FZQ2oX4RZ04Ltx1mzgxdt8qDnaY_Wte_B6CQ=.588bdde5-55c2-476e-8024-8c6b34c72f82@github.com> Message-ID: > This PR proposes to reformat all the JavaDocs for the FFM API. This would bring the FFM API docs more in line with the existing Java documentation (see below). Occasional drive-by fixes are also included in this PR (such as spelling and capitalization). > > I am aware this PR will (if approved) make a significant mark in the change logs which is regrettable. > > Background: > > Older classes like `Object` and `List` have a maximum line length of 80 characters whereas newer classes like `ScopedValue` have a maximum line length of 90 characters. > > The FFM API currently has javadoc lines that exceed 135 characters per line. It is also customary to use double spaces when starting a new sentence. Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits: - Merge master - Update after additional reviews - Remove additional redundant full stops - Merge master and update Linker formatting - Harmonize the use of full stops in tags - Remove double spaces after full stops - Review classes not in the foreign package - Update after review - Merge master - Reformat javadocs - ... and 3 more: https://git.openjdk.org/jdk/compare/8555e0f6...b91beb2a ------------- Changes: https://git.openjdk.org/jdk/pull/16518/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16518&range=09 Stats: 3026 lines in 16 files changed: 852 ins; 17 del; 2157 mod Patch: https://git.openjdk.org/jdk/pull/16518.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16518/head:pull/16518 PR: https://git.openjdk.org/jdk/pull/16518 From duke at openjdk.org Wed Nov 8 09:42:25 2023 From: duke at openjdk.org (Ryan Wallace) Date: Wed, 8 Nov 2023 09:42:25 GMT Subject: RFR: 8318971: jar v17 should either exit on error immediately or create archive as jar v1.8 did [v2] In-Reply-To: References: Message-ID: <8OdwloG5cSRKPoHhdOloNgOngp0NIBhXroLW_BjAkAc=.17c74b0a-8b7f-453f-b138-7f764a1cf425@github.com> > Hi all, > > Please review this fix for jar tool not producing archive if there is a missing file supplied. Fix is to throw an exception and exit processing when a missing file is supplied. Current behaviour will recognise missing file as an error but continue processing and not produce the archive. Updated ClassPath test to verify jar is not created. > > Thanks, > Ryan. Ryan Wallace has updated the pull request with a new target base 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: - 8318971: jar v17 should either exit on error immediately or create archive as jar v1.8 did - Merge branch 'master' into 8318971 - 8318971: jar v17 should either exit on error immediately or create archive as jar v1.8 did - 8318971: jar v17 should either exit on error immediately or create archive as jar v1.8 did ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16423/files - new: https://git.openjdk.org/jdk/pull/16423/files/07553306..612f4c05 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16423&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16423&range=00-01 Stats: 30476 lines in 738 files changed: 15924 ins; 6266 del; 8286 mod Patch: https://git.openjdk.org/jdk/pull/16423.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16423/head:pull/16423 PR: https://git.openjdk.org/jdk/pull/16423 From duke at openjdk.org Wed Nov 8 09:42:26 2023 From: duke at openjdk.org (Ryan Wallace) Date: Wed, 8 Nov 2023 09:42:26 GMT Subject: RFR: 8318971: jar v17 should either exit on error immediately or create archive as jar v1.8 did In-Reply-To: References: Message-ID: On Mon, 30 Oct 2023 16:16:52 GMT, Ryan Wallace wrote: > Hi all, > > Please review this fix for jar tool not producing archive if there is a missing file supplied. Fix is to throw an exception and exit processing when a missing file is supplied. Current behaviour will recognise missing file as an error but continue processing and not produce the archive. Updated ClassPath test to verify jar is not created. > > Thanks, > Ryan. Thanks Jaikiran, I have amended the logic and now return false when we hit this scenario and it is working as you expected. It will stop processing when we find a missing file and not produce the jar while showing the existing error message. I agree this is better behaviour. I have updated the changes to reflect this. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16423#issuecomment-1801426138 From rgiulietti at openjdk.org Wed Nov 8 09:57:59 2023 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Wed, 8 Nov 2023 09:57:59 GMT Subject: RFR: 8318915: Enhance checks in BigDecimal.toPlainString() [v2] In-Reply-To: References: Message-ID: On Wed, 8 Nov 2023 00:23:22 GMT, Brian Burkhalter wrote: >> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: >> >> Using repeat() instead of loop. > > src/java.base/share/classes/java/math/BigDecimal.java line 3510: > >> 3508: : intVal.toString(); >> 3509: int len = str.length() + trailingZeros; >> 3510: if (len < 0) { > > One could use `Math.addExact`, which has an intrinsic, and convert any thrown `ArithmeticException` into an OOME but I am not sure it's worth it. Yes, I considered that but I'm not sure how the throwing and catching of `ArithmeticException` with `*Exact` intrinsics is optimized by C2, so I have a manual overflow check for the addition. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16457#discussion_r1386307618 From mcimadamore at openjdk.org Wed Nov 8 10:54:01 2023 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Wed, 8 Nov 2023 10:54:01 GMT Subject: RFR: 8319324: FFM: Reformat javadocs [v10] In-Reply-To: References: <-CK9Ln5FZQ2oX4RZ04Ltx1mzgxdt8qDnaY_Wte_B6CQ=.588bdde5-55c2-476e-8024-8c6b34c72f82@github.com> Message-ID: <-TcZjgvDVCpEqy8hhpUgSaHVxDP0iVKDYPefPtPm5bY=.91a232ce-df6c-4ee1-8736-7f6141cff717@github.com> On Wed, 8 Nov 2023 09:03:12 GMT, Per Minborg wrote: >> This PR proposes to reformat all the JavaDocs for the FFM API. This would bring the FFM API docs more in line with the existing Java documentation (see below). Occasional drive-by fixes are also included in this PR (such as spelling and capitalization). >> >> I am aware this PR will (if approved) make a significant mark in the change logs which is regrettable. >> >> Background: >> >> Older classes like `Object` and `List` have a maximum line length of 80 characters whereas newer classes like `ScopedValue` have a maximum line length of 90 characters. >> >> The FFM API currently has javadoc lines that exceed 135 characters per line. It is also customary to use double spaces when starting a new sentence. > > Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits: > > - Merge master > - Update after additional reviews > - Remove additional redundant full stops > - Merge master and update Linker formatting > - Harmonize the use of full stops in tags > - Remove double spaces after full stops > - Review classes not in the foreign package > - Update after review > - Merge master > - Reformat javadocs > - ... and 3 more: https://git.openjdk.org/jdk/compare/8555e0f6...b91beb2a Please create a specdiff between the old version and the version in this PR, so that we can take a look at the differences in the resulting javadoc, and make sure that nothing else got affected (by accident). ------------- PR Review: https://git.openjdk.org/jdk/pull/16518#pullrequestreview-1720038255 From jpai at openjdk.org Wed Nov 8 11:09:58 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 8 Nov 2023 11:09:58 GMT Subject: RFR: 8318971: jar v17 should either exit on error immediately or create archive as jar v1.8 did [v2] In-Reply-To: <8OdwloG5cSRKPoHhdOloNgOngp0NIBhXroLW_BjAkAc=.17c74b0a-8b7f-453f-b138-7f764a1cf425@github.com> References: <8OdwloG5cSRKPoHhdOloNgOngp0NIBhXroLW_BjAkAc=.17c74b0a-8b7f-453f-b138-7f764a1cf425@github.com> Message-ID: <2oB2_gy51_2MnQLce9Xq6yDoI7GGH3T23dqKkzDkMGs=.90db7454-7f70-4a8c-b264-8870ef827c70@github.com> On Wed, 8 Nov 2023 09:42:25 GMT, Ryan Wallace wrote: >> Hi all, >> >> Please review this fix for jar tool not producing archive if there is a missing file supplied. Fix is to throw an exception and exit processing when a missing file is supplied. Current behaviour will recognise missing file as an error but continue processing and not produce the archive. Updated ClassPath test to verify jar is not created. >> >> Thanks, >> Ryan. > > Ryan Wallace has updated the pull request with a new target base 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: > > - 8318971: jar v17 should either exit on error immediately or create archive as jar v1.8 did > - Merge branch 'master' into 8318971 > - 8318971: jar v17 should either exit on error immediately or create archive as jar v1.8 did > - 8318971: jar v17 should either exit on error immediately or create archive as jar v1.8 did Thank you Ryan for trying this change. There's one more place in run() where we call this expand() and that happens when we want to update the jar file. (Previously) line 340 is where this call to expand() happens. Can you add a similar check after that call there and see if things continue to work? ------------- PR Comment: https://git.openjdk.org/jdk/pull/16423#issuecomment-1801665250 From asotona at openjdk.org Wed Nov 8 11:59:05 2023 From: asotona at openjdk.org (Adam Sotona) Date: Wed, 8 Nov 2023 11:59:05 GMT Subject: RFR: 8294980: test/jdk/java/lang/invoke 15 test classes use experimental bytecode library [v5] In-Reply-To: References: <-JRa1cWErB4H5zW-TqhXXd1y3TchfIXPMinb-CJ4OUE=.96cb1861-cb27-4030-a8a0-f90df924f041@github.com> Message-ID: <92og-LJdqqDXdn8kw1hB58I3rZ3gaTuxo-JtUmN52uM=.1a232a71-1e11-405d-bbff-da3366e17d1b@github.com> On Tue, 7 Nov 2023 18:56:07 GMT, Mourad Abbay wrote: >> early experimental version of the bytecode library is bundled under: >> test/jdk/lib/testlibrary/bytecode >> >> following tests reference it: >> test/jdk/java/lang/invoke/common/test/java/lang/invoke/lib/InstructionHelper.java >> test/jdk/java/lang/invoke/condy/CondyWithGarbageTest.java >> test/jdk/java/lang/invoke/condy/CondyReturnPrimitiveTest.java >> test/jdk/java/lang/invoke/condy/CondyWrongType.java >> test/jdk/java/lang/invoke/condy/CondyNestedTest.java >> test/jdk/java/lang/invoke/condy/CondyStaticArgumentsTest.java >> test/jdk/java/lang/invoke/condy/BootstrapMethodJumboArgsTest.java >> test/jdk/java/lang/invoke/condy/ConstantBootstrapsTest.java >> test/jdk/java/lang/invoke/condy/CondyRepeatFailedResolution.java >> test/jdk/java/lang/invoke/condy/CondyBSMInvocation.java >> test/jdk/java/lang/invoke/condy/CondyTypeValidationTest.java >> test/jdk/java/lang/invoke/condy/CondyBSMValidationTest.java >> test/jdk/java/lang/invoke/condy/CondyNameValidationTest.java >> test/jdk/java/lang/invoke/condy/CondyBSMException.java >> test/jdk/java/lang/invoke/condy/CondyInterfaceWithOverpassMethods.java > > Mourad Abbay has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 21 additional commits since the last revision: > > - Merge branch 'master' into 8294980 > - Use TypeKind.from . > - Merge branch 'master' into 8294980 > - specify packages to export in jtreg tests. > - Remove reference to old bytecode library. > - Remove early experimental version of the bytecode library. > - Convert CondyInterfaceWithOverpassMethods . > - Convert CondyBSMException . > - Convert CondyNameValidationTest . > - Convert CondyBSMValidationTest . > - ... and 11 more: https://git.openjdk.org/jdk/compare/b16cc497...c95c1e2f test/jdk/java/lang/invoke/condy/CondyNameValidationTest.java line 65: > 63: "bsm", BSM_TYPE, > 64: S -> { > 65: }); Why is this lambda removed from the test? test/jdk/java/lang/invoke/condy/CondyNameValidationTest.java line 72: > 70: return Stream.of("", > 71: "", > 72: "") Isn't this reducing the test cases? test/jdk/java/lang/invoke/condy/CondyNameValidationTest.java line 82: > 80: "bsm", BSM_TYPE, > 81: S -> { > 82: }); The same as above - removed test case. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16268#discussion_r1386502043 PR Review Comment: https://git.openjdk.org/jdk/pull/16268#discussion_r1386503354 PR Review Comment: https://git.openjdk.org/jdk/pull/16268#discussion_r1386502908 From mabbay at openjdk.org Wed Nov 8 12:13:04 2023 From: mabbay at openjdk.org (Mourad Abbay) Date: Wed, 8 Nov 2023 12:13:04 GMT Subject: RFR: 8294980: test/jdk/java/lang/invoke 15 test classes use experimental bytecode library [v5] In-Reply-To: <92og-LJdqqDXdn8kw1hB58I3rZ3gaTuxo-JtUmN52uM=.1a232a71-1e11-405d-bbff-da3366e17d1b@github.com> References: <-JRa1cWErB4H5zW-TqhXXd1y3TchfIXPMinb-CJ4OUE=.96cb1861-cb27-4030-a8a0-f90df924f041@github.com> <92og-LJdqqDXdn8kw1hB58I3rZ3gaTuxo-JtUmN52uM=.1a232a71-1e11-405d-bbff-da3366e17d1b@github.com> Message-ID: On Wed, 8 Nov 2023 11:56:27 GMT, Adam Sotona wrote: >> Mourad Abbay has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 21 additional commits since the last revision: >> >> - Merge branch 'master' into 8294980 >> - Use TypeKind.from . >> - Merge branch 'master' into 8294980 >> - specify packages to export in jtreg tests. >> - Remove reference to old bytecode library. >> - Remove early experimental version of the bytecode library. >> - Convert CondyInterfaceWithOverpassMethods . >> - Convert CondyBSMException . >> - Convert CondyNameValidationTest . >> - Convert CondyBSMValidationTest . >> - ... and 11 more: https://git.openjdk.org/jdk/compare/7e3a66df...c95c1e2f > > test/jdk/java/lang/invoke/condy/CondyNameValidationTest.java line 72: > >> 70: return Stream.of("", >> 71: "", >> 72: "") > > Isn't this reducing the test cases? `` is not a valid name for dynamic constant. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16268#discussion_r1386518496 From mabbay at openjdk.org Wed Nov 8 12:18:02 2023 From: mabbay at openjdk.org (Mourad Abbay) Date: Wed, 8 Nov 2023 12:18:02 GMT Subject: RFR: 8294980: test/jdk/java/lang/invoke 15 test classes use experimental bytecode library [v5] In-Reply-To: References: <-JRa1cWErB4H5zW-TqhXXd1y3TchfIXPMinb-CJ4OUE=.96cb1861-cb27-4030-a8a0-f90df924f041@github.com> <92og-LJdqqDXdn8kw1hB58I3rZ3gaTuxo-JtUmN52uM=.1a232a71-1e11-405d-bbff-da3366e17d1b@github.com> Message-ID: On Wed, 8 Nov 2023 12:09:57 GMT, Mourad Abbay wrote: >> test/jdk/java/lang/invoke/condy/CondyNameValidationTest.java line 72: >> >>> 70: return Stream.of("", >>> 71: "", >>> 72: "") >> >> Isn't this reducing the test cases? > > `` is not a valid name for dynamic constant. You can see `java.lang.constant.ConstantUtils.validateMemberName` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16268#discussion_r1386523308 From asotona at openjdk.org Wed Nov 8 12:18:02 2023 From: asotona at openjdk.org (Adam Sotona) Date: Wed, 8 Nov 2023 12:18:02 GMT Subject: RFR: 8294980: test/jdk/java/lang/invoke 15 test classes use experimental bytecode library [v5] In-Reply-To: References: <-JRa1cWErB4H5zW-TqhXXd1y3TchfIXPMinb-CJ4OUE=.96cb1861-cb27-4030-a8a0-f90df924f041@github.com> <92og-LJdqqDXdn8kw1hB58I3rZ3gaTuxo-JtUmN52uM=.1a232a71-1e11-405d-bbff-da3366e17d1b@github.com> Message-ID: On Wed, 8 Nov 2023 12:14:09 GMT, Mourad Abbay wrote: >> `` is not a valid name for dynamic constant. > > You can see `java.lang.constant.ConstantUtils.validateMemberName` So how is it possible that `testValidNames` has been passing with the name? Conversion should not change the tested subjects. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16268#discussion_r1386524619 From mabbay at openjdk.org Wed Nov 8 12:32:03 2023 From: mabbay at openjdk.org (Mourad Abbay) Date: Wed, 8 Nov 2023 12:32:03 GMT Subject: RFR: 8294980: test/jdk/java/lang/invoke 15 test classes use experimental bytecode library [v5] In-Reply-To: References: <-JRa1cWErB4H5zW-TqhXXd1y3TchfIXPMinb-CJ4OUE=.96cb1861-cb27-4030-a8a0-f90df924f041@github.com> <92og-LJdqqDXdn8kw1hB58I3rZ3gaTuxo-JtUmN52uM=.1a232a71-1e11-405d-bbff-da3366e17d1b@github.com> Message-ID: On Wed, 8 Nov 2023 12:15:13 GMT, Adam Sotona wrote: >> You can see `java.lang.constant.ConstantUtils.validateMemberName` > > So how is it possible that `testValidNames` has been passing with the name? > Conversion should not change the tested subjects. I think the old experimental library wasn't validating constant name. In the new library, constant name is validated in the constructor of `DynamicConstantDesc` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16268#discussion_r1386537459 From mabbay at openjdk.org Wed Nov 8 12:32:03 2023 From: mabbay at openjdk.org (Mourad Abbay) Date: Wed, 8 Nov 2023 12:32:03 GMT Subject: RFR: 8294980: test/jdk/java/lang/invoke 15 test classes use experimental bytecode library [v5] In-Reply-To: References: <-JRa1cWErB4H5zW-TqhXXd1y3TchfIXPMinb-CJ4OUE=.96cb1861-cb27-4030-a8a0-f90df924f041@github.com> <92og-LJdqqDXdn8kw1hB58I3rZ3gaTuxo-JtUmN52uM=.1a232a71-1e11-405d-bbff-da3366e17d1b@github.com> Message-ID: On Wed, 8 Nov 2023 12:26:26 GMT, Mourad Abbay wrote: >> So how is it possible that `testValidNames` has been passing with the name? >> Conversion should not change the tested subjects. > > I think the old experimental library wasn't validating constant name. In the new library, constant name is validated in the constructor of `DynamicConstantDesc` Also, the test only generate bytecode, without execution. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16268#discussion_r1386540761 From asotona at openjdk.org Wed Nov 8 13:08:07 2023 From: asotona at openjdk.org (Adam Sotona) Date: Wed, 8 Nov 2023 13:08:07 GMT Subject: RFR: 8294980: test/jdk/java/lang/invoke 15 test classes use experimental bytecode library [v5] In-Reply-To: References: <-JRa1cWErB4H5zW-TqhXXd1y3TchfIXPMinb-CJ4OUE=.96cb1861-cb27-4030-a8a0-f90df924f041@github.com> Message-ID: On Tue, 7 Nov 2023 18:56:07 GMT, Mourad Abbay wrote: >> early experimental version of the bytecode library is bundled under: >> test/jdk/lib/testlibrary/bytecode >> >> following tests reference it: >> test/jdk/java/lang/invoke/common/test/java/lang/invoke/lib/InstructionHelper.java >> test/jdk/java/lang/invoke/condy/CondyWithGarbageTest.java >> test/jdk/java/lang/invoke/condy/CondyReturnPrimitiveTest.java >> test/jdk/java/lang/invoke/condy/CondyWrongType.java >> test/jdk/java/lang/invoke/condy/CondyNestedTest.java >> test/jdk/java/lang/invoke/condy/CondyStaticArgumentsTest.java >> test/jdk/java/lang/invoke/condy/BootstrapMethodJumboArgsTest.java >> test/jdk/java/lang/invoke/condy/ConstantBootstrapsTest.java >> test/jdk/java/lang/invoke/condy/CondyRepeatFailedResolution.java >> test/jdk/java/lang/invoke/condy/CondyBSMInvocation.java >> test/jdk/java/lang/invoke/condy/CondyTypeValidationTest.java >> test/jdk/java/lang/invoke/condy/CondyBSMValidationTest.java >> test/jdk/java/lang/invoke/condy/CondyNameValidationTest.java >> test/jdk/java/lang/invoke/condy/CondyBSMException.java >> test/jdk/java/lang/invoke/condy/CondyInterfaceWithOverpassMethods.java > > Mourad Abbay has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 21 additional commits since the last revision: > > - Merge branch 'master' into 8294980 > - Use TypeKind.from . > - Merge branch 'master' into 8294980 > - specify packages to export in jtreg tests. > - Remove reference to old bytecode library. > - Remove early experimental version of the bytecode library. > - Convert CondyInterfaceWithOverpassMethods . > - Convert CondyBSMException . > - Convert CondyNameValidationTest . > - Convert CondyBSMValidationTest . > - ... and 11 more: https://git.openjdk.org/jdk/compare/98c74731...c95c1e2f Looks good. ------------- Marked as reviewed by asotona (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16268#pullrequestreview-1720305963 From duke at openjdk.org Wed Nov 8 13:20:33 2023 From: duke at openjdk.org (Eirik Bjorsnos) Date: Wed, 8 Nov 2023 13:20:33 GMT Subject: RFR: 8303866: Allow ZipInputStream.readEnd to parse small Zip64 ZIP files [v4] In-Reply-To: References: Message-ID: > ZipInputStream.readEnd currently assumes a Zip64 data descriptor if the number of compressed or uncompressed bytes read from the inflater is larger than the Zip64 magic value. > > While the ZIP format mandates that the data descriptor `SHOULD be stored in ZIP64 format (as 8 byte values) when a file's size exceeds 0xFFFFFFFF`, it also states that `ZIP64 format MAY be used regardless of the size of a file`. For such small entries, the above assumption does not hold. > > This PR augments ZipInputStream.readEnd to also assume 8-byte sizes if the ZipEntry includes a Zip64 extra information field. This brings ZipInputStream into alignment with the APPNOTE format spec: > > > When extracting, if the zip64 extended information extra > field is present for the file the compressed and > uncompressed sizes will be 8 byte values. > > > While small Zip64 files with 8-byte data descriptors are not commonly found in the wild, it is possible to create one using the Info-ZIP command line `-fd` flag: > > `echo hello | zip -fd > hello.zip` > > The PR also adds a test verifying that such a small Zip64 file can be parsed by ZipInputStream. Eirik Bjorsnos has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 25 commits: - Convert test from testNG to JUnit - Fix the check that the size of an extra field block size must not grow past the total extra field length - Move isZip64ExtBlockSizeValid back into ZipInputStream, since it is different from the ZipFile implementation which reads the LOC - Merge branch 'master' into data-descriptor # Conflicts: # src/java.base/share/classes/java/util/zip/ZipFile.java - Remove excessive comment - Move isZip64ExtBlockSizeValid to ZipUtils, use it from ZipInputStream and ZipFile.Source - Merge branch 'master' into data-descriptor - Use block comments instead of javadoc comments to avoid doclint warnings - Merge branch 'master' into data-descriptor - Zip64 extra field of a LOC header has 1-3 long components - ... and 15 more: https://git.openjdk.org/jdk/compare/1e687b45...657f961e ------------- Changes: https://git.openjdk.org/jdk/pull/12524/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12524&range=03 Stats: 229 lines in 2 files changed: 228 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/12524.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/12524/head:pull/12524 PR: https://git.openjdk.org/jdk/pull/12524 From egahlin at openjdk.org Wed Nov 8 13:25:07 2023 From: egahlin at openjdk.org (Erik Gahlin) Date: Wed, 8 Nov 2023 13:25:07 GMT Subject: Integrated: 8319374: JFR: Remove instrumentation for exception events In-Reply-To: References: Message-ID: On Fri, 3 Nov 2023 12:19:07 GMT, Erik Gahlin wrote: > Could I have a review of a PR that removes the bytecode instrumentation for the exception events. > > Testing: jdk/jdk/jfr + tier1 + tier2 This pull request has now been integrated. Changeset: e8418972 Author: Erik Gahlin URL: https://git.openjdk.org/jdk/commit/e8418972474d41c6cc1985df5c650461ded34313 Stats: 560 lines in 19 files changed: 268 ins; 281 del; 11 mod 8319374: JFR: Remove instrumentation for exception events Reviewed-by: mgronlun, alanb ------------- PR: https://git.openjdk.org/jdk/pull/16493 From duke at openjdk.org Wed Nov 8 13:28:00 2023 From: duke at openjdk.org (Eirik Bjorsnos) Date: Wed, 8 Nov 2023 13:28:00 GMT Subject: RFR: 8303866: Allow ZipInputStream.readEnd to parse small Zip64 ZIP files [v3] In-Reply-To: <1Qtbbgfnl43in140E7muNTX_Ps8Sd5pWOBLC8lhBAkU=.271f17c7-6719-43d0-bd98-c77bd5d1110c@github.com> References: <1Qtbbgfnl43in140E7muNTX_Ps8Sd5pWOBLC8lhBAkU=.271f17c7-6719-43d0-bd98-c77bd5d1110c@github.com> Message-ID: On Sat, 28 Oct 2023 17:34:35 GMT, Eirik Bjorsnos wrote: > We need to hold off this PR until #15650 has been integrated as it impacts some of the changes proposed here Marking this PR ready for review, now that #15650 has been integrated. A summary of updates after #15650: - `ZipFile.isZip64ExtBlockSizeValid` cannot be reused from `ZipInputStream` because values from the CEN are not available in streaming mode. My understanding of ZIP64 fields in a LOC is that they should contain csize and/or size, since LOC Offset and Disk Start Number are CEN-only - Converted the test to junit - Fixed an incorrect check that a Zip64 block size does not exceed the size of the total extra field ------------- PR Comment: https://git.openjdk.org/jdk/pull/12524#issuecomment-1801887748 From mabbay at openjdk.org Wed Nov 8 13:30:13 2023 From: mabbay at openjdk.org (Mourad Abbay) Date: Wed, 8 Nov 2023 13:30:13 GMT Subject: Integrated: 8294980: test/jdk/java/lang/invoke 15 test classes use experimental bytecode library In-Reply-To: <-JRa1cWErB4H5zW-TqhXXd1y3TchfIXPMinb-CJ4OUE=.96cb1861-cb27-4030-a8a0-f90df924f041@github.com> References: <-JRa1cWErB4H5zW-TqhXXd1y3TchfIXPMinb-CJ4OUE=.96cb1861-cb27-4030-a8a0-f90df924f041@github.com> Message-ID: On Thu, 19 Oct 2023 14:37:06 GMT, Mourad Abbay wrote: > early experimental version of the bytecode library is bundled under: > test/jdk/lib/testlibrary/bytecode > > following tests reference it: > test/jdk/java/lang/invoke/common/test/java/lang/invoke/lib/InstructionHelper.java > test/jdk/java/lang/invoke/condy/CondyWithGarbageTest.java > test/jdk/java/lang/invoke/condy/CondyReturnPrimitiveTest.java > test/jdk/java/lang/invoke/condy/CondyWrongType.java > test/jdk/java/lang/invoke/condy/CondyNestedTest.java > test/jdk/java/lang/invoke/condy/CondyStaticArgumentsTest.java > test/jdk/java/lang/invoke/condy/BootstrapMethodJumboArgsTest.java > test/jdk/java/lang/invoke/condy/ConstantBootstrapsTest.java > test/jdk/java/lang/invoke/condy/CondyRepeatFailedResolution.java > test/jdk/java/lang/invoke/condy/CondyBSMInvocation.java > test/jdk/java/lang/invoke/condy/CondyTypeValidationTest.java > test/jdk/java/lang/invoke/condy/CondyBSMValidationTest.java > test/jdk/java/lang/invoke/condy/CondyNameValidationTest.java > test/jdk/java/lang/invoke/condy/CondyBSMException.java > test/jdk/java/lang/invoke/condy/CondyInterfaceWithOverpassMethods.java This pull request has now been integrated. Changeset: 7bc8e4c8 Author: Mourad Abbay Committer: Adam Sotona URL: https://git.openjdk.org/jdk/commit/7bc8e4c891b2703e82b022fea40c29a143cc1806 Stats: 7591 lines in 38 files changed: 427 ins; 6544 del; 620 mod 8294980: test/jdk/java/lang/invoke 15 test classes use experimental bytecode library Reviewed-by: asotona ------------- PR: https://git.openjdk.org/jdk/pull/16268 From duke at openjdk.org Wed Nov 8 13:36:05 2023 From: duke at openjdk.org (Eirik Bjorsnos) Date: Wed, 8 Nov 2023 13:36:05 GMT Subject: RFR: 8303866: Allow ZipInputStream.readEnd to parse small Zip64 ZIP files [v4] In-Reply-To: References: Message-ID: On Wed, 8 Nov 2023 13:20:33 GMT, Eirik Bjorsnos wrote: >> ZipInputStream.readEnd currently assumes a Zip64 data descriptor if the number of compressed or uncompressed bytes read from the inflater is larger than the Zip64 magic value. >> >> While the ZIP format mandates that the data descriptor `SHOULD be stored in ZIP64 format (as 8 byte values) when a file's size exceeds 0xFFFFFFFF`, it also states that `ZIP64 format MAY be used regardless of the size of a file`. For such small entries, the above assumption does not hold. >> >> This PR augments ZipInputStream.readEnd to also assume 8-byte sizes if the ZipEntry includes a Zip64 extra information field. This brings ZipInputStream into alignment with the APPNOTE format spec: >> >> >> When extracting, if the zip64 extended information extra >> field is present for the file the compressed and >> uncompressed sizes will be 8 byte values. >> >> >> While small Zip64 files with 8-byte data descriptors are not commonly found in the wild, it is possible to create one using the Info-ZIP command line `-fd` flag: >> >> `echo hello | zip -fd > hello.zip` >> >> The PR also adds a test verifying that such a small Zip64 file can be parsed by ZipInputStream. > > Eirik Bjorsnos has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 25 commits: > > - Convert test from testNG to JUnit > - Fix the check that the size of an extra field block size must not grow past the total extra field length > - Move isZip64ExtBlockSizeValid back into ZipInputStream, since it is different from the ZipFile implementation which reads the LOC > - Merge branch 'master' into data-descriptor > > # Conflicts: > # src/java.base/share/classes/java/util/zip/ZipFile.java > - Remove excessive comment > - Move isZip64ExtBlockSizeValid to ZipUtils, use it from ZipInputStream and ZipFile.Source > - Merge branch 'master' into data-descriptor > - Use block comments instead of javadoc comments to avoid doclint warnings > - Merge branch 'master' into data-descriptor > - Zip64 extra field of a LOC header has 1-3 long components > - ... and 15 more: https://git.openjdk.org/jdk/compare/1e687b45...657f961e Observation: Unfortunately, `readLOC` skips reading the LOC's `size`, `csize` and `crc` values when in streaming mode. The fields are also overwritten by `ZipEntry.setExtra0`. This means we cannot use the original values and compare them to ZIP64_MAGICVAL when determining whether a data descriptor uses 4 or 8 byte values. ------------- PR Comment: https://git.openjdk.org/jdk/pull/12524#issuecomment-1801900801 From duke at openjdk.org Wed Nov 8 13:40:21 2023 From: duke at openjdk.org (Konrad Windszus) Date: Wed, 8 Nov 2023 13:40:21 GMT Subject: RFR: 8308753: Class-File API transition to Preview [v24] In-Reply-To: References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com> Message-ID: On Fri, 3 Nov 2023 08:39: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 with a new target base due to a merge or a rebase. The pull request now contains 358 commits: > > - Merge branch 'master' into JDK-8308753-preview > > # Conflicts: > # test/jdk/tools/lib/tests/JImageValidator.java > - fixed jdk.jfr > - Merge branch 'master' into JDK-8308753-preview > > # Conflicts: > # src/java.base/share/classes/module-info.java > - applied javadoc fix suggestions > - fixed new benchmark > - Merge branch 'master' into JDK-8308753-preview > > # Conflicts: > # src/java.base/share/classes/jdk/internal/classfile/impl/AbstractPoolEntry.java > - removed trailing space > - Merge branch 'master' into JDK-8308753-preview > > # Conflicts: > # src/java.base/share/classes/module-info.java > - package info javadoc improvements > - removed obsolete exports from BuildMicrobenchmark.gmk > - ... and 348 more: https://git.openjdk.org/jdk/compare/ec79ab4b...5f4f47c4 I would appreciate a hint in the javadocs why `Classfile.of` requires a byte array and cannot deal with inputstreams (iiuc this is due to the lazy reading which requires adjusting the offset back and forth potentially) ------------- PR Comment: https://git.openjdk.org/jdk/pull/15706#issuecomment-1801897871 From dfuchs at openjdk.org Wed Nov 8 13:42:11 2023 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Wed, 8 Nov 2023 13:42:11 GMT Subject: RFR: 8319374: JFR: Remove instrumentation for exception events [v3] In-Reply-To: References: Message-ID: <9as_D0HLvxVsIssfobrgL071tvNTWR5voqCOwaP00AU=.3999d6ec-5d00-4c53-aa74-22853c9a0265@github.com> On Wed, 8 Nov 2023 05:34:47 GMT, Erik Gahlin wrote: >> src/java.base/share/classes/jdk/internal/event/ThrowableTracer.java line 62: >> >>> 60: if (ExceptionThrownEvent.enabled()) { >>> 61: long timestamp = ExceptionThrownEvent.timestamp(); >>> 62: ExceptionThrownEvent.commit(timestamp, message, clazz); >> >> Just a drive-by observation, but now you get the timestamp from the event it seems strange to pull it out and then pass it back to commit, instead of having a version of commit that automatically uses the internal timestamp. > > I agree, and I have looked into it, but I think it's better to do that refactorization separately as it will impact other events. Just for my own understanding: in this particular case the time stamp is meaningless because the duration is expected to be 0 (or close to it) since nothing happens between the time the timestamp is taken and the time the event is committed. Is that correct? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16493#discussion_r1386635624 From duke at openjdk.org Wed Nov 8 13:42:20 2023 From: duke at openjdk.org (Eirik Bjorsnos) Date: Wed, 8 Nov 2023 13:42:20 GMT Subject: RFR: 8303866: Allow ZipInputStream.readEnd to parse small Zip64 ZIP files [v5] In-Reply-To: References: Message-ID: > ZipInputStream.readEnd currently assumes a Zip64 data descriptor if the number of compressed or uncompressed bytes read from the inflater is larger than the Zip64 magic value. > > While the ZIP format mandates that the data descriptor `SHOULD be stored in ZIP64 format (as 8 byte values) when a file's size exceeds 0xFFFFFFFF`, it also states that `ZIP64 format MAY be used regardless of the size of a file`. For such small entries, the above assumption does not hold. > > This PR augments ZipInputStream.readEnd to also assume 8-byte sizes if the ZipEntry includes a Zip64 extra information field. This brings ZipInputStream into alignment with the APPNOTE format spec: > > > When extracting, if the zip64 extended information extra > field is present for the file the compressed and > uncompressed sizes will be 8 byte values. > > > While small Zip64 files with 8-byte data descriptors are not commonly found in the wild, it is possible to create one using the Info-ZIP command line `-fd` flag: > > `echo hello | zip -fd > hello.zip` > > The PR also adds a test verifying that such a small Zip64 file can be parsed by ZipInputStream. Eirik Bjorsnos has updated the pull request incrementally with two additional commits since the last revision: - Use the term "block size" when referring to the size of a Zip64 extra field data block - Update comment reflect that a Zip64 extended field in a LOC header has only two valid block sizes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12524/files - new: https://git.openjdk.org/jdk/pull/12524/files/657f961e..01e26a4f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12524&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12524&range=03-04 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/12524.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/12524/head:pull/12524 PR: https://git.openjdk.org/jdk/pull/12524 From duke at openjdk.org Wed Nov 8 13:45:14 2023 From: duke at openjdk.org (Eirik Bjorsnos) Date: Wed, 8 Nov 2023 13:45:14 GMT Subject: RFR: 8303866: Allow ZipInputStream.readEnd to parse small Zip64 ZIP files [v6] In-Reply-To: References: Message-ID: <10PRjaMYxDxbkI2V-ZjMBn5S5MnnCBMQyi_mxTXe7Zk=.a61de0c0-eb77-49a4-9280-8abf3493c410@github.com> > ZipInputStream.readEnd currently assumes a Zip64 data descriptor if the number of compressed or uncompressed bytes read from the inflater is larger than the Zip64 magic value. > > While the ZIP format mandates that the data descriptor `SHOULD be stored in ZIP64 format (as 8 byte values) when a file's size exceeds 0xFFFFFFFF`, it also states that `ZIP64 format MAY be used regardless of the size of a file`. For such small entries, the above assumption does not hold. > > This PR augments ZipInputStream.readEnd to also assume 8-byte sizes if the ZipEntry includes a Zip64 extra information field. This brings ZipInputStream into alignment with the APPNOTE format spec: > > > When extracting, if the zip64 extended information extra > field is present for the file the compressed and > uncompressed sizes will be 8 byte values. > > > While small Zip64 files with 8-byte data descriptors are not commonly found in the wild, it is possible to create one using the Info-ZIP command line `-fd` flag: > > `echo hello | zip -fd > hello.zip` > > The PR also adds a test verifying that such a small Zip64 file can be parsed by ZipInputStream. Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision: Add a @bug reference in the test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12524/files - new: https://git.openjdk.org/jdk/pull/12524/files/01e26a4f..7601b8dd Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12524&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12524&range=04-05 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/12524.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/12524/head:pull/12524 PR: https://git.openjdk.org/jdk/pull/12524 From duke at openjdk.org Wed Nov 8 13:51:03 2023 From: duke at openjdk.org (Eirik Bjorsnos) Date: Wed, 8 Nov 2023 13:51:03 GMT Subject: RFR: 8303920: Avoid calling out to python in DataDescriptorSignatureMissing test [v9] In-Reply-To: References: Message-ID: On Mon, 30 Oct 2023 17:48:48 GMT, Eirik Bjorsnos wrote: >> Please review this PR which brings the DataDescriptorSignatureMissing test back to life. >> >> This test currently calls out to Python to create a test vector ZIP with a Data Descriptor without the recommended but optional signature. The Python dependency has turned out to be very brittle, so the test is currently marked with `@ignore` >> >> The PR replaces Python callouts with directly creating the test vector ZIP in the test itself. We can then remove the `@ignore`tag and run this useful test automatically. > > Eirik Bjorsnos has updated the pull request incrementally with three additional commits since the last revision: > > - Describe the structure of Data Descriptors using an example > - Extend the comment of `makeZipWithSignaturelessDescriptor` with some background info on (signature-less) data descriptors, for the benefit of future maintainers. > - Convert test from testng to junit > > I can kick of a test run internally next week or perhaps Sunday > > > FWIW, the test ran fine on Github Actions, including on `linux-x86` (which is 32-bit, right?): Disregard this comment, since it confuses this PR with #12991 :-) ------------- PR Comment: https://git.openjdk.org/jdk/pull/12959#issuecomment-1801925790 From duke at openjdk.org Wed Nov 8 13:57:59 2023 From: duke at openjdk.org (Eirik Bjorsnos) Date: Wed, 8 Nov 2023 13:57:59 GMT Subject: RFR: 8304020: Speed up test/jdk/java/util/zip/ZipFile/TestTooManyEntries.java and clarify its purpose [v3] In-Reply-To: References: <8Imbn5098NjdJMPtI2UD7BNSP3oRM4q8vB5_Lq1pLhs=.4686073b-207c-4e3b-b6c0-6227037b11b6@github.com> <8-6wXmCKNsCXaOoTxmKsGycIEOcmrjMUyZWIBU9fBgg=.11832ae5-8e2f-489d-81df-291629cfc8c6@github.com> Message-ID: On Mon, 30 Oct 2023 14:29:41 GMT, Lance Andersen wrote: > > > I think the changes look good overall. Thank you for this. I am not sure that the `@requires` is needed at this point. > > > > > > Was the `@requires (sun.arch.data.model == "64")` added to satisfy the 8GB memory requirement? If so, I guess we can safely remove the requires tag, even though the test still creates a ~2GB sparse file? > > We would have to run across all of the mach5 platforms to verify. You could remove it for now and we go from here FWIW, this test ran successfully on `linux-x86` on Github Actions (which is 32 bit?): TEST: java/util/zip/ZipFile/CenSizeTooLarge.java build: 0.059 seconds compile: 0.059 seconds junit: 2.437 seconds TEST RESULT: Passed. Execution successful ------------- PR Comment: https://git.openjdk.org/jdk/pull/12991#issuecomment-1801937743 From liach at openjdk.org Wed Nov 8 14:10:15 2023 From: liach at openjdk.org (Chen Liang) Date: Wed, 8 Nov 2023 14:10:15 GMT Subject: RFR: 8308753: Class-File API transition to Preview [v24] In-Reply-To: References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com> Message-ID: On Wed, 8 Nov 2023 13:31:32 GMT, Konrad Windszus wrote: > I would appreciate a hint in the javadocs why `Classfile.of` requires a byte array and cannot deal with inputstreams (iiuc this is due to the lazy reading which requires adjusting the offset back and forth potentially) You can simply call `ClassFile.of().parse(inputStream.readAllBytes())` instead. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15706#issuecomment-1801960923 From asotona at openjdk.org Wed Nov 8 14:32:52 2023 From: asotona at openjdk.org (Adam Sotona) Date: Wed, 8 Nov 2023 14:32:52 GMT Subject: RFR: 8308753: Class-File API transition to Preview [v25] In-Reply-To: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com> References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com> Message-ID: > Classfile API is an internal library under package `jdk.internal.classfile`?in JDK 21. > This pull request turns the Classfile API into a preview feature and moves it into `java.lang.classfile`. > It repackages all uses across JDK and tests and adds lots of missing Javadoc. > > This PR goes in sync with?[JDK-8308754](https://bugs.openjdk.org/browse/JDK-8308754): Class-File API (Preview) (CSR) > and?[JDK-8280389](https://bugs.openjdk.org/browse/JDK-8280389): Class-File API (Preview) (JEP). > > Online javadoc is available at:? > https://cr.openjdk.org/~asotona/JDK-8308753-preview/api/java.base/java/lang/classfile/package-summary.html > > In addition to the primary transition to preview, this pull request also includes: > - All?Classfile*?classes ranamed to?ClassFile*?(based on JEP discussion). > - A new preview feature, `CLASSFILE_API`, has been added. > - Buildsystem tool required a little patch to support annotated modules. > - All JDK modules using the Classfile API are newly participating in the preview. > - All tests that use the Classfile API now have preview enabled. > - A few Javac tests not allowing preview have been partially reverted; their conversion can be re-applied when the Classfile API leaves preview mode. > > Despite the number of affected files, this pull request is relatively straight-forward. The preview version of the Classfile API is based on the internal version of the library from the JDK master branch, and there are no API features added. > > Please review this pull request to help the Classfile API turn into a preview. > > Any comments are welcome. > > Thanks, > Adam Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 360 commits: - fixed condy tests - Merge branch 'master' into JDK-8308753-preview - Merge branch 'master' into JDK-8308753-preview # Conflicts: # test/jdk/tools/lib/tests/JImageValidator.java - fixed jdk.jfr - Merge branch 'master' into JDK-8308753-preview # Conflicts: # src/java.base/share/classes/module-info.java - applied javadoc fix suggestions - fixed new benchmark - Merge branch 'master' into JDK-8308753-preview # Conflicts: # src/java.base/share/classes/jdk/internal/classfile/impl/AbstractPoolEntry.java - removed trailing space - Merge branch 'master' into JDK-8308753-preview # Conflicts: # src/java.base/share/classes/module-info.java - ... and 350 more: https://git.openjdk.org/jdk/compare/7bc8e4c8...29c8fad3 ------------- Changes: https://git.openjdk.org/jdk/pull/15706/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15706&range=24 Stats: 32301 lines in 783 files changed: 14623 ins; 14111 del; 3567 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 egahlin at openjdk.org Wed Nov 8 15:13:12 2023 From: egahlin at openjdk.org (Erik Gahlin) Date: Wed, 8 Nov 2023 15:13:12 GMT Subject: RFR: 8319374: JFR: Remove instrumentation for exception events [v3] In-Reply-To: <9as_D0HLvxVsIssfobrgL071tvNTWR5voqCOwaP00AU=.3999d6ec-5d00-4c53-aa74-22853c9a0265@github.com> References: <9as_D0HLvxVsIssfobrgL071tvNTWR5voqCOwaP00AU=.3999d6ec-5d00-4c53-aa74-22853c9a0265@github.com> Message-ID: On Wed, 8 Nov 2023 13:39:10 GMT, Daniel Fuchs wrote: >> I agree, and I have looked into it, but I think it's better to do that refactorization separately as it will impact other events. > > Just for my own understanding: in this particular case the time stamp is meaningless because the duration is expected to be 0 (or close to it) since nothing happens between the time the timestamp is taken and the time the event is committed. Is that correct? Yes, the event has no duration. Before https://bugs.openjdk.org/browse/JDK-8239508 we wrote timestamp and duration for all Java events. For exception events, we wrote duration = 0. Now we can differentiate between durational and instant events, which means bytecode can be generated to take the timestamp in the commit method. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16493#discussion_r1386777042 From redestad at openjdk.org Wed Nov 8 15:22:14 2023 From: redestad at openjdk.org (Claes Redestad) Date: Wed, 8 Nov 2023 15:22:14 GMT Subject: Integrated: 8319423: Improve Year.isLeap by checking divisibility by 16 In-Reply-To: References: Message-ID: On Fri, 3 Nov 2023 12:03:24 GMT, Claes Redestad wrote: > https://github.com/cassioneri/eaf suggest this code for leap year calculation: > > public static boolean isLeap(long year) { > int d = year % 100 != 0 ? 4 : 16; > return (year & (d - 1)) == 0; > } > > .. with a claim this would compile down to branchless, easily pipelined code. > > This doesn't currently happen with C2. In the meantime I think we can improve the current code in `Year.isLeap` and `IsoChronology.isLeapYear` by leveraging the fact that the `% 100` check is only needed if `(year & 15) != 0`: > > > public static boolean isLeap(long year) { > return (year & 15) == 0 ? (year & 3) == 0 : (year & 3) == 0 && year % 100 != 0; > } > > > Mac M1: > > Name Cnt Base Error Test Error Unit Change > LeapYearBench.isLeapYear 15 0,743 ? 0,009 0,994 ? 0,005 ops/us 1,34x (p = 0,000*) > LeapYearBench.isLeapYearChrono 15 0,748 ? 0,006 0,991 ? 0,003 ops/us 1,32x (p = 0,000*) > LeapYearBench.isLeapYearNS 15 0,558 ? 0,026 0,552 ? 0,033 ops/us 0,99x (p = 0,602 ) > * = significant > > > Linux x64: > > Name Cnt Base Error Test Error Unit Change > LeapYearBench.isLeapYear 15 0.534 ? 0.001 0.765 ? 0.004 ops/us 1.43x (p = 0.000*) > LeapYearBench.isLeapYearChrono 15 0.535 ? 0.000 0.753 ? 0.040 ops/us 1.41x (p = 0.000*) > LeapYearBench.isLeapYearNS 15 0.352 ? 0.000 0.351 ? 0.001 ops/us 1.00x (p = 0.000*) > * = significant > > > 30% higher throughput on M1, 40% on x64. `isLeapYearNS` runs a variant of the code from https://github.com/cassioneri/eaf ported to java - perhaps the JIT can be improved to do whatever clang/gcc does here and achieve an even better speed-up. > > Testing: so far only java/time/tck/java/time locally, will run a few tiers before filing an enhancement and opening the PR for review. This pull request has now been integrated. Changeset: 7d25f1c6 Author: Claes Redestad URL: https://git.openjdk.org/jdk/commit/7d25f1c6cb770e21cfad8096c1637a24e65fab8c Stats: 125 lines in 6 files changed: 118 ins; 0 del; 7 mod 8319423: Improve Year.isLeap by checking divisibility by 16 Reviewed-by: naoto, rriggs ------------- PR: https://git.openjdk.org/jdk/pull/16491 From liach at openjdk.org Wed Nov 8 15:26:21 2023 From: liach at openjdk.org (Chen Liang) Date: Wed, 8 Nov 2023 15:26:21 GMT Subject: RFR: 8308753: Class-File API transition to Preview [v25] In-Reply-To: References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com> Message-ID: <1O6wmxmmlST1cR3SkMDbz6AQPxQPQzR9LQ2lLX-Gfn4=.04c03978-f129-496e-831e-fdbfe8adf255@github.com> On Wed, 8 Nov 2023 14:32:52 GMT, Adam Sotona wrote: >> Classfile API is an internal library under package `jdk.internal.classfile`?in JDK 21. >> This pull request turns the Classfile API into a preview feature and moves it into `java.lang.classfile`. >> It repackages all uses across JDK and tests and adds lots of missing Javadoc. >> >> This PR goes in sync with?[JDK-8308754](https://bugs.openjdk.org/browse/JDK-8308754): Class-File API (Preview) (CSR) >> and?[JDK-8280389](https://bugs.openjdk.org/browse/JDK-8280389): Class-File API (Preview) (JEP). >> >> Online javadoc is available at:? >> https://cr.openjdk.org/~asotona/JDK-8308753-preview/api/java.base/java/lang/classfile/package-summary.html >> >> In addition to the primary transition to preview, this pull request also includes: >> - All?Classfile*?classes ranamed to?ClassFile*?(based on JEP discussion). >> - A new preview feature, `CLASSFILE_API`, has been added. >> - Buildsystem tool required a little patch to support annotated modules. >> - All JDK modules using the Classfile API are newly participating in the preview. >> - All tests that use the Classfile API now have preview enabled. >> - A few Javac tests not allowing preview have been partially reverted; their conversion can be re-applied when the Classfile API leaves preview mode. >> >> Despite the number of affected files, this pull request is relatively straight-forward. The preview version of the Classfile API is based on the internal version of the library from the JDK master branch, and there are no API features added. >> >> Please review this pull request to help the Classfile API turn into a preview. >> >> Any comments are welcome. >> >> Thanks, >> Adam > > Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 360 commits: > > - fixed condy tests > - Merge branch 'master' into JDK-8308753-preview > - Merge branch 'master' into JDK-8308753-preview > > # Conflicts: > # test/jdk/tools/lib/tests/JImageValidator.java > - fixed jdk.jfr > - Merge branch 'master' into JDK-8308753-preview > > # Conflicts: > # src/java.base/share/classes/module-info.java > - applied javadoc fix suggestions > - fixed new benchmark > - Merge branch 'master' into JDK-8308753-preview > > # Conflicts: > # src/java.base/share/classes/jdk/internal/classfile/impl/AbstractPoolEntry.java > - removed trailing space > - Merge branch 'master' into JDK-8308753-preview > > # Conflicts: > # src/java.base/share/classes/module-info.java > - ... and 350 more: https://git.openjdk.org/jdk/compare/7bc8e4c8...29c8fad3 test/jdk/jdk/classfile/SignaturesTest.java line 1: > 1: /* The new test in this file for classDesc bug needs a migration too. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15706#discussion_r1386795420 From vklang at openjdk.org Wed Nov 8 15:40:57 2023 From: vklang at openjdk.org (Viktor Klang) Date: Wed, 8 Nov 2023 15:40:57 GMT Subject: RFR: JDK-8319123 : Implementation of JEP-461: Stream Gatherers (Preview) Message-ID: This is a Draft PR for [JEP-461](https://openjdk.org/jeps/461) ------------- Commit messages: - Updating Javadoc for Gatherer and Gatherers based - Addressing feedback on Gatherers - Removing Gatherers.peek() and Gatherers.peekOrdered() - Updates after review comments - Removing trailing whitespace - Formatting and Javadoc improvements to JEP-461 - Additional improvements to Gatherer Javadoc - Minor adjustments to Javadoc for Gatherers - Updating Gatherers preview name and JEP number - Adding --enable-preview to Gatherer benchmarks - ... and 7 more: https://git.openjdk.org/jdk/compare/36de19d4...2206e04d Changes: https://git.openjdk.org/jdk/pull/16420/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16420&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8319123 Stats: 4803 lines in 24 files changed: 4796 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/16420.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16420/head:pull/16420 PR: https://git.openjdk.org/jdk/pull/16420 From duke at openjdk.org Wed Nov 8 15:41:21 2023 From: duke at openjdk.org (ExE Boss) Date: Wed, 8 Nov 2023 15:41:21 GMT Subject: RFR: JDK-8319123 : Implementation of JEP-461: Stream Gatherers (Preview) In-Reply-To: References: Message-ID: On Mon, 30 Oct 2023 15:38:35 GMT, Viktor Klang wrote: > This is a Draft PR for [JEP-461](https://openjdk.org/jeps/461) These?should probably?use `{@snippet?...}`: src/java.base/share/classes/java/util/stream/Gatherer.java line 82: > 80: * } > 81: * gatherer.finisher().accept(state, downstream); > 82: * } Suggestion: * {@snippet lang="java" : * Gatherer.Downstream downstream = ...; * A state = gatherer.initializer().get(); * for (T t : data) { * gatherer.integrator().integrate(state, t, downstream); * } * gatherer.finisher().accept(state, downstream); * } src/java.base/share/classes/java/util/stream/Gatherer.java line 103: > 101: * ); > 102: * } > 103: * } Suggestion: * {@snippet lang="java" : * public static Gatherer map(Function mapper) { * return Gatherer.of( * (unused, element, downstream) -> // integrator * downstream.push(mapper.apply(element)) * ); * } * } src/java.base/share/classes/java/util/stream/Gatherer.java line 116: > 114: * > 115: * Gatherer incrementThenToString = plusOne.andThen(intToString); > 116: * } Suggestion: * {@snippet lang="java" : * // using the implementation of `map` as seen above * Gatherer increment = map(i -> i + 1); * * Gatherer toString = map(i -> i.toString()); * * Gatherer incrementThenToString = plusOne.andThen(intToString); * } src/java.base/share/classes/java/util/stream/Gatherer.java line 138: > 136: * ); > 137: * } > 138: * } Suggestion: * {@snippet lang="java" : * public static Gatherer scan( * Supplier initial, * BiFunction scanner) { * * class State { * R current = initial.get(); * } * * return Gatherer.ofSequential( * State::new, * Gatherer.Integrator.ofGreedy((state, element, downstream) -> { * state.current = scanner.apply(state.current, element); * return downstream.push(state.current); * }) * ); * } * } src/java.base/share/classes/java/util/stream/Gatherer.java line 549: > 547: return greedy; > 548: } > 549: Since?[GH?16213] was?closed in?favour of?adding diamond?inference to?casts (e.g.:?`(Integrator<>) Foo::bar` or?`(Integrator.Greedy<>) Foo::bar`), these?should?probably be?removed as?well: Suggestion: [GH?16213]: https://github.com/openjdk/jdk/pull/16213 src/java.base/share/classes/java/util/stream/Stream.java line 1080: > 1078: * var stream1 = Stream.of(...).gather(gatherer1).gather(gatherer2); > 1079: * var stream2 = Stream.of(...).gather(gatherer1.andThen(gatherer2)); > 1080: * } Suggestion: * {@snippet lang="java" : * // @replace region substring="values" replacement="..." * var stream1 = Stream.of(values).gather(gatherer1).gather(gatherer2); * var stream2 = Stream.of(values).gather(gatherer1.andThen(gatherer2)); * // @end * } src/java.base/share/classes/java/util/stream/Stream.java line 1085: > 1083: *
    {@code
    > 1084:      * StreamSupport.stream(spliterator(), isParallel()).gather(gatherer)
    > 1085:      * }
    Suggestion: * {@snippet lang="java" : * StreamSupport.stream(spliterator(), isParallel()).gather(gatherer) * } ------------- PR Review: https://git.openjdk.org/jdk/pull/16420#pullrequestreview-1715691921 PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1383646341 PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1383647033 PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1383647410 PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1383647839 PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1380597659 PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1383652617 PR Review Comment: https://git.openjdk.org/jdk/pull/16420#discussion_r1383654255 From vklang at openjdk.org Wed Nov 8 15:41:22 2023 From: vklang at openjdk.org (Viktor Klang) Date: Wed, 8 Nov 2023 15:41:22 GMT Subject: RFR: JDK-8319123 : Implementation of JEP-461: Stream Gatherers (Preview) In-Reply-To: References: Message-ID: <3z8IYhG73DKYCv_643Jtb-nDyNRlaLPyvqoPTDeI6SM=.b336d2d0-29ea-4ee2-98e9-3d89f4f85a7d@github.com> On Sun, 5 Nov 2023 17:55:39 GMT, Tagir F. Valeev wrote: >> This is a Draft PR for [JEP-461](https://openjdk.org/jeps/461) > > Very solid work, thank you! See some minor comments inline. I actually have much more ideas of specific gatherers, but they could be discussed separately. > > One thing that bothers me is that Gatherer is similar to Collector, yet the APIs are totally different, so users may be confused. I like the Gatherer API much more and I see that evolving current Collector API might be hard, given tons of third-party implementations, so I don't see a good way to fix this. But probably we should provide Collector-to-Gatherer adapter (producing one-element stream)? And in general, it would be nice to use exactly-one-element-producing-gatherers as terminal operations, without explicit findFirst().get(). Thanks for the feedback @amaembo! I hope you find the updates reasonable :) > src/java.base/share/classes/java/util/stream/AbstractPipeline.java line 191: > >> 189: * existing pipeline. >> 190: * >> 191: * The previous stage must be unlinked and unconsumed. > > Note that linebreak in Javadoc is normally ignored. It's probably better to add an explicit `

    `. This way it will be rendered better in IDE documentation view. @amaembo That's true, but given that this is internal API which won't be a part of the JDK Javadoc I think it is safe to address this at a later point. ? > src/java.base/share/classes/java/util/stream/Gatherer.java line 99: > >> 97: * public static Gatherer map(Function mapper) { >> 98: * return Gatherer.of( >> 99: * (unused, element, downstream) -> // integrator > > As [JEP 456](https://openjdk.org/jeps/456) is already integrated, probably it's reasonable to use `(_, element, downstream) ->` here? I thought this over for a while, and given that most developers won't be used to that feature yet I think it is clearer for the first preview to keep `unused` here. > src/java.base/share/classes/java/util/stream/Gatherer.java line 119: > >> 117: * >> 118: * AS an example, in order to create a gatherer to implement a sequential >> 119: * Prefix Scan as a Gatherer, it could be done the following way: > > Do we need 'Prefix Scan' in title case? The reason for capitalizing it was that it is a specific term with specific meaning. Capitalizing it makes it stand out and let people do their own research if they want/need to learn more about Prefix Scans. > src/java.base/share/classes/java/util/stream/Gatherer.java line 308: > >> 306: */ >> 307: static Gatherer ofSequential( >> 308: Integrator integrator) { > > Probably PECS signature `? super T, ? extends R` could be useful here? I've thought about that, and since we don't use that for the other parameters (like `initializer`) I don't think it helps changing it here. And the reason this has little effect is that the code calling the factory typically controls the components/parameters/return type. > src/java.base/share/classes/java/util/stream/Gatherers.java line 389: > >> 387: * @throws IllegalArgumentException when windowSize is less than 1 >> 388: */ >> 389: public static

    Method 122
    Method 122