From acobbs at openjdk.org Thu Feb 1 00:03:01 2024 From: acobbs at openjdk.org (Archie Cobbs) Date: Thu, 1 Feb 2024 00:03:01 GMT Subject: RFR: JDK-8318761: MessageFormat pattern support for CompactNumberFormat, ListFormat, and DateTimeFormatter In-Reply-To: References: Message-ID: On Wed, 31 Jan 2024 22:24:14 GMT, Justin Lu wrote: > Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8319344) which adds MessageFormat pattern support for the following subformats: ListFormat, CompactNumberFormat, and DateTimeFormatter. This change is intended to provide pattern support for the more recently added JDK Format subclasses, as well as improving java.time formatting within i18n. The draft javadoc can be viewed here: https://cr.openjdk.org/~jlu/docs/api/java.base/java/text/MessageFormat.html. Please see the CSR for more in-depth behavioral changes, as well as limitations. > > The `FormatTypes`: dtf_date, dtf_time, dtf_datetime, pre-defined DateTimeFormatter(s), and list are added. > The `FormatStyles`: compact_short, compact_long, or, and unit are added. > > For example, previously, > > > Object[] args = {LocalDate.of(2023, 11, 16), LocalDate.of(2023, 11, 27)}; > MessageFormat.format("It was {0,date,full}, now it is {1,date,full}", args); > > > would throw `Exception java.lang.IllegalArgumentException: Cannot format given Object as a Date` > > Now, a user can call > > > MessageFormat.format("It was {0,dtf_date,full}, now it is {1,dtf_date,full}", args); > > > which returns "It was Thursday, November 16, 2023, now it is Friday, November 17, 2023" Slightly tangential question (since you're talking about adding new subformats)... Has it ever been considered to add `MessageFormat` itself as a subformat option? It's not as crazy an idea as it sounds :) Here's an example: MessageFormat f = new MessageFormat( "Result: {0,choice,0#no letters|1#one letter: {1,message,'{0}'}|2#two letters: {1,message,'{0} and {1}'}}"); f.format(new Object[] { 2, new Object[] { "A", "B" } }); // "Result: two letters: A and B" ------------- PR Comment: https://git.openjdk.org/jdk/pull/17663#issuecomment-1920211513 From psandoz at openjdk.org Thu Feb 1 00:31:04 2024 From: psandoz at openjdk.org (Paul Sandoz) Date: Thu, 1 Feb 2024 00:31:04 GMT Subject: RFR: 8318650: Optimized subword gather for x86 targets. [v11] In-Reply-To: References: Message-ID: On Wed, 31 Jan 2024 23:53:16 GMT, Sandhya Viswanathan wrote: >> src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 1613: >> >>> 1611: vpand(xtmp, idx_vec, xtmp, vlen_enc); >>> 1612: // Load double words from normalized indices. >>> 1613: evpgatherdd(dst, gmask, Address(base, xtmp, scale), vlen_enc); >> >> Another question, looks to me that we could read beyond the allocated memory for the array here. e.g. consider the following case: >> * It is a byte gather >> * The byte source array is of size 41, i.e. only indices 0-40 are valid >> * The gather index is 40 >> >> Then as part of evpgatherdd we would be reading bytes at 40-43 offset from source array. > > I guess the fact that the Java objects are 8 byte alignment padded and the alignment being done at lines 1609-1611 and 1616-1621 somehow takes care of this. Drive by comment, that can change with Project Lilliput. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16354#discussion_r1473650392 From darcy at openjdk.org Thu Feb 1 01:36:16 2024 From: darcy at openjdk.org (Joe Darcy) Date: Thu, 1 Feb 2024 01:36:16 GMT Subject: RFR: JDK-8322218: Better escaping of single and double quotes in annotation toString() results Message-ID: A double quote character doesn't need to be escaped when it is a char literal and single quote character doesn't need to be escaped when it is in a string. This change updates the toString() output of annotations to account for the different escaping requirements of strings and characters. Corresponding issue filed for javac's compile-time annotations: JDK-8325078. ------------- Commit messages: - JDK-8322218: Better quoting of single and double quotes in annotation toString() results Changes: https://git.openjdk.org/jdk/pull/17664/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17664&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8322218 Stats: 18 lines in 2 files changed: 6 ins; 0 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/17664.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17664/head:pull/17664 PR: https://git.openjdk.org/jdk/pull/17664 From ihse at openjdk.org Thu Feb 1 09:13:07 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Thu, 1 Feb 2024 09:13:07 GMT Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v4] In-Reply-To: References: Message-ID: On Wed, 31 Jan 2024 09:19:39 GMT, Matthias Baesken wrote: >> Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision: >> >> - Merge branch 'master' into jdk-FOB64 >> - Move #include out of debug_util.h >> - Restore AIX dirent64 et al defines >> - Rollback AIX changes since they are now tracked in JDK-8324834 >> - Remove superfluous setting of FOB64 >> - Replace all foo64() with foo() for large-file functions in the JDK >> - 8324539: Do not use LFS64 symbols in JDK libs > > After adding this additional patch I fully build fastdebug on AIX (hav to admit it does not look very nice). > > > diff --git a/src/java.desktop/share/native/libawt/java2d/pipe/BufferedRenderPipe.c b/src/java.desktop/share/native/libawt/java2d/pipe/BufferedRenderPipe.c > index 823475b0a23..ee0109b6806 100644 > --- a/src/java.desktop/share/native/libawt/java2d/pipe/BufferedRenderPipe.c > +++ b/src/java.desktop/share/native/libawt/java2d/pipe/BufferedRenderPipe.c > @@ -31,6 +31,10 @@ > #include "SpanIterator.h" > #include "Trace.h" > > +#if defined(_AIX) && defined(open) > +#undef open > +#endif > + > /* The "header" consists of a jint opcode and a jint span count value */ > #define INTS_PER_HEADER 2 > #define BYTES_PER_HEADER 8 @MBaesken So my fix in [25c691d](https://github.com/openjdk/jdk/pull/17538/commits/25c691df823eb9d9db1451637f28d59dd9508386) did not help? Maybe then it is some other system library that drags in `fcntl.h`; I assumed it was stdlib or stdio. That header file includes way too much that it does not need, so we can surely strip it of even more standard includes if that is what is required to fix this. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1920844523 From jbhateja at openjdk.org Thu Feb 1 11:54:02 2024 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Thu, 1 Feb 2024 11:54:02 GMT Subject: RFR: 8324858: [vectorapi] Bounds checking issues when accessing memory segments In-Reply-To: References: Message-ID: On Mon, 29 Jan 2024 19:45:41 GMT, Paul Sandoz wrote: > The implementation of method `VectorSpecies::fromMemorySegment`, in `AbstractSpecies::fromMemorySegment`, neglects to perform bounds checks on the offset argument when the method is compiled by C2 (bounds checks are performed when interpreted and by C1). > > This is an oversight and explicit bounds checks are required, as is already case for the other load and store memory access methods (including storing to memory memory segments). > > The workaround is to call the static method `{T}Vector::fromMemorySegment`. > > The fix is for the implementation(s) of `VectorSpecies::fromMemorySegment` to do the same and call `{T}Vector::fromMemorySegment`, following the same pattern for implementations of `VectorSpecies::fromArray`. > > The tests have been conservatively updated to call the species access method where possible in the knowledge that it calls the vector access method (the tests were intended to test out of bounds access when compiled by C2). > > Thinking ahead its tempting to remove the species access methods, simplifying functionality that is duplicated. Marked as reviewed by jbhateja (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/17621#pullrequestreview-1856297285 From pminborg at openjdk.org Thu Feb 1 11:56:08 2024 From: pminborg at openjdk.org (Per Minborg) Date: Thu, 1 Feb 2024 11:56:08 GMT Subject: Integrated: 8325001: Typo in the javadocs for the Arena::ofShared method In-Reply-To: References: Message-ID: <8JyF_JMKw2A3GdQpHrFrxcFtRxXXhQspdxn6Y4_kdy0=.aae248c5-ed8d-4267-85a7-d6a66a4ae3a0@github.com> On Wed, 31 Jan 2024 13:12:10 GMT, Per Minborg wrote: > This PR fixes a typo in the documentation for the `Arena::ofShared`. This pull request has now been integrated. Changeset: 6b84f9bb Author: Per Minborg URL: https://git.openjdk.org/jdk/commit/6b84f9bb3ee4362bf9daa4fb3905b168f9035336 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8325001: Typo in the javadocs for the Arena::ofShared method Reviewed-by: dfuchs ------------- PR: https://git.openjdk.org/jdk/pull/17653 From ihse at openjdk.org Thu Feb 1 12:02:12 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Thu, 1 Feb 2024 12:02:12 GMT Subject: RFR: 8325109: Sort method modifiers in canonical order Message-ID: This is a follow-up on [JDK-8324053](https://bugs.openjdk.org/browse/JDK-8324053). I have run the bin/blessed-modifier-order.sh on the entire code base, and manually checked the result. I have reverted all but these trivial and uncontroversial changes. Almost all of these are about moving `static` to its proper position; a few do not involve `static` but instead puts `final` or `abstract` in the correct place. I have deliberately stayed away from `default` in this PR, since they should probably get a more thorough treatment, see https://github.com/openjdk/jdk/pull/17468#pullrequestreview-1829238473. ------------- Commit messages: - 8325109: Sort method modifiers in canonical order Changes: https://git.openjdk.org/jdk/pull/17670/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17670&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8325109 Stats: 61 lines in 39 files changed: 0 ins; 0 del; 61 mod Patch: https://git.openjdk.org/jdk/pull/17670.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17670/head:pull/17670 PR: https://git.openjdk.org/jdk/pull/17670 From pminborg at openjdk.org Thu Feb 1 12:13:36 2024 From: pminborg at openjdk.org (Per Minborg) Date: Thu, 1 Feb 2024 12:13:36 GMT Subject: [jdk22] RFR: 8325001: Typo in the javadocs for the Arena::ofShared method Message-ID: 8325001: Typo in the javadocs for the Arena::ofShared method ------------- Commit messages: - Backport 6b84f9bb3ee4362bf9daa4fb3905b168f9035336 Changes: https://git.openjdk.org/jdk22/pull/100/files Webrev: https://webrevs.openjdk.org/?repo=jdk22&pr=100&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8325001 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk22/pull/100.diff Fetch: git fetch https://git.openjdk.org/jdk22.git pull/100/head:pull/100 PR: https://git.openjdk.org/jdk22/pull/100 From alanb at openjdk.org Thu Feb 1 12:16:06 2024 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 1 Feb 2024 12:16:06 GMT Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v4] In-Reply-To: References: Message-ID: On Tue, 30 Jan 2024 14:15:57 GMT, Magnus Ihse Bursie wrote: >> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK native libraries. > > Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision: > > - Merge branch 'master' into jdk-FOB64 > - Move #include out of debug_util.h > - Restore AIX dirent64 et al defines > - Rollback AIX changes since they are now tracked in JDK-8324834 > - Remove superfluous setting of FOB64 > - Replace all foo64() with foo() for large-file functions in the JDK > - 8324539: Do not use LFS64 symbols in JDK libs I skimmed through the changes and they look okay. Can you confirm that you've run tier1-4 at least? Some of the library code that is changed here is not tested in the lower tiers. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1921189429 From mcimadamore at openjdk.org Thu Feb 1 12:23:09 2024 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Thu, 1 Feb 2024 12:23:09 GMT Subject: RFR: 8325001: Typo in the javadocs for the Arena::ofShared method In-Reply-To: References: Message-ID: On Wed, 31 Jan 2024 13:12:10 GMT, Per Minborg wrote: > This PR fixes a typo in the documentation for the `Arena::ofShared`. Ugh - I typed these comments, but forgot to click on the big review button :-( src/java.base/share/classes/java/lang/foreign/Arena.java line 261: > 259: > 260: /** > 261: * {@return a new shared arena} Segments allocated with the shared arena can be Suggestion: * {@return a new shared arena} Segments allocated with a shared arena can be ------------- PR Review: https://git.openjdk.org/jdk/pull/17653#pullrequestreview-1853934875 PR Review Comment: https://git.openjdk.org/jdk/pull/17653#discussion_r1472941143 From mcimadamore at openjdk.org Thu Feb 1 12:23:09 2024 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Thu, 1 Feb 2024 12:23:09 GMT Subject: RFR: 8325001: Typo in the javadocs for the Arena::ofShared method In-Reply-To: References: Message-ID: On Wed, 31 Jan 2024 14:51:34 GMT, Maurizio Cimadamore wrote: >> This PR fixes a typo in the documentation for the `Arena::ofShared`. > > src/java.base/share/classes/java/lang/foreign/Arena.java line 261: > >> 259: >> 260: /** >> 261: * {@return a new shared arena} Segments allocated with the shared arena can be > > Suggestion: > > * {@return a new shared arena} Segments allocated with a shared arena can be There is a similar issue in the javadoc of `ofConfined`, which also uses `the` instead of `a`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17653#discussion_r1472943087 From mcimadamore at openjdk.org Thu Feb 1 12:23:09 2024 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Thu, 1 Feb 2024 12:23:09 GMT Subject: RFR: 8325001: Typo in the javadocs for the Arena::ofShared method In-Reply-To: References: Message-ID: On Wed, 31 Jan 2024 14:52:58 GMT, Maurizio Cimadamore wrote: >> src/java.base/share/classes/java/lang/foreign/Arena.java line 261: >> >>> 259: >>> 260: /** >>> 261: * {@return a new shared arena} Segments allocated with the shared arena can be >> >> Suggestion: >> >> * {@return a new shared arena} Segments allocated with a shared arena can be > > There is a similar issue in the javadoc of `ofConfined`, which also uses `the` instead of `a`. Also, I have noted that the javadoc of `ofAuto` uses a different style - instead of saying "segments allocated with an automatic arena", it says "segments allocated with the returned arena" (in more places). So perhaps we should make these more consistent? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17653#discussion_r1472944597 From mcimadamore at openjdk.org Thu Feb 1 12:25:09 2024 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Thu, 1 Feb 2024 12:25:09 GMT Subject: RFR: 8324858: [vectorapi] Bounds checking issues when accessing memory segments In-Reply-To: References: Message-ID: On Wed, 31 Jan 2024 00:34:40 GMT, Paul Sandoz wrote: >> test/jdk/jdk/incubator/vector/templates/X-LoadStoreTest.java.template line 271: >> >>> 269: @DontInline >>> 270: static $abstractvectortype$ fromArray($type$[] a, int i) { >>> 271: return ($abstractvectortype$) SPECIES.fromArray(a, i); >> >> These new tests focus on the species method - but should we also test the statics factories in the record class, just in case a regression is introduced and the two implementation start diverging again? > > My expectation is the risk is small, but of course non-zero. These tests can be expensive to run so i was trying balance the risk without increasing test execution times. > > I could strengthen the comment from: > > @ForceInline > @Override final > public ByteVector fromMemorySegment(MemorySegment ms, long offset, ByteOrder bo) { > // User entry point: Be careful with inputs. > return ByteVector > .fromMemorySegment(this, ms, offset, bo); > } > > > to: > > > @ForceInline > @Override final > public ByteVector fromMemorySegment(MemorySegment ms, long offset, ByteOrder bo) { > // User entry point > // Defer only to the equivalent method on the vector class, using the same inputs > return ByteVector > .fromMemorySegment(this, ms, offset, bo); > } Sounds good ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17621#discussion_r1474374111 From asotona at openjdk.org Thu Feb 1 13:09:12 2024 From: asotona at openjdk.org (Adam Sotona) Date: Thu, 1 Feb 2024 13:09:12 GMT Subject: RFR: 8323058: Revisit j.l.classfile.CodeBuilder API surface Message-ID: `java.lang.classfile.CodeBuilder` contains more than 230 API methods. Existing ClassFile API use cases proved the concept one big CodeBuilder is comfortable. However there are some redundancies, glitches in the naming conventions, some frequently used methods are hard to find and some methods have low practical use. This patch revisits the `CodeBuilder` API methods and introduces some changes. For more details, please, visit the [CSR ](https://bugs.openjdk.org/browse/JDK-8323067) Please review. Thank you, Adam ------------- Commit messages: - Merge branch 'master' into JDK-8323058-CodeBuilder - extended CodeBuilder::conversion functionality - removed CodeBuilder::newPrimitiveArray, newReferenceArray, newMultidimensionalArray and operator methods - fixed tests - fixed jdk/classfile tests - fixed benchmarks - fixed jdk.jfr and jdk.jlink - fixed java.base - 8323058: Revisit j.l.classfile.CodeBuilder API surface Changes: https://git.openjdk.org/jdk/pull/17282/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17282&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8323058 Stats: 876 lines in 43 files changed: 41 ins; 188 del; 647 mod Patch: https://git.openjdk.org/jdk/pull/17282.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17282/head:pull/17282 PR: https://git.openjdk.org/jdk/pull/17282 From dfuchs at openjdk.org Thu Feb 1 13:43:00 2024 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Thu, 1 Feb 2024 13:43:00 GMT Subject: RFR: 8325109: Sort method modifiers in canonical order In-Reply-To: References: Message-ID: <8VqjbOBjkNCr7PmXABZ1xmQqvF0jidmGyIMNUdKQDww=.8ffdc2ac-023f-4b79-ac5a-9ef541af68a7@github.com> On Thu, 1 Feb 2024 11:57:04 GMT, Magnus Ihse Bursie wrote: > This is a follow-up on [JDK-8324053](https://bugs.openjdk.org/browse/JDK-8324053). I have run the bin/blessed-modifier-order.sh on the entire code base, and manually checked the result. I have reverted all but these trivial and uncontroversial changes. > > Almost all of these are about moving `static` to its proper position; a few do not involve `static` but instead puts `final` or `abstract` in the correct place. > > I have deliberately stayed away from `default` in this PR, since they should probably get a more thorough treatment, see https://github.com/openjdk/jdk/pull/17468#pullrequestreview-1829238473. Changes to IPAdressUtil look fine. I eyeballed the rest and didn't spot any issue. ------------- PR Review: https://git.openjdk.org/jdk/pull/17670#pullrequestreview-1856519410 From mbaesken at openjdk.org Thu Feb 1 13:50:15 2024 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 1 Feb 2024 13:50:15 GMT Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v4] In-Reply-To: References: Message-ID: On Wed, 31 Jan 2024 09:19:39 GMT, Matthias Baesken wrote: >> Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision: >> >> - Merge branch 'master' into jdk-FOB64 >> - Move #include out of debug_util.h >> - Restore AIX dirent64 et al defines >> - Rollback AIX changes since they are now tracked in JDK-8324834 >> - Remove superfluous setting of FOB64 >> - Replace all foo64() with foo() for large-file functions in the JDK >> - 8324539: Do not use LFS64 symbols in JDK libs > > After adding this additional patch I fully build fastdebug on AIX (hav to admit it does not look very nice). > > > diff --git a/src/java.desktop/share/native/libawt/java2d/pipe/BufferedRenderPipe.c b/src/java.desktop/share/native/libawt/java2d/pipe/BufferedRenderPipe.c > index 823475b0a23..ee0109b6806 100644 > --- a/src/java.desktop/share/native/libawt/java2d/pipe/BufferedRenderPipe.c > +++ b/src/java.desktop/share/native/libawt/java2d/pipe/BufferedRenderPipe.c > @@ -31,6 +31,10 @@ > #include "SpanIterator.h" > #include "Trace.h" > > +#if defined(_AIX) && defined(open) > +#undef open > +#endif > + > /* The "header" consists of a jint opcode and a jint span count value */ > #define INTS_PER_HEADER 2 > #define BYTES_PER_HEADER 8 > @MBaesken So my fix in [25c691d](https://github.com/openjdk/jdk/pull/17538/commits/25c691df823eb9d9db1451637f28d59dd9508386) did not help? Maybe then it is some other system library that drags in `fcntl.h`; I assumed it was stdlib or stdio. That header file includes way too much that it does not need, so we can surely strip it of even more standard includes if that is what is required to fix this. Unfortunately it did not help. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1921367368 From duke at openjdk.org Thu Feb 1 13:53:34 2024 From: duke at openjdk.org (ExE Boss) Date: Thu, 1 Feb 2024 13:53:34 GMT Subject: RFR: 8303374: Implement JEP 455: Primitive Types in Patterns, instanceof, and switch (Preview) [v57] In-Reply-To: References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com> Message-ID: On Wed, 31 Jan 2024 10:03:23 GMT, Aggelos Biboudis wrote: >> This is the proposed patch for Primitive types in patterns, instanceof, and switch (Preview). >> >> Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/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 78 commits: > > - Merge branch 'master' into primitive-patterns > - Update summary in ExactnessConversionsSupportTest > - Address review by Jan > - Remove redundant null check and introduce a const boolean for unconditionally exact pairs > - Small fix in Javadoc > - Tidy up Javadoc of Lower.visitTypeTest > - Tidy up Javadoc of IllegalArgumentException in typeSwitch > - Improve readability in SwitchBootstraps > - Update year > - Cleanup redundant clone > - ... and 68 more: https://git.openjdk.org/jdk/compare/ec56c72b...f68748b1 src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 721: > 719: typePairToName.put(new TypePairs(double.class, long.class), "isDoubleToLongExact"); > 720: typePairToName.put(new TypePairs(double.class, float.class), "isDoubleToFloatExact"); > 721: return typePairToName; This?should?return an?immutable?map, so that `TypePairs`?lookups can?be?treated as?constant: Suggestion: return Map.copyOf(typePairToName); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1474502668 From ihse at openjdk.org Thu Feb 1 14:21:37 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Thu, 1 Feb 2024 14:21:37 GMT Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v5] In-Reply-To: References: Message-ID: > Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK native libraries. Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: Remove all system includes from debug_util.h ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17538/files - new: https://git.openjdk.org/jdk/pull/17538/files/d6c64bc4..6e9ec631 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17538&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17538&range=03-04 Stats: 10 lines in 4 files changed: 6 ins; 4 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/17538.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17538/head:pull/17538 PR: https://git.openjdk.org/jdk/pull/17538 From ihse at openjdk.org Thu Feb 1 14:27:15 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Thu, 1 Feb 2024 14:27:15 GMT Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v6] In-Reply-To: References: Message-ID: <_ZwLqLPG2IQY-9lP4XO3KlStPatpZGye-Blofj9qfQQ=.dbffd3e3-1f37-4403-92de-63740436cde2@github.com> > Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK native libraries. Magnus Ihse Bursie 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 jdk-FOB64 - Remove all system includes from debug_util.h - Merge branch 'master' into jdk-FOB64 - Move #include out of debug_util.h - Restore AIX dirent64 et al defines - Rollback AIX changes since they are now tracked in JDK-8324834 - Remove superfluous setting of FOB64 - Replace all foo64() with foo() for large-file functions in the JDK - 8324539: Do not use LFS64 symbols in JDK libs ------------- Changes: https://git.openjdk.org/jdk/pull/17538/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17538&range=05 Stats: 233 lines in 23 files changed: 14 ins; 105 del; 114 mod Patch: https://git.openjdk.org/jdk/pull/17538.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17538/head:pull/17538 PR: https://git.openjdk.org/jdk/pull/17538 From ihse at openjdk.org Thu Feb 1 14:27:15 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Thu, 1 Feb 2024 14:27:15 GMT Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v4] In-Reply-To: References: Message-ID: <3c6OBIr0CfTFj2PGPn3n3rzLkNxiNavNj-sOx5dWqTw=.64b85b44-36f1-44de-b187-93c6c94ebc9d@github.com> On Thu, 1 Feb 2024 13:47:45 GMT, Matthias Baesken wrote: >> After adding this additional patch I fully build fastdebug on AIX (hav to admit it does not look very nice). >> >> >> diff --git a/src/java.desktop/share/native/libawt/java2d/pipe/BufferedRenderPipe.c b/src/java.desktop/share/native/libawt/java2d/pipe/BufferedRenderPipe.c >> index 823475b0a23..ee0109b6806 100644 >> --- a/src/java.desktop/share/native/libawt/java2d/pipe/BufferedRenderPipe.c >> +++ b/src/java.desktop/share/native/libawt/java2d/pipe/BufferedRenderPipe.c >> @@ -31,6 +31,10 @@ >> #include "SpanIterator.h" >> #include "Trace.h" >> >> +#if defined(_AIX) && defined(open) >> +#undef open >> +#endif >> + >> /* The "header" consists of a jint opcode and a jint span count value */ >> #define INTS_PER_HEADER 2 >> #define BYTES_PER_HEADER 8 > >> @MBaesken So my fix in [25c691d](https://github.com/openjdk/jdk/pull/17538/commits/25c691df823eb9d9db1451637f28d59dd9508386) did not help? Maybe then it is some other system library that drags in `fcntl.h`; I assumed it was stdlib or stdio. That header file includes way too much that it does not need, so we can surely strip it of even more standard includes if that is what is required to fix this. > > > Unfortunately it did not help. @MBaesken How annoying. :( I have now tried to remove *all* system includes from `debug_util.h`. Can you please try again building debug on AIX, to see if it works without the `#undef` in `BufferedRenderPipe.c`? ------------- PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1921455438 From pminborg at openjdk.org Thu Feb 1 14:28:03 2024 From: pminborg at openjdk.org (Per Minborg) Date: Thu, 1 Feb 2024 14:28:03 GMT Subject: RFR: 8323746: Add PathElement hashCode and equals In-Reply-To: <2zRwcXQMMxxvY08iS2mnnf3zXZFYeiF5L-C4iZWvZeI=.5c54d231-bd7c-41c8-ad94-d45b15cfb2d2@github.com> References: <2zRwcXQMMxxvY08iS2mnnf3zXZFYeiF5L-C4iZWvZeI=.5c54d231-bd7c-41c8-ad94-d45b15cfb2d2@github.com> Message-ID: On Wed, 31 Jan 2024 18:21:09 GMT, Maurizio Cimadamore wrote: >> This PR proposes to implement `hashCode()` and `equals()` methods for implementations of `PathElement`. >> >> In doing so, the previous `PathElementImpl` was removed and replaced in favor of distinct `record` implementations, each reflecting its own path element selection type. This also allowed the `PathKind` to be removed as this piece of information is now carried in the sealed type hierarchy. >> >> It is worth noting, the implementations resides in the `jdk.internal` package and consequently, they are not exposed to clients. So, we could use pattern matching (for example) internally but not in client code. > > src/java.base/share/classes/jdk/internal/foreign/LayoutPath.java line 454: > >> 452: } >> 453: >> 454: public static final class SequenceElement > > Why are these not empty records? I had that in the beginning but converted them to regular classes as they do not have any record components. But maybe it is better to make them all records for consistency? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17651#discussion_r1474565655 From qamai at openjdk.org Thu Feb 1 14:41:04 2024 From: qamai at openjdk.org (Quan Anh Mai) Date: Thu, 1 Feb 2024 14:41:04 GMT Subject: RFR: 8318650: Optimized subword gather for x86 targets. [v11] In-Reply-To: References: Message-ID: <6FBkOeh7PqeQeaFE1IucK504SqleVHwmXD2Hq5JEajo=.aa83b71a-826a-4b6e-b73d-5e96948fcd1e@github.com> On Thu, 1 Feb 2024 00:28:26 GMT, Paul Sandoz wrote: >> I guess the fact that the Java objects are 8 byte alignment padded and the alignment being done at lines 1609-1611 and 1616-1621 somehow takes care of this. > > Drive by comment, that can change with Project Lilliput. I don't think Lilliput will relax the array alignment to below 4 bytes since the array length needs to be aligned at that. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16354#discussion_r1474586479 From aivanov at openjdk.org Thu Feb 1 14:44:02 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 1 Feb 2024 14:44:02 GMT Subject: RFR: 8325109: Sort method modifiers in canonical order In-Reply-To: References: Message-ID: On Thu, 1 Feb 2024 11:57:04 GMT, Magnus Ihse Bursie wrote: > This is a follow-up on [JDK-8324053](https://bugs.openjdk.org/browse/JDK-8324053). I have run the bin/blessed-modifier-order.sh on the entire code base, and manually checked the result. I have reverted all but these trivial and uncontroversial changes. > > Almost all of these are about moving `static` to its proper position; a few do not involve `static` but instead puts `final` or `abstract` in the correct place. > > I have deliberately stayed away from `default` in this PR, since they should probably get a more thorough treatment, see https://github.com/openjdk/jdk/pull/17468#pullrequestreview-1829238473. Looks good to me. I looked through all the changes. ------------- Marked as reviewed by aivanov (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17670#pullrequestreview-1856683827 From mcimadamore at openjdk.org Thu Feb 1 15:04:02 2024 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Thu, 1 Feb 2024 15:04:02 GMT Subject: RFR: 8323746: Add PathElement hashCode and equals In-Reply-To: References: <2zRwcXQMMxxvY08iS2mnnf3zXZFYeiF5L-C4iZWvZeI=.5c54d231-bd7c-41c8-ad94-d45b15cfb2d2@github.com> Message-ID: On Thu, 1 Feb 2024 14:25:24 GMT, Per Minborg wrote: >> src/java.base/share/classes/jdk/internal/foreign/LayoutPath.java line 454: >> >>> 452: } >>> 453: >>> 454: public static final class SequenceElement >> >> Why are these not empty records? > > I had that in the beginning but converted them to regular classes as they do not have any record components. But maybe it is better to make them all records for consistency? I think so, even less code :-) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17651#discussion_r1474622217 From mbaesken at openjdk.org Thu Feb 1 15:57:06 2024 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 1 Feb 2024 15:57:06 GMT Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v4] In-Reply-To: References: Message-ID: <7M86DsSoWaLOQmf_cK6mXD4hTI8NZ356Z7ZRugqETzM=.bb90569d-0386-4498-9f21-d4c7e66f864f@github.com> On Thu, 1 Feb 2024 13:47:45 GMT, Matthias Baesken wrote: >> After adding this additional patch I fully build fastdebug on AIX (hav to admit it does not look very nice). >> >> >> diff --git a/src/java.desktop/share/native/libawt/java2d/pipe/BufferedRenderPipe.c b/src/java.desktop/share/native/libawt/java2d/pipe/BufferedRenderPipe.c >> index 823475b0a23..ee0109b6806 100644 >> --- a/src/java.desktop/share/native/libawt/java2d/pipe/BufferedRenderPipe.c >> +++ b/src/java.desktop/share/native/libawt/java2d/pipe/BufferedRenderPipe.c >> @@ -31,6 +31,10 @@ >> #include "SpanIterator.h" >> #include "Trace.h" >> >> +#if defined(_AIX) && defined(open) >> +#undef open >> +#endif >> + >> /* The "header" consists of a jint opcode and a jint span count value */ >> #define INTS_PER_HEADER 2 >> #define BYTES_PER_HEADER 8 > >> @MBaesken So my fix in [25c691d](https://github.com/openjdk/jdk/pull/17538/commits/25c691df823eb9d9db1451637f28d59dd9508386) did not help? Maybe then it is some other system library that drags in `fcntl.h`; I assumed it was stdlib or stdio. That header file includes way too much that it does not need, so we can surely strip it of even more standard includes if that is what is required to fix this. > > > Unfortunately it did not help. > @MBaesken How annoying. :( I have now tried to remove _all_ system includes from `debug_util.h`. Can you please try again building debug on AIX, to see if it works without the `#undef` in `BufferedRenderPipe.c`? The AIX (fast)debug build still fails . ------------- PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1921645170 From ihse at openjdk.org Thu Feb 1 16:21:05 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Thu, 1 Feb 2024 16:21:05 GMT Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v4] In-Reply-To: References: Message-ID: <1wzw4p_VVMn-Qkb6utSVBVN4HDK9uwRnr3MGDsxi51A=.5028d021-ecd3-45af-a9a1-2033a897cf9b@github.com> On Thu, 1 Feb 2024 12:13:08 GMT, Alan Bateman wrote: > Can you confirm that you've run tier1-4 at least? Some of the library code that is changed here is not tested in the lower tiers. I have run tier1-4 now, and it passes (bar the tests that are currently failing in mainline). However, this only tests 64-bit builds, and these changes do not affect 64-bit builds, only 32-bit linux. So the tier1-4 is more of a sanity check that I did not inadvertenly broke any 64-bit code. To really test that this works properly, a 32-bit linux with an assortment of operations on > 2GB files would be needed. To the best of my knowledge, we have no such test environment available, and I could not even try to think of how to create such a test setup that does anything useful. (That is, if I even were to spend any time on creating new tests for 32-bit platforms...) ------------- PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1921697168 From jbhateja at openjdk.org Thu Feb 1 16:24:16 2024 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Thu, 1 Feb 2024 16:24:16 GMT Subject: RFR: 8318650: Optimized subword gather for x86 targets. [v12] 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 using 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.5-10x gains with included micro on Intel Atom family CPUs and with JVM option UseAVX=2. > > ![image](https://github.com/openjdk/jdk/assets/59989778/e25ba4ad-6a61-42fa-9566-452f741a9c6d) > > > 2) For AVX512 targets algorithm uses integral gather instructions to load values from normalized indices which are multiple of integer size, followed by shuffling and packing exact sub-word values from integral lanes. > > 3) 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. > > Kindly review and share your feedback. > > Best Regards, > Jatin Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits: - Generalizing masked sub-gather support. - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8318650 - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8318650 - Fix incorrect comment - Review comments resolutions. - Review comments resolutions. - Review comments resolutions. - Restricting masked sub-word gather to AVX512 target to align with integral gather support. - Review comments resolution. - 8318650: Optimized subword gather for x86 targets. ------------- Changes: https://git.openjdk.org/jdk/pull/16354/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16354&range=11 Stats: 1216 lines in 32 files changed: 1168 ins; 20 del; 28 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 Thu Feb 1 16:28:06 2024 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Thu, 1 Feb 2024 16:28:06 GMT Subject: RFR: 8318650: Optimized subword gather for x86 targets. [v11] In-Reply-To: References: Message-ID: On Wed, 31 Jan 2024 23:53:16 GMT, Sandhya Viswanathan wrote: >> src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 1613: >> >>> 1611: vpand(xtmp, idx_vec, xtmp, vlen_enc); >>> 1612: // Load double words from normalized indices. >>> 1613: evpgatherdd(dst, gmask, Address(base, xtmp, scale), vlen_enc); >> >> Another question, looks to me that we could read beyond the allocated memory for the array here. e.g. consider the following case: >> * It is a byte gather >> * The byte source array is of size 41, i.e. only indices 0-40 are valid >> * The gather index is 40 >> >> Then as part of evpgatherdd we would be reading bytes at 40-43 offset from source array. > > I guess the fact that the Java objects are 8 byte alignment padded and the alignment being done at lines 1609-1611 and 1616-1621 somehow takes care of this. Hi @sviswa7 , I have rolled back to originally proposed solution. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16354#discussion_r1474741688 From rriggs at openjdk.org Thu Feb 1 17:02:01 2024 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 1 Feb 2024 17:02:01 GMT Subject: RFR: 8325109: Sort method modifiers in canonical order In-Reply-To: References: Message-ID: On Thu, 1 Feb 2024 11:57:04 GMT, Magnus Ihse Bursie wrote: > This is a follow-up on [JDK-8324053](https://bugs.openjdk.org/browse/JDK-8324053). I have run the bin/blessed-modifier-order.sh on the entire code base, and manually checked the result. I have reverted all but these trivial and uncontroversial changes. > > Almost all of these are about moving `static` to its proper position; a few do not involve `static` but instead puts `final` or `abstract` in the correct place. > > I have deliberately stayed away from `default` in this PR, since they should probably get a more thorough treatment, see https://github.com/openjdk/jdk/pull/17468#pullrequestreview-1829238473. lgtm; all look good ------------- Marked as reviewed by rriggs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17670#pullrequestreview-1857031136 From rriggs at openjdk.org Thu Feb 1 17:04:02 2024 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 1 Feb 2024 17:04:02 GMT Subject: RFR: 8324960: Unsafe.allocateMemory documentation incorrect regarding zero return value In-Reply-To: References: Message-ID: On Wed, 31 Jan 2024 01:17:07 GMT, Brian Burkhalter wrote: > Align the specification of `Unsafe.allocateMemory` with its implementation and with the specification of `Unsafe.reallocateMemory`. lgtm ------------- Marked as reviewed by rriggs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17643#pullrequestreview-1857034055 From darcy at openjdk.org Thu Feb 1 17:24:01 2024 From: darcy at openjdk.org (Joe Darcy) Date: Thu, 1 Feb 2024 17:24:01 GMT Subject: RFR: 8325109: Sort method modifiers in canonical order In-Reply-To: References: Message-ID: On Thu, 1 Feb 2024 11:57:04 GMT, Magnus Ihse Bursie wrote: > This is a follow-up on [JDK-8324053](https://bugs.openjdk.org/browse/JDK-8324053). I have run the bin/blessed-modifier-order.sh on the entire code base, and manually checked the result. I have reverted all but these trivial and uncontroversial changes. > > Almost all of these are about moving `static` to its proper position; a few do not involve `static` but instead puts `final` or `abstract` in the correct place. > > I have deliberately stayed away from `default` in this PR, since they should probably get a more thorough treatment, see https://github.com/openjdk/jdk/pull/17468#pullrequestreview-1829238473. Looks fine; I just suggest double-checking on the current maintenance procedures for the java.util.concurrent code. ------------- Marked as reviewed by darcy (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17670#pullrequestreview-1857088376 From duke at openjdk.org Thu Feb 1 19:17:09 2024 From: duke at openjdk.org (duke) Date: Thu, 1 Feb 2024 19:17:09 GMT Subject: Withdrawn: 8321468: Remove StringUTF16::equals In-Reply-To: References: Message-ID: <-NcFNFFX-Avf9EiYqMntALToh_w6F_SIZ6caNzUD6qU=.ee1ca764-1ac2-4f89-8dd8-c3944be067d2@github.com> On Wed, 6 Dec 2023 14:20:14 GMT, Claes Redestad wrote: > https://bugs.openjdk.org/browse/JDK-8215017 removed the only use of `StringUTF16::equals`. At the time I did some performance verification focused on x86 showing that simplifying and only using `StringLatin1::equals` was either neutral or a win. > > I repeated this experiment recently, adding some focused tests on aarch64 where the code generation actually tries to take advantage and generate slightly more efficient code for `StringUTF16::equals`: > https://github.com/openjdk/jdk/pull/16933#discussion_r1414118658 > > The indication here is that disabling use of `StringUTF16::equals` was the right choice: any effect from the low-level optimization (one less branch at the tail end) was offset by the `isLatin1()` branch and added code generation (that all gets inlined). > > In a `-XX:-CompactStrings` configuration the slightly improved code generation in `StringUTF16::equals` might help, since the `isLatin1()` test and subsequent call to `StringLatin1::equals` would be DCEd. To get the best of both worlds the code in `String::equals` _could_ be sharpened so that we statically pick the best implementation based on `CompactStrings` mode (see comment below). This shows a tiny win when testing with `-XX:-CompactStrings` on M1 (up to -0.2ns/op per `String::equals`; neutral on x86). But is all this complexity worth it for a gain that will get lost in the noise on anything realistic? > > This PR instead proposes removing `StringUTF16::equals` and simplifying the mechanisms to support the `StringLatin1/UTF16::equals` pair of intrinsics in hotspot. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/16995 From bpb at openjdk.org Thu Feb 1 19:19:02 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 1 Feb 2024 19:19:02 GMT Subject: RFR: 8324960: Unsafe.allocateMemory documentation incorrect regarding zero return value In-Reply-To: References: Message-ID: On Thu, 1 Feb 2024 17:01:11 GMT, Roger Riggs wrote: > lgtm Thanks @RogerRiggs. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17643#issuecomment-1922050326 From psandoz at openjdk.org Thu Feb 1 19:46:05 2024 From: psandoz at openjdk.org (Paul Sandoz) Date: Thu, 1 Feb 2024 19:46:05 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... Marked as reviewed by psandoz (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/16681#pullrequestreview-1857461928 From jvernee at openjdk.org Thu Feb 1 20:10:29 2024 From: jvernee at openjdk.org (Jorn Vernee) Date: Thu, 1 Feb 2024 20:10:29 GMT Subject: RFR: 8318966: Some methods make promises about Java array element alignment that are too strong [v2] In-Reply-To: References: Message-ID: <7BH7MA_XWtqbGekVB83r9KMCYIq2P1QXeMX25QmqvTU=.edb35293-fa11-4d7f-945d-9ec0ce0e2a31@github.com> > 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... Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision: - Merge branch 'master' into AlignedOffset - Add api note pointing to alternatives for client that require non-plain access - simplify spec for alignmentOffset and alignedSlice - Merge note about misaligned access in byteBufferViewVarHandle - updated alignedSlice implNote as well - updated alignedOffset implNote - Use ISE for bbvvh instead of UOE - restore some tests for direct buffers - fix BAVV and BBVV impl and tests - regen test files - ... and 1 more: https://git.openjdk.org/jdk/compare/0468810a...eccf4f41 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16681/files - new: https://git.openjdk.org/jdk/pull/16681/files/d74f47f1..eccf4f41 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16681&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16681&range=00-01 Stats: 235568 lines in 5388 files changed: 128775 ins; 77246 del; 29547 mod Patch: https://git.openjdk.org/jdk/pull/16681.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16681/head:pull/16681 PR: https://git.openjdk.org/jdk/pull/16681 From darcy at openjdk.org Thu Feb 1 21:16:24 2024 From: darcy at openjdk.org (Joe Darcy) Date: Thu, 1 Feb 2024 21:16:24 GMT Subject: RFR: JDK-8325148: Enable restricted javac warning in java.base Message-ID: <8zJEeLqHKWm91gZPlYNBVP_5qDXhQgh7g2sWgLXFp3k=.8404dccf-c5a3-4d13-9227-39fc3696f3a5@github.com> The restricted javac warning is disabled for java.base, but could be enabled by suppressing the warning in a handful of files. ------------- Commit messages: - JDK-8325148: Enable restricted javac warning in java.base Changes: https://git.openjdk.org/jdk/pull/17677/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17677&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8325148 Stats: 26 lines in 9 files changed: 10 ins; 0 del; 16 mod Patch: https://git.openjdk.org/jdk/pull/17677.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17677/head:pull/17677 PR: https://git.openjdk.org/jdk/pull/17677 From naoto at openjdk.org Thu Feb 1 21:25:06 2024 From: naoto at openjdk.org (Naoto Sato) Date: Thu, 1 Feb 2024 21:25:06 GMT Subject: RFR: JDK-8318761: MessageFormat pattern support for CompactNumberFormat, ListFormat, and DateTimeFormatter In-Reply-To: References: Message-ID: On Wed, 31 Jan 2024 22:24:14 GMT, Justin Lu wrote: > Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8319344) which adds MessageFormat pattern support for the following subformats: ListFormat, CompactNumberFormat, and DateTimeFormatter. This change is intended to provide pattern support for the more recently added JDK Format subclasses, as well as improving java.time formatting within i18n. The draft javadoc can be viewed here: https://cr.openjdk.org/~jlu/docs/api/java.base/java/text/MessageFormat.html. Please see the CSR for more in-depth behavioral changes, as well as limitations. > > The `FormatTypes`: dtf_date, dtf_time, dtf_datetime, pre-defined DateTimeFormatter(s), and list are added. > The `FormatStyles`: compact_short, compact_long, or, and unit are added. > > For example, previously, > > > Object[] args = {LocalDate.of(2023, 11, 16), LocalDate.of(2023, 11, 27)}; > MessageFormat.format("It was {0,date,full}, now it is {1,date,full}", args); > > > would throw `Exception java.lang.IllegalArgumentException: Cannot format given Object as a Date` > > Now, a user can call > > > MessageFormat.format("It was {0,dtf_date,full}, now it is {1,dtf_date,full}", args); > > > which returns "It was Thursday, November 16, 2023, now it is Friday, November 17, 2023" src/java.base/share/classes/java/text/MessageFormat.java line 370: > 368: * > 369: * MessageFormat provides patterns that support both the {@link java.time} package > 370: * and the {@link Date java.util.Date} type. Consider the following three examples, Might read better with "patterns that support the date/time formatters in the java.time.format and java.text packages" src/java.base/share/classes/java/text/MessageFormat.java line 375: > 373: *

1) a date {@code FormatType} with a full {@code FormatStyle}, > 374: * {@snippet lang=java : > 375: * Object[] arg = {new Date(2023, 11, 16)}; This is not correct (year and month are wrong), and actually should not be used in an example as the 3-arg constructor is deprecated. Use `Calendar.getTime()` to obtain a `Date` instead. src/java.base/share/classes/java/text/MessageFormat.java line 676: > 674: * java.time.format.DateTimeFormatter}. In addition, {@code DateTimeFormatter} > 675: * does not implement {@code equals()}, and thus cannot be represented as a > 676: * pattern. Any "default"/"medium" styles are omitted according to the specification. Since `DateTimeFormatter` eventually are converted to j.t.Format with `toFormat()` method, wouldn't it be possible to implement this method for those dtf(s)? src/java.base/share/classes/java/text/MessageFormat.java line 1868: > 1866: throw new IllegalArgumentException(); > 1867: } > 1868: } Can this be replaced with `Enum.valueOf(String)`, after input is normalized? src/java.base/share/classes/java/text/MessageFormat.java line 1904: > 1902: throw new IllegalArgumentException(); > 1903: } > 1904: } Same as above. test/jdk/java/text/Format/MessageFormat/CompactSubFormats.java line 42: > 40: > 41: import static org.junit.jupiter.api.Assertions.assertEquals; > 42: import static org.junit.jupiter.api.Assertions.assertThrows; Does not seem to be used in this test test/jdk/java/text/Format/MessageFormat/CompactSubFormats.java line 62: > 60: @Test > 61: public void badApplyPatternTest() { > 62: // An exception won't be thrown since 'compact_regular' will be interpreted as a If the test is to ensure the given type is a subformat, the comment and the method name do not seem to represent it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17663#discussion_r1475065503 PR Review Comment: https://git.openjdk.org/jdk/pull/17663#discussion_r1475076366 PR Review Comment: https://git.openjdk.org/jdk/pull/17663#discussion_r1475100517 PR Review Comment: https://git.openjdk.org/jdk/pull/17663#discussion_r1475152563 PR Review Comment: https://git.openjdk.org/jdk/pull/17663#discussion_r1475152764 PR Review Comment: https://git.openjdk.org/jdk/pull/17663#discussion_r1475153695 PR Review Comment: https://git.openjdk.org/jdk/pull/17663#discussion_r1475159578 From naoto at openjdk.org Thu Feb 1 21:26:14 2024 From: naoto at openjdk.org (Naoto Sato) Date: Thu, 1 Feb 2024 21:26:14 GMT Subject: RFR: 8309622: Re-examine the cache mechanism in BaseLocale [v6] In-Reply-To: <-g3xZNoboLRPlrTcQv17TGig7R0WNUJ0oJDAIWc0lwo=.f7946875-077b-4d15-a5a9-bb415b3ab062@github.com> References: <5MqmN4P1TLKDCfXPhKWrH1b2FTgOXmjtKgd1bVXDd_M=.2000f20d-365d-48dc-bc37-45d8bcb9447f@github.com> <-g3xZNoboLRPlrTcQv17TGig7R0WNUJ0oJDAIWc0lwo=.f7946875-077b-4d15-a5a9-bb415b3ab062@github.com> Message-ID: On Wed, 30 Aug 2023 22:35:43 GMT, Naoto Sato wrote: >> This is stemming from the PR: https://github.com/openjdk/jdk/pull/14211 where aggressive GC can cause NPE in `BaseLocale$Key` class. I refactored the in-house cache with WeakHashMap, and removed the Key class as it is no longer needed (thus the original NPE will no longer be possible). Also with the new JMH test case, it gains some performance improvement: >> >> (w/o fix) >> >> Benchmark Mode Cnt Score Error Units >> LocaleCache.testForLanguageTag avgt 20 5781.275 ? 569.580 ns/op >> LocaleCache.testLocaleOf avgt 20 62564.079 ? 406.697 ns/op >> >> (w/ fix) >> Benchmark Mode Cnt Score Error Units >> LocaleCache.testForLanguageTag avgt 20 4801.175 ? 371.830 ns/op >> LocaleCache.testLocaleOf avgt 20 60394.652 ? 352.471 ns/op > > Naoto Sato has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 31 commits: > > - Restored the test > - Merge branch 'master' into JDK-8309622-Cache-BaseLocale > - Merge branch 'master' of https://git.openjdk.org/jdk into JDK-8309622-Cache-BaseLocale > - small cleanup > - Merge branch 'pull/14684' into JDK-8309622-Cache-BaseLocale > - Update ReferencedKeyTest.java > - Simple versions of create > - Add flag for reference queue type > - Merge branch 'master' into 8310913 > - Update to use VirtualThread friendly stale queue. > - ... and 21 more: https://git.openjdk.org/jdk/compare/99ea8bf2...b1f64e93 keep open ------------- PR Comment: https://git.openjdk.org/jdk/pull/14404#issuecomment-1922270437 From erikj at openjdk.org Thu Feb 1 21:30:01 2024 From: erikj at openjdk.org (Erik Joelsson) Date: Thu, 1 Feb 2024 21:30:01 GMT Subject: RFR: JDK-8325148: Enable restricted javac warning in java.base In-Reply-To: <8zJEeLqHKWm91gZPlYNBVP_5qDXhQgh7g2sWgLXFp3k=.8404dccf-c5a3-4d13-9227-39fc3696f3a5@github.com> References: <8zJEeLqHKWm91gZPlYNBVP_5qDXhQgh7g2sWgLXFp3k=.8404dccf-c5a3-4d13-9227-39fc3696f3a5@github.com> Message-ID: <4znJHUj228pJIUQcDaUteF1uD8WxW14V1dQhlQBCQ9s=.9b2df0f8-c154-43c4-8e64-6900baac4a32@github.com> On Thu, 1 Feb 2024 21:10:48 GMT, Joe Darcy wrote: > The restricted javac warning is disabled for java.base, but could be enabled by suppressing the warning in a handful of files. Marked as reviewed by erikj (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/17677#pullrequestreview-1857672295 From bpb at openjdk.org Thu Feb 1 21:34:00 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 1 Feb 2024 21:34:00 GMT Subject: RFR: 8324960: Unsafe.allocateMemory documentation incorrect regarding zero return value In-Reply-To: References: Message-ID: On Wed, 31 Jan 2024 01:17:07 GMT, Brian Burkhalter wrote: > Align the specification of `Unsafe.allocateMemory` with its implementation and with the specification of `Unsafe.reallocateMemory`. CSR created. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17643#issuecomment-1922281572 From egahlin at openjdk.org Thu Feb 1 21:40:05 2024 From: egahlin at openjdk.org (Erik Gahlin) Date: Thu, 1 Feb 2024 21:40:05 GMT Subject: RFR: 8323058: Revisit j.l.classfile.CodeBuilder API surface In-Reply-To: References: Message-ID: On Fri, 5 Jan 2024 15:17:13 GMT, Adam Sotona wrote: > `java.lang.classfile.CodeBuilder` contains more than 230 API methods. > Existing ClassFile API use cases proved the concept one big CodeBuilder is comfortable. However there are some redundancies, glitches in the naming conventions, some frequently used methods are hard to find and some methods have low practical use. > > This patch revisits the `CodeBuilder` API methods and introduces some changes. > > For more details, please, visit the [CSR ](https://bugs.openjdk.org/browse/JDK-8323067) > > Please review. > > Thank you, > Adam JFR part (EventInstrumentation.java) looks good. ------------- PR Review: https://git.openjdk.org/jdk/pull/17282#pullrequestreview-1857688408 From mcimadamore at openjdk.org Thu Feb 1 21:54:06 2024 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Thu, 1 Feb 2024 21:54:06 GMT Subject: RFR: 8318966: Some methods make promises about Java array element alignment that are too strong [v2] In-Reply-To: <7BH7MA_XWtqbGekVB83r9KMCYIq2P1QXeMX25QmqvTU=.edb35293-fa11-4d7f-945d-9ec0ce0e2a31@github.com> References: <7BH7MA_XWtqbGekVB83r9KMCYIq2P1QXeMX25QmqvTU=.edb35293-fa11-4d7f-945d-9ec0ce0e2a31@github.com> Message-ID: On Thu, 1 Feb 2024 20:10:29 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... > > Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision: > > - Merge branch 'master' into AlignedOffset > - Add api note pointing to alternatives for client that require non-plain access > - simplify spec for alignmentOffset and alignedSlice > - Merge note about misaligned access in byteBufferViewVarHandle > - updated alignedSlice implNote as well > - updated alignedOffset implNote > - Use ISE for bbvvh instead of UOE > - restore some tests for direct buffers > - fix BAVV and BBVV impl and tests > - regen test files > - ... and 1 more: https://git.openjdk.org/jdk/compare/da4eca34...eccf4f41 Marked as reviewed by mcimadamore (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/16681#pullrequestreview-1857716614 From jvernee at openjdk.org Thu Feb 1 22:04:01 2024 From: jvernee at openjdk.org (Jorn Vernee) Date: Thu, 1 Feb 2024 22:04:01 GMT Subject: RFR: JDK-8325148: Enable restricted javac warning in java.base In-Reply-To: <8zJEeLqHKWm91gZPlYNBVP_5qDXhQgh7g2sWgLXFp3k=.8404dccf-c5a3-4d13-9227-39fc3696f3a5@github.com> References: <8zJEeLqHKWm91gZPlYNBVP_5qDXhQgh7g2sWgLXFp3k=.8404dccf-c5a3-4d13-9227-39fc3696f3a5@github.com> Message-ID: On Thu, 1 Feb 2024 21:10:48 GMT, Joe Darcy wrote: > The restricted javac warning is disabled for java.base, but could be enabled by suppressing the warning in a handful of files. This looks good to me. It will be easier to find where we are doing restricted operations like this. ------------- Marked as reviewed by jvernee (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17677#pullrequestreview-1857741290 From darcy at openjdk.org Thu Feb 1 22:19:26 2024 From: darcy at openjdk.org (Joe Darcy) Date: Thu, 1 Feb 2024 22:19:26 GMT Subject: RFR: JDK-8325148: Enable restricted javac warning in java.base [v2] In-Reply-To: <8zJEeLqHKWm91gZPlYNBVP_5qDXhQgh7g2sWgLXFp3k=.8404dccf-c5a3-4d13-9227-39fc3696f3a5@github.com> References: <8zJEeLqHKWm91gZPlYNBVP_5qDXhQgh7g2sWgLXFp3k=.8404dccf-c5a3-4d13-9227-39fc3696f3a5@github.com> Message-ID: > The restricted javac warning is disabled for java.base, but could be enabled by suppressing the warning in a handful of files. Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Add comment highlighting restricted method calls. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17677/files - new: https://git.openjdk.org/jdk/pull/17677/files/4973b1fb..9ac261c0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17677&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17677&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/17677.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17677/head:pull/17677 PR: https://git.openjdk.org/jdk/pull/17677 From darcy at openjdk.org Thu Feb 1 22:19:26 2024 From: darcy at openjdk.org (Joe Darcy) Date: Thu, 1 Feb 2024 22:19:26 GMT Subject: RFR: JDK-8325148: Enable restricted javac warning in java.base [v2] In-Reply-To: References: <8zJEeLqHKWm91gZPlYNBVP_5qDXhQgh7g2sWgLXFp3k=.8404dccf-c5a3-4d13-9227-39fc3696f3a5@github.com> Message-ID: On Thu, 1 Feb 2024 22:01:49 GMT, Jorn Vernee wrote: > This looks good to me. It will be easier to find where we are doing restricted operations like this. Right; follows the recommended approach of minimizing the scope of the SuppressWarnings annotations too. Thanks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17677#issuecomment-1922360484 From jlu at openjdk.org Thu Feb 1 22:24:08 2024 From: jlu at openjdk.org (Justin Lu) Date: Thu, 1 Feb 2024 22:24:08 GMT Subject: Integrated: JDK-6285888: ChoiceFormat can support unescaped relational symbols in the Format segment In-Reply-To: <154YlkQWp3Zi9ksGuOUZpDkdQUXuq0musq8HuCq_LAw=.de42ce19-8d56-44fb-861b-72e3380a49b4@github.com> References: <154YlkQWp3Zi9ksGuOUZpDkdQUXuq0musq8HuCq_LAw=.de42ce19-8d56-44fb-861b-72e3380a49b4@github.com> Message-ID: On Tue, 30 Jan 2024 21:19:27 GMT, Justin Lu wrote: > Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8314822) which allows for the _Format_ segment of a ChoiceFormat pattern to use the ChoiceFormat Relational symbols without the need to escape them using quotes. Previously, using a non escaped Relational symbol within a _Format_ segment would throw an IAE. > > Implementation wise, this can be achieved by adding an additional check of `part == 0` to the relational symbol conditional. This is safe to do, as any subsequent relational symbols should only come after a '|' is parsed, which sets part back to 0. This ensures that for the duration of `part = 1` (Format segment), the relational symbols can be used without syntactic meaning. > > For example, this change allows behavior such as: `new ChoiceFormat("1#The code is #7281")`. Previously, the workaround would have been new `ChoiceFormat("1#The code is '#'7281")` to achieve the same formatted behavior. Please see the CSR for more detail. > > Additionally, this change also includes an unrelated grouping of the ChoiceFormat examples under a single header: **Usage Information**. This pull request has now been integrated. Changeset: d3c3194a Author: Justin Lu URL: https://git.openjdk.org/jdk/commit/d3c3194ac343a0e754448cd337f64114760de50b Stats: 209 lines in 3 files changed: 144 ins; 56 del; 9 mod 6285888: ChoiceFormat can support unescaped relational symbols in the Format segment Reviewed-by: naoto ------------- PR: https://git.openjdk.org/jdk/pull/17640 From prappo at openjdk.org Thu Feb 1 23:07:08 2024 From: prappo at openjdk.org (Pavel Rappo) Date: Thu, 1 Feb 2024 23:07:08 GMT Subject: RFR: 8325109: Sort method modifiers in canonical order In-Reply-To: References: Message-ID: On Thu, 1 Feb 2024 11:57:04 GMT, Magnus Ihse Bursie wrote: > This is a follow-up on [JDK-8324053](https://bugs.openjdk.org/browse/JDK-8324053). I have run the bin/blessed-modifier-order.sh on the entire code base, and manually checked the result. I have reverted all but these trivial and uncontroversial changes. > > Almost all of these are about moving `static` to its proper position; a few do not involve `static` but instead puts `final` or `abstract` in the correct place. > > I have deliberately stayed away from `default` in this PR, since they should probably get a more thorough treatment, see https://github.com/openjdk/jdk/pull/17468#pullrequestreview-1829238473. Changes to jdk.javadoc look fine. ------------- Marked as reviewed by prappo (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17670#pullrequestreview-1857871131 From naoto at openjdk.org Thu Feb 1 23:18:14 2024 From: naoto at openjdk.org (Naoto Sato) Date: Thu, 1 Feb 2024 23:18:14 GMT Subject: RFR: 8324665: Loose matching of space separators in the lenient date/time parsing mode Message-ID: Implementing "loose matching" of space separators in both `java.time.format.DateTimeFormatter` and `java.text.DateFormat` on lenient parsing. This will effectively fix the NNBSP issues on parsing time with am/pm markers introduced with CLDR version 42 (https://inside.java/2023/03/28/quality-heads-up/). A draft CSR has also been drafted. ------------- Commit messages: - initial commit Changes: https://git.openjdk.org/jdk/pull/17678/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17678&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8324665 Stats: 175 lines in 4 files changed: 169 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/17678.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17678/head:pull/17678 PR: https://git.openjdk.org/jdk/pull/17678 From jlu at openjdk.org Thu Feb 1 23:30:04 2024 From: jlu at openjdk.org (Justin Lu) Date: Thu, 1 Feb 2024 23:30:04 GMT Subject: RFR: 8323699: MessageFormat.toPattern() generates non-equivalent MessageFormat pattern [v7] In-Reply-To: References: Message-ID: On Tue, 30 Jan 2024 18:28:32 GMT, Archie Cobbs wrote: >> Please consider this fix to ensure that going from `MessageFormat` to pattern string via `toPattern()` and then back via `new MessageFormat()` results in a format that is equivalent to the original. >> >> The quoting and escaping rules for `MessageFormat` pattern strings are really tricky. I admit not completely understanding them. At a high level, they work like this: The normal way one would "nest" strings containing special characters is with straightforward recursive escaping like with the `bash` command line. For example, if you want to echo `a "quoted string" example` then you enter `echo "a "quoted string" example"`. With this scheme it's always the "outer" layer's job to (un)escape special characters as needed. That is, the echo command never sees the backslash characters. >> >> In contrast, with `MessageFormat` and friends, nested subformat pattern strings are always provided "pre-escaped". So to build an "outer" string (e.g., for `ChoiceFormat`) the "inner" subformat pattern strings are more or less just concatenated, and then only the `ChoiceFormat` option separator characters (e.g., `<`, `#`, `|`, etc.) are escaped. >> >> The "pre-escape" escaping algorithm escapes `{` characters, because `{` indicates the beginning of a format argument. However, it doesn't escape `}` characters. This is OK because the format string parser treats any "extra" closing braces (where "extra" means not matching an opening brace) as plain characters. >> >> So far, so good... at least, until a format string containing an extra closing brace is nested inside a larger format string, where the extra closing brace, which was previously "extra", can now suddenly match an opening brace in the outer pattern containing it, thus truncating it by "stealing" the match from some subsequent closing brace. >> >> An example is the `MessageFormat` string `"{0,choice,0.0#option A: {1}|1.0#option B: {1}'}'}"`. Note the second option format string has a trailing closing brace in plain text. If you create a `MessageFormat` with this string, you see a trailing `}` only with the second option. >> >> However, if you then invoke `toPattern()`, the result is `"{0,choice,0.0#option A: {1}|1.0#option B: {1}}}"`. Oops, now because the "extra" closing brace is no longer quoted, it matches the opening brace at the beginning of the string, and the following closing brace, which was the previous match, is now just plain text in the outer `MessageFormat` string. >> >> As a result, invoking `f.format(new ... > > Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision: > > Fix misspelling in comment. Left some minor comments, but LGTM, I also ran this change against internal tests and all is good there. Others may have suggestions, in any case, you will still need a review from someone with 'reviewer' status. test/jdk/java/text/Format/MessageFormat/MessageFormatToPatternTest.java line 26: > 24: /* > 25: * @test > 26: * @summary Verify MessageFormat.toPattern() is equivalent to original pattern Could make the summary a little more specific for future readers test/jdk/java/text/Format/MessageFormat/MessageFormatToPatternTest.java line 70: > 68: @BeforeAll > 69: public static void setup() { > 70: savedLocale = Locale.getDefault(); I'm not sure we need to save the default locale and restore it, unless I'm missing something. test/jdk/java/text/Format/MessageFormat/MessageFormatToPatternTest.java line 104: > 102: Arguments.of("{0,choice,0.0#option A: {0}|1.0#option B: {0}'}'}", "option B: 1.23}"), > 103: Arguments.of("{0,choice,0.0#option A: {0}|2.0#option B: {0}'}'}", "option A: 1.23"), > 104: Suggestion: // Absurd double quote examples Arguments.of("Foo '}''''''''}' {0,number,bar'}' '}' } baz ", "Foo }''''} bar} } 1 baz "), Arguments.of("'''}''{'''}''''}'"), "'}'{'}''}"), test/jdk/java/text/Format/MessageFormat/MessageFormatsByArgumentIndex.java line 35: > 33: import java.text.NumberFormat; > 34: > 35: public class MessageFormatsByArgumentIndex { Can you bump the latter copyright year for this file test/jdk/java/text/Format/MessageFormat/MessageRegression.java line 114: > 112: * MessageFormat.toPattern has weird rounding behavior. > 113: */ > 114: @Test This file as well ------------- Marked as reviewed by jlu (Committer). PR Review: https://git.openjdk.org/jdk/pull/17416#pullrequestreview-1857862268 PR Review Comment: https://git.openjdk.org/jdk/pull/17416#discussion_r1475280475 PR Review Comment: https://git.openjdk.org/jdk/pull/17416#discussion_r1475279603 PR Review Comment: https://git.openjdk.org/jdk/pull/17416#discussion_r1475294193 PR Review Comment: https://git.openjdk.org/jdk/pull/17416#discussion_r1475277825 PR Review Comment: https://git.openjdk.org/jdk/pull/17416#discussion_r1475278147 From psandoz at openjdk.org Thu Feb 1 23:54:25 2024 From: psandoz at openjdk.org (Paul Sandoz) Date: Thu, 1 Feb 2024 23:54:25 GMT Subject: RFR: 8324858: [vectorapi] Bounds checking issues when accessing memory segments [v2] In-Reply-To: References: Message-ID: > The implementation of method `VectorSpecies::fromMemorySegment`, in `AbstractSpecies::fromMemorySegment`, neglects to perform bounds checks on the offset argument when the method is compiled by C2 (bounds checks are performed when interpreted and by C1). > > This is an oversight and explicit bounds checks are required, as is already case for the other load and store memory access methods (including storing to memory memory segments). > > The workaround is to call the static method `{T}Vector::fromMemorySegment`. > > The fix is for the implementation(s) of `VectorSpecies::fromMemorySegment` to do the same and call `{T}Vector::fromMemorySegment`, following the same pattern for implementations of `VectorSpecies::fromArray`. > > The tests have been conservatively updated to call the species access method where possible in the knowledge that it calls the vector access method (the tests were intended to test out of bounds access when compiled by C2). > > Thinking ahead its tempting to remove the species access methods, simplifying functionality that is duplicated. Paul Sandoz has updated the pull request incrementally with one additional commit since the last revision: Update/add clarifying comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17621/files - new: https://git.openjdk.org/jdk/pull/17621/files/ba326467..e3958a16 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17621&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17621&range=00-01 Stats: 90 lines in 38 files changed: 76 ins; 0 del; 14 mod Patch: https://git.openjdk.org/jdk/pull/17621.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17621/head:pull/17621 PR: https://git.openjdk.org/jdk/pull/17621 From naoto at openjdk.org Fri Feb 2 00:03:02 2024 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 2 Feb 2024 00:03:02 GMT Subject: RFR: 8323699: MessageFormat.toPattern() generates non-equivalent MessageFormat pattern [v7] In-Reply-To: References: Message-ID: On Tue, 30 Jan 2024 18:28:32 GMT, Archie Cobbs wrote: >> Please consider this fix to ensure that going from `MessageFormat` to pattern string via `toPattern()` and then back via `new MessageFormat()` results in a format that is equivalent to the original. >> >> The quoting and escaping rules for `MessageFormat` pattern strings are really tricky. I admit not completely understanding them. At a high level, they work like this: The normal way one would "nest" strings containing special characters is with straightforward recursive escaping like with the `bash` command line. For example, if you want to echo `a "quoted string" example` then you enter `echo "a "quoted string" example"`. With this scheme it's always the "outer" layer's job to (un)escape special characters as needed. That is, the echo command never sees the backslash characters. >> >> In contrast, with `MessageFormat` and friends, nested subformat pattern strings are always provided "pre-escaped". So to build an "outer" string (e.g., for `ChoiceFormat`) the "inner" subformat pattern strings are more or less just concatenated, and then only the `ChoiceFormat` option separator characters (e.g., `<`, `#`, `|`, etc.) are escaped. >> >> The "pre-escape" escaping algorithm escapes `{` characters, because `{` indicates the beginning of a format argument. However, it doesn't escape `}` characters. This is OK because the format string parser treats any "extra" closing braces (where "extra" means not matching an opening brace) as plain characters. >> >> So far, so good... at least, until a format string containing an extra closing brace is nested inside a larger format string, where the extra closing brace, which was previously "extra", can now suddenly match an opening brace in the outer pattern containing it, thus truncating it by "stealing" the match from some subsequent closing brace. >> >> An example is the `MessageFormat` string `"{0,choice,0.0#option A: {1}|1.0#option B: {1}'}'}"`. Note the second option format string has a trailing closing brace in plain text. If you create a `MessageFormat` with this string, you see a trailing `}` only with the second option. >> >> However, if you then invoke `toPattern()`, the result is `"{0,choice,0.0#option A: {1}|1.0#option B: {1}}}"`. Oops, now because the "extra" closing brace is no longer quoted, it matches the opening brace at the beginning of the string, and the following closing brace, which was the previous match, is now just plain text in the outer `MessageFormat` string. >> >> As a result, invoking `f.format(new ... > > Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision: > > Fix misspelling in comment. src/java.base/share/classes/java/text/MessageFormat.java line 1675: > 1673: i++; > 1674: } else > 1675: quoted = !quoted; Nit: be consistent on curly-braces. Same for some other places as well. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17416#discussion_r1475338907 From psandoz at openjdk.org Fri Feb 2 00:06:01 2024 From: psandoz at openjdk.org (Paul Sandoz) Date: Fri, 2 Feb 2024 00:06:01 GMT Subject: RFR: 8324858: [vectorapi] Bounds checking issues when accessing memory segments [v2] In-Reply-To: References: Message-ID: On Thu, 1 Feb 2024 12:22:10 GMT, Maurizio Cimadamore wrote: >> My expectation is the risk is small, but of course non-zero. These tests can be expensive to run so i was trying balance the risk without increasing test execution times. >> >> I could strengthen the comment from: >> >> @ForceInline >> @Override final >> public ByteVector fromMemorySegment(MemorySegment ms, long offset, ByteOrder bo) { >> // User entry point: Be careful with inputs. >> return ByteVector >> .fromMemorySegment(this, ms, offset, bo); >> } >> >> >> to: >> >> >> @ForceInline >> @Override final >> public ByteVector fromMemorySegment(MemorySegment ms, long offset, ByteOrder bo) { >> // User entry point >> // Defer only to the equivalent method on the vector class, using the same inputs >> return ByteVector >> .fromMemorySegment(this, ms, offset, bo); >> } > > Sounds good Done ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17621#discussion_r1475344913 From bpb at openjdk.org Fri Feb 2 00:43:10 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 2 Feb 2024 00:43:10 GMT Subject: RFR: 8325152: Clarify specification of java.io.RandomAccessFile.setLength Message-ID: <6s1H_WwYoHtrO9N7-BhmsW6HvUhdtJUYzQyxJMeu3DI=.73712304-befe-4da2-8243-328774f9724f@github.com> Modify the specification verbiage of `java.io.RandomAccessFile.setLength` to account for the effect of the method on the file offset as returned by `getFilePointer`. ------------- Commit messages: - 8325152: Clarify specification of java.io.RandomAccessFile.setLength Changes: https://git.openjdk.org/jdk/pull/17679/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17679&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8325152 Stats: 20 lines in 1 file changed: 9 ins; 2 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/17679.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17679/head:pull/17679 PR: https://git.openjdk.org/jdk/pull/17679 From acobbs at openjdk.org Fri Feb 2 01:57:18 2024 From: acobbs at openjdk.org (Archie Cobbs) Date: Fri, 2 Feb 2024 01:57:18 GMT Subject: RFR: 8323699: MessageFormat.toPattern() generates non-equivalent MessageFormat pattern [v8] In-Reply-To: References: Message-ID: > Please consider this fix to ensure that going from `MessageFormat` to pattern string via `toPattern()` and then back via `new MessageFormat()` results in a format that is equivalent to the original. > > The quoting and escaping rules for `MessageFormat` pattern strings are really tricky. I admit not completely understanding them. At a high level, they work like this: The normal way one would "nest" strings containing special characters is with straightforward recursive escaping like with the `bash` command line. For example, if you want to echo `a "quoted string" example` then you enter `echo "a "quoted string" example"`. With this scheme it's always the "outer" layer's job to (un)escape special characters as needed. That is, the echo command never sees the backslash characters. > > In contrast, with `MessageFormat` and friends, nested subformat pattern strings are always provided "pre-escaped". So to build an "outer" string (e.g., for `ChoiceFormat`) the "inner" subformat pattern strings are more or less just concatenated, and then only the `ChoiceFormat` option separator characters (e.g., `<`, `#`, `|`, etc.) are escaped. > > The "pre-escape" escaping algorithm escapes `{` characters, because `{` indicates the beginning of a format argument. However, it doesn't escape `}` characters. This is OK because the format string parser treats any "extra" closing braces (where "extra" means not matching an opening brace) as plain characters. > > So far, so good... at least, until a format string containing an extra closing brace is nested inside a larger format string, where the extra closing brace, which was previously "extra", can now suddenly match an opening brace in the outer pattern containing it, thus truncating it by "stealing" the match from some subsequent closing brace. > > An example is the `MessageFormat` string `"{0,choice,0.0#option A: {1}|1.0#option B: {1}'}'}"`. Note the second option format string has a trailing closing brace in plain text. If you create a `MessageFormat` with this string, you see a trailing `}` only with the second option. > > However, if you then invoke `toPattern()`, the result is `"{0,choice,0.0#option A: {1}|1.0#option B: {1}}}"`. Oops, now because the "extra" closing brace is no longer quoted, it matches the opening brace at the beginning of the string, and the following closing brace, which was the previous match, is now just plain text in the outer `MessageFormat` string. > > As a result, invoking `f.format(new Object{} { 0, 5 })` will retur... Archie Cobbs has updated the pull request incrementally with four additional commits since the last revision: - Add a couple more pattern test cases suggested in review. - Update unit test @summary to better reflect what it tests. - Use curly braces consistently in patch. - Update copyright year in modified unit test files. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17416/files - new: https://git.openjdk.org/jdk/pull/17416/files/76e3d6ef..59e88126 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17416&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17416&range=06-07 Stats: 13 lines in 4 files changed: 6 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/17416.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17416/head:pull/17416 PR: https://git.openjdk.org/jdk/pull/17416 From acobbs at openjdk.org Fri Feb 2 01:57:18 2024 From: acobbs at openjdk.org (Archie Cobbs) Date: Fri, 2 Feb 2024 01:57:18 GMT Subject: RFR: 8323699: MessageFormat.toPattern() generates non-equivalent MessageFormat pattern [v7] In-Reply-To: References: Message-ID: On Thu, 1 Feb 2024 23:57:24 GMT, Naoto Sato wrote: >> Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix misspelling in comment. > > src/java.base/share/classes/java/text/MessageFormat.java line 1675: > >> 1673: i++; >> 1674: } else >> 1675: quoted = !quoted; > > Nit: be consistent on curly-braces. Same for some other places as well. Thanks, should be fixed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17416#discussion_r1475419901 From acobbs at openjdk.org Fri Feb 2 01:57:19 2024 From: acobbs at openjdk.org (Archie Cobbs) Date: Fri, 2 Feb 2024 01:57:19 GMT Subject: RFR: 8323699: MessageFormat.toPattern() generates non-equivalent MessageFormat pattern [v7] In-Reply-To: References: Message-ID: <2Jm1RVUV9uStnOqSh684SHV3qYJGtjpys8v7UeZvvtc=.b9d9b195-5662-4b27-b9f4-305d514dffcb@github.com> On Thu, 1 Feb 2024 23:02:59 GMT, Justin Lu wrote: >> Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix misspelling in comment. > > test/jdk/java/text/Format/MessageFormat/MessageFormatToPatternTest.java line 26: > >> 24: /* >> 25: * @test >> 26: * @summary Verify MessageFormat.toPattern() is equivalent to original pattern > > Could make the summary a little more specific for future readers Thanks, should be fixed. > test/jdk/java/text/Format/MessageFormat/MessageFormatToPatternTest.java line 70: > >> 68: @BeforeAll >> 69: public static void setup() { >> 70: savedLocale = Locale.getDefault(); > > I'm not sure we need to save the default locale and restore it, unless I'm missing something. We are verifying output that includes floating point numbers, and the current locale affects that: jshell> Locale.setDefault(Locale.US); jshell> new MessageFormat("{0}").format(new Object[] { 1.23 }); $9 ==> "1.23" jshell> Locale.setDefault(Locale.FRENCH); jshell> new MessageFormat("{0}").format(new Object[] { 1.23 }); $11 ==> "1,23" > test/jdk/java/text/Format/MessageFormat/MessageFormatToPatternTest.java line 104: > >> 102: Arguments.of("{0,choice,0.0#option A: {0}|1.0#option B: {0}'}'}", "option B: 1.23}"), >> 103: Arguments.of("{0,choice,0.0#option A: {0}|2.0#option B: {0}'}'}", "option A: 1.23"), >> 104: > > Suggestion: > > // Absurd double quote examples > Arguments.of("Foo '}''''''''}' {0,number,bar'}' '}' } baz ", "Foo }''''} bar} } 1 baz "), > Arguments.of("'''}''{'''}''''}'"), "'}'{'}''}"), Thanks, should be fixed. > test/jdk/java/text/Format/MessageFormat/MessageFormatsByArgumentIndex.java line 35: > >> 33: import java.text.NumberFormat; >> 34: >> 35: public class MessageFormatsByArgumentIndex { > > Can you bump the latter copyright year for this file Thanks, should be fixed. > test/jdk/java/text/Format/MessageFormat/MessageRegression.java line 114: > >> 112: * MessageFormat.toPattern has weird rounding behavior. >> 113: */ >> 114: @Test > > This file as well Thanks, should be fixed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17416#discussion_r1475420027 PR Review Comment: https://git.openjdk.org/jdk/pull/17416#discussion_r1475420069 PR Review Comment: https://git.openjdk.org/jdk/pull/17416#discussion_r1475419965 PR Review Comment: https://git.openjdk.org/jdk/pull/17416#discussion_r1475420147 PR Review Comment: https://git.openjdk.org/jdk/pull/17416#discussion_r1475420112 From jbhateja at openjdk.org Fri Feb 2 03:38:04 2024 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Fri, 2 Feb 2024 03:38:04 GMT Subject: RFR: 8318650: Optimized subword gather for x86 targets. [v11] In-Reply-To: References: Message-ID: On Thu, 1 Feb 2024 16:25:52 GMT, Jatin Bhateja wrote: >> I guess the fact that the Java objects are 8 byte alignment padded and the alignment being done at lines 1609-1611 and 1616-1621 somehow takes care of this. > > Hi @sviswa7 , I have rolled back to originally proposed solution. > I don't think Lilliput will relax the array alignment to below 4 bytes since the array length needs to be aligned at that. HI @merykitty Lilliput wiki mention about shrinking object header below 4 bytes in future. https://wiki.openjdk.org/display/lilliput#:~:text=Future%20work%3A%2032%20bit%20or%20even%20smaller%20header%3F%20(If%20so%3A%20improve%20field%20layout%20to%20put%20fields%20in%20unused%20bits%20of%20header%20word) On x86 page size always a power of 2, this along with minimum object size alignment in Java of 8 bytes even 4 bytes should be ok, We are anyway shuffling and extracting the byte / word of interest so any junk data read will be chopped off. But in edge case an overrun may land us into a non accessible address space, so we want to be super safe here. I am also sitting over other solution which is performant. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16354#discussion_r1475481319 From jbhateja at openjdk.org Fri Feb 2 03:38:05 2024 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Fri, 2 Feb 2024 03:38:05 GMT Subject: RFR: 8318650: Optimized subword gather for x86 targets. [v11] In-Reply-To: References: Message-ID: On Wed, 31 Jan 2024 21:29:08 GMT, Sandhya Viswanathan wrote: >> Jatin Bhateja has refreshed the contents of this pull request, and previous commits have been removed. Incremental views are not available. > > src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 1613: > >> 1611: vpand(xtmp, idx_vec, xtmp, vlen_enc); >> 1612: // Load double words from normalized indices. >> 1613: evpgatherdd(dst, gmask, Address(base, xtmp, scale), vlen_enc); > > Considering the byte vector case, could we not do here directly: > evpgatherdd(dst, gmask, Address(base, idx_vec, scale), vlen_enc); > Then we dont need lines 1609-1611 and also 1616-1621 as well. Gathering is happening at doubleword granularity, where as masks are applier over sub-word lanes. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16354#discussion_r1475481601 From duke at openjdk.org Fri Feb 2 04:23:04 2024 From: duke at openjdk.org (duke) Date: Fri, 2 Feb 2024 04:23:04 GMT Subject: Withdrawn: 8320198: some reference processing tests don't wait long enough for reference processing to complete In-Reply-To: <8Gi1trYkUo7x5YiAURAeH3TdzpoJchvmrHyIm2WCHKk=.18df4d76-6ad9-40f9-a079-f271b5cd7272@github.com> References: <8Gi1trYkUo7x5YiAURAeH3TdzpoJchvmrHyIm2WCHKk=.18df4d76-6ad9-40f9-a079-f271b5cd7272@github.com> Message-ID: <1ahhHRyipOIOVBjXn5Cgo-mQIKf81kIjwPOEYopWdqg=.79c8a205-8ef1-44b5-81e4-401a1747cbe8@github.com> On Mon, 4 Dec 2023 17:46:18 GMT, Tom Rodriguez wrote: > This slightly increases the wait for reference processing to complete to accommodate long Xcomp compile times. Testing is underway. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/16956 From qamai at openjdk.org Fri Feb 2 04:50:03 2024 From: qamai at openjdk.org (Quan Anh Mai) Date: Fri, 2 Feb 2024 04:50:03 GMT Subject: RFR: 8318650: Optimized subword gather for x86 targets. [v11] In-Reply-To: References: Message-ID: On Fri, 2 Feb 2024 03:34:38 GMT, Jatin Bhateja wrote: >> Hi @sviswa7 , I have rolled back to originally proposed solution. > >> I don't think Lilliput will relax the array alignment to below 4 bytes since the array length needs to be aligned at that. > > HI @merykitty > > Lilliput wiki mention about shrinking object header below 4 bytes in future. > https://wiki.openjdk.org/display/lilliput#:~:text=Future%20work%3A%2032%20bit%20or%20even%20smaller%20header%3F%20(If%20so%3A%20improve%20field%20layout%20to%20put%20fields%20in%20unused%20bits%20of%20header%20word) > > On x86 page size always a power of 2, this along with minimum object size alignment in JVM (8 bytes even 4 bytes) should be ok, We are anyway shuffling and extracting the byte / word of interest so any junk data read will be chopped off. But in edge case an overrun may land us into a non accessible address space, so we want to be super safe here. I am also sitting over other solution which is performant. Hi @jatin-bhateja, The layout of an array is as follows: [header] - [length] - [data] Since `length` is a 4-byte field, which is 4-byte aligned, in the foreseeable future, even if the `header` is shrunk to below 4 bytes, I don't think `data` can be less than 4-byte aligned. Thanks a lot. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16354#discussion_r1475532720 From duke at openjdk.org Fri Feb 2 04:54:02 2024 From: duke at openjdk.org (jmehrens) Date: Fri, 2 Feb 2024 04:54:02 GMT Subject: RFR: 8324573: HashMap::putAll should resize to sum of both map sizes [v3] In-Reply-To: <2vXbnfpS3bC4hOF68TmibX_HGN5N517KUMjcdD6Tam8=.82f9b370-4928-45a8-850c-e6e55ec26c02@github.com> References: <2vXbnfpS3bC4hOF68TmibX_HGN5N517KUMjcdD6Tam8=.82f9b370-4928-45a8-850c-e6e55ec26c02@github.com> Message-ID: On Sat, 27 Jan 2024 21:58:05 GMT, Joshua Cao wrote: >> src/java.base/share/classes/java/util/HashMap.java line 503: >> >>> 501: */ >>> 502: final void putMapEntries(Map m, boolean evict) { >>> 503: int s = Math.max(size() + m.size(), m.size()); >> >> If we decide this approach is best, shouldn't we do the same for ConcurrentHashMap? > > Sure. Created https://bugs.openjdk.org/browse/JDK-8324798. Won't implement that until this gets merged. Circling back to "the case where many keys exist in both maps". What are your thoughts on some optimized variant/refactoring of: `int s = Math.max(m.size() - this.size(), 1);` This would make it so we aggressively presize when know a large map is being added to a small or empty map. Obviously, if both maps are large and don't contain the same keys this doesn't help. Also, are we sure it is wise to actually call m.size() when we don't know the runtime of the size operation on the given map? The only thing we can reason about is runtime of this.size(). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17544#discussion_r1475534839 From mcimadamore at openjdk.org Fri Feb 2 05:36:01 2024 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Fri, 2 Feb 2024 05:36:01 GMT Subject: RFR: JDK-8325148: Enable restricted javac warning in java.base [v2] In-Reply-To: References: <8zJEeLqHKWm91gZPlYNBVP_5qDXhQgh7g2sWgLXFp3k=.8404dccf-c5a3-4d13-9227-39fc3696f3a5@github.com> Message-ID: <3AB1PLupLZXqHdZuduNyWoVwqRRGJat55gE4rDXAgIQ=.7b6e6c0d-60f2-47fa-bc40-39aaaf77cd1f@github.com> On Thu, 1 Feb 2024 22:19:26 GMT, Joe Darcy wrote: >> The restricted javac warning is disabled for java.base, but could be enabled by suppressing the warning in a handful of files. > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > Add comment highlighting restricted method calls. Looks good - a pity that we cannot disable the warning at the package level - I think it would make sense give blanket approval to the FFM implementation classes. But, even like this it's not too bad. Thanks. ------------- Marked as reviewed by mcimadamore (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17677#pullrequestreview-1858347672 From duke at openjdk.org Fri Feb 2 05:59:01 2024 From: duke at openjdk.org (Joshua Cao) Date: Fri, 2 Feb 2024 05:59:01 GMT Subject: RFR: 8324573: HashMap::putAll should resize to sum of both map sizes [v3] In-Reply-To: References: <2vXbnfpS3bC4hOF68TmibX_HGN5N517KUMjcdD6Tam8=.82f9b370-4928-45a8-850c-e6e55ec26c02@github.com> Message-ID: <9DcaHW_fU1MFA5g0b73CuJ0bTfjkIOGF6e1uIv_7uXk=.abd86cde-5809-43d2-af5a-02780da54150@github.com> On Fri, 2 Feb 2024 04:51:33 GMT, jmehrens wrote: > Circling back to "the case where many keys exist in both maps". What are your thoughts on some optimized variant/refactoring of: int s = Math.max(m.size() - this.size(), 1); Calling `Math.max` is unnecessary here. Its ok if `s` ends up non-positive, presizing would become a no-op in that case. I don't understand why there is a subtraction. If `m` is a larger map than `this`, and has all of `this`'s keys, the resulting map will have the same size as `m`. In this case, we should just presize to `m.size()`. > Also, are we sure it is wise to actually call m.size() when we don't know the runtime of the size operation on the given map? Not sure, but the current code already calls `m.size()`. I can create a `int msize = m.size()` so we only call it once. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17544#discussion_r1475575700 From jbhateja at openjdk.org Fri Feb 2 06:12:02 2024 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Fri, 2 Feb 2024 06:12:02 GMT Subject: RFR: 8318650: Optimized subword gather for x86 targets. [v11] In-Reply-To: References: Message-ID: On Fri, 2 Feb 2024 04:47:22 GMT, Quan Anh Mai wrote: >>> I don't think Lilliput will relax the array alignment to below 4 bytes since the array length needs to be aligned at that. >> >> HI @merykitty >> >> Lilliput wiki mention about shrinking object header below 4 bytes in future. >> https://wiki.openjdk.org/display/lilliput#:~:text=Future%20work%3A%2032%20bit%20or%20even%20smaller%20header%3F%20(If%20so%3A%20improve%20field%20layout%20to%20put%20fields%20in%20unused%20bits%20of%20header%20word) >> >> On x86 page size always a power of 2, this along with minimum object size alignment in JVM (8 bytes even 4 bytes) should be ok, We are anyway shuffling and extracting the byte / word of interest so any junk data read will be chopped off. But in edge case an overrun may land us into a non accessible address space, so we want to be super safe here. I am also sitting over other solution which is performant. > > Hi @jatin-bhateja, > > The layout of an array is as follows: > > [header] - [length] - [data] > > Since `length` is a 4-byte field, which is 4-byte aligned, in the foreseeable future, even if the `header` is shrunk to below 4 bytes, I don't think `data` can be less than 4-byte aligned. > > Thanks a lot. Hi @merykitty , As mentioned earlier, JVM commits heap space in multiple of page sizes and granularity at which a double word gather operates is 4 bytes, thus there may not a chance of going beyond a page boundary while reading a double word from a normalized index which will always begin at byte address multiple of doubleword, @sviswa7's concern was around running into subsequent heap object header (instance / array) in case gather array size is non power of two and a double word read access bytes beyond sub-word array. Default ObjectAlignmentInBytes is 8 bytes and I expect it will never be less than 4 bytes as that is the word size for most of the targets. I am sitting over the performant solution for AVX512 targets. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16354#discussion_r1475582599 From ihse at openjdk.org Fri Feb 2 06:40:01 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 2 Feb 2024 06:40:01 GMT Subject: RFR: 8325109: Sort method modifiers in canonical order In-Reply-To: References: Message-ID: On Thu, 1 Feb 2024 17:21:23 GMT, Joe Darcy wrote: > I just suggest double-checking on the current maintenance procedures for the java.util.concurrent code. @jddarcy Any idea how to do that? I tried searching for JSR-166 and java.util.concurrent, but all I could find was talk about a now-deleted mailing list concurrency-interest, and a link to a [CVS repo for JDK8](http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/jsr166/src/jdk8/java/util/). ------------- PR Comment: https://git.openjdk.org/jdk/pull/17670#issuecomment-1923018074 From ihse at openjdk.org Fri Feb 2 06:55:19 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 2 Feb 2024 06:55:19 GMT Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v7] In-Reply-To: References: Message-ID: > Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK native libraries. Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: Add kludge to BufferedRenderPipe.c for AIX ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17538/files - new: https://git.openjdk.org/jdk/pull/17538/files/eb92119e..3c404183 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17538&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17538&range=05-06 Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/17538.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17538/head:pull/17538 PR: https://git.openjdk.org/jdk/pull/17538 From ihse at openjdk.org Fri Feb 2 06:55:19 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 2 Feb 2024 06:55:19 GMT Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v4] In-Reply-To: <7M86DsSoWaLOQmf_cK6mXD4hTI8NZ356Z7ZRugqETzM=.bb90569d-0386-4498-9f21-d4c7e66f864f@github.com> References: <7M86DsSoWaLOQmf_cK6mXD4hTI8NZ356Z7ZRugqETzM=.bb90569d-0386-4498-9f21-d4c7e66f864f@github.com> Message-ID: On Thu, 1 Feb 2024 15:54:40 GMT, Matthias Baesken wrote: >>> @MBaesken So my fix in [25c691d](https://github.com/openjdk/jdk/pull/17538/commits/25c691df823eb9d9db1451637f28d59dd9508386) did not help? Maybe then it is some other system library that drags in `fcntl.h`; I assumed it was stdlib or stdio. That header file includes way too much that it does not need, so we can surely strip it of even more standard includes if that is what is required to fix this. >> >> >> Unfortunately it did not help. > >> @MBaesken How annoying. :( I have now tried to remove _all_ system includes from `debug_util.h`. Can you please try again building debug on AIX, to see if it works without the `#undef` in `BufferedRenderPipe.c`? > > The AIX (fast)debug build still fails . @MBaesken Ok, I officially give up. :-( I added your patch from https://github.com/openjdk/jdk/pull/17538#issuecomment-1918699480. I agree that it is not elegant, but at least it works. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1923062901 From duke at openjdk.org Fri Feb 2 07:01:05 2024 From: duke at openjdk.org (Sam James) Date: Fri, 2 Feb 2024 07:01:05 GMT Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v7] In-Reply-To: References: Message-ID: On Fri, 2 Feb 2024 06:55:19 GMT, Magnus Ihse Bursie wrote: >> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK native libraries. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Add kludge to BufferedRenderPipe.c for AIX First, huge thanks for doing this. I did have a very rough cut of this locally which I'd put to one side, and you and I have done essentially the same thing (but yours with more tact). That's a positive sign. > > Can you confirm that you've run tier1-4 at least? Some of the library code that is changed here is not tested in the lower tiers. > > I have run tier1-4 now, and it passes (bar the tests that are currently failing in mainline). However, this only tests 64-bit builds, and these changes do not affect 64-bit builds, only 32-bit linux. So the tier1-4 is more of a sanity check that I did not inadvertenly broke any 64-bit code. > > To really test that this works properly, a 32-bit linux with an assortment of operations on > 2GB files would be needed. To the best of my knowledge, we have no such test environment available, and I could not even try to think of how to create such a test setup that does anything useful. (That is, if I even were to spend any time on creating new tests for 32-bit platforms...) Yeah, let's not, I think. The only way of doing this is with libc shims and a huge mess. As long as we have tests which handle > 2GB files in general, and then also we can get someone to run this on a 32-bit system and tell us if the test suite passes as-is, then we're fine. Really, even if it builds on a 32-bit system with strict `-Werror=x` for pointer conversions and such, then we're OK. I'll leave comments inline for the rest. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1923093781 From duke at openjdk.org Fri Feb 2 07:05:07 2024 From: duke at openjdk.org (Sam James) Date: Fri, 2 Feb 2024 07:05:07 GMT Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v7] In-Reply-To: References: Message-ID: On Fri, 2 Feb 2024 06:55:19 GMT, Magnus Ihse Bursie wrote: >> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK native libraries. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Add kludge to BufferedRenderPipe.c for AIX make/modules/jdk.hotspot.agent/Lib.gmk line 31: > 29: > 30: ifeq ($(call isTargetOs, linux), true) > 31: SA_CFLAGS := -D_FILE_OFFSET_BITS=64 We have two choices to feel a bit more comfortable: 1) We unconditionally `static_assert` in a few places for large `off_t`, or 2) We only do it for platforms we know definitely support F_O_B and aren't AIX (which we've handled separately). Not sure that's strictly necessary though. Also, if something understands LARGEFILE*_SOURCE, then it probably understood F_O_B, or at least has some macro to control it. Just thinking aloud. src/java.base/linux/native/libnio/ch/FileDispatcherImpl.c line 94: > 92: return IOS_UNSUPPORTED_CASE; > 93: > 94: loff_t offset = (loff_t)position; Is this `loff_t` for the benefit of `copy_file_range`? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17538#discussion_r1475635336 PR Review Comment: https://git.openjdk.org/jdk/pull/17538#discussion_r1475636686 From duke at openjdk.org Fri Feb 2 07:10:07 2024 From: duke at openjdk.org (Sam James) Date: Fri, 2 Feb 2024 07:10:07 GMT Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v7] In-Reply-To: References: Message-ID: On Fri, 2 Feb 2024 06:55:19 GMT, Magnus Ihse Bursie wrote: >> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK native libraries. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Add kludge to BufferedRenderPipe.c for AIX src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c line 365: > 363: #else > 364: // Make sure we link to the 64-bit version of the functions > 365: my_openat_func = (openat_func*) dlsym(RTLD_DEFAULT, "openat64"); Explain this part to me, if you wouldn't mind? (Why do we keep the `64` variants?) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17538#discussion_r1475642841 From pminborg at openjdk.org Fri Feb 2 07:26:01 2024 From: pminborg at openjdk.org (Per Minborg) Date: Fri, 2 Feb 2024 07:26:01 GMT Subject: RFR: JDK-8325148: Enable restricted javac warning in java.base [v2] In-Reply-To: References: <8zJEeLqHKWm91gZPlYNBVP_5qDXhQgh7g2sWgLXFp3k=.8404dccf-c5a3-4d13-9227-39fc3696f3a5@github.com> Message-ID: <1F2_HcNM-D5F0nOFXlBpBRbPpFQKPPUJxYMoKw4k7Ho=.7c11c0b1-5f4d-475c-b111-e2b0ed207e48@github.com> On Thu, 1 Feb 2024 22:19:26 GMT, Joe Darcy wrote: >> The restricted javac warning is disabled for java.base, but could be enabled by suppressing the warning in a handful of files. > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > Add comment highlighting restricted method calls. Nice fix. Thanks. ------------- Marked as reviewed by pminborg (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17677#pullrequestreview-1858547285 From pminborg at openjdk.org Fri Feb 2 07:41:16 2024 From: pminborg at openjdk.org (Per Minborg) Date: Fri, 2 Feb 2024 07:41:16 GMT Subject: RFR: 8323746: Add PathElement hashCode and equals [v2] In-Reply-To: References: Message-ID: > This PR proposes to implement `hashCode()` and `equals()` methods for implementations of `PathElement`. > > In doing so, the previous `PathElementImpl` was removed and replaced in favor of distinct `record` implementations, each reflecting its own path element selection type. This also allowed the `PathKind` to be removed as this piece of information is now carried in the sealed type hierarchy. > > It is worth noting, the implementations resides in the `jdk.internal` package and consequently, they are not exposed to clients. So, we could use pattern matching (for example) internally but not in client code. Per Minborg has updated the pull request incrementally with one additional commit since the last revision: Make all PathElements records ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17651/files - new: https://git.openjdk.org/jdk/pull/17651/files/af7fa99d..5685e31a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17651&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17651&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/17651.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17651/head:pull/17651 PR: https://git.openjdk.org/jdk/pull/17651 From redestad at openjdk.org Fri Feb 2 12:30:00 2024 From: redestad at openjdk.org (Claes Redestad) Date: Fri, 2 Feb 2024 12:30:00 GMT Subject: RFR: 8321468: Remove StringUTF16::equals In-Reply-To: References: Message-ID: <4uEu7i9FQoNW8OSV-CaTvINOHXPfhoBSFx4pXygZTec=.92203df2-18b1-4697-942a-7424c43bbc95@github.com> On Wed, 6 Dec 2023 14:20:14 GMT, Claes Redestad wrote: > https://bugs.openjdk.org/browse/JDK-8215017 removed the only use of `StringUTF16::equals`. At the time I did some performance verification focused on x86 showing that simplifying and only using `StringLatin1::equals` was either neutral or a win. > > I repeated this experiment recently, adding some focused tests on aarch64 where the code generation actually tries to take advantage and generate slightly more efficient code for `StringUTF16::equals`: > https://github.com/openjdk/jdk/pull/16933#discussion_r1414118658 > > The indication here is that disabling use of `StringUTF16::equals` was the right choice: any effect from the low-level optimization (one less branch at the tail end) was offset by the `isLatin1()` branch and added code generation (that all gets inlined). > > In a `-XX:-CompactStrings` configuration the slightly improved code generation in `StringUTF16::equals` might help, since the `isLatin1()` test and subsequent call to `StringLatin1::equals` would be DCEd. To get the best of both worlds the code in `String::equals` _could_ be sharpened so that we statically pick the best implementation based on `CompactStrings` mode (see comment below). This shows a tiny win when testing with `-XX:-CompactStrings` on M1 (up to -0.2ns/op per `String::equals`; neutral on x86). But is all this complexity worth it for a gain that will get lost in the noise on anything realistic? > > This PR instead proposes removing `StringUTF16::equals` and simplifying the mechanisms to support the `StringLatin1/UTF16::equals` pair of intrinsics in hotspot. Can I please get a review for this cleanup? This PR does not cause a regression to `-XX:-CompactStrings`; a very minor regression as detailed in comments was caused by https://bugs.openjdk.org/browse/JDK-8215017 -- If this regression is a real concern we can recuperate this by making the emitted intrinsics use `-CompactStrings` as a signal to optimize away the one-byte tail checks in a follow-up PR. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16995#issuecomment-1923705005 From jai.forums2013 at gmail.com Fri Feb 2 13:35:26 2024 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Fri, 2 Feb 2024 19:05:26 +0530 Subject: The common ForkJoinPool does not have any ForkJoinWorkerThread while tasks are submitted to the queue In-Reply-To: References: Message-ID: Hello Xiao, I don't have enough knowledge of this area to provide any insight into the issue. However, just to try and get the discussion started, do you have any sample code of your application which shows how the application uses the ForkJoinPool? More specifically what APIs do you use in the application? Few other questions inline below. On 12/01/24 11:30 am, Xiao Yu wrote: > .... > Here is the full background. One of our process experienced an OOME > and a heap > dump was obtained. We know there was a concurrent issue of our system > happening > on some other machines such that network failure and retries occurred > in this > process at the same time. Upon analyzing the heap dump, we observed a > lot of > our network connection handlers being frequently created and > terminated which > is expected due to the network failure and retry attempts mentioned above. > However, those terminated handlers are not being GC'ed because of > there were > references to tasks submitted to the ForkJoinPool during the connection > attempts. The tasks stayed in the queue until OOME happened as there is no > threads to execute them. What are these handlers? Are they classes which implement Runnable or are they something else? What does termination of handler mean in this context? Do you use any java.util.concurrent.* APIs to "cancel" such terminated handlers? Finally, what does the OutOfMemoryError exception stacktrace look like and what is the JVM parameters (heap size for example) used to launch this application? -Jaikiran From duke at openjdk.org Fri Feb 2 14:18:12 2024 From: duke at openjdk.org (duke) Date: Fri, 2 Feb 2024 14:18:12 GMT Subject: Withdrawn: JDK-8316708: Augment WorstCaseTests with more cases In-Reply-To: References: Message-ID: On Fri, 22 Sep 2023 05:36:02 GMT, Joe Darcy wrote: > A new paper > > "Accuracy of Mathematical Functions in Single, Double, Double Extended, and Quadruple Precision" > by Brian Gladman, Vincenzo Innocente and Paul Zimmermann > https://members.loria.fr/PZimmermann/papers/accuracy.pdf > > details the inputs with generate the worst-case observed errors in different math library implementations. The FDLIBM-related worst cases should be added to the test suite. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/15879 From rgiulietti at openjdk.org Fri Feb 2 14:48:06 2024 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Fri, 2 Feb 2024 14:48:06 GMT Subject: RFR: JDK-8316708: Augment WorstCaseTests with more cases In-Reply-To: References: Message-ID: On Fri, 22 Sep 2023 05:36:02 GMT, Joe Darcy wrote: > A new paper > > "Accuracy of Mathematical Functions in Single, Double, Double Extended, and Quadruple Precision" > by Brian Gladman, Vincenzo Innocente and Paul Zimmermann > https://members.loria.fr/PZimmermann/papers/accuracy.pdf > > details the inputs with generate the worst-case observed errors in different math library implementations. The FDLIBM-related worst cases should be added to the test suite. ping... ------------- PR Comment: https://git.openjdk.org/jdk/pull/15879#issuecomment-1924027940 From rriggs at openjdk.org Fri Feb 2 14:56:01 2024 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 2 Feb 2024 14:56:01 GMT Subject: RFR: 8321468: Remove StringUTF16::equals In-Reply-To: References: Message-ID: On Wed, 6 Dec 2023 14:20:14 GMT, Claes Redestad wrote: > https://bugs.openjdk.org/browse/JDK-8215017 removed the only use of `StringUTF16::equals`. At the time I did some performance verification focused on x86 showing that simplifying and only using `StringLatin1::equals` was either neutral or a win. > > I repeated this experiment recently, adding some focused tests on aarch64 where the code generation actually tries to take advantage and generate slightly more efficient code for `StringUTF16::equals`: > https://github.com/openjdk/jdk/pull/16933#discussion_r1414118658 > > The indication here is that disabling use of `StringUTF16::equals` was the right choice: any effect from the low-level optimization (one less branch at the tail end) was offset by the `isLatin1()` branch and added code generation (that all gets inlined). > > In a `-XX:-CompactStrings` configuration the slightly improved code generation in `StringUTF16::equals` might help, since the `isLatin1()` test and subsequent call to `StringLatin1::equals` would be DCEd. To get the best of both worlds the code in `String::equals` _could_ be sharpened so that we statically pick the best implementation based on `CompactStrings` mode (see comment below). This shows a tiny win when testing with `-XX:-CompactStrings` on M1 (up to -0.2ns/op per `String::equals`; neutral on x86). But is all this complexity worth it for a gain that will get lost in the noise on anything realistic? > > This PR instead proposes removing `StringUTF16::equals` and simplifying the mechanisms to support the `StringLatin1/UTF16::equals` pair of intrinsics in hotspot. LGTM for the core-libs point of view. (And what I understand of the assembler) ------------- Marked as reviewed by rriggs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16995#pullrequestreview-1859448983 From redestad at openjdk.org Fri Feb 2 14:59:11 2024 From: redestad at openjdk.org (Claes Redestad) Date: Fri, 2 Feb 2024 14:59:11 GMT Subject: RFR: 8325169: Reduce String::indexOf overheads Message-ID: This patch streamlines and specializes various `String::indexOf` methods. Mainly avoids the need for clamping and doing checks that are redundant in almost all cases, moving the checks to the API boundary where they are needed. This improves performance both at peak and during startup/warmup. Since indexOf is heavily used in bootstrapping code it makes sense to slightly dial back abstraction and delegation, which in this case also brought some benefit to peak performance. Testing: tier1-3 ------------- Commit messages: - Reduce String.indexOf overheads Changes: https://git.openjdk.org/jdk/pull/17685/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17685&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8325169 Stats: 36 lines in 4 files changed: 17 ins; 15 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/17685.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17685/head:pull/17685 PR: https://git.openjdk.org/jdk/pull/17685 From redestad at openjdk.org Fri Feb 2 14:59:11 2024 From: redestad at openjdk.org (Claes Redestad) Date: Fri, 2 Feb 2024 14:59:11 GMT Subject: RFR: 8325169: Reduce String::indexOf overheads In-Reply-To: References: Message-ID: On Fri, 2 Feb 2024 13:54:46 GMT, Claes Redestad wrote: > This patch streamlines and specializes various `String::indexOf` methods. Mainly avoids the need for clamping and doing checks that are redundant in almost all cases, moving the checks to the API boundary where they are needed. > > This improves performance both at peak and during startup/warmup. Since indexOf is heavily used in bootstrapping code it makes sense to slightly dial back abstraction and delegation, which in this case also brought some benefit to peak performance. > > Testing: tier1-3 M1 MacBook: ```Name Cnt Base Error Test Error Unit Change StringIndexOf.searchChar16LongSuccess 5 14,909 ? 3,284 14,480 ? 0,256 ns/op 1,03x (p = 0,324 ) StringIndexOf.searchChar16LongWithOffsetSuccess 5 14,715 ? 0,870 14,373 ? 0,382 ns/op 1,02x (p = 0,024 ) StringIndexOf.searchChar16MediumSuccess 5 6,611 ? 0,016 6,476 ? 0,050 ns/op 1,02x (p = 0,000*) StringIndexOf.searchChar16MediumWithOffsetSuccess 5 7,151 ? 0,026 6,884 ? 0,014 ns/op 1,04x (p = 0,000*) StringIndexOf.searchChar16ShortSuccess 5 2,667 ? 0,007 2,369 ? 0,005 ns/op 1,13x (p = 0,000*) StringIndexOf.searchChar16ShortWithOffsetSuccess 5 2,494 ? 0,112 2,102 ? 0,006 ns/op 1,19x (p = 0,000*) StringIndexOf.searchCharLongSuccess 5 5,995 ? 0,017 5,276 ? 0,017 ns/op 1,14x (p = 0,000*) StringIndexOf.searchCharLongWithOffsetSuccess 5 6,377 ? 0,118 5,735 ? 0,014 ns/op 1,11x (p = 0,000*) StringIndexOf.searchCharMediumSuccess 5 2,350 ? 0,013 1,927 ? 0,012 ns/op 1,22x (p = 0,000*) StringIndexOf.searchCharMediumWithOffsetSuccess 5 2,675 ? 0,002 2,247 ? 0,057 ns/op 1,19x (p = 0,000*) StringIndexOf.searchCharShortSuccess 5 1,719 ? 0,002 1,245 ? 0,005 ns/op 1,38x (p = 0,000*) StringIndexOf.searchCharShortWithOffsetSuccess 5 1,635 ? 0,006 1,247 ? 0,009 ns/op 1,31x (p = 0,000*) * = significant `-Xint`, M1 MacBook: ```Name Cnt Base Error Test Error Unit Change StringIndexOf.searchChar16LongSuccess 5 4683,186 ? 6,431 4482,179 ? 26,216 ns/op 1,04x (p = 0,000*) StringIndexOf.searchChar16LongWithOffsetSuccess 5 4586,540 ? 39,266 4403,976 ? 18,652 ns/op 1,04x (p = 0,000*) StringIndexOf.searchChar16MediumSuccess 5 2123,355 ? 3,885 1942,100 ? 77,042 ns/op 1,09x (p = 0,000*) StringIndexOf.searchChar16MediumWithOffsetSuccess 5 2007,646 ? 52,087 1859,545 ? 67,424 ns/op 1,08x (p = 0,000*) StringIndexOf.searchChar16ShortSuccess 5 548,599 ? 3,048 386,671 ? 60,860 ns/op 1,42x (p = 0,000*) StringIndexOf.searchChar16ShortWithOffsetSuccess 5 459,164 ? 5,782 302,377 ? 39,086 ns/op 1,52x (p = 0,000*) StringIndexOf.searchCharLongSuccess 5 908,953 ? 78,580 799,114 ? 34,290 ns/op 1,14x (p = 0,000*) StringIndexOf.searchCharLongWithOffsetSuccess 5 855,726 ? 28,357 790,690 ? 19,452 ns/op 1,08x (p = 0,000*) StringIndexOf.searchCharMediumSuccess 5 360,903 ? 3,214 262,320 ? 1,706 ns/op 1,38x (p = 0,000*) StringIndexOf.searchCharMediumWithOffsetSuccess 5 322,950 ? 5,790 268,992 ? 8,008 ns/op 1,20x (p = 0,000*) StringIndexOf.searchCharShortSuccess 5 274,718 ? 7,208 174,274 ? 3,445 ns/op 1,58x (p = 0,000*) StringIndexOf.searchCharShortWithOffsetSuccess 5 254,141 ? 11,992 186,917 ? 11,471 ns/op 1,36x (p = 0,000*) * = significant ------------- PR Comment: https://git.openjdk.org/jdk/pull/17685#issuecomment-1923869466 From redestad at openjdk.org Fri Feb 2 15:00:09 2024 From: redestad at openjdk.org (Claes Redestad) Date: Fri, 2 Feb 2024 15:00:09 GMT Subject: RFR: 8321468: Remove StringUTF16::equals In-Reply-To: References: Message-ID: On Fri, 2 Feb 2024 14:53:51 GMT, Roger Riggs wrote: > LGTM for the core-libs point of view. (And what I understand of the assembler) Thanks! I'll try to get someone from the compiler team to look over the assembler change. @TobiHartmann, can you help get some eyes on this? ------------- PR Comment: https://git.openjdk.org/jdk/pull/16995#issuecomment-1924049126 From ihse at openjdk.org Fri Feb 2 15:27:12 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 2 Feb 2024 15:27:12 GMT Subject: RFR: 8325163: Enable -Wpedantic on clang Message-ID: Inspired by (the later backed-out) [JDK-8296115](https://bugs.openjdk.org/browse/JDK-8296115), I propose to enable `-Wpedantic` for clang. This has already found some irregularities in the code, like mistakenly using `#import` instead of `#include`. In this patch, I disable warnings for these individual buggy or badly written files, but I intend to post follow-up issues on the respective teams to have them properly fixed. Unfortunately, it is not possible to enable `-Wpedantic` on gcc, since individual warnings in `-Wpedantic` cannot be disabled. This means that code like this: #define DEBUG_ONLY(code) code; DEBUG_ONLY(foo()); will result in a `; ;`. This breaks the C standard, but is benign, and we use it all over the place. On clang, we can ignore this by `-Wno-extra-semi`, but this is not available on gcc. ------------- Commit messages: - 8325163: Enable -Wpedantic on clang Changes: https://git.openjdk.org/jdk/pull/17687/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17687&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8325163 Stats: 43 lines in 11 files changed: 31 ins; 0 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/17687.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17687/head:pull/17687 PR: https://git.openjdk.org/jdk/pull/17687 From ihse at openjdk.org Fri Feb 2 15:48:00 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 2 Feb 2024 15:48:00 GMT Subject: RFR: JDK-8325148: Enable restricted javac warning in java.base [v2] In-Reply-To: References: <8zJEeLqHKWm91gZPlYNBVP_5qDXhQgh7g2sWgLXFp3k=.8404dccf-c5a3-4d13-9227-39fc3696f3a5@github.com> Message-ID: On Thu, 1 Feb 2024 22:19:26 GMT, Joe Darcy wrote: >> The restricted javac warning is disabled for java.base, but could be enabled by suppressing the warning in a handful of files. > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > Add comment highlighting restricted method calls. Great, thanks for cleaning up! ------------- Marked as reviewed by ihse (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17677#pullrequestreview-1859561572 From ihse at openjdk.org Fri Feb 2 15:53:07 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 2 Feb 2024 15:53:07 GMT Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v7] In-Reply-To: References: Message-ID: <160IUiEFfgHTenlTpN4C2yL2oMdZPpV1fsK0YysXcr8=.cf71797d-9e10-4713-804e-368b481efde0@github.com> On Fri, 2 Feb 2024 07:02:43 GMT, Sam James wrote: >> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: >> >> Add kludge to BufferedRenderPipe.c for AIX > > src/java.base/linux/native/libnio/ch/FileDispatcherImpl.c line 94: > >> 92: return IOS_UNSUPPORTED_CASE; >> 93: >> 94: loff_t offset = (loff_t)position; > > Is this `loff_t` for the benefit of `copy_file_range`? That is how copy_file_range is defined. The cast to off64_t was technically incorrect (but they ended up being the same type). > src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c line 365: > >> 363: #else >> 364: // Make sure we link to the 64-bit version of the functions >> 365: my_openat_func = (openat_func*) dlsym(RTLD_DEFAULT, "openat64"); > > Explain this part to me, if you wouldn't mind? (Why do we keep the `64` variants?) I wrote earlier: > There is one change that merit highlighting: In src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c, I kept the dlsym lookup for openat64, fstatat64 and fdopendir64, on non-BSD OSes (i.e. Linux and AIX), and on AIX, respectively. This seems to me to be the safest choice, as we do not need to know if a lookup of openat would yield a 32-bit or a 64-bit version. (I frankly don't know, but I'm guessing it would yield the 32-bit version.) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17538#discussion_r1476232283 PR Review Comment: https://git.openjdk.org/jdk/pull/17538#discussion_r1476229335 From ihse at openjdk.org Fri Feb 2 15:53:08 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 2 Feb 2024 15:53:08 GMT Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v7] In-Reply-To: <160IUiEFfgHTenlTpN4C2yL2oMdZPpV1fsK0YysXcr8=.cf71797d-9e10-4713-804e-368b481efde0@github.com> References: <160IUiEFfgHTenlTpN4C2yL2oMdZPpV1fsK0YysXcr8=.cf71797d-9e10-4713-804e-368b481efde0@github.com> Message-ID: On Fri, 2 Feb 2024 15:48:04 GMT, Magnus Ihse Bursie wrote: >> src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c line 365: >> >>> 363: #else >>> 364: // Make sure we link to the 64-bit version of the functions >>> 365: my_openat_func = (openat_func*) dlsym(RTLD_DEFAULT, "openat64"); >> >> Explain this part to me, if you wouldn't mind? (Why do we keep the `64` variants?) > > I wrote earlier: > >> There is one change that merit highlighting: In src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c, I kept the dlsym lookup for openat64, fstatat64 and fdopendir64, on non-BSD OSes (i.e. Linux and AIX), and on AIX, respectively. This seems to me to be the safest choice, as we do not need to know if a lookup of openat would yield a 32-bit or a 64-bit version. (I frankly don't know, but I'm guessing it would yield the 32-bit version.) Basically, my understanding is that a call to "openat" in the source file will be converted into a call to openat64 on 32-bit platforms. When we look up the function using dlsym, I assume we need to find the 64-bit version directly. Even if this is incorrect, it seems at least *safe* to do it this way. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17538#discussion_r1476231574 From ihse at openjdk.org Fri Feb 2 15:57:07 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 2 Feb 2024 15:57:07 GMT Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v7] In-Reply-To: References: Message-ID: On Fri, 2 Feb 2024 07:01:33 GMT, Sam James wrote: >> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: >> >> Add kludge to BufferedRenderPipe.c for AIX > > make/modules/jdk.hotspot.agent/Lib.gmk line 31: > >> 29: >> 30: ifeq ($(call isTargetOs, linux), true) >> 31: SA_CFLAGS := -D_FILE_OFFSET_BITS=64 > > We have two choices to feel a bit more comfortable: > 1) We unconditionally `static_assert` in a few places for large `off_t`, or > 2) We only do it for platforms we know definitely support F_O_B and aren't AIX (which we've handled separately). > > Not sure that's strictly necessary though. Also, if something understands LARGEFILE*_SOURCE, then it probably understood F_O_B, or at least has some macro to control it. Just thinking aloud. I'm guessing your comment was really more general, and just happened to be placed here? The reason I am removing `-D_FILE_OFFSET_BITS=64` here is that it is always set for all JDK compilations. 1. I don't know why you would not trust that compiler flags in the build system would work, but if you really want to add a static_assert, let me know where you want it. 2. No, AIX is not handled separately. It is handled as part of this PR. You are probably thinking about JDK-8324834, but that was only about Hotspot. This PR is about all the other JDK native libraries. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17538#discussion_r1476236956 From jwaters at openjdk.org Fri Feb 2 15:58:00 2024 From: jwaters at openjdk.org (Julian Waters) Date: Fri, 2 Feb 2024 15:58:00 GMT Subject: RFR: 8325163: Enable -Wpedantic on clang In-Reply-To: References: Message-ID: On Fri, 2 Feb 2024 15:22:03 GMT, Magnus Ihse Bursie wrote: > Inspired by (the later backed-out) [JDK-8296115](https://bugs.openjdk.org/browse/JDK-8296115), I propose to enable `-Wpedantic` for clang. This has already found some irregularities in the code, like mistakenly using `#import` instead of `#include`. In this patch, I disable warnings for these individual buggy or badly written files, but I intend to post follow-up issues on the respective teams to have them properly fixed. > > Unfortunately, it is not possible to enable `-Wpedantic` on gcc, since individual warnings in `-Wpedantic` cannot be disabled. This means that code like this: > > > #define DEBUG_ONLY(code) code; > > DEBUG_ONLY(foo()); > > > will result in a `; ;`. This breaks the C standard, but is benign, and we use it all over the place. On clang, we can ignore this by `-Wno-extra-semi`, but this is not available on gcc. +++++1 for this, anything to help Standard conformance is great! Just a few questions... ------------- PR Comment: https://git.openjdk.org/jdk/pull/17687#issuecomment-1924155329 From jwaters at openjdk.org Fri Feb 2 16:03:01 2024 From: jwaters at openjdk.org (Julian Waters) Date: Fri, 2 Feb 2024 16:03:01 GMT Subject: RFR: 8325163: Enable -Wpedantic on clang In-Reply-To: References: Message-ID: On Fri, 2 Feb 2024 15:22:03 GMT, Magnus Ihse Bursie wrote: > Inspired by (the later backed-out) [JDK-8296115](https://bugs.openjdk.org/browse/JDK-8296115), I propose to enable `-Wpedantic` for clang. This has already found some irregularities in the code, like mistakenly using `#import` instead of `#include`. In this patch, I disable warnings for these individual buggy or badly written files, but I intend to post follow-up issues on the respective teams to have them properly fixed. > > Unfortunately, it is not possible to enable `-Wpedantic` on gcc, since individual warnings in `-Wpedantic` cannot be disabled. This means that code like this: > > > #define DEBUG_ONLY(code) code; > > DEBUG_ONLY(foo()); > > > will result in a `; ;`. This breaks the C standard, but is benign, and we use it all over the place. On clang, we can ignore this by `-Wno-extra-semi`, but this is not available on gcc. Guess I could work on the gcc counterpart and find a way around the inability to disable -Wpedantic with it in tandem with this change... ------------- PR Comment: https://git.openjdk.org/jdk/pull/17687#issuecomment-1924163226 From duke at openjdk.org Fri Feb 2 16:25:02 2024 From: duke at openjdk.org (ExE Boss) Date: Fri, 2 Feb 2024 16:25:02 GMT Subject: RFR: 8325169: Reduce String::indexOf overheads In-Reply-To: References: Message-ID: On Fri, 2 Feb 2024 13:54:46 GMT, Claes Redestad wrote: > This patch streamlines and specializes various `String::indexOf` methods. Mainly avoids the need for clamping and doing checks that are redundant in almost all cases, moving the checks to the API boundary where they are needed. > > This improves performance both at peak and during startup/warmup. Since indexOf is heavily used in bootstrapping code it makes sense to slightly dial back abstraction and delegation, which in this case also brought some benefit to peak performance. > > Testing: tier1-3 src/java.base/share/classes/java/lang/String.java line 2506: > 2504: fromIndex = Math.max(0, fromIndex); > 2505: return isLatin1() ? StringLatin1.indexOf(value, ch, fromIndex, value.length) > 2506: : StringUTF16.indexOf(value, ch, fromIndex, value.length >> 1); This?needs to?include the?check for?`fromIndex >=?this.length()`: Suggestion: fromIndex = Math.max(0, fromIndex); int toIndex = length(); if (fromIndex >= toIndex) { return -1; } return isLatin1() ? StringLatin1.indexOf(value, ch, fromIndex, toIndex) : StringUTF16.indexOf(value, ch, fromIndex, toIndex); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17685#discussion_r1476268336 From rgiulietti at openjdk.org Fri Feb 2 16:43:01 2024 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Fri, 2 Feb 2024 16:43:01 GMT Subject: RFR: 8325169: Reduce String::indexOf overheads In-Reply-To: References: Message-ID: <3Bd_zBors5V8_uHwG3VE_HzDICmStS9hCn-fNU96MvM=.c8421d00-56fb-4f0f-8d44-17c616ca9c57@github.com> On Fri, 2 Feb 2024 16:20:21 GMT, ExE Boss wrote: >> This patch streamlines and specializes various `String::indexOf` methods. Mainly avoids the need for clamping and doing checks that are redundant in almost all cases, moving the checks to the API boundary where they are needed. >> >> This improves performance both at peak and during startup/warmup. Since indexOf is heavily used in bootstrapping code it makes sense to slightly dial back abstraction and delegation, which in this case also brought some benefit to peak performance. >> >> Testing: tier1-3 > > src/java.base/share/classes/java/lang/String.java line 2506: > >> 2504: fromIndex = Math.max(0, fromIndex); >> 2505: return isLatin1() ? StringLatin1.indexOf(value, ch, fromIndex, value.length) >> 2506: : StringUTF16.indexOf(value, ch, fromIndex, value.length >> 1); > > This?needs to?include the?check for?`fromIndex >=?this.length()`: > Suggestion: > > fromIndex = Math.max(0, fromIndex); > int toIndex = length(); > if (fromIndex >= toIndex) { > return -1; > } > return isLatin1() > ? StringLatin1.indexOf(value, ch, fromIndex, toIndex) > : StringUTF16.indexOf(value, ch, fromIndex, toIndex); I don't think so. If you deeply follow the invoked `indexOf()` methods, there's either a check later, or the loop conditions are false on entry (although I'm not sure about the intrinsic methods). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17685#discussion_r1476293651 From bpb at openjdk.org Fri Feb 2 16:48:12 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 2 Feb 2024 16:48:12 GMT Subject: RFR: 8325152: Clarify specification of java.io.RandomAccessFile.setLength [v2] In-Reply-To: <6s1H_WwYoHtrO9N7-BhmsW6HvUhdtJUYzQyxJMeu3DI=.73712304-befe-4da2-8243-328774f9724f@github.com> References: <6s1H_WwYoHtrO9N7-BhmsW6HvUhdtJUYzQyxJMeu3DI=.73712304-befe-4da2-8243-328774f9724f@github.com> Message-ID: <6DdY9lGZB6YXCpyRsChm4F4R_PuUyvfQTa3jpiem1Ow=.5785f651-cf22-47e4-ac6e-d173436b5744@github.com> > Modify the specification verbiage of `java.io.RandomAccessFile.setLength` to account for the effect of the method on the file offset as returned by `getFilePointer`. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8325152: Minor change to paragraph about file offset ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17679/files - new: https://git.openjdk.org/jdk/pull/17679/files/80e562f9..5eaa8dda Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17679&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17679&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/17679.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17679/head:pull/17679 PR: https://git.openjdk.org/jdk/pull/17679 From duke at openjdk.org Fri Feb 2 16:57:08 2024 From: duke at openjdk.org (Srinivas Vamsi Parasa) Date: Fri, 2 Feb 2024 16:57:08 GMT Subject: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort) [v11] In-Reply-To: <9q8Gg6DQnrf0HLW3oxwfpoUP9639drr1BIQMc1rxDFo=.eb4ea73c-b632-446a-8d50-b51838f67f69@github.com> References: <918oCEfFu2JweXfV-afD1l_AGDDuc7dJwAxip-Ze6ZI=.8d5e9692-23db-47e4-9586-99e53b9cfbb6@github.com> <-bYhysKjQVb_ZS0I0YutJZ7umfYwbs74rtK6-d2qL9U=.f9981e59-f0c4-48f3-ad7e-5627aad00919@github.com> <91Zv361kqKOjCSJPu20-yhKOb4lBIZVyVTm9f79dkcQ=.745c271d-3cb1-4ff3-9d71-5cad85ff4f14@github.com> <9q8Gg6DQnrf0HLW3oxwfpoUP9639drr1BIQMc1rxDFo=.eb4ea73c-b632-446a-8d50-b51838f67f69@github.com> Message-ID: On Sun, 28 Jan 2024 22:23:38 GMT, Vladimir Yaroslavskiy wrote: >> Hi Vladimir (@iaroslavski), >> >> Please see the JMH data below. >> >> Thanks, >> Vamsi >> >> Benchmark (builder) (size) Mode Cnt Score Error Units >> ArraysSort.Int.a15 RANDOM 600 avgt 4 7.096 ? 0.081 us/op >> ArraysSort.Int.a15 RANDOM 2000 avgt 4 44.014 ? 1.717 us/op >> ArraysSort.Int.a15 RANDOM 90000 avgt 4 4451.444 ? 71.168 us/op >> ArraysSort.Int.a15 RANDOM 400000 avgt 4 22751.966 ? 683.597 us/op >> ArraysSort.Int.a15 RANDOM 3000000 avgt 4 190326.306 ? 8008.512 us/op >> ArraysSort.Int.a15 REPEATED 600 avgt 4 1.044 ? 0.016 us/op >> ArraysSort.Int.a15 REPEATED 2000 avgt 4 2.272 ? 0.287 us/op >> ArraysSort.Int.a15 REPEATED 90000 avgt 4 412.331 ? 11.656 us/op >> ArraysSort.Int.a15 REPEATED 400000 avgt 4 1908.978 ? 30.241 us/op >> ArraysSort.Int.a15 REPEATED 3000000 avgt 4 15163.443 ? 100.425 us/op >> ArraysSort.Int.a15 STAGGER 600 avgt 4 1.055 ? 0.057 us/op >> ArraysSort.Int.a15 STAGGER 2000 avgt 4 3.408 ? 0.096 us/op >> ArraysSort.Int.a15 STAGGER 90000 avgt 4 149.220 ? 4.022 us/op >> ArraysSort.Int.a15 STAGGER 400000 avgt 4 663.096 ? 30.252 us/op >> ArraysSort.Int.a15 STAGGER 3000000 avgt 4 5206.890 ? 234.857 us/op >> ArraysSort.Int.a15 SHUFFLE 600 avgt 4 4.611 ? 0.118 us/op >> ArraysSort.Int.a15 SHUFFLE 2000 avgt 4 17.955 ? 0.356 us/op >> ArraysSort.Int.a15 SHUFFLE 90000 avgt 4 1410.357 ? 41.128 us/op >> ArraysSort.Int.a15 SHUFFLE 400000 avgt 4 5739.311 ? 128.270 us/op >> ArraysSort.Int.a15 SHUFFLE 3000000 avgt 4 41501.980 ? 829.443 us/op >> ArraysSort.Int.jdk RANDOM 600 avgt 4 1.612 ? 0.088 us/op >> ArraysSort.Int.jdk RANDOM 2000 avgt 4 6.893 ? 0.375 us/op >> ArraysSort.Int.jdk RANDOM 90000 avgt 4 522.749 ? 19.386 us/op >> ArraysSort.Int.jdk RANDOM 400000 avgt 4 2424.204 ? 63.844 us/op >> ArraysSort.Int.jdk RANDOM 3000000 avgt 4 21000.434 ? 801.315 us/op >> ArraysSort.Int.jdk REPEATED 600 avgt 4 0.496 ? 0.030 us/op >> ArraysSort.Int.jdk REPEATED 2000 avgt 4 1.037 ? 0.083 us/op >> ArraysSort.Int.jdk REPE... > > Hi Vamsi (@vamsi-parasa), Laurent(@bourgesl), > > The latest benchmarking compares compares the following versions: > jdk - direct call of Arrays.sort(); > a15 - the current source of DualPivotQuicksort from the latest build (except renaming) > https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/DualPivotQuicksort.java > https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_a15.java > r20s - new version without Radix sort > r20p - new version with Radix sort in parallel case only > > It is expected that timing of jdk and a15 should be more or less the same, but please look at the results: > > Benchmark | Data Type | Array Size | Arrays.sort() from jdk | Current source (a15) > -- | -- | -- | -- | -- > ArraysSort.Int.testSort | RANDOM ? | ? ? 600 | 1.612 ? ? | 7.096 > ArraysSort.Int.testSort | RANDOM ? | ? ?2000 | 6.893 ? ? | 44.014 > ArraysSort.Int.testSort | RANDOM ? | ? 90000 | 522.749 ? | 4451.444 > ArraysSort.Int.testSort | RANDOM ? | ?400000 | 2424.204 ?| 22751.966 > ArraysSort.Int.testSort | RANDOM ? | 3000000 | 21000.434 | 190326.306 > ArraysSort.Int.testSort | REPEATED | ? ? 600 | 0.496 ? ? | 1.044 > ArraysSort.Int.testSort | REPEATED | ? ?2000 | 1.037 ? ? | 2.272 > ArraysSort.Int.testSort | REPEATED | ? 90000 | 57.763 ? ?| 412.331 > ArraysSort.Int.testSort | REPEATED | ?400000 | 182.238 ? | 1908.978 > ArraysSort.Int.testSort | REPEATED | 3000000 | 1708.082 ?| 15163.443 > ArraysSort.Int.testSort | STAGGER ?| ? ? 600 | 1.038 ? ? | 1.055 > ArraysSort.Int.testSort | STAGGER ?| ? ?2000 | 3.434 ? ? | 3.408 > ArraysSort.Int.testSort | STAGGER ?| ? 90000 | 148.638 ? | 149.220 > ArraysSort.Int.testSort | STAGGER ?| ?400000 | 663.076 ? | 663.096 > ArraysSort.Int.testSort | STAGGER ?| 3000000 | 5212.821 ?| 5206.890 > ArraysSort.Int.testSort | SHUFFLE ?| ? ? 600 | 1.926 ? ? | 4.611 > ArraysSort.Int.testSort | SHUFFLE ?| ? ?2000 | 6.858 ? ? | 17.955 > ArraysSort.Int.testSort | SHUFFLE ?| ? 90000 | 473.441 ? | 1410.357 > ArraysSort.Int.testSort | SHUFFLE ?| ?400000 | 2153.779 ?| 5739.311 > ArraysSort.Int.testSort | SHUFFLE ?| 3000000 | 18180.141 | 41501.980 > > You can see that a15 (current source) works extremly slower than Arrays.sort(), but the code is the same > with minor differences: renaming and repackaging (I put the class to the test package org.openjdk.bench.java.util). > How does other package org.openjdk.bench.java.util effect so much? > > I use this pom.xml file https://github.com/iaroslavski/sorting/blob/master/radixsort/pom.xml and run as following script: > > `mvn cl... Hi Vladimir (@iaroslavski), Will provide the data in few hours. Working on it... Thanks, Vamsi ------------- PR Comment: https://git.openjdk.org/jdk/pull/13568#issuecomment-1924266279 From psandoz at openjdk.org Fri Feb 2 16:57:08 2024 From: psandoz at openjdk.org (Paul Sandoz) Date: Fri, 2 Feb 2024 16:57:08 GMT Subject: Integrated: 8324858: [vectorapi] Bounds checking issues when accessing memory segments In-Reply-To: References: Message-ID: On Mon, 29 Jan 2024 19:45:41 GMT, Paul Sandoz wrote: > The implementation of method `VectorSpecies::fromMemorySegment`, in `AbstractSpecies::fromMemorySegment`, neglects to perform bounds checks on the offset argument when the method is compiled by C2 (bounds checks are performed when interpreted and by C1). > > This is an oversight and explicit bounds checks are required, as is already case for the other load and store memory access methods (including storing to memory memory segments). > > The workaround is to call the static method `{T}Vector::fromMemorySegment`. > > The fix is for the implementation(s) of `VectorSpecies::fromMemorySegment` to do the same and call `{T}Vector::fromMemorySegment`, following the same pattern for implementations of `VectorSpecies::fromArray`. > > The tests have been conservatively updated to call the species access method where possible in the knowledge that it calls the vector access method (the tests were intended to test out of bounds access when compiled by C2). > > Thinking ahead its tempting to remove the species access methods, simplifying functionality that is duplicated. This pull request has now been integrated. Changeset: 1ae85138 Author: Paul Sandoz URL: https://git.openjdk.org/jdk/commit/1ae851387f881263ccc6aeace5afdd0f49d41d33 Stats: 248 lines in 39 files changed: 132 ins; 8 del; 108 mod 8324858: [vectorapi] Bounds checking issues when accessing memory segments Reviewed-by: mcimadamore, jbhateja ------------- PR: https://git.openjdk.org/jdk/pull/17621 From rgiulietti at openjdk.org Fri Feb 2 17:05:02 2024 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Fri, 2 Feb 2024 17:05:02 GMT Subject: RFR: 8325169: Reduce String::indexOf overheads In-Reply-To: References: Message-ID: On Fri, 2 Feb 2024 13:54:46 GMT, Claes Redestad wrote: > This patch streamlines and specializes various `String::indexOf` methods. Mainly avoids the need for clamping and doing checks that are redundant in almost all cases, moving the checks to the API boundary where they are needed. > > This improves performance both at peak and during startup/warmup. Since indexOf is heavily used in bootstrapping code it makes sense to slightly dial back abstraction and delegation, which in this case also brought some benefit to peak performance. > > Testing: tier1-3 src/java.base/share/classes/java/lang/StringLatin1.java line 1: > 1: /* L.313 What about a comment stating that the method expects `fromIndex >= 0`? Albeit on a package private class, it is still a `public` method, so stating preconditions helps. Similarly for the `StringUTF16` case. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17685#discussion_r1476322233 From duke at openjdk.org Fri Feb 2 17:38:13 2024 From: duke at openjdk.org (Joshua Cao) Date: Fri, 2 Feb 2024 17:38:13 GMT Subject: RFR: 8324573: HashMap::putAll should resize to sum of both map sizes [v4] In-Reply-To: References: Message-ID: <-eVaZ9AgZ_GzfN2yeTK8VdE3efeSyx1NqjPyOOkPZAI=.e1007274-1943-46eb-bfab-f796d461da31@github.com> > This change mirrors what we did for ConcurrentHashMap in https://github.com/openjdk/jdk/pull/17116. When we add all entries from one map to anther, we should resize that map to the size of the sum of both maps. > > I used the command below to run the benchmarks. I set a high heap to reduce garbage collection noise. > > java -Xms25G -jar benchmarks.jar -p size=100000 -p addSize=100000 -gc true org.openjdk.bench.java.util.HashMapBench > > > Before change > > > Benchmark (addSize) (mapType) (size) Mode Cnt Score Error Units > HashMapBench.putAll 100000 HASH_MAP 100000 avgt 4 22.927 ? 3.170 ms/op > HashMapBench.putAll 100000 LINKED_HASH_MAP 100000 avgt 4 25.198 ? 2.189 ms/op > > > After change > > > Benchmark (addSize) (mapType) (size) Mode Cnt Score Error Units > HashMapBench.putAll 100000 HASH_MAP 100000 avgt 4 16.780 ? 0.526 ms/op > HashMapBench.putAll 100000 LINKED_HASH_MAP 100000 avgt 4 19.721 ? 0.349 ms/op > > > We see about average time improvements of 26% in HashMap and 20% in LinkedHashMap. > > --- > > In the worse case, we may have two maps with identical keys. In this case, we would aggressively resize when we do not need to. I'm also adding an additional `putAllSameKeys` benchmark. > > Before change: > > > Benchmark (addSize) (mapType) (size) Mode Cnt Score Error Units > HashMapBench.putAllSameKeys 100000 HASH_MAP 100000 avgt 6.956 ms/op > HashMapBench.putAllSameKeys:gc.alloc.rate 100000 HASH_MAP 100000 avgt 1091.383 MB/sec > HashMapBench.putAllSameKeys:gc.alloc.rate.norm 100000 HASH_MAP 100000 avgt 7968871.917 B/op > HashMapBench.putAllSameKeys:gc.count 100000 HASH_MAP 100000 avgt ? 0 counts > HashMapBench.putAllSameKeys 100000 LINKED_HASH_MAP 100000 avgt 8.417 ms/op > HashMapBench.putAllSameKeys:gc.alloc.rate 100000 LINKED_HASH_MAP 100000 avgt 992.543 MB/sec > HashMapBench.putAllSameKeys:gc.alloc.rate.norm 100000 LINKED_HASH_MAP 100000 avgt 8768892.941 B/op > HashMapBench.putAllSameKeys:gc.count 100000 LINKED_HASH_MAP 100000 avgt ? 0 counts > > > After change: > > > Benchmark (addSize) (mapType)... Joshua Cao has updated the pull request incrementally with one additional commit since the last revision: extract msize variable ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17544/files - new: https://git.openjdk.org/jdk/pull/17544/files/4ecc08a7..2a896d0c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17544&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17544&range=02-03 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/17544.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17544/head:pull/17544 PR: https://git.openjdk.org/jdk/pull/17544 From darcy at openjdk.org Fri Feb 2 17:50:24 2024 From: darcy at openjdk.org (Joe Darcy) Date: Fri, 2 Feb 2024 17:50:24 GMT Subject: Integrated: JDK-8325148: Enable restricted javac warning in java.base In-Reply-To: <8zJEeLqHKWm91gZPlYNBVP_5qDXhQgh7g2sWgLXFp3k=.8404dccf-c5a3-4d13-9227-39fc3696f3a5@github.com> References: <8zJEeLqHKWm91gZPlYNBVP_5qDXhQgh7g2sWgLXFp3k=.8404dccf-c5a3-4d13-9227-39fc3696f3a5@github.com> Message-ID: On Thu, 1 Feb 2024 21:10:48 GMT, Joe Darcy wrote: > The restricted javac warning is disabled for java.base, but could be enabled by suppressing the warning in a handful of files. This pull request has now been integrated. Changeset: adc36040 Author: Joe Darcy URL: https://git.openjdk.org/jdk/commit/adc36040278049b118ea49fba41cb4bcfb9b85f2 Stats: 28 lines in 9 files changed: 10 ins; 0 del; 18 mod 8325148: Enable restricted javac warning in java.base Reviewed-by: erikj, jvernee, mcimadamore, pminborg, ihse ------------- PR: https://git.openjdk.org/jdk/pull/17677 From darcy at openjdk.org Fri Feb 2 17:50:24 2024 From: darcy at openjdk.org (Joe Darcy) Date: Fri, 2 Feb 2024 17:50:24 GMT Subject: RFR: JDK-8325148: Enable restricted javac warning in java.base [v3] In-Reply-To: <8zJEeLqHKWm91gZPlYNBVP_5qDXhQgh7g2sWgLXFp3k=.8404dccf-c5a3-4d13-9227-39fc3696f3a5@github.com> References: <8zJEeLqHKWm91gZPlYNBVP_5qDXhQgh7g2sWgLXFp3k=.8404dccf-c5a3-4d13-9227-39fc3696f3a5@github.com> Message-ID: > The restricted javac warning is disabled for java.base, but could be enabled by suppressing the warning in a handful of files. Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - Merge branch 'master' into JDK-8325148 - Add comment highlighting restricted method calls. - JDK-8325148: Enable restricted javac warning in java.base ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17677/files - new: https://git.openjdk.org/jdk/pull/17677/files/9ac261c0..23c93895 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17677&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17677&range=01-02 Stats: 521 lines in 20 files changed: 317 ins; 95 del; 109 mod Patch: https://git.openjdk.org/jdk/pull/17677.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17677/head:pull/17677 PR: https://git.openjdk.org/jdk/pull/17677 From naoto at openjdk.org Fri Feb 2 17:56:04 2024 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 2 Feb 2024 17:56:04 GMT Subject: RFR: 8323699: MessageFormat.toPattern() generates non-equivalent MessageFormat pattern [v8] In-Reply-To: References: Message-ID: On Fri, 2 Feb 2024 01:57:18 GMT, Archie Cobbs wrote: >> Please consider this fix to ensure that going from `MessageFormat` to pattern string via `toPattern()` and then back via `new MessageFormat()` results in a format that is equivalent to the original. >> >> The quoting and escaping rules for `MessageFormat` pattern strings are really tricky. I admit not completely understanding them. At a high level, they work like this: The normal way one would "nest" strings containing special characters is with straightforward recursive escaping like with the `bash` command line. For example, if you want to echo `a "quoted string" example` then you enter `echo "a "quoted string" example"`. With this scheme it's always the "outer" layer's job to (un)escape special characters as needed. That is, the echo command never sees the backslash characters. >> >> In contrast, with `MessageFormat` and friends, nested subformat pattern strings are always provided "pre-escaped". So to build an "outer" string (e.g., for `ChoiceFormat`) the "inner" subformat pattern strings are more or less just concatenated, and then only the `ChoiceFormat` option separator characters (e.g., `<`, `#`, `|`, etc.) are escaped. >> >> The "pre-escape" escaping algorithm escapes `{` characters, because `{` indicates the beginning of a format argument. However, it doesn't escape `}` characters. This is OK because the format string parser treats any "extra" closing braces (where "extra" means not matching an opening brace) as plain characters. >> >> So far, so good... at least, until a format string containing an extra closing brace is nested inside a larger format string, where the extra closing brace, which was previously "extra", can now suddenly match an opening brace in the outer pattern containing it, thus truncating it by "stealing" the match from some subsequent closing brace. >> >> An example is the `MessageFormat` string `"{0,choice,0.0#option A: {1}|1.0#option B: {1}'}'}"`. Note the second option format string has a trailing closing brace in plain text. If you create a `MessageFormat` with this string, you see a trailing `}` only with the second option. >> >> However, if you then invoke `toPattern()`, the result is `"{0,choice,0.0#option A: {1}|1.0#option B: {1}}}"`. Oops, now because the "extra" closing brace is no longer quoted, it matches the opening brace at the beginning of the string, and the following closing brace, which was the previous match, is now just plain text in the outer `MessageFormat` string. >> >> As a result, invoking `f.format(new ... > > Archie Cobbs has updated the pull request incrementally with four additional commits since the last revision: > > - Add a couple more pattern test cases suggested in review. > - Update unit test @summary to better reflect what it tests. > - Use curly braces consistently in patch. > - Update copyright year in modified unit test files. LGTM ------------- Marked as reviewed by naoto (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17416#pullrequestreview-1859995559 From jlu at openjdk.org Fri Feb 2 18:44:04 2024 From: jlu at openjdk.org (Justin Lu) Date: Fri, 2 Feb 2024 18:44:04 GMT Subject: RFR: 8323699: MessageFormat.toPattern() generates non-equivalent MessageFormat pattern [v8] In-Reply-To: References: Message-ID: On Fri, 2 Feb 2024 01:57:18 GMT, Archie Cobbs wrote: >> Please consider this fix to ensure that going from `MessageFormat` to pattern string via `toPattern()` and then back via `new MessageFormat()` results in a format that is equivalent to the original. >> >> The quoting and escaping rules for `MessageFormat` pattern strings are really tricky. I admit not completely understanding them. At a high level, they work like this: The normal way one would "nest" strings containing special characters is with straightforward recursive escaping like with the `bash` command line. For example, if you want to echo `a "quoted string" example` then you enter `echo "a "quoted string" example"`. With this scheme it's always the "outer" layer's job to (un)escape special characters as needed. That is, the echo command never sees the backslash characters. >> >> In contrast, with `MessageFormat` and friends, nested subformat pattern strings are always provided "pre-escaped". So to build an "outer" string (e.g., for `ChoiceFormat`) the "inner" subformat pattern strings are more or less just concatenated, and then only the `ChoiceFormat` option separator characters (e.g., `<`, `#`, `|`, etc.) are escaped. >> >> The "pre-escape" escaping algorithm escapes `{` characters, because `{` indicates the beginning of a format argument. However, it doesn't escape `}` characters. This is OK because the format string parser treats any "extra" closing braces (where "extra" means not matching an opening brace) as plain characters. >> >> So far, so good... at least, until a format string containing an extra closing brace is nested inside a larger format string, where the extra closing brace, which was previously "extra", can now suddenly match an opening brace in the outer pattern containing it, thus truncating it by "stealing" the match from some subsequent closing brace. >> >> An example is the `MessageFormat` string `"{0,choice,0.0#option A: {1}|1.0#option B: {1}'}'}"`. Note the second option format string has a trailing closing brace in plain text. If you create a `MessageFormat` with this string, you see a trailing `}` only with the second option. >> >> However, if you then invoke `toPattern()`, the result is `"{0,choice,0.0#option A: {1}|1.0#option B: {1}}}"`. Oops, now because the "extra" closing brace is no longer quoted, it matches the opening brace at the beginning of the string, and the following closing brace, which was the previous match, is now just plain text in the outer `MessageFormat` string. >> >> As a result, invoking `f.format(new ... > > Archie Cobbs has updated the pull request incrementally with four additional commits since the last revision: > > - Add a couple more pattern test cases suggested in review. > - Update unit test @summary to better reflect what it tests. > - Use curly braces consistently in patch. > - Update copyright year in modified unit test files. Thanks for making the changes ------------- Marked as reviewed by jlu (Committer). PR Review: https://git.openjdk.org/jdk/pull/17416#pullrequestreview-1860069717 From jlu at openjdk.org Fri Feb 2 18:44:06 2024 From: jlu at openjdk.org (Justin Lu) Date: Fri, 2 Feb 2024 18:44:06 GMT Subject: RFR: 8323699: MessageFormat.toPattern() generates non-equivalent MessageFormat pattern [v7] In-Reply-To: <2Jm1RVUV9uStnOqSh684SHV3qYJGtjpys8v7UeZvvtc=.b9d9b195-5662-4b27-b9f4-305d514dffcb@github.com> References: <2Jm1RVUV9uStnOqSh684SHV3qYJGtjpys8v7UeZvvtc=.b9d9b195-5662-4b27-b9f4-305d514dffcb@github.com> Message-ID: <0EUOd-6jUuZb1f_pIGRPpX56WDWbjmwYFmNgvl2znHY=.4a0856fc-c707-4ba4-9993-e33852624ac8@github.com> On Fri, 2 Feb 2024 01:54:12 GMT, Archie Cobbs wrote: >> test/jdk/java/text/Format/MessageFormat/MessageFormatToPatternTest.java line 70: >> >>> 68: @BeforeAll >>> 69: public static void setup() { >>> 70: savedLocale = Locale.getDefault(); >> >> I'm not sure we need to save the default locale and restore it, unless I'm missing something. > > We are verifying output that includes floating point numbers, and the current locale affects that: > > jshell> Locale.setDefault(Locale.US); > > jshell> new MessageFormat("{0}").format(new Object[] { 1.23 }); > $9 ==> "1.23" > > jshell> Locale.setDefault(Locale.FRENCH); > > jshell> new MessageFormat("{0}").format(new Object[] { 1.23 }); > $11 ==> "1,23" Right, that makes sense. >> test/jdk/java/text/Format/MessageFormat/MessageFormatToPatternTest.java line 104: >> >>> 102: Arguments.of("{0,choice,0.0#option A: {0}|1.0#option B: {0}'}'}", "option B: 1.23}"), >>> 103: Arguments.of("{0,choice,0.0#option A: {0}|2.0#option B: {0}'}'}", "option A: 1.23"), >>> 104: >> >> Suggestion: >> >> // Absurd double quote examples >> Arguments.of("Foo '}''''''''}' {0,number,bar'}' '}' } baz ", "Foo }''''} bar} } 1 baz "), >> Arguments.of("'''}''{'''}''''}'"), "'}'{'}''}"), > > Thanks, should be fixed. Thanks for correcting the suggested test case, second argument had the extra `)` on accident. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17416#discussion_r1476525565 PR Review Comment: https://git.openjdk.org/jdk/pull/17416#discussion_r1476524867 From kvn at openjdk.org Fri Feb 2 18:48:01 2024 From: kvn at openjdk.org (Vladimir Kozlov) Date: Fri, 2 Feb 2024 18:48:01 GMT Subject: RFR: 8321468: Remove StringUTF16::equals In-Reply-To: References: Message-ID: <7I-SN7RC5JdW0PWegMBa6c7idd27jT6oV2I7nvgRTi4=.86acebe9-5b2d-4b8d-9ce7-abc88ef80013@github.com> On Wed, 6 Dec 2023 14:20:14 GMT, Claes Redestad wrote: > https://bugs.openjdk.org/browse/JDK-8215017 removed the only use of `StringUTF16::equals`. At the time I did some performance verification focused on x86 showing that simplifying and only using `StringLatin1::equals` was either neutral or a win. > > I repeated this experiment recently, adding some focused tests on aarch64 where the code generation actually tries to take advantage and generate slightly more efficient code for `StringUTF16::equals`: > https://github.com/openjdk/jdk/pull/16933#discussion_r1414118658 > > The indication here is that disabling use of `StringUTF16::equals` was the right choice: any effect from the low-level optimization (one less branch at the tail end) was offset by the `isLatin1()` branch and added code generation (that all gets inlined). > > In a `-XX:-CompactStrings` configuration the slightly improved code generation in `StringUTF16::equals` might help, since the `isLatin1()` test and subsequent call to `StringLatin1::equals` would be DCEd. To get the best of both worlds the code in `String::equals` _could_ be sharpened so that we statically pick the best implementation based on `CompactStrings` mode (see comment below). This shows a tiny win when testing with `-XX:-CompactStrings` on M1 (up to -0.2ns/op per `String::equals`; neutral on x86). But is all this complexity worth it for a gain that will get lost in the noise on anything realistic? > > This PR instead proposes removing `StringUTF16::equals` and simplifying the mechanisms to support the `StringLatin1/UTF16::equals` pair of intrinsics in hotspot. I don't see x86 changes. Why? ------------- Changes requested by kvn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16995#pullrequestreview-1860078647 From erikj at openjdk.org Fri Feb 2 19:15:02 2024 From: erikj at openjdk.org (Erik Joelsson) Date: Fri, 2 Feb 2024 19:15:02 GMT Subject: RFR: 8325163: Enable -Wpedantic on clang In-Reply-To: References: Message-ID: On Fri, 2 Feb 2024 15:22:03 GMT, Magnus Ihse Bursie wrote: > Inspired by (the later backed-out) [JDK-8296115](https://bugs.openjdk.org/browse/JDK-8296115), I propose to enable `-Wpedantic` for clang. This has already found some irregularities in the code, like mistakenly using `#import` instead of `#include`. In this patch, I disable warnings for these individual buggy or badly written files, but I intend to post follow-up issues on the respective teams to have them properly fixed. > > Unfortunately, it is not possible to enable `-Wpedantic` on gcc, since individual warnings in `-Wpedantic` cannot be disabled. This means that code like this: > > > #define DEBUG_ONLY(code) code; > > DEBUG_ONLY(foo()); > > > will result in a `; ;`. This breaks the C standard, but is benign, and we use it all over the place. On clang, we can ignore this by `-Wno-extra-semi`, but this is not available on gcc. Marked as reviewed by erikj (Reviewer). Looks like GHA found some more issues. ------------- PR Review: https://git.openjdk.org/jdk/pull/17687#pullrequestreview-1860130881 PR Review: https://git.openjdk.org/jdk/pull/17687#pullrequestreview-1860132459 From rriggs at openjdk.org Fri Feb 2 19:32:02 2024 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 2 Feb 2024 19:32:02 GMT Subject: RFR: 8325169: Reduce String::indexOf overheads In-Reply-To: References: Message-ID: On Fri, 2 Feb 2024 13:54:46 GMT, Claes Redestad wrote: > This patch streamlines and specializes various `String::indexOf` methods. Mainly avoids the need for clamping and doing checks that are redundant in almost all cases, moving the checks to the API boundary where they are needed. > > This improves performance both at peak and during startup/warmup. Since indexOf is heavily used in bootstrapping code it makes sense to slightly dial back abstraction and delegation, which in this case also brought some benefit to peak performance. > > Testing: tier1-3 Looks ok as a performance improvement; some comments about assertions might be useful for future readers. ------------- Marked as reviewed by rriggs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17685#pullrequestreview-1860173585 From joehw at openjdk.org Fri Feb 2 19:35:02 2024 From: joehw at openjdk.org (Joe Wang) Date: Fri, 2 Feb 2024 19:35:02 GMT Subject: RFR: 8324665: Loose matching of space separators in the lenient date/time parsing mode In-Reply-To: References: Message-ID: On Thu, 1 Feb 2024 23:12:46 GMT, Naoto Sato wrote: > Implementing "loose matching" of space separators in both `java.time.format.DateTimeFormatter` and `java.text.DateFormat` on lenient parsing. This will effectively fix the NNBSP issues on parsing time with am/pm markers introduced with CLDR version 42 (https://inside.java/2023/03/28/quality-heads-up/). A draft CSR has also been drafted. The compatibility risk is low for this change itself as assessed in the CSR, and this change looks good to me. However, just would like to note that it conforms to CLDR, but doesn't address completely the issue reported in JDK-8304925. Since the default parsing mode is strict in java.time.format, applications would still have to make code changes when moving existing code to the new JDK releases. In java.text then, all space separators will be parsed by default, that would be a welcoming behavior change to me. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17678#issuecomment-1924550866 From ryan at iernst.net Fri Feb 2 19:42:45 2024 From: ryan at iernst.net (Ryan Ernst) Date: Fri, 2 Feb 2024 11:42:45 -0800 Subject: Object creation from iterating Map.of()/Set.of()/List.of() Message-ID: The newer ?of? methods in collections are really nice, they make creating these collections much easier and often result in better performance. However, the empty collection cases with Map.of()/Set.of()/List.of() has one small downside. The implementations within ImmutableCollections use non-specialized implementations for zero sized collections. For example, ImmutableCollections.EMPTY_MAP is a MapN. If you iterate over that Map, even if it is empty as in the case for Map.of(), a new anonymous AbstractSet is created. In comparison, Collections.emptyMap().entrySet() returns emptySet(). I don?t know what the reasoning was for rebuilding the empty based variants in ImmutableCollections. But regardless, it seems like the empty collections defined in ImmutableCollections should likewise never construct any objects. I?m happy to raise a PR to either mimic or reuse the empty collection implementations from Collections, but I wanted to check there isn?t some reasoning the of() methods work this way. From lancea at openjdk.org Fri Feb 2 19:58:05 2024 From: lancea at openjdk.org (Lance Andersen) Date: Fri, 2 Feb 2024 19:58:05 GMT Subject: RFR: 8321274: Rename ZipEntry.extraAttributes to ZipEntry.externalAttributes [v2] In-Reply-To: <-e1Q7OFfQ6tppgashjdUtiqM6uou0IETGRaQWRHDEX8=.02b4ef00-725a-4317-b06e-2d1a699c4860@github.com> References: <-e1Q7OFfQ6tppgashjdUtiqM6uou0IETGRaQWRHDEX8=.02b4ef00-725a-4317-b06e-2d1a699c4860@github.com> Message-ID: On Tue, 30 Jan 2024 16:17:13 GMT, Eirik Bj?rsn?s wrote: >> Please consider this PR which suggests we rename `ZipEntry.extraAttributes` to `ZipEntry.externalAttributes`. >> >> This field was introduced in [JDK-8218021](https://bugs.openjdk.org/browse/JDK-8218021), originally under the name `ZipEntry.posixPerms`. [JDK-8250968](https://bugs.openjdk.org/browse/JDK-8250968) later renamed the field to `ZipEntry.extraAttributes` and extended its semantics to hold the full two-byte value of the `external file attributes` field, as defined by `APPNOTE.TXT` >> >> The name `extraAttributes` is misleading. It has nothing to do with the `extra field` (an unrelated structure defined in `APPNOTE.TXT`), although the name indicates it does. >> >> To prevent confusion and make life easier for future maintainers, I suggest we rename this field to `ZipEntry.externalAttributes` and update related methods, parameters and comments accordingly. >> >> While this change is a straightforward renaming, reviewers should consider whether it carries its weight, especially considering it might complicate future backports. >> >> As a note to reviewers, this PR includes the following intended updates: >> >> - Rename `ZipEntry.extraAttributes` and any references to this field to `ZipEntry.externalAttributes` >> - Update `JavaUtilZipFileAccess` to similarly rename methods to `setExternalAttributes` and `getExternalAttributes` >> - Rename the field `JarSigner.extraAttrsDetected` to `JarSigner.externalAttrsDetected` >> - Rename a local variable in `JarSigner.writeEntry` to `externalAttrs` >> - Rename `s.s.t.jarsigner.Main.extraAttrsDetected` to `externalAttrsDetected` >> - Rename resource string key names in `s.s.t.jarsigner.Resources` from `extra.attributes.detected` to `external.attributes.detected` >> - Rename method `SymlinkTest.verifyExtraAttrs` to `verifyExternalAttrs`, also updated two references to 'extra attributes' in this method >> - Updated copyright in all affected files >> >> If the resource file changes should be dropped and instead handled via `msgdop` updates, let me know and I can revert the non-default files. >> >> I did a search across the code base to find 'extraAttrs', 'extra.attr' after these updates, and found nothing related to zip/jar. The `zip` and `jar` tests run clean: >> >> >> make test TEST="test/jdk/java/util/jar" >> make test TEST="test/jdk/java/util/zip" > > Eirik Bj?rsn?s has updated the pull request with a new target base 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: > > - Update copyright years for 2024 > - Merge branch 'master' into zipentry-external-attributes > - Rename ZipEntry.extraAttributes to ZipEntry.externalAttributes I think the change is OK, any reason to not make it `externalFileAttributes`? ------------- Marked as reviewed by lancea (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16952#pullrequestreview-1860228844 From lancea at openjdk.org Fri Feb 2 20:04:02 2024 From: lancea at openjdk.org (Lance Andersen) Date: Fri, 2 Feb 2024 20:04:02 GMT Subject: RFR: 8324635: (zipfs) Regression in Files.setPosixFilePermissions called on existing MSDOS entries In-Reply-To: <4-JvAWwMDyx-5tMy_qnVwOE3zdUZITFo4-LR-Ascmrc=.0eb713b7-07c3-4884-af42-401ecce11325@github.com> References: <4-JvAWwMDyx-5tMy_qnVwOE3zdUZITFo4-LR-Ascmrc=.0eb713b7-07c3-4884-af42-401ecce11325@github.com> Message-ID: On Wed, 24 Jan 2024 14:34:03 GMT, Eirik Bj?rsn?s wrote: > Please review this PR to fix to a regression in ZipFileSystem, introduced by JDK-8322565 in PR #17170. > > When `Files.setPosixFilePermissions` is called on an existing MSDOS entry, then `Entry.posixPerms` field will be -1 (all 1s in binary). The logic introduced by JDK-8322565 did not account for this and incorrectly sets the leading seven bits to all ones instead of all zeros. > > The fix is to introduce a branch for `Entry.posixPerms` being -1 and deal with that case separately. > > The PR adds a test case to `TestPosix` which reproduces the regression. While visiting this test, I also fixed an incorrect spelling of `setPosixFilePermissions` (also introduced by #17170). Looks OK overall. One minor suggestion test/jdk/jdk/nio/zipfs/TestPosix.java line 757: > 755: try (FileSystem fs = FileSystems.newFileSystem(ZIP_FILE, ENV_POSIX)) { > 756: Path path = fs.getPath("hello.txt"); > 757: Files.setPosixFilePermissions(path, EnumSet.of(OWNER_READ)); It might be helpful to show the before/after output of the CEN fields here just for extra clarity ------------- Marked as reviewed by lancea (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17556#pullrequestreview-1860241911 PR Review Comment: https://git.openjdk.org/jdk/pull/17556#discussion_r1476630176 From lancea at openjdk.org Fri Feb 2 20:05:03 2024 From: lancea at openjdk.org (Lance Andersen) Date: Fri, 2 Feb 2024 20:05:03 GMT Subject: RFR: 8313739: ZipOutputStream.close() should always close the wrapped stream [v5] In-Reply-To: References: Message-ID: On Mon, 22 Jan 2024 13:58:00 GMT, Eirik Bj?rsn?s wrote: >> Please consider this PR which makes `DeflaterOutputStream.close()` always close its wrapped output stream exactly once. >> >> Currently, closing of the wrapped output stream happens outside the finally block where `finish()` is called. If `finish()` throws, this means the wrapped stream will not be closed. This can potentially lead to leaking resources such as file descriptors or sockets. >> >> This fix is to move the closing of the wrapped stream inside the finally block. >> >> Additionally, the `closed = true;` statement is moved to the start of the close method. This makes sure we only ever close the wrapped stream once (this aligns with the overridden method `FilterOutputStream.close?) >> >> Specification: This change brings the implementation of `DeflaterOutputStream.close()` in line with its specification: *Writes remaining compressed data to the output stream and closes the underlying stream.* >> >> Risk: This is a behavioural change. There is a small risk that existing code depends on the close method not following its specification. >> >> Testing: The PR adds a new JUnit 5 test `CloseWrappedStream.java` which simulates the failure condition and verifies that the wrapped stream was closed under failing and non-failing conditions. > > Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision: > > Spell out what is checked by each test instead of using the word "correct" Marked as reviewed by lancea (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/17209#pullrequestreview-1860246844 From lancea at openjdk.org Fri Feb 2 20:08:03 2024 From: lancea at openjdk.org (Lance Andersen) Date: Fri, 2 Feb 2024 20:08:03 GMT Subject: RFR: 8321396: Retire test/jdk/java/util/zip/NoExtensionSignature.java [v2] In-Reply-To: References: Message-ID: On Wed, 24 Jan 2024 10:28:46 GMT, Eirik Bj?rsn?s wrote: >> Please review this PR which suggests we retire the ZIP test `NoExtensionSignature` along with its `test.jar` test vector. >> >> The concern of a missing data descriptor signature is covered by the recently updated `DataDescriptorSignatureMissing` test, see #12959. That test is more complete, includes more documentation and uses a programmatically generated test vector. >> >> Careful analysis of the deleted `test.jar` test vector revealed that it contains a local header with non-zero `compressed size` and `uncompressed size` fields for a streaming-mode entry. `APPNOTE.TXT` mandates that when bit 3 of the general purpose bit flag is set, then these fields and the `crc` field should all be set to zero. >> >> By injecting assertions into `ZipInputStream.readLOC` I was able to determine that `NoExtensionSignature` is the only test currently parsing a ZIP file with such non-zero fields in streaming mode. >> >> Because of this, and out of caution, this PR introduces a new test `DataDescriptorIgnoreCrcAndSizeFields` which explicitly verifies that `ZipInputStream` does not read any non-zero `crc`, `compressed size` or `uncompressed size` field values from a local header when in streaming mode. `ZipInputStream` should ignore these values and it would be good to have a test which asserts that this invariant holds even when the fields are non-zero. > > Eirik Bj?rsn?s has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Merge branch 'master' into retire-no-extension-signature > - Rename 'nameAndContent' parameter to 'expected' > - Retire the test NoExtensionSignature in favor of DataDescriptorSignatureMissing. Introduce the new test DataDescriptorIgnoreCrcAndSizeFields covering unrelated aspects implicitly tested by NoExtensionSignature. Marked as reviewed by lancea (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/16975#pullrequestreview-1860257395 From duke at openjdk.org Fri Feb 2 20:13:05 2024 From: duke at openjdk.org (Srinivas Vamsi Parasa) Date: Fri, 2 Feb 2024 20:13:05 GMT Subject: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort) [v11] In-Reply-To: <9q8Gg6DQnrf0HLW3oxwfpoUP9639drr1BIQMc1rxDFo=.eb4ea73c-b632-446a-8d50-b51838f67f69@github.com> References: <918oCEfFu2JweXfV-afD1l_AGDDuc7dJwAxip-Ze6ZI=.8d5e9692-23db-47e4-9586-99e53b9cfbb6@github.com> <-bYhysKjQVb_ZS0I0YutJZ7umfYwbs74rtK6-d2qL9U=.f9981e59-f0c4-48f3-ad7e-5627aad00919@github.com> <91Zv361kqKOjCSJPu20-yhKOb4lBIZVyVTm9f79dkcQ=.745c271d-3cb1-4ff3-9d71-5cad85ff4f14@github.com> <9q8Gg6DQnrf0HLW3oxwfpoUP9639drr1BIQMc1rxDFo=.eb4ea73c-b632-446a-8d50-b51838f67f69@github.com> Message-ID: On Sun, 28 Jan 2024 22:23:38 GMT, Vladimir Yaroslavskiy wrote: >> Hi Vladimir (@iaroslavski), >> >> Please see the JMH data below. >> >> Thanks, >> Vamsi >> >> Benchmark (builder) (size) Mode Cnt Score Error Units >> ArraysSort.Int.a15 RANDOM 600 avgt 4 7.096 ? 0.081 us/op >> ArraysSort.Int.a15 RANDOM 2000 avgt 4 44.014 ? 1.717 us/op >> ArraysSort.Int.a15 RANDOM 90000 avgt 4 4451.444 ? 71.168 us/op >> ArraysSort.Int.a15 RANDOM 400000 avgt 4 22751.966 ? 683.597 us/op >> ArraysSort.Int.a15 RANDOM 3000000 avgt 4 190326.306 ? 8008.512 us/op >> ArraysSort.Int.a15 REPEATED 600 avgt 4 1.044 ? 0.016 us/op >> ArraysSort.Int.a15 REPEATED 2000 avgt 4 2.272 ? 0.287 us/op >> ArraysSort.Int.a15 REPEATED 90000 avgt 4 412.331 ? 11.656 us/op >> ArraysSort.Int.a15 REPEATED 400000 avgt 4 1908.978 ? 30.241 us/op >> ArraysSort.Int.a15 REPEATED 3000000 avgt 4 15163.443 ? 100.425 us/op >> ArraysSort.Int.a15 STAGGER 600 avgt 4 1.055 ? 0.057 us/op >> ArraysSort.Int.a15 STAGGER 2000 avgt 4 3.408 ? 0.096 us/op >> ArraysSort.Int.a15 STAGGER 90000 avgt 4 149.220 ? 4.022 us/op >> ArraysSort.Int.a15 STAGGER 400000 avgt 4 663.096 ? 30.252 us/op >> ArraysSort.Int.a15 STAGGER 3000000 avgt 4 5206.890 ? 234.857 us/op >> ArraysSort.Int.a15 SHUFFLE 600 avgt 4 4.611 ? 0.118 us/op >> ArraysSort.Int.a15 SHUFFLE 2000 avgt 4 17.955 ? 0.356 us/op >> ArraysSort.Int.a15 SHUFFLE 90000 avgt 4 1410.357 ? 41.128 us/op >> ArraysSort.Int.a15 SHUFFLE 400000 avgt 4 5739.311 ? 128.270 us/op >> ArraysSort.Int.a15 SHUFFLE 3000000 avgt 4 41501.980 ? 829.443 us/op >> ArraysSort.Int.jdk RANDOM 600 avgt 4 1.612 ? 0.088 us/op >> ArraysSort.Int.jdk RANDOM 2000 avgt 4 6.893 ? 0.375 us/op >> ArraysSort.Int.jdk RANDOM 90000 avgt 4 522.749 ? 19.386 us/op >> ArraysSort.Int.jdk RANDOM 400000 avgt 4 2424.204 ? 63.844 us/op >> ArraysSort.Int.jdk RANDOM 3000000 avgt 4 21000.434 ? 801.315 us/op >> ArraysSort.Int.jdk REPEATED 600 avgt 4 0.496 ? 0.030 us/op >> ArraysSort.Int.jdk REPEATED 2000 avgt 4 1.037 ? 0.083 us/op >> ArraysSort.Int.jdk REPE... > > Hi Vamsi (@vamsi-parasa), Laurent(@bourgesl), > > The latest benchmarking compares compares the following versions: > jdk - direct call of Arrays.sort(); > a15 - the current source of DualPivotQuicksort from the latest build (except renaming) > https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/DualPivotQuicksort.java > https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_a15.java > r20s - new version without Radix sort > r20p - new version with Radix sort in parallel case only > > It is expected that timing of jdk and a15 should be more or less the same, but please look at the results: > > Benchmark | Data Type | Array Size | Arrays.sort() from jdk | Current source (a15) > -- | -- | -- | -- | -- > ArraysSort.Int.testSort | RANDOM ? | ? ? 600 | 1.612 ? ? | 7.096 > ArraysSort.Int.testSort | RANDOM ? | ? ?2000 | 6.893 ? ? | 44.014 > ArraysSort.Int.testSort | RANDOM ? | ? 90000 | 522.749 ? | 4451.444 > ArraysSort.Int.testSort | RANDOM ? | ?400000 | 2424.204 ?| 22751.966 > ArraysSort.Int.testSort | RANDOM ? | 3000000 | 21000.434 | 190326.306 > ArraysSort.Int.testSort | REPEATED | ? ? 600 | 0.496 ? ? | 1.044 > ArraysSort.Int.testSort | REPEATED | ? ?2000 | 1.037 ? ? | 2.272 > ArraysSort.Int.testSort | REPEATED | ? 90000 | 57.763 ? ?| 412.331 > ArraysSort.Int.testSort | REPEATED | ?400000 | 182.238 ? | 1908.978 > ArraysSort.Int.testSort | REPEATED | 3000000 | 1708.082 ?| 15163.443 > ArraysSort.Int.testSort | STAGGER ?| ? ? 600 | 1.038 ? ? | 1.055 > ArraysSort.Int.testSort | STAGGER ?| ? ?2000 | 3.434 ? ? | 3.408 > ArraysSort.Int.testSort | STAGGER ?| ? 90000 | 148.638 ? | 149.220 > ArraysSort.Int.testSort | STAGGER ?| ?400000 | 663.076 ? | 663.096 > ArraysSort.Int.testSort | STAGGER ?| 3000000 | 5212.821 ?| 5206.890 > ArraysSort.Int.testSort | SHUFFLE ?| ? ? 600 | 1.926 ? ? | 4.611 > ArraysSort.Int.testSort | SHUFFLE ?| ? ?2000 | 6.858 ? ? | 17.955 > ArraysSort.Int.testSort | SHUFFLE ?| ? 90000 | 473.441 ? | 1410.357 > ArraysSort.Int.testSort | SHUFFLE ?| ?400000 | 2153.779 ?| 5739.311 > ArraysSort.Int.testSort | SHUFFLE ?| 3000000 | 18180.141 | 41501.980 > > You can see that a15 (current source) works extremly slower than Arrays.sort(), but the code is the same > with minor differences: renaming and repackaging (I put the class to the test package org.openjdk.bench.java.util). > How does other package org.openjdk.bench.java.util effect so much? > > I use this pom.xml file https://github.com/iaroslavski/sorting/blob/master/radixsort/pom.xml and run as following script: > > `mvn cl... Hi Vladimir (@iaroslavski), Please see the data below. All tests were run after putting the DPQS code in java.util package and recompiling the JDK for each case. Benchmark (us/op) | (builder) | (size) | Stock JDK | a15 | r20p | r20s -- | -- | -- | -- | -- | -- | -- ArraysSort.Int.testParallelSort | RANDOM | 600 | 2.24 | 2.201 | 2.423 | 2.389 ArraysSort.Int.testParallelSort | RANDOM | 9000 | 35.318 | 35.961 | 79.028 | 83.774 ArraysSort.Int.testParallelSort | RANDOM | 20000 | 118.729 | 120.872 | 134.829 | 138.349 ArraysSort.Int.testParallelSort | RANDOM | 400000 | 822.676 | 822.44 | 1200.858 | 872.264 ArraysSort.Int.testParallelSort | RANDOM | 3000000 | 5864.514 | 5948.82 | 8800.391 | 6020.616 ArraysSort.Int.testParallelSort | REPEATED | 600 | 0.924 | 0.936 | 0.752 | 0.733 ArraysSort.Int.testParallelSort | REPEATED | 9000 | 9.896 | 9.317 | 31.409 | 24.896 ArraysSort.Int.testParallelSort | REPEATED | 20000 | 58.265 | 42.189 | 40.92 | 40.101 ArraysSort.Int.testParallelSort | REPEATED | 400000 | 256.952 | 253.217 | 236.568 | 239.163 ArraysSort.Int.testParallelSort | REPEATED | 3000000 | 2844.107 | 2851.088 | 2752.939 | 3040.423 ArraysSort.Int.testParallelSort | STAGGER | 600 | 2.245 | 2.296 | 2.15 | 2.219 ArraysSort.Int.testParallelSort | STAGGER | 9000 | 29.278 | 29.119 | 28.288 | 28.141 ArraysSort.Int.testParallelSort | STAGGER | 20000 | 50.129 | 50.442 | 49.746 | 49.686 ArraysSort.Int.testParallelSort | STAGGER | 400000 | 463.309 | 413.619 | 418.077 | 407.519 ArraysSort.Int.testParallelSort | STAGGER | 3000000 | 3687.198 | 4363.242 | 3732.777 | 3769.898 ArraysSort.Int.testParallelSort | SHUFFLE | 600 | 1.715 | 1.698 | 2.799 | 2.733 ArraysSort.Int.testParallelSort | SHUFFLE | 9000 | 27.69 | 27.183 | 32.883 | 32.373 ArraysSort.Int.testParallelSort | SHUFFLE | 20000 | 62.067 | 60.987 | 63.281 | 52.89 ArraysSort.Int.testParallelSort | SHUFFLE | 400000 | 467.213 | 495.14 | 650.173 | 476.403 ArraysSort.Int.testParallelSort | SHUFFLE | 3000000 | 4456.617 | 4318.491 | 7676.837 | 4259.434 ArraysSort.Int.testSort | RANDOM | 600 | 2.282 | 2.356 | 2.479 | 2.56 ArraysSort.Int.testSort | RANDOM | 9000 | 36.457 | 36.25 | 35.399 | 36.066 ArraysSort.Int.testSort | RANDOM | 20000 | 81.019 | 81.012 | 79.987 | 80.566 ArraysSort.Int.testSort | RANDOM | 400000 | 2523.781 | 2492.705 | 2713.143 | 2694.033 ArraysSort.Int.testSort | RANDOM | 3000000 | 21299.95 | 21436.19 | 23279.92 | 23557.36 ArraysSort.Int.testSort | REPEATED | 600 | 0.923 | 0.925 | 0.728 | 0.731 ArraysSort.Int.testSort | REPEATED | 9000 | 5.015 | 5.324 | 4.789 | 4.868 ArraysSort.Int.testSort | REPEATED | 20000 | 10.76 | 11.464 | 13.833 | 11.873 ArraysSort.Int.testSort | REPEATED | 400000 | 236.532 | 213.273 | 247.777 | 231.067 ArraysSort.Int.testSort | REPEATED | 3000000 | 2050.757 | 2059.629 | 2113.255 | 2122.659 ArraysSort.Int.testSort | STAGGER | 600 | 2.236 | 2.192 | 2.116 | 2.21 ArraysSort.Int.testSort | STAGGER | 9000 | 28.12 | 27.949 | 30.822 | 29.807 ArraysSort.Int.testSort | STAGGER | 20000 | 66.48 | 67.361 | 63.297 | 62.592 ArraysSort.Int.testSort | STAGGER | 400000 | 1422.026 | 1410.685 | 1268.24 | 1312.031 ArraysSort.Int.testSort | STAGGER | 3000000 | 10938.67 | 10913.78 | 34406.74 | 10467.03 ArraysSort.Int.testSort | SHUFFLE | 600 | 1.712 | 1.67 | 2.803 | 2.809 ArraysSort.Int.testSort | SHUFFLE | 9000 | 32.927 | 32.824 | 34.267 | 35.117 ArraysSort.Int.testSort | SHUFFLE | 20000 | 85.591 | 85.656 | 77.072 | 77.365 ArraysSort.Int.testSort | SHUFFLE | 400000 | 2273.753 | 2274.048 | 2343.126 | 2307.69 ArraysSort.Int.testSort | SHUFFLE | 3000000 | 18675.12 | 18575.08 | 19684.59 | 19613.74 ------------- PR Comment: https://git.openjdk.org/jdk/pull/13568#issuecomment-1924613668 From eirbjo at openjdk.org Fri Feb 2 20:22:03 2024 From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=) Date: Fri, 2 Feb 2024 20:22:03 GMT Subject: RFR: 8321274: Rename ZipEntry.extraAttributes to ZipEntry.externalAttributes [v2] In-Reply-To: References: <-e1Q7OFfQ6tppgashjdUtiqM6uou0IETGRaQWRHDEX8=.02b4ef00-725a-4317-b06e-2d1a699c4860@github.com> Message-ID: On Fri, 2 Feb 2024 19:55:51 GMT, Lance Andersen wrote: > I think the change is OK, any reason to not make it `externalFileAttributes`? None other than length / verbosity. But since this refers to the _attributes of the external file_, dropping any name element also loses some semantics, introducing a potential for confusion. Perhaps verbosity is the sensible choice here. If you agree to the above, I can update the PR to rename to the following names instead: - `ZipFile.externalFileAttributes` - `JavaUtilZipFileAccess.java.[set|get]ExternalFileAttributes` - `JarSigner.externalFileAttributesDetected` - `jarsigner/Main.externalFileAttributesDetected` - `external.file.attributes.detected` in `Resources.java` WDYT? ------------- PR Comment: https://git.openjdk.org/jdk/pull/16952#issuecomment-1924638322 From eirbjo at openjdk.org Fri Feb 2 20:23:08 2024 From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=) Date: Fri, 2 Feb 2024 20:23:08 GMT Subject: Integrated: 8313739: ZipOutputStream.close() should always close the wrapped stream In-Reply-To: References: Message-ID: On Mon, 1 Jan 2024 16:12:13 GMT, Eirik Bj?rsn?s wrote: > Please consider this PR which makes `DeflaterOutputStream.close()` always close its wrapped output stream exactly once. > > Currently, closing of the wrapped output stream happens outside the finally block where `finish()` is called. If `finish()` throws, this means the wrapped stream will not be closed. This can potentially lead to leaking resources such as file descriptors or sockets. > > This fix is to move the closing of the wrapped stream inside the finally block. > > Additionally, the `closed = true;` statement is moved to the start of the close method. This makes sure we only ever close the wrapped stream once (this aligns with the overridden method `FilterOutputStream.close?) > > Specification: This change brings the implementation of `DeflaterOutputStream.close()` in line with its specification: *Writes remaining compressed data to the output stream and closes the underlying stream.* > > Risk: This is a behavioural change. There is a small risk that existing code depends on the close method not following its specification. > > Testing: The PR adds a new JUnit 5 test `CloseWrappedStream.java` which simulates the failure condition and verifies that the wrapped stream was closed under failing and non-failing conditions. This pull request has now been integrated. Changeset: f613e133 Author: Eirik Bj?rsn?s URL: https://git.openjdk.org/jdk/commit/f613e13397c7890bdc9fcfb068531b3aa03ce122 Stats: 283 lines in 2 files changed: 279 ins; 2 del; 2 mod 8313739: ZipOutputStream.close() should always close the wrapped stream Reviewed-by: jpai, lancea ------------- PR: https://git.openjdk.org/jdk/pull/17209 From eirbjo at openjdk.org Fri Feb 2 20:24:08 2024 From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=) Date: Fri, 2 Feb 2024 20:24:08 GMT Subject: Integrated: 8321396: Retire test/jdk/java/util/zip/NoExtensionSignature.java In-Reply-To: References: Message-ID: On Tue, 5 Dec 2023 15:58:14 GMT, Eirik Bj?rsn?s wrote: > Please review this PR which suggests we retire the ZIP test `NoExtensionSignature` along with its `test.jar` test vector. > > The concern of a missing data descriptor signature is covered by the recently updated `DataDescriptorSignatureMissing` test, see #12959. That test is more complete, includes more documentation and uses a programmatically generated test vector. > > Careful analysis of the deleted `test.jar` test vector revealed that it contains a local header with non-zero `compressed size` and `uncompressed size` fields for a streaming-mode entry. `APPNOTE.TXT` mandates that when bit 3 of the general purpose bit flag is set, then these fields and the `crc` field should all be set to zero. > > By injecting assertions into `ZipInputStream.readLOC` I was able to determine that `NoExtensionSignature` is the only test currently parsing a ZIP file with such non-zero fields in streaming mode. > > Because of this, and out of caution, this PR introduces a new test `DataDescriptorIgnoreCrcAndSizeFields` which explicitly verifies that `ZipInputStream` does not read any non-zero `crc`, `compressed size` or `uncompressed size` field values from a local header when in streaming mode. `ZipInputStream` should ignore these values and it would be good to have a test which asserts that this invariant holds even when the fields are non-zero. This pull request has now been integrated. Changeset: 63cb1f88 Author: Eirik Bj?rsn?s URL: https://git.openjdk.org/jdk/commit/63cb1f8818322c970454664b387a113935923f2b Stats: 222 lines in 3 files changed: 180 ins; 42 del; 0 mod 8321396: Retire test/jdk/java/util/zip/NoExtensionSignature.java Reviewed-by: lancea ------------- PR: https://git.openjdk.org/jdk/pull/16975 From lancea at openjdk.org Fri Feb 2 20:46:02 2024 From: lancea at openjdk.org (Lance Andersen) Date: Fri, 2 Feb 2024 20:46:02 GMT Subject: RFR: 8321274: Rename ZipEntry.extraAttributes to ZipEntry.externalAttributes [v2] In-Reply-To: References: <-e1Q7OFfQ6tppgashjdUtiqM6uou0IETGRaQWRHDEX8=.02b4ef00-725a-4317-b06e-2d1a699c4860@github.com> Message-ID: On Fri, 2 Feb 2024 20:19:51 GMT, Eirik Bj?rsn?s wrote: > > I think the change is OK, any reason to not make it `externalFileAttributes`? > > None other than length / verbosity. But since this refers to the _attributes of the external file_, dropping any name element also loses some semantics, introducing a potential for confusion. Perhaps verbosity is the sensible choice here. > > If you agree to the above, I can update the PR to rename to the following names instead: > > * `ZipFile.externalFileAttributes` > * `JavaUtilZipFileAccess.java.[set|get]ExternalFileAttributes` > * `JarSigner.externalFileAttributesDetected` > * `jarsigner/Main.externalFileAttributesDetected` > * `external.file.attributes.detected` in `Resources.java` > > WDYT? I think the proposed change above makes things clearer. Perhaps also make the same change in zipfs as well while you are at it? ------------- PR Comment: https://git.openjdk.org/jdk/pull/16952#issuecomment-1924670785 From naoto at openjdk.org Fri Feb 2 20:47:29 2024 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 2 Feb 2024 20:47:29 GMT Subject: RFR: 8324665: Loose matching of space separators in the lenient date/time parsing mode [v2] In-Reply-To: References: Message-ID: > Implementing "loose matching" of space separators in both `java.time.format.DateTimeFormatter` and `java.text.DateFormat` on lenient parsing. This will effectively fix the NNBSP issues on parsing time with am/pm markers introduced with CLDR version 42 (https://inside.java/2023/03/28/quality-heads-up/). A draft CSR has also been drafted. Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: Reworded spec ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17678/files - new: https://git.openjdk.org/jdk/pull/17678/files/aef2bcfc..0c950941 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17678&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17678&range=00-01 Stats: 9 lines in 2 files changed: 2 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/17678.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17678/head:pull/17678 PR: https://git.openjdk.org/jdk/pull/17678 From redestad at openjdk.org Fri Feb 2 20:53:14 2024 From: redestad at openjdk.org (Claes Redestad) Date: Fri, 2 Feb 2024 20:53:14 GMT Subject: RFR: 8325169: Reduce String::indexOf overheads [v2] In-Reply-To: References: Message-ID: <6JFAtUUQ4Uel7cjfHr0SbQYIM7e9bWZ65hcvFHA1qNo=.a2d2e97f-086d-46d1-82cf-c2f74b0c655a@github.com> > This patch streamlines and specializes various `String::indexOf` methods. Mainly avoids the need for clamping and doing checks that are redundant in almost all cases, moving the checks to the API boundary where they are needed. > > This improves performance both at peak and during startup/warmup. Since indexOf is heavily used in bootstrapping code it makes sense to slightly dial back abstraction and delegation, which in this case also brought some benefit to peak performance. > > Testing: tier1-3 Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: Add comment about preconditions ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17685/files - new: https://git.openjdk.org/jdk/pull/17685/files/067f1ea6..aad343b3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17685&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17685&range=00-01 Stats: 2 lines in 2 files changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/17685.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17685/head:pull/17685 PR: https://git.openjdk.org/jdk/pull/17685 From jason_mehrens at hotmail.com Fri Feb 2 20:53:59 2024 From: jason_mehrens at hotmail.com (Jason Mehrens) Date: Fri, 2 Feb 2024 20:53:59 +0000 Subject: Object creation from iterating Map.of()/Set.of()/List.of() In-Reply-To: References: Message-ID: See: https://bugs.openjdk.org/browse/JDK-8193128 Jason ________________________________ From: core-libs-dev on behalf of Ryan Ernst Sent: Friday, February 2, 2024 1:42 PM To: core-libs-dev at openjdk.org Subject: Object creation from iterating Map.of()/Set.of()/List.of() The newer ?of? methods in collections are really nice, they make creating these collections much easier and often result in better performance. However, the empty collection cases with Map.of()/Set.of()/List.of() has one small downside. The implementations within ImmutableCollections use non-specialized implementations for zero sized collections. For example, ImmutableCollections.EMPTY_MAP is a MapN. If you iterate over that Map, even if it is empty as in the case for Map.of(), a new anonymous AbstractSet is created. In comparison, Collections.emptyMap().entrySet() returns emptySet(). I don?t know what the reasoning was for rebuilding the empty based variants in ImmutableCollections. But regardless, it seems like the empty collections defined in ImmutableCollections should likewise never construct any objects. I?m happy to raise a PR to either mimic or reuse the empty collection implementations from Collections, but I wanted to check there isn?t some reasoning the of() methods work this way. -------------- next part -------------- An HTML attachment was scrubbed... URL: From naoto at openjdk.org Fri Feb 2 21:02:01 2024 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 2 Feb 2024 21:02:01 GMT Subject: RFR: 8324665: Loose matching of space separators in the lenient date/time parsing mode In-Reply-To: References: Message-ID: On Fri, 2 Feb 2024 19:31:55 GMT, Joe Wang wrote: > Since the default parsing mode is strict in java.time.format, applications would still have to make code changes when moving existing code to the new JDK releases. You are right, Joe. Apps using `java.time` formatters would still need to make changes to their code base. However, the bar is significantly lower. They would have to write some ugly workaround without this fix. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17678#issuecomment-1924688591 From joehw at openjdk.org Fri Feb 2 21:08:01 2024 From: joehw at openjdk.org (Joe Wang) Date: Fri, 2 Feb 2024 21:08:01 GMT Subject: RFR: 8324665: Loose matching of space separators in the lenient date/time parsing mode [v2] In-Reply-To: References: Message-ID: <0hX9JQ5FkrtxKPXjTtEO8UPCPQCbpgRoeb85oAj6jqE=.9268e067-feda-4da2-9b28-d7c012ffd0a3@github.com> On Fri, 2 Feb 2024 20:47:29 GMT, Naoto Sato wrote: >> Implementing "loose matching" of space separators in both `java.time.format.DateTimeFormatter` and `java.text.DateFormat` on lenient parsing. This will effectively fix the NNBSP issues on parsing time with am/pm markers introduced with CLDR version 42 (https://inside.java/2023/03/28/quality-heads-up/). A draft CSR has also been drafted. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Reworded spec Marked as reviewed by joehw (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/17678#pullrequestreview-1860391401 From joehw at openjdk.org Fri Feb 2 21:11:02 2024 From: joehw at openjdk.org (Joe Wang) Date: Fri, 2 Feb 2024 21:11:02 GMT Subject: RFR: 8324665: Loose matching of space separators in the lenient date/time parsing mode In-Reply-To: References: Message-ID: On Fri, 2 Feb 2024 20:59:13 GMT, Naoto Sato wrote: > > Since the default parsing mode is strict in java.time.format, applications would still have to make code changes when moving existing code to the new JDK releases. > > You are right, Joe. Apps using `java.time` formatters would still need to make changes to their code base. However, the bar is significantly lower. They would have to write some ugly workaround without this fix. True, indeed what an improvement / enhancement is for. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17678#issuecomment-1924699469 From eirbjo at openjdk.org Fri Feb 2 21:20:29 2024 From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=) Date: Fri, 2 Feb 2024 21:20:29 GMT Subject: RFR: 8324635: (zipfs) Regression in Files.setPosixFilePermissions called on existing MSDOS entries [v2] In-Reply-To: <4-JvAWwMDyx-5tMy_qnVwOE3zdUZITFo4-LR-Ascmrc=.0eb713b7-07c3-4884-af42-401ecce11325@github.com> References: <4-JvAWwMDyx-5tMy_qnVwOE3zdUZITFo4-LR-Ascmrc=.0eb713b7-07c3-4884-af42-401ecce11325@github.com> Message-ID: > Please review this PR to fix to a regression in ZipFileSystem, introduced by JDK-8322565 in PR #17170. > > When `Files.setPosixFilePermissions` is called on an existing MSDOS entry, then `Entry.posixPerms` field will be -1 (all 1s in binary). The logic introduced by JDK-8322565 did not account for this and incorrectly sets the leading seven bits to all ones instead of all zeros. > > The fix is to introduce a branch for `Entry.posixPerms` being -1 and deal with that case separately. > > The PR adds a test case to `TestPosix` which reproduces the regression. While visiting this test, I also fixed an incorrect spelling of `setPosixFilePermissions` (also introduced by #17170). Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision: For clarity, add comments with the before/after zipdetails output of the relevant CEN fields ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17556/files - new: https://git.openjdk.org/jdk/pull/17556/files/dabe0fb7..4bb77e1e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17556&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17556&range=00-01 Stats: 22 lines in 1 file changed: 20 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/17556.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17556/head:pull/17556 PR: https://git.openjdk.org/jdk/pull/17556 From eirbjo at openjdk.org Fri Feb 2 21:20:30 2024 From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=) Date: Fri, 2 Feb 2024 21:20:30 GMT Subject: RFR: 8324635: (zipfs) Regression in Files.setPosixFilePermissions called on existing MSDOS entries [v2] In-Reply-To: References: <4-JvAWwMDyx-5tMy_qnVwOE3zdUZITFo4-LR-Ascmrc=.0eb713b7-07c3-4884-af42-401ecce11325@github.com> Message-ID: On Fri, 2 Feb 2024 20:01:06 GMT, Lance Andersen wrote: > It might be helpful to show the before/after output of the CEN fields here just for extra clarity Thanks! Can you take a look at 4bb77e1 which shows the `zipdetails` output for relevant fields before/after calling `setPosixFilePermissions`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17556#discussion_r1476739887 From lancea at openjdk.org Fri Feb 2 21:37:11 2024 From: lancea at openjdk.org (Lance Andersen) Date: Fri, 2 Feb 2024 21:37:11 GMT Subject: RFR: 8324635: (zipfs) Regression in Files.setPosixFilePermissions called on existing MSDOS entries [v2] In-Reply-To: References: <4-JvAWwMDyx-5tMy_qnVwOE3zdUZITFo4-LR-Ascmrc=.0eb713b7-07c3-4884-af42-401ecce11325@github.com> Message-ID: On Fri, 2 Feb 2024 21:20:29 GMT, Eirik Bj?rsn?s wrote: >> Please review this PR to fix to a regression in ZipFileSystem, introduced by JDK-8322565 in PR #17170. >> >> When `Files.setPosixFilePermissions` is called on an existing MSDOS entry, then `Entry.posixPerms` field will be -1 (all 1s in binary). The logic introduced by JDK-8322565 did not account for this and incorrectly sets the leading seven bits to all ones instead of all zeros. >> >> The fix is to introduce a branch for `Entry.posixPerms` being -1 and deal with that case separately. >> >> The PR adds a test case to `TestPosix` which reproduces the regression. While visiting this test, I also fixed an incorrect spelling of `setPosixFilePermissions` (also introduced by #17170). > > Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision: > > For clarity, add comments with the before/after zipdetails output of the relevant CEN fields Marked as reviewed by lancea (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/17556#pullrequestreview-1860426767 From lancea at openjdk.org Fri Feb 2 21:37:11 2024 From: lancea at openjdk.org (Lance Andersen) Date: Fri, 2 Feb 2024 21:37:11 GMT Subject: RFR: 8324635: (zipfs) Regression in Files.setPosixFilePermissions called on existing MSDOS entries [v2] In-Reply-To: References: <4-JvAWwMDyx-5tMy_qnVwOE3zdUZITFo4-LR-Ascmrc=.0eb713b7-07c3-4884-af42-401ecce11325@github.com> Message-ID: On Fri, 2 Feb 2024 21:17:48 GMT, Eirik Bj?rsn?s wrote: >> test/jdk/jdk/nio/zipfs/TestPosix.java line 757: >> >>> 755: try (FileSystem fs = FileSystems.newFileSystem(ZIP_FILE, ENV_POSIX)) { >>> 756: Path path = fs.getPath("hello.txt"); >>> 757: Files.setPosixFilePermissions(path, EnumSet.of(OWNER_READ)); >> >> It might be helpful to show the before/after output of the CEN fields here just for extra clarity > >> It might be helpful to show the before/after output of the CEN fields here just for extra clarity > > Thanks! Can you take a look at 4bb77e1 which shows the `zipdetails` output for relevant fields before/after calling `setPosixFilePermissions`. thank you Looks good ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17556#discussion_r1476753283 From redestad at openjdk.org Fri Feb 2 21:45:12 2024 From: redestad at openjdk.org (Claes Redestad) Date: Fri, 2 Feb 2024 21:45:12 GMT Subject: RFR: 8325169: Reduce String::indexOf overheads [v2] In-Reply-To: <6JFAtUUQ4Uel7cjfHr0SbQYIM7e9bWZ65hcvFHA1qNo=.a2d2e97f-086d-46d1-82cf-c2f74b0c655a@github.com> References: <6JFAtUUQ4Uel7cjfHr0SbQYIM7e9bWZ65hcvFHA1qNo=.a2d2e97f-086d-46d1-82cf-c2f74b0c655a@github.com> Message-ID: <2ebJf0wGVxQlZ81PyQYfrYrLWlFMVMwv5PB_S8zw_Bg=.cb66fa3d-9592-48cd-bbf0-ac1d83848241@github.com> On Fri, 2 Feb 2024 20:53:14 GMT, Claes Redestad wrote: >> This patch streamlines and specializes various `String::indexOf` methods. Mainly avoids the need for clamping and doing checks that are redundant in almost all cases, moving the checks to the API boundary where they are needed. >> >> This improves performance both at peak and during startup/warmup. Since indexOf is heavily used in bootstrapping code it makes sense to slightly dial back abstraction and delegation, which in this case also brought some benefit to peak performance. >> >> Testing: tier1-3 > > Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: > > Add comment about preconditions Thanks for looking at this! I want to do a thorough check of all the intrinsics myself before I feel comfortable integrating. Tests should cover most out-of-bounds scenarios, but I'll double-check that as well. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17685#issuecomment-1924740139 From liangchenblue at gmail.com Fri Feb 2 21:48:59 2024 From: liangchenblue at gmail.com (-) Date: Fri, 2 Feb 2024 15:48:59 -0600 Subject: Object creation from iterating Map.of()/Set.of()/List.of() In-Reply-To: References: Message-ID: Also see https://github.com/openjdk/jdk/pull/15614, which removes caching in `AbstractMap` etc, meaning once Valhalla is out, the anonymous set will be a value object with no overhead. In addition, hotspot already has an escape analysis mechanism which can optimize iterators to index for loops if it determines an iterator does not get shared. On Fri, Feb 2, 2024 at 2:54?PM Jason Mehrens wrote: > See: https://bugs.openjdk.org/browse/JDK-8193128 > > Jason > ------------------------------ > *From:* core-libs-dev on behalf of Ryan > Ernst > *Sent:* Friday, February 2, 2024 1:42 PM > *To:* core-libs-dev at openjdk.org > *Subject:* Object creation from iterating Map.of()/Set.of()/List.of() > > The newer ?of? methods in collections are really nice, they make creating > these collections much easier and often result in better performance. > However, the empty collection cases with Map.of()/Set.of()/List.of() has > one small downside. The implementations within ImmutableCollections use > non-specialized implementations for zero sized collections. For example, > ImmutableCollections.EMPTY_MAP is a MapN. If you iterate over that Map, > even if it is empty as in the case for Map.of(), a new anonymous > AbstractSet is created. In comparison, Collections.emptyMap().entrySet() > returns emptySet(). > > I don?t know what the reasoning was for rebuilding the empty based > variants in ImmutableCollections. But regardless, it seems like the empty > collections defined in ImmutableCollections should likewise never construct > any objects. > > I?m happy to raise a PR to either mimic or reuse the empty collection > implementations from Collections, but I wanted to check there isn?t some > reasoning the of() methods work this way. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eirbjo at openjdk.org Fri Feb 2 21:53:10 2024 From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=) Date: Fri, 2 Feb 2024 21:53:10 GMT Subject: Integrated: 8324635: (zipfs) Regression in Files.setPosixFilePermissions called on existing MSDOS entries In-Reply-To: <4-JvAWwMDyx-5tMy_qnVwOE3zdUZITFo4-LR-Ascmrc=.0eb713b7-07c3-4884-af42-401ecce11325@github.com> References: <4-JvAWwMDyx-5tMy_qnVwOE3zdUZITFo4-LR-Ascmrc=.0eb713b7-07c3-4884-af42-401ecce11325@github.com> Message-ID: On Wed, 24 Jan 2024 14:34:03 GMT, Eirik Bj?rsn?s wrote: > Please review this PR to fix to a regression in ZipFileSystem, introduced by JDK-8322565 in PR #17170. > > When `Files.setPosixFilePermissions` is called on an existing MSDOS entry, then `Entry.posixPerms` field will be -1 (all 1s in binary). The logic introduced by JDK-8322565 did not account for this and incorrectly sets the leading seven bits to all ones instead of all zeros. > > The fix is to introduce a branch for `Entry.posixPerms` being -1 and deal with that case separately. > > The PR adds a test case to `TestPosix` which reproduces the regression. While visiting this test, I also fixed an incorrect spelling of `setPosixFilePermissions` (also introduced by #17170). This pull request has now been integrated. Changeset: a18b03b8 Author: Eirik Bj?rsn?s URL: https://git.openjdk.org/jdk/commit/a18b03b86fdd0eef773badbced46607a8e5a068a Stats: 51 lines in 2 files changed: 49 ins; 0 del; 2 mod 8324635: (zipfs) Regression in Files.setPosixFilePermissions called on existing MSDOS entries Reviewed-by: lancea ------------- PR: https://git.openjdk.org/jdk/pull/17556 From redestad at openjdk.org Fri Feb 2 22:02:11 2024 From: redestad at openjdk.org (Claes Redestad) Date: Fri, 2 Feb 2024 22:02:11 GMT Subject: RFR: 8321468: Remove StringUTF16::equals In-Reply-To: <7I-SN7RC5JdW0PWegMBa6c7idd27jT6oV2I7nvgRTi4=.86acebe9-5b2d-4b8d-9ce7-abc88ef80013@github.com> References: <7I-SN7RC5JdW0PWegMBa6c7idd27jT6oV2I7nvgRTi4=.86acebe9-5b2d-4b8d-9ce7-abc88ef80013@github.com> Message-ID: On Fri, 2 Feb 2024 18:45:22 GMT, Vladimir Kozlov wrote: > I don't see x86 changes. Why? The 2-byte variants for `string_equals`, if they ever existed, seems to be gone: // fast string equals instruct string_equals(rdi_RegP str1, rsi_RegP str2, rcx_RegI cnt, rax_RegI result, legRegD tmp1, legRegD tmp2, rbx_RegI tmp3, rFlagsReg cr) %{ predicate(!VM_Version::supports_avx512vlbw()); match(Set result (StrEquals (Binary str1 str2) cnt)); effect(TEMP tmp1, TEMP tmp2, USE_KILL str1, USE_KILL str2, USE_KILL cnt, KILL tmp3, KILL cr); format %{ "String Equals $str1,$str2,$cnt -> $result // KILL $tmp1, $tmp2, $tmp3" %} ins_encode %{ __ arrays_equals(false, $str1$$Register, $str2$$Register, $cnt$$Register, $result$$Register, $tmp3$$Register, $tmp1$$XMMRegister, $tmp2$$XMMRegister, false /* char */, knoreg); %} ins_pipe( pipe_slow ); %} So AFAICT there is nothing to change on x86. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16995#issuecomment-1924766391 From rgiulietti at openjdk.org Fri Feb 2 22:08:06 2024 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Fri, 2 Feb 2024 22:08:06 GMT Subject: RFR: 8325169: Reduce String::indexOf overheads [v2] In-Reply-To: <6JFAtUUQ4Uel7cjfHr0SbQYIM7e9bWZ65hcvFHA1qNo=.a2d2e97f-086d-46d1-82cf-c2f74b0c655a@github.com> References: <6JFAtUUQ4Uel7cjfHr0SbQYIM7e9bWZ65hcvFHA1qNo=.a2d2e97f-086d-46d1-82cf-c2f74b0c655a@github.com> Message-ID: On Fri, 2 Feb 2024 20:53:14 GMT, Claes Redestad wrote: >> This patch streamlines and specializes various `String::indexOf` methods. Mainly avoids the need for clamping and doing checks that are redundant in almost all cases, moving the checks to the API boundary where they are needed. >> >> This improves performance both at peak and during startup/warmup. Since indexOf is heavily used in bootstrapping code it makes sense to slightly dial back abstraction and delegation, which in this case also brought some benefit to peak performance. >> >> Testing: tier1-3 > > Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: > > Add comment about preconditions LGTM ------------- Marked as reviewed by rgiulietti (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17685#pullrequestreview-1860479471 From jlu at openjdk.org Fri Feb 2 22:16:30 2024 From: jlu at openjdk.org (Justin Lu) Date: Fri, 2 Feb 2024 22:16:30 GMT Subject: RFR: JDK-8318761: MessageFormat pattern support for CompactNumberFormat, ListFormat, and DateTimeFormatter [v2] In-Reply-To: References: Message-ID: <5QAKwv2dbNhOoI9r6VpDKs-9rTbV4pBqazNWYZCKtQA=.4bb56f5f-4ea7-44c9-a6c5-ac10f70b371b@github.com> > Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8319344) which adds MessageFormat pattern support for the following subformats: ListFormat, CompactNumberFormat, and DateTimeFormatter. This change is intended to provide pattern support for the more recently added JDK Format subclasses, as well as improving java.time formatting within i18n. The draft javadoc can be viewed here: https://cr.openjdk.org/~jlu/docs/api/java.base/java/text/MessageFormat.html. Please see the CSR for more in-depth behavioral changes, as well as limitations. > > The `FormatTypes`: dtf_date, dtf_time, dtf_datetime, pre-defined DateTimeFormatter(s), and list are added. > The `FormatStyles`: compact_short, compact_long, or, and unit are added. > > For example, previously, > > > Object[] args = {LocalDate.of(2023, 11, 16), LocalDate.of(2023, 11, 27)}; > MessageFormat.format("It was {0,date,full}, now it is {1,date,full}", args); > > > would throw `Exception java.lang.IllegalArgumentException: Cannot format given Object as a Date` > > Now, a user can call > > > MessageFormat.format("It was {0,dtf_date,full}, now it is {1,dtf_date,full}", args); > > > which returns "It was Thursday, November 16, 2023, now it is Friday, November 17, 2023" Justin Lu has updated the pull request incrementally with one additional commit since the last revision: reflect Naoto's comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17663/files - new: https://git.openjdk.org/jdk/pull/17663/files/cd15b398..264799b0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17663&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17663&range=00-01 Stats: 59 lines in 2 files changed: 6 ins; 21 del; 32 mod Patch: https://git.openjdk.org/jdk/pull/17663.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17663/head:pull/17663 PR: https://git.openjdk.org/jdk/pull/17663 From jlu at openjdk.org Fri Feb 2 22:16:30 2024 From: jlu at openjdk.org (Justin Lu) Date: Fri, 2 Feb 2024 22:16:30 GMT Subject: RFR: JDK-8318761: MessageFormat pattern support for CompactNumberFormat, ListFormat, and DateTimeFormatter In-Reply-To: References: Message-ID: On Wed, 31 Jan 2024 22:24:14 GMT, Justin Lu wrote: > Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8319344) which adds MessageFormat pattern support for the following subformats: ListFormat, CompactNumberFormat, and DateTimeFormatter. This change is intended to provide pattern support for the more recently added JDK Format subclasses, as well as improving java.time formatting within i18n. The draft javadoc can be viewed here: https://cr.openjdk.org/~jlu/docs/api/java.base/java/text/MessageFormat.html. Please see the CSR for more in-depth behavioral changes, as well as limitations. > > The `FormatTypes`: dtf_date, dtf_time, dtf_datetime, pre-defined DateTimeFormatter(s), and list are added. > The `FormatStyles`: compact_short, compact_long, or, and unit are added. > > For example, previously, > > > Object[] args = {LocalDate.of(2023, 11, 16), LocalDate.of(2023, 11, 27)}; > MessageFormat.format("It was {0,date,full}, now it is {1,date,full}", args); > > > would throw `Exception java.lang.IllegalArgumentException: Cannot format given Object as a Date` > > Now, a user can call > > > MessageFormat.format("It was {0,dtf_date,full}, now it is {1,dtf_date,full}", args); > > > which returns "It was Thursday, November 16, 2023, now it is Friday, November 17, 2023" > Slightly tangential question (since you're talking about adding new subformats)... > > Has it ever been considered to add `MessageFormat` itself as a subformat option? > > It's not as crazy an idea as it sounds :) Here's an example: > > ```java > MessageFormat f = new MessageFormat( > "Result: {0,choice,0#no letters|1#one letter: {1,message,'{0}'}|2#two letters: {1,message,'{0} and {1}'}}"); > f.format(new Object[] { 2, new Object[] { "A", "B" } }); // "Result: two letters: A and B" > ``` Definitely an interesting idea, although I think the pattern syntax is generally reserved for common use cases, I'm not sure if this would be that common. Something to think about/consider though, although it would be beyond the scope of this change. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17663#issuecomment-1924779134 From jlu at openjdk.org Fri Feb 2 22:16:31 2024 From: jlu at openjdk.org (Justin Lu) Date: Fri, 2 Feb 2024 22:16:31 GMT Subject: RFR: JDK-8318761: MessageFormat pattern support for CompactNumberFormat, ListFormat, and DateTimeFormatter [v2] In-Reply-To: References: Message-ID: On Thu, 1 Feb 2024 19:50:30 GMT, Naoto Sato wrote: >> Justin Lu has updated the pull request incrementally with one additional commit since the last revision: >> >> reflect Naoto's comments > > src/java.base/share/classes/java/text/MessageFormat.java line 370: > >> 368: * >> 369: * MessageFormat provides patterns that support both the {@link java.time} package >> 370: * and the {@link Date java.util.Date} type. Consider the following three examples, > > Might read better with "patterns that support the date/time formatters in the java.time.format and java.text packages" Updated as suggested. > src/java.base/share/classes/java/text/MessageFormat.java line 375: > >> 373: *

1) a date {@code FormatType} with a full {@code FormatStyle}, >> 374: * {@snippet lang=java : >> 375: * Object[] arg = {new Date(2023, 11, 16)}; > > This is not correct (year and month are wrong), and actually should not be used in an example as the 3-arg constructor is deprecated. Use `Calendar.getTime()` to obtain a `Date` instead. oops - should have caught this, replaced with `Calendar.getTime()` as recommended > src/java.base/share/classes/java/text/MessageFormat.java line 676: > >> 674: * java.time.format.DateTimeFormatter}. In addition, {@code DateTimeFormatter} >> 675: * does not implement {@code equals()}, and thus cannot be represented as a >> 676: * pattern. Any "default"/"medium" styles are omitted according to the specification. > > Since `DateTimeFormatter` eventually are converted to j.t.Format with `toFormat()` method, wouldn't it be possible to implement this method for those dtf(s)? We discussed this separately, but will go over again here in case others are interested. Since DTF does not implement `equals()`, even if we implement `equals()` for the `ClassicFormat`, we would basically still need to implement our own `equals()` for a DTF to effectively compare the ClassicFormats. I had also mentioned that we could reference check the pre-defined DTFs, but this won't work either actually. This is because we cannot reference check the DTFs, but rather the Format adapted DTFs, which mean they are now new ClassicFormats every time since we don't store them. > src/java.base/share/classes/java/text/MessageFormat.java line 1868: > >> 1866: throw new IllegalArgumentException(); >> 1867: } >> 1868: } > > Can this be replaced with `Enum.valueOf(String)`, after input is normalized? Good point, changed and also removed the `.text` field from the `FormatType` enum, as the enum name is 1 to 1 with the input String. > src/java.base/share/classes/java/text/MessageFormat.java line 1904: > >> 1902: throw new IllegalArgumentException(); >> 1903: } >> 1904: } > > Same as above. I would rather use `fromString(String text)` here, as using `Enum.valueOf()` does not work as smoothly as `FormatType`, since the `FormatStyle.text` value does not always match the `FormatStyle` enum name. For example, `FormatStyle.DEFAULT` has a `.text` value of "". So I would have to convert a "" to "default" to check for `FormatStyle.DEFAULT` via `Enum.valueOf()`, but at the same time, this also means that the behavior would now change to accept "default" as `FormatStyle.DEFAULT` (which is not in the spec). I could then add extra code to handle the "default" case, but I think at that point it would be much too much complexity. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17663#discussion_r1476794026 PR Review Comment: https://git.openjdk.org/jdk/pull/17663#discussion_r1476794049 PR Review Comment: https://git.openjdk.org/jdk/pull/17663#discussion_r1476794075 PR Review Comment: https://git.openjdk.org/jdk/pull/17663#discussion_r1476794095 PR Review Comment: https://git.openjdk.org/jdk/pull/17663#discussion_r1476794127 From naoto at openjdk.org Fri Feb 2 22:29:01 2024 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 2 Feb 2024 22:29:01 GMT Subject: RFR: JDK-8318761: MessageFormat pattern support for CompactNumberFormat, ListFormat, and DateTimeFormatter In-Reply-To: References: Message-ID: On Fri, 2 Feb 2024 22:13:39 GMT, Justin Lu wrote: > > Slightly tangential question (since you're talking about adding new subformats)... > > Has it ever been considered to add `MessageFormat` itself as a subformat option? > > It's not as crazy an idea as it sounds :) Here's an example: > > ```java > > MessageFormat f = new MessageFormat( > > "Result: {0,choice,0#no letters|1#one letter: {1,message,'{0}'}|2#two letters: {1,message,'{0} and {1}'}}"); > > f.format(new Object[] { 2, new Object[] { "A", "B" } }); // "Result: two letters: A and B" > > ``` > > Definitely an interesting idea, although I think the pattern syntax is generally reserved for common use cases, I'm not sure if this would be that common. Something to think about/consider though, although it would be beyond the scope of this change. I agree with Justin. Not that justifiable for our commitment in the future. BTW, the said example can nicely be handled with `ListFormat` IMO. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17663#issuecomment-1924795058 From naoto at openjdk.org Fri Feb 2 22:29:02 2024 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 2 Feb 2024 22:29:02 GMT Subject: RFR: JDK-8318761: MessageFormat pattern support for CompactNumberFormat, ListFormat, and DateTimeFormatter [v2] In-Reply-To: References: Message-ID: On Fri, 2 Feb 2024 22:11:17 GMT, Justin Lu wrote: >> src/java.base/share/classes/java/text/MessageFormat.java line 676: >> >>> 674: * java.time.format.DateTimeFormatter}. In addition, {@code DateTimeFormatter} >>> 675: * does not implement {@code equals()}, and thus cannot be represented as a >>> 676: * pattern. Any "default"/"medium" styles are omitted according to the specification. >> >> Since `DateTimeFormatter` eventually are converted to j.t.Format with `toFormat()` method, wouldn't it be possible to implement this method for those dtf(s)? > > We discussed this separately, but will go over again here in case others are interested. Since DTF does not implement `equals()`, even if we implement `equals()` for the `ClassicFormat`, we would basically still need to implement our own `equals()` for a DTF to effectively compare the ClassicFormats. > > I had also mentioned that we could reference check the pre-defined DTFs, but this won't work either actually. This is because we cannot reference check the DTFs, but rather the Format adapted DTFs, which mean they are now new ClassicFormats every time since we don't store them. Thanks. I think it is fine. >> src/java.base/share/classes/java/text/MessageFormat.java line 1904: >> >>> 1902: throw new IllegalArgumentException(); >>> 1903: } >>> 1904: } >> >> Same as above. > > I would rather use `fromString(String text)` here, as using `Enum.valueOf()` does not work as smoothly as `FormatType`, since the `FormatStyle.text` value does not always match the `FormatStyle` enum name. > > For example, `FormatStyle.DEFAULT` has a `.text` value of "". So I would have to convert a "" to "default" to check for `FormatStyle.DEFAULT` via `Enum.valueOf()`, but at the same time, this also means that the behavior would now change to accept "default" as `FormatStyle.DEFAULT` (which is not in the spec). > > I could then add extra code to handle the "default" case, but I think at that point it would be much too much complexity compared to this `fromString()` method Let's keep this static method then. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17663#discussion_r1476805391 PR Review Comment: https://git.openjdk.org/jdk/pull/17663#discussion_r1476805499 From naoto at openjdk.org Fri Feb 2 22:38:02 2024 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 2 Feb 2024 22:38:02 GMT Subject: RFR: JDK-8318761: MessageFormat pattern support for CompactNumberFormat, ListFormat, and DateTimeFormatter [v2] In-Reply-To: <5QAKwv2dbNhOoI9r6VpDKs-9rTbV4pBqazNWYZCKtQA=.4bb56f5f-4ea7-44c9-a6c5-ac10f70b371b@github.com> References: <5QAKwv2dbNhOoI9r6VpDKs-9rTbV4pBqazNWYZCKtQA=.4bb56f5f-4ea7-44c9-a6c5-ac10f70b371b@github.com> Message-ID: On Fri, 2 Feb 2024 22:16:30 GMT, Justin Lu wrote: >> Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8319344) which adds MessageFormat pattern support for the following subformats: ListFormat, CompactNumberFormat, and DateTimeFormatter. This change is intended to provide pattern support for the more recently added JDK Format subclasses, as well as improving java.time formatting within i18n. The draft javadoc can be viewed here: https://cr.openjdk.org/~jlu/docs/api/java.base/java/text/MessageFormat.html. Please see the CSR for more in-depth behavioral changes, as well as limitations. >> >> The `FormatTypes`: dtf_date, dtf_time, dtf_datetime, pre-defined DateTimeFormatter(s), and list are added. >> The `FormatStyles`: compact_short, compact_long, or, and unit are added. >> >> For example, previously, >> >> >> Object[] args = {LocalDate.of(2023, 11, 16), LocalDate.of(2023, 11, 27)}; >> MessageFormat.format("It was {0,date,full}, now it is {1,date,full}", args); >> >> >> would throw `Exception java.lang.IllegalArgumentException: Cannot format given Object as a Date` >> >> Now, a user can call >> >> >> MessageFormat.format("It was {0,dtf_date,full}, now it is {1,dtf_date,full}", args); >> >> >> which returns "It was Thursday, November 16, 2023, now it is Friday, November 17, 2023" > > Justin Lu has updated the pull request incrementally with one additional commit since the last revision: > > reflect Naoto's comments src/java.base/share/classes/java/text/MessageFormat.java line 377: > 375: * Calendar cal = Calendar.getInstance(); > 376: * cal.set(123 + 1900, 10, 16); > 377: * Object[] arg = {cal.getTime()}; Maybe with the following, better aligned with `java.time`'s example? Object[] arg = {new GregorianCalendar(2023, Calendar.NOVEMBER, 16).getTime()}; ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17663#discussion_r1476820208 From jlu at openjdk.org Fri Feb 2 22:43:28 2024 From: jlu at openjdk.org (Justin Lu) Date: Fri, 2 Feb 2024 22:43:28 GMT Subject: RFR: JDK-8318761: MessageFormat pattern support for CompactNumberFormat, ListFormat, and DateTimeFormatter [v3] In-Reply-To: References: Message-ID: > Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8319344) which adds MessageFormat pattern support for the following subformats: ListFormat, CompactNumberFormat, and DateTimeFormatter. This change is intended to provide pattern support for the more recently added JDK Format subclasses, as well as improving java.time formatting within i18n. The draft javadoc can be viewed here: https://cr.openjdk.org/~jlu/docs/api/java.base/java/text/MessageFormat.html. Please see the CSR for more in-depth behavioral changes, as well as limitations. > > The `FormatTypes`: dtf_date, dtf_time, dtf_datetime, pre-defined DateTimeFormatter(s), and list are added. > The `FormatStyles`: compact_short, compact_long, or, and unit are added. > > For example, previously, > > > Object[] args = {LocalDate.of(2023, 11, 16), LocalDate.of(2023, 11, 27)}; > MessageFormat.format("It was {0,date,full}, now it is {1,date,full}", args); > > > would throw `Exception java.lang.IllegalArgumentException: Cannot format given Object as a Date` > > Now, a user can call > > > MessageFormat.format("It was {0,dtf_date,full}, now it is {1,dtf_date,full}", args); > > > which returns "It was Thursday, November 16, 2023, now it is Friday, November 17, 2023" Justin Lu has updated the pull request incrementally with one additional commit since the last revision: Use Naoto's recommended example ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17663/files - new: https://git.openjdk.org/jdk/pull/17663/files/264799b0..bf0174ff Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17663&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17663&range=01-02 Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/17663.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17663/head:pull/17663 PR: https://git.openjdk.org/jdk/pull/17663 From jlu at openjdk.org Fri Feb 2 22:43:28 2024 From: jlu at openjdk.org (Justin Lu) Date: Fri, 2 Feb 2024 22:43:28 GMT Subject: RFR: JDK-8318761: MessageFormat pattern support for CompactNumberFormat, ListFormat, and DateTimeFormatter [v2] In-Reply-To: References: <5QAKwv2dbNhOoI9r6VpDKs-9rTbV4pBqazNWYZCKtQA=.4bb56f5f-4ea7-44c9-a6c5-ac10f70b371b@github.com> Message-ID: On Fri, 2 Feb 2024 22:35:17 GMT, Naoto Sato wrote: >> Justin Lu has updated the pull request incrementally with one additional commit since the last revision: >> >> reflect Naoto's comments > > src/java.base/share/classes/java/text/MessageFormat.java line 377: > >> 375: * Calendar cal = Calendar.getInstance(); >> 376: * cal.set(123 + 1900, 10, 16); >> 377: * Object[] arg = {cal.getTime()}; > > Maybe with the following, better aligned with `java.time`'s example? > > Object[] arg = {new GregorianCalendar(2023, Calendar.NOVEMBER, 16).getTime()}; Thanks, that's a lot more concise, fixed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17663#discussion_r1476830875 From jlu at openjdk.org Fri Feb 2 22:49:01 2024 From: jlu at openjdk.org (Justin Lu) Date: Fri, 2 Feb 2024 22:49:01 GMT Subject: RFR: 8324665: Loose matching of space separators in the lenient date/time parsing mode [v2] In-Reply-To: References: Message-ID: On Fri, 2 Feb 2024 20:47:29 GMT, Naoto Sato wrote: >> Implementing "loose matching" of space separators in both `java.time.format.DateTimeFormatter` and `java.text.DateFormat` on lenient parsing. This will effectively fix the NNBSP issues on parsing time with am/pm markers introduced with CLDR version 42 (https://inside.java/2023/03/28/quality-heads-up/). A draft CSR has also been drafted. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Reworded spec Marked as reviewed by jlu (Committer). src/java.base/share/classes/java/text/DateFormat.java line 751: > 749: * @implSpec A {@link Character#SPACE_SEPARATOR SPACE_SEPARATOR} in the input > 750: * text will match any other {@link Character#SPACE_SEPARATOR SPACE_SEPARATOR}s > 751: * in the pattern with the lenient parsing; otherwise, it will not match. LGTM. Nit: Might read better as either "in the pattern with lenient parsing" or "in the pattern when parsing is lenient" ------------- PR Review: https://git.openjdk.org/jdk/pull/17678#pullrequestreview-1860571955 PR Review Comment: https://git.openjdk.org/jdk/pull/17678#discussion_r1476840850 From kvn at openjdk.org Fri Feb 2 22:52:02 2024 From: kvn at openjdk.org (Vladimir Kozlov) Date: Fri, 2 Feb 2024 22:52:02 GMT Subject: RFR: 8321468: Remove StringUTF16::equals In-Reply-To: References: Message-ID: <3Kl1Lnl7taMhJBnhxwEutDn9ed0FUh_ERnj-bK_J904=.8ddf9d82-625a-4056-a8be-20922afc47b0@github.com> On Wed, 6 Dec 2023 14:20:14 GMT, Claes Redestad wrote: > https://bugs.openjdk.org/browse/JDK-8215017 removed the only use of `StringUTF16::equals`. At the time I did some performance verification focused on x86 showing that simplifying and only using `StringLatin1::equals` was either neutral or a win. > > I repeated this experiment recently, adding some focused tests on aarch64 where the code generation actually tries to take advantage and generate slightly more efficient code for `StringUTF16::equals`: > https://github.com/openjdk/jdk/pull/16933#discussion_r1414118658 > > The indication here is that disabling use of `StringUTF16::equals` was the right choice: any effect from the low-level optimization (one less branch at the tail end) was offset by the `isLatin1()` branch and added code generation (that all gets inlined). > > In a `-XX:-CompactStrings` configuration the slightly improved code generation in `StringUTF16::equals` might help, since the `isLatin1()` test and subsequent call to `StringLatin1::equals` would be DCEd. To get the best of both worlds the code in `String::equals` _could_ be sharpened so that we statically pick the best implementation based on `CompactStrings` mode (see comment below). This shows a tiny win when testing with `-XX:-CompactStrings` on M1 (up to -0.2ns/op per `String::equals`; neutral on x86). But is all this complexity worth it for a gain that will get lost in the noise on anything realistic? > > This PR instead proposes removing `StringUTF16::equals` and simplifying the mechanisms to support the `StringLatin1/UTF16::equals` pair of intrinsics in hotspot. You are right. I mistook `string_compareU*` instructions for it. Can you check history why we don't have it in x86*.ad? ------------- PR Comment: https://git.openjdk.org/jdk/pull/16995#issuecomment-1924855153 From rriggs at openjdk.org Fri Feb 2 22:55:00 2024 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 2 Feb 2024 22:55:00 GMT Subject: RFR: 8324665: Loose matching of space separators in the lenient date/time parsing mode In-Reply-To: References: Message-ID: On Fri, 2 Feb 2024 21:08:33 GMT, Joe Wang wrote: > You are right, Joe. Apps using `java.time` formatters would still need to make changes to their code base. However, the bar is significantly lower. They would have to write some ugly workaround without this fix. I'd also expect that applications accepting user input may already be using lenient mode to make the application easier to use; so in come cases, it will come without new code changes. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17678#issuecomment-1924866263 From naoto at openjdk.org Fri Feb 2 23:02:28 2024 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 2 Feb 2024 23:02:28 GMT Subject: RFR: 8324665: Loose matching of space separators in the lenient date/time parsing mode [v3] In-Reply-To: References: Message-ID: > Implementing "loose matching" of space separators in both `java.time.format.DateTimeFormatter` and `java.text.DateFormat` on lenient parsing. This will effectively fix the NNBSP issues on parsing time with am/pm markers introduced with CLDR version 42 (https://inside.java/2023/03/28/quality-heads-up/). A draft CSR has also been drafted. Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: Fixed wording ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17678/files - new: https://git.openjdk.org/jdk/pull/17678/files/0c950941..6fb0f05b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17678&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17678&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/17678.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17678/head:pull/17678 PR: https://git.openjdk.org/jdk/pull/17678 From naoto at openjdk.org Fri Feb 2 23:02:28 2024 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 2 Feb 2024 23:02:28 GMT Subject: RFR: 8324665: Loose matching of space separators in the lenient date/time parsing mode [v2] In-Reply-To: References: Message-ID: On Fri, 2 Feb 2024 22:46:34 GMT, Justin Lu wrote: >> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: >> >> Reworded spec > > src/java.base/share/classes/java/text/DateFormat.java line 751: > >> 749: * @implSpec A {@link Character#SPACE_SEPARATOR SPACE_SEPARATOR} in the input >> 750: * text will match any other {@link Character#SPACE_SEPARATOR SPACE_SEPARATOR}s >> 751: * in the pattern with the lenient parsing; otherwise, it will not match. > > LGTM. > > Nit: Might read better as either "in the pattern with lenient parsing" or "in the pattern when parsing is lenient" Thanks. Fixed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17678#discussion_r1476851850 From sviswanathan at openjdk.org Fri Feb 2 23:18:06 2024 From: sviswanathan at openjdk.org (Sandhya Viswanathan) Date: Fri, 2 Feb 2024 23:18:06 GMT Subject: RFR: 8318650: Optimized subword gather for x86 targets. [v12] In-Reply-To: References: Message-ID: On Thu, 1 Feb 2024 16:24:16 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 using 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.5-10x 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. >> >> Kindly review and share your feedback. >> >> Best Regards, >> Jatin > > Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits: > > - Generalizing masked sub-gather support. > - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8318650 > - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8318650 > - Fix incorrect comment > - Review comments resolutions. > - Review comments resolutions. > - Review comments resolutions. > - Restricting masked sub-word gather to AVX512 target to align with integral gather support. > - Review comments resolution. > - 8318650: Optimized subword gather for x86 targets. I only have two comments, rest of the PR looks good to me. Thanks for taking a conservative stance and reverting to a simple solution for now. src/hotspot/cpu/x86/x86.ad line 4255: > 4253: %} > 4254: > 4255: instruct vgather_masked_subwordLE8B_avx2(vec dst, memory mem, rRegP idx, immI_0 offset, vec mask, rRegL midx, rRegP tmp, rRegI rtmp, rRegL rtmp2) %{ We need to kill rFlagsReg here and other avx2 instructs added since my last review. src/hotspot/cpu/x86/x86.ad line 4268: > 4266: __ mov64($midx$$Register, 0x5555555555555555ULL); > 4267: __ pextq($rtmp2$$Register, $rtmp2$$Register, $midx$$Register); > 4268: } This could be movl and pextd in newly added avx2 instructs as we are limited to 32 byte vectors. ------------- PR Review: https://git.openjdk.org/jdk/pull/16354#pullrequestreview-1860528833 PR Review Comment: https://git.openjdk.org/jdk/pull/16354#discussion_r1476816723 PR Review Comment: https://git.openjdk.org/jdk/pull/16354#discussion_r1476828631 From naoto at openjdk.org Fri Feb 2 23:22:01 2024 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 2 Feb 2024 23:22:01 GMT Subject: RFR: JDK-8318761: MessageFormat pattern support for CompactNumberFormat, ListFormat, and DateTimeFormatter [v3] In-Reply-To: References: Message-ID: On Fri, 2 Feb 2024 22:43:28 GMT, Justin Lu wrote: >> Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8319344) which adds MessageFormat pattern support for the following subformats: ListFormat, CompactNumberFormat, and DateTimeFormatter. This change is intended to provide pattern support for the more recently added JDK Format subclasses, as well as improving java.time formatting within i18n. The draft javadoc can be viewed here: https://cr.openjdk.org/~jlu/docs/api/java.base/java/text/MessageFormat.html. Please see the CSR for more in-depth behavioral changes, as well as limitations. >> >> The `FormatTypes`: dtf_date, dtf_time, dtf_datetime, pre-defined DateTimeFormatter(s), and list are added. >> The `FormatStyles`: compact_short, compact_long, or, and unit are added. >> >> For example, previously, >> >> >> Object[] args = {LocalDate.of(2023, 11, 16), LocalDate.of(2023, 11, 27)}; >> MessageFormat.format("It was {0,date,full}, now it is {1,date,full}", args); >> >> >> would throw `Exception java.lang.IllegalArgumentException: Cannot format given Object as a Date` >> >> Now, a user can call >> >> >> MessageFormat.format("It was {0,dtf_date,full}, now it is {1,dtf_date,full}", args); >> >> >> which returns "It was Thursday, November 16, 2023, now it is Friday, November 17, 2023" > > Justin Lu has updated the pull request incrementally with one additional commit since the last revision: > > Use Naoto's recommended example LGTM ------------- Marked as reviewed by naoto (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17663#pullrequestreview-1860617335 From darcy at openjdk.org Fri Feb 2 23:41:11 2024 From: darcy at openjdk.org (Joe Darcy) Date: Fri, 2 Feb 2024 23:41:11 GMT Subject: RFR: JDK-8325189: Enable this-escape javac warning in java.base Message-ID: After the "this-escape" lint warning was added to javac (JDK-8015831), the base module was not updated to be able to compile with this warning enabled. This PR makes the necessary changes to allow the base module to build with the warning enabled. ------------- Commit messages: - JDK-8325189: Enable this-escape javac warning in java.base Changes: https://git.openjdk.org/jdk/pull/17692/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17692&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8325189 Stats: 151 lines in 93 files changed: 149 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/17692.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17692/head:pull/17692 PR: https://git.openjdk.org/jdk/pull/17692 From darcy at openjdk.org Fri Feb 2 23:41:11 2024 From: darcy at openjdk.org (Joe Darcy) Date: Fri, 2 Feb 2024 23:41:11 GMT Subject: RFR: JDK-8325189: Enable this-escape javac warning in java.base In-Reply-To: References: Message-ID: On Fri, 2 Feb 2024 23:36:41 GMT, Joe Darcy wrote: > After the "this-escape" lint warning was added to javac (JDK-8015831), the base module was not updated to be able to compile with this warning enabled. This PR makes the necessary changes to allow the base module to build with the warning enabled. In its initial form, the changes are tested on Linux. Later on, I'll do cross-platform builds to make sure there aren't any, say, windows-specific changes that are needed as well. I can file a follow-up umbrella bug with the original list of ~200 warnings so the constructors and initializers in question can be examined to see if they should be updated. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17692#issuecomment-1924907536 From redestad at openjdk.org Sat Feb 3 00:09:01 2024 From: redestad at openjdk.org (Claes Redestad) Date: Sat, 3 Feb 2024 00:09:01 GMT Subject: RFR: 8321468: Remove StringUTF16::equals In-Reply-To: References: Message-ID: On Wed, 6 Dec 2023 14:20:14 GMT, Claes Redestad wrote: > https://bugs.openjdk.org/browse/JDK-8215017 removed the only use of `StringUTF16::equals`. At the time I did some performance verification focused on x86 showing that simplifying and only using `StringLatin1::equals` was either neutral or a win. > > I repeated this experiment recently, adding some focused tests on aarch64 where the code generation actually tries to take advantage and generate slightly more efficient code for `StringUTF16::equals`: > https://github.com/openjdk/jdk/pull/16933#discussion_r1414118658 > > The indication here is that disabling use of `StringUTF16::equals` was the right choice: any effect from the low-level optimization (one less branch at the tail end) was offset by the `isLatin1()` branch and added code generation (that all gets inlined). > > In a `-XX:-CompactStrings` configuration the slightly improved code generation in `StringUTF16::equals` might help, since the `isLatin1()` test and subsequent call to `StringLatin1::equals` would be DCEd. To get the best of both worlds the code in `String::equals` _could_ be sharpened so that we statically pick the best implementation based on `CompactStrings` mode (see comment below). This shows a tiny win when testing with `-XX:-CompactStrings` on M1 (up to -0.2ns/op per `String::equals`; neutral on x86). But is all this complexity worth it for a gain that will get lost in the noise on anything realistic? > > This PR instead proposes removing `StringUTF16::equals` and simplifying the mechanisms to support the `StringLatin1/UTF16::equals` pair of intrinsics in hotspot. The x86 `string_equals` instruction pre-dates and was updated for the Compact Strings JEP. No specialized 2-byte variants: https://github.com/openjdk/jdk/commit/7af927f9c10923b61f746eb6e566bcda853dd95a#diff-89791d4b051172965f7ba8f0cb7afbeb7e141f6de924dc07167c5ceefdce6bbe A bit strange since distinct 1-byte `array_equalsB` and 2-byte `array_equalsC` were introduced at this time, sharing code. So either an unintended omission, or the benefit of having both variants didn't manifest in benchmarks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16995#issuecomment-1924924403 From kvn at openjdk.org Sat Feb 3 00:41:06 2024 From: kvn at openjdk.org (Vladimir Kozlov) Date: Sat, 3 Feb 2024 00:41:06 GMT Subject: RFR: 8321468: Remove StringUTF16::equals In-Reply-To: References: Message-ID: On Wed, 6 Dec 2023 14:20:14 GMT, Claes Redestad wrote: > https://bugs.openjdk.org/browse/JDK-8215017 removed the only use of `StringUTF16::equals`. At the time I did some performance verification focused on x86 showing that simplifying and only using `StringLatin1::equals` was either neutral or a win. > > I repeated this experiment recently, adding some focused tests on aarch64 where the code generation actually tries to take advantage and generate slightly more efficient code for `StringUTF16::equals`: > https://github.com/openjdk/jdk/pull/16933#discussion_r1414118658 > > The indication here is that disabling use of `StringUTF16::equals` was the right choice: any effect from the low-level optimization (one less branch at the tail end) was offset by the `isLatin1()` branch and added code generation (that all gets inlined). > > In a `-XX:-CompactStrings` configuration the slightly improved code generation in `StringUTF16::equals` might help, since the `isLatin1()` test and subsequent call to `StringLatin1::equals` would be DCEd. To get the best of both worlds the code in `String::equals` _could_ be sharpened so that we statically pick the best implementation based on `CompactStrings` mode (see comment below). This shows a tiny win when testing with `-XX:-CompactStrings` on M1 (up to -0.2ns/op per `String::equals`; neutral on x86). But is all this complexity worth it for a gain that will get lost in the noise on anything realistic? > > This PR instead proposes removing `StringUTF16::equals` and simplifying the mechanisms to support the `StringLatin1/UTF16::equals` pair of intrinsics in hotspot. Good. Thank you for checking. ------------- Marked as reviewed by kvn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16995#pullrequestreview-1860686125 PR Comment: https://git.openjdk.org/jdk/pull/16995#issuecomment-1924943916 From redestad at openjdk.org Sat Feb 3 01:04:04 2024 From: redestad at openjdk.org (Claes Redestad) Date: Sat, 3 Feb 2024 01:04:04 GMT Subject: RFR: 8325169: Reduce String::indexOf overheads [v2] In-Reply-To: <3Bd_zBors5V8_uHwG3VE_HzDICmStS9hCn-fNU96MvM=.c8421d00-56fb-4f0f-8d44-17c616ca9c57@github.com> References: <3Bd_zBors5V8_uHwG3VE_HzDICmStS9hCn-fNU96MvM=.c8421d00-56fb-4f0f-8d44-17c616ca9c57@github.com> Message-ID: <7NKg49y8r4r4rNH0O5fDwYrOLX0hLF0DyQuTC7I3AAs=.b087da38-3a80-4b21-900b-f19e48ee405f@github.com> On Fri, 2 Feb 2024 16:40:45 GMT, Raffaello Giulietti wrote: >> src/java.base/share/classes/java/lang/String.java line 2506: >> >>> 2504: fromIndex = Math.max(0, fromIndex); >>> 2505: return isLatin1() ? StringLatin1.indexOf(value, ch, fromIndex, value.length) >>> 2506: : StringUTF16.indexOf(value, ch, fromIndex, value.length >> 1); >> >> This?needs to?include the?check for?`fromIndex >=?this.length()`: >> Suggestion: >> >> fromIndex = Math.max(0, fromIndex); >> int toIndex = length(); >> if (fromIndex >= toIndex) { >> return -1; >> } >> return isLatin1() >> ? StringLatin1.indexOf(value, ch, fromIndex, toIndex) >> : StringUTF16.indexOf(value, ch, fromIndex, toIndex); > > I don't think so. > If you deeply follow the invoked `indexOf()` methods, there's either a check later, or the loop conditions are false on entry (although I'm not sure about the intrinsic methods). While not directly observable (all tests pass) then sadly the intrinsic implementation emits a string range check that triggers a decompilation and subsequent compilation without the intrinsic if you'd call with a `fromIndex` with values greater than `length()` (equal to should be fine). I'll try out some options here. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17685#discussion_r1476907109 From darcy at openjdk.org Sat Feb 3 01:37:03 2024 From: darcy at openjdk.org (Joe Darcy) Date: Sat, 3 Feb 2024 01:37:03 GMT Subject: RFR: JDK-8325189: Enable this-escape javac warning in java.base In-Reply-To: References: Message-ID: On Fri, 2 Feb 2024 23:38:41 GMT, Joe Darcy wrote: > In its initial form, the changes are tested on Linux. Later on, I'll do cross-platform builds to make sure there aren't any, say, windows-specific changes that are needed as well. > PS Builds pass on all platforms (linux, mac, and windows) on Oracle's internal build system. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17692#issuecomment-1925001815 From duke at openjdk.org Sat Feb 3 07:24:13 2024 From: duke at openjdk.org (ExE Boss) Date: Sat, 3 Feb 2024 07:24:13 GMT Subject: RFR: JDK-8310913 Move ReferencedKeyMap to jdk.internal so it may be shared [v10] In-Reply-To: References: Message-ID: On Mon, 31 Jul 2023 13:34:30 GMT, Jim Laskey wrote: >> java.lang.runtime.ReferencedKeyMap was introduced to provide a concurrent caching scheme for Carrier objects. The technique used is generally useful for a variety of caching schemes and is being moved to be shared in other parts of the jdk. The MethodType interning case is one example. > > Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits: > > - Merge branch 'master' into 8310913 > - Update implNote for intern > - Merge branch 'master' into 8310913 > - Requested changes. > > Added intern with UnaryOperator interning function to prepare key before adding to set. > - Update test to check for gc. > - Update ReferencedKeyTest.java > - Simple versions of create > - Add flag for reference queue type > - Merge branch 'master' into 8310913 > - Update to use VirtualThread friendly stale queue. > - ... and 7 more: https://git.openjdk.org/jdk/compare/408987e1...af95e5ae src/java.base/share/classes/jdk/internal/util/ReferencedKeySet.java line 151: > 149: @Override > 150: public boolean add(T e) { > 151: return intern(e) == null; This?line is?wrong, as?`intern(?)` will?never return?`null`. -------------------------------------------------------------------------------- This?is the?closest to?the?correct implementation, Suggestion: return !contains(e) & intern(e) == e; but?may incorrectly return?`true` in?case of?the?following data?race, assuming?`t1e ==?t2e`: 1. **Thread?1** calls `contains(t1e)` and gets `false`. 2. **Thread 2** calls `intern(t2e)` and successfully adds `t2e`. 3. **Thread?1** calls `intern(t1e)` and gets back `t2e`, which?is?`==` to?`t1e`. 4. **Thread?1** returns `true`, even?though it?was **Thread?2** which?modified the?`ReferencedKeySet`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14684#discussion_r1477004059 From mcimadamore at openjdk.org Sat Feb 3 09:10:06 2024 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Sat, 3 Feb 2024 09:10:06 GMT Subject: RFR: 8323746: Add PathElement hashCode and equals [v2] In-Reply-To: References: Message-ID: On Fri, 2 Feb 2024 07:41:16 GMT, Per Minborg wrote: >> This PR proposes to implement `hashCode()` and `equals()` methods for implementations of `PathElement`. >> >> In doing so, the previous `PathElementImpl` was removed and replaced in favor of distinct `record` implementations, each reflecting its own path element selection type. This also allowed the `PathKind` to be removed as this piece of information is now carried in the sealed type hierarchy. >> >> It is worth noting, the implementations resides in the `jdk.internal` package and consequently, they are not exposed to clients. So, we could use pattern matching (for example) internally but not in client code. > > Per Minborg has updated the pull request incrementally with one additional commit since the last revision: > > Make all PathElements records Marked as reviewed by mcimadamore (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/17651#pullrequestreview-1860956786 From alanb at openjdk.org Sat Feb 3 09:13:01 2024 From: alanb at openjdk.org (Alan Bateman) Date: Sat, 3 Feb 2024 09:13:01 GMT Subject: RFR: 8325152: Clarify specification of java.io.RandomAccessFile.setLength [v2] In-Reply-To: <6DdY9lGZB6YXCpyRsChm4F4R_PuUyvfQTa3jpiem1Ow=.5785f651-cf22-47e4-ac6e-d173436b5744@github.com> References: <6s1H_WwYoHtrO9N7-BhmsW6HvUhdtJUYzQyxJMeu3DI=.73712304-befe-4da2-8243-328774f9724f@github.com> <6DdY9lGZB6YXCpyRsChm4F4R_PuUyvfQTa3jpiem1Ow=.5785f651-cf22-47e4-ac6e-d173436b5744@github.com> Message-ID: On Fri, 2 Feb 2024 16:48:12 GMT, Brian Burkhalter wrote: >> Modify the specification verbiage of `java.io.RandomAccessFile.setLength` to account for the effect of the method on the file offset as returned by `getFilePointer`. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8325152: Minor change to paragraph about file offset Marked as reviewed by alanb (Reviewer). src/java.base/share/classes/java/io/RandomAccessFile.java line 682: > 680: * @param newLength The desired length of the file > 681: * @throws IOException If the argument is negative or > 682: * if some other I/O error occurs Throwing IOException when the newLength is negative is unfortunate but long standing behavior that can't be changed. So I think the proposed text looks okay. I can review the CSR when you have it ready. ------------- PR Review: https://git.openjdk.org/jdk/pull/17679#pullrequestreview-1860957960 PR Review Comment: https://git.openjdk.org/jdk/pull/17679#discussion_r1477026772 From duke at openjdk.org Sat Feb 3 11:32:02 2024 From: duke at openjdk.org (ExE Boss) Date: Sat, 3 Feb 2024 11:32:02 GMT Subject: RFR: 8323746: Add PathElement hashCode and equals [v2] In-Reply-To: References: Message-ID: On Fri, 2 Feb 2024 07:41:16 GMT, Per Minborg wrote: >> This PR proposes to implement `hashCode()` and `equals()` methods for implementations of `PathElement`. >> >> In doing so, the previous `PathElementImpl` was removed and replaced in favor of distinct `record` implementations, each reflecting its own path element selection type. This also allowed the `PathKind` to be removed as this piece of information is now carried in the sealed type hierarchy. >> >> It is worth noting, the implementations resides in the `jdk.internal` package and consequently, they are not exposed to clients. So, we could use pattern matching (for example) internally but not in client code. > > Per Minborg has updated the pull request incrementally with one additional commit since the last revision: > > Make all PathElements records These can?now be?removed: src/java.base/share/classes/jdk/internal/foreign/LayoutPath.java line 468: > 466: return 31; > 467: } > 468: Suggestion: src/java.base/share/classes/jdk/internal/foreign/LayoutPath.java line 494: > 492: return 63; > 493: } > 494: Suggestion: ------------- PR Review: https://git.openjdk.org/jdk/pull/17651#pullrequestreview-1861006117 PR Review Comment: https://git.openjdk.org/jdk/pull/17651#discussion_r1477051207 PR Review Comment: https://git.openjdk.org/jdk/pull/17651#discussion_r1477051227 From redestad at openjdk.org Sat Feb 3 14:22:01 2024 From: redestad at openjdk.org (Claes Redestad) Date: Sat, 3 Feb 2024 14:22:01 GMT Subject: RFR: 8325169: Reduce String::indexOf overheads [v2] In-Reply-To: <6JFAtUUQ4Uel7cjfHr0SbQYIM7e9bWZ65hcvFHA1qNo=.a2d2e97f-086d-46d1-82cf-c2f74b0c655a@github.com> References: <6JFAtUUQ4Uel7cjfHr0SbQYIM7e9bWZ65hcvFHA1qNo=.a2d2e97f-086d-46d1-82cf-c2f74b0c655a@github.com> Message-ID: On Fri, 2 Feb 2024 20:53:14 GMT, Claes Redestad wrote: >> This patch streamlines and specializes various `String::indexOf` methods. Mainly avoids the need for clamping and doing checks that are redundant in almost all cases, moving the checks to the API boundary where they are needed. >> >> This improves performance both at peak and during startup/warmup. Since indexOf is heavily used in bootstrapping code it makes sense to slightly dial back abstraction and delegation, which in this case also brought some benefit to peak performance. >> >> Testing: tier1-3 > > Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: > > Add comment about preconditions Updated to clamp `fromIndex` to `value.length >> coder` since the intrinsic might silently deoptimize if passed a `fromIndex` value that's out of bounds. This correctness fix dials back the speed-up on some of the `indexOf(c, offset)` micros, but not by much: Name Cnt Base Error Test Error Unit Change StringIndexOf.searchChar16LongSuccess 5/25 14,909 ? 3,284 14,351 ? 0,105 ns/op 1,04x (p = 0,218 ) StringIndexOf.searchChar16LongWithOffsetSuccess 5/25 14,715 ? 0,870 14,098 ? 0,015 ns/op 1,04x (p = 0,004*) StringIndexOf.searchChar16MediumSuccess 5/25 6,611 ? 0,016 6,488 ? 0,025 ns/op 1,02x (p = 0,000*) StringIndexOf.searchChar16MediumWithOffsetSuccess 5/25 7,151 ? 0,026 7,064 ? 0,021 ns/op 1,01x (p = 0,000*) StringIndexOf.searchChar16ShortSuccess 5/25 2,667 ? 0,007 2,362 ? 0,002 ns/op 1,13x (p = 0,000*) StringIndexOf.searchChar16ShortWithOffsetSuccess 5/25 2,494 ? 0,112 2,543 ? 0,008 ns/op 0,98x (p = 0,018 ) StringIndexOf.searchCharLongSuccess 5/25 5,995 ? 0,017 5,270 ? 0,005 ns/op 1,14x (p = 0,000*) StringIndexOf.searchCharLongWithOffsetSuccess 5/25 6,377 ? 0,118 6,212 ? 0,003 ns/op 1,03x (p = 0,000*) StringIndexOf.searchCharMediumSuccess 5/25 2,350 ? 0,013 1,924 ? 0,002 ns/op 1,22x (p = 0,000*) StringIndexOf.searchCharMediumWithOffsetSuccess 5/25 2,675 ? 0,002 2,581 ? 0,005 ns/op 1,04x (p = 0,000*) StringIndexOf.searchCharShortSuccess 5/25 1,719 ? 0,002 1,243 ? 0,002 ns/op 1,38x (p = 0,000*) StringIndexOf.searchCharShortWithOffsetSuccess 5/25 1,635 ? 0,006 1,311 ? 0,001 ns/op 1,25x (p = 0,000*) * = significant ------------- PR Comment: https://git.openjdk.org/jdk/pull/17685#issuecomment-1925339945 From redestad at openjdk.org Sat Feb 3 14:36:14 2024 From: redestad at openjdk.org (Claes Redestad) Date: Sat, 3 Feb 2024 14:36:14 GMT Subject: RFR: 8325169: Reduce String::indexOf overheads [v3] In-Reply-To: References: Message-ID: > This patch streamlines and specializes various `String::indexOf` methods. Mainly avoids the need for clamping and doing checks that are redundant in almost all cases, moving the checks to the API boundary where they are needed. > > This improves performance both at peak and during startup/warmup. Since indexOf is heavily used in bootstrapping code it makes sense to slightly dial back abstraction and delegation, which in this case also brought some benefit to peak performance. > > Testing: tier1-3 Claes Redestad has updated the pull request incrementally with two additional commits since the last revision: - Update comments regarding bounds checks - Clamp fromIndex to be in range ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17685/files - new: https://git.openjdk.org/jdk/pull/17685/files/aad343b3..097fc981 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17685&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17685&range=01-02 Stats: 5 lines in 3 files changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/17685.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17685/head:pull/17685 PR: https://git.openjdk.org/jdk/pull/17685 From eirbjo at openjdk.org Sat Feb 3 17:28:29 2024 From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=) Date: Sat, 3 Feb 2024 17:28:29 GMT Subject: RFR: 8321274: Rename ZipEntry.extraAttributes to ZipEntry.externalAttributes [v3] In-Reply-To: References: Message-ID: > Please consider this PR which suggests we rename `ZipEntry.extraAttributes` to `ZipEntry.externalAttributes`. > > This field was introduced in [JDK-8218021](https://bugs.openjdk.org/browse/JDK-8218021), originally under the name `ZipEntry.posixPerms`. [JDK-8250968](https://bugs.openjdk.org/browse/JDK-8250968) later renamed the field to `ZipEntry.extraAttributes` and extended its semantics to hold the full two-byte value of the `external file attributes` field, as defined by `APPNOTE.TXT` > > The name `extraAttributes` is misleading. It has nothing to do with the `extra field` (an unrelated structure defined in `APPNOTE.TXT`), although the name indicates it does. > > To prevent confusion and make life easier for future maintainers, I suggest we rename this field to `ZipEntry.externalAttributes` and update related methods, parameters and comments accordingly. > > While this change is a straightforward renaming, reviewers should consider whether it carries its weight, especially considering it might complicate future backports. > > As a note to reviewers, this PR includes the following intended updates: > > - Rename `ZipEntry.extraAttributes` and any references to this field to `ZipEntry.externalAttributes` > - Update `JavaUtilZipFileAccess` to similarly rename methods to `setExternalAttributes` and `getExternalAttributes` > - Rename the field `JarSigner.extraAttrsDetected` to `JarSigner.externalAttrsDetected` > - Rename a local variable in `JarSigner.writeEntry` to `externalAttrs` > - Rename `s.s.t.jarsigner.Main.extraAttrsDetected` to `externalAttrsDetected` > - Rename resource string key names in `s.s.t.jarsigner.Resources` from `extra.attributes.detected` to `external.attributes.detected` > - Rename method `SymlinkTest.verifyExtraAttrs` to `verifyExternalAttrs`, also updated two references to 'extra attributes' in this method > - Updated copyright in all affected files > > If the resource file changes should be dropped and instead handled via `msgdop` updates, let me know and I can revert the non-default files. > > I did a search across the code base to find 'extraAttrs', 'extra.attr' after these updates, and found nothing related to zip/jar. The `zip` and `jar` tests run clean: > > > make test TEST="test/jdk/java/util/jar" > make test TEST="test/jdk/java/util/zip" Eirik Bj?rsn?s has updated the pull request with a new target base 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: - Rename ZipFileSystem.Entry.posixPerms to externalFileAttributes - For clarity, use "externalFileAttributes" instead of "externalAttributes" - Merge branch 'master' into zipentry-external-attributes - Update copyright years for 2024 - Merge branch 'master' into zipentry-external-attributes - Rename ZipEntry.extraAttributes to ZipEntry.externalAttributes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16952/files - new: https://git.openjdk.org/jdk/pull/16952/files/481ae754..10db9803 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16952&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16952&range=01-02 Stats: 44114 lines in 1909 files changed: 21144 ins; 10053 del; 12917 mod Patch: https://git.openjdk.org/jdk/pull/16952.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16952/head:pull/16952 PR: https://git.openjdk.org/jdk/pull/16952 From eirbjo at openjdk.org Sat Feb 3 17:31:00 2024 From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=) Date: Sat, 3 Feb 2024 17:31:00 GMT Subject: RFR: 8321274: Rename ZipEntry.extraAttributes to ZipEntry.externalAttributes [v2] In-Reply-To: References: <-e1Q7OFfQ6tppgashjdUtiqM6uou0IETGRaQWRHDEX8=.02b4ef00-725a-4317-b06e-2d1a699c4860@github.com> Message-ID: <5vVA_gN2SdDN8XtWtebLuVD8zvUy6_0haF5Gs4tOBX4=.0b16f411-81f3-4255-9867-6d9918a80dcb@github.com> On Fri, 2 Feb 2024 20:43:54 GMT, Lance Andersen wrote: > I think the proposed change above makes things clearer. Perhaps also make the same change in zipfs as well while you are at it? I have pushed the rename to "ZipEntry.externalFileAttributes". Also renamed `ZipFileSystem.Entry.posixPerms` to `ZipFileSystem.Entry.externalFileAttributes`. Hopefully this makes things clearer. A side note: The Posix support in `ZipFileSystem` is somewhat odd in that it supports the notion of a `null` permission set. So setting the permissions attribute to `null` clears all the attributes, not just the permisson ones. But even so, I think using the full name here is also an improvement, since it signals that the field may also carry preexisting file type, setuid, setgid, sticky bits. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16952#issuecomment-1925403883 From cutefish.yx at gmail.com Sat Feb 3 18:54:25 2024 From: cutefish.yx at gmail.com (Xiao Yu) Date: Sat, 3 Feb 2024 10:54:25 -0800 Subject: The common ForkJoinPool does not have any ForkJoinWorkerThread while tasks are submitted to the queue In-Reply-To: References: Message-ID: Hi Jaikiran, Thanks a lot for replying. Our application is a client that communicates to the server for request/response. The client creates a secure (TLS) connection to the server, that is, on top of the SocketChannel, we implement a Wrapper class called SSLDataChannel for reading and writing. The SSLDataChannel uses the javax.net.ssl.SSLEngine. Before any read and write can happen, we need to do SSL handshakes by calling methods in SSLEngine. One of the methods is SSLEngine#getDelegatedTask(). The returned task needs to be executed before the handshake can proceed. After the task is done, we need to continue processing read and write events on the connection. The connection read and write events are all handled by a class called NioEndpointHandler. One requirement for our client is that it supports an asynchronous API and therefore the whole stack must all implement non-blocking methods. The tasks from the SSLEngine could take a long time and we do not want them to block our other connection events, and this is when the ForkJoinPool is used. We run the SSL tasks in the ForkJoinPool and after the task is done we arrange to run the NioEndpointHandler callbacks to proceed with the read and write events. The much simplified code looks somewhat like the following. ``` class NioEndpointHandler { /** The ssl channel */ private final SSLDataChannel sslDataChannel; /** The runnable to execute to handle read after ssl tasks is done. */ private final Runnable handleReadAfterSSLTask = () -> onRead(); /** The handler state. */ State state; /** Executes the SSL tasks until no task to run, then run the callback. */ private void executeSSLTask(ExecutorService executor, Runnable callback) { executor.submit(() -> { Runnable task; while ((task = sslDataChannel.getSSLEngine().getDelegatedTask()) != null) { task.run(); } try { callback.run(); } catch (Throwable t) { /* logging the exception. */ } }); } /** Handle a read event. */ private void onRead() { if (sslDataChannel.needsHandshake()) { /* do handshake */ /* One of the handshake step is to check if there is any SSL task to run. */ if (sslDataChannel.needExecuteTask()) { executeSSLTask(ForkJoinPool.commonPool(), handleReadAfterSSLTask); } } } private void terminate() { state = TERMINATED; /* Other clean up tasks, however, tasks submitted to the ForkJoinPool are not cancelled. */ } } ``` > What are these handlers? Are they classes which implement Runnable or > are they something else? What does termination of handler mean in this > context? Do you use any java.util.concurrent.* APIs to "cancel" such > terminated handlers? The much simplified handler code please see above. The tasks submitted to the ForkJoinPool queue are Runnables that are fields to the NioEndpointHandler. What we have observed is that there are a lot of tasks in the fork join pool that have a reference to the lambda inside NioEndpointHandler#executeSSLTask which eventually have a reference to the NioEndpointHandler. Those NioEndpointHandler are in the TERMINATED state. The only reference to those NioEndpointHandler are these tasks or otherwise they can be garbage collected after the termination cleans up all the other references. Termination of the handler means those connections are at the end of their life cycle. We clean up things such as signal end of life cycle for all the associated request/response pairs and closing the SSLDataChannel, etc. No, we have not use the cancel method to cancel the submitted tasks. I agree that this is an oversight and it would be cleaner to cancel them. However, my current theory is that this is not the root cause. From my understanding of the code, the cancel method only changes the state of the task. It does not remove the task from the queue of the ForkJoinPool. Therefore, those tasks, even if got cancelled, would still stay in the queue preventing the terminated NioEndpointHandler from being garbage collected. Currently, I am strongly biased to my own theory that somehow there is no ForkJoinPool thread that polling tasks out of the queue and I am trying to use the ctl field in the ForkJoinPool as the evidence to backup my theory. I am wondering if I am making some mistake with my theory. > Finally, what does the OutOfMemoryError exception stacktrace look like > and what is the JVM parameters (heap size for example) used to launch > this application? Our clients creates about 155 threads and quite a lot of them have OOME on their stack. I am not quite sure how to reply to this question. Going through the stack traces, I do not find anything very suspicious. They are just exercising their most frequent code path: some I/O threads waiting for I/O events and some execution threads waiting for more work to do, etc. It is worth mentioning that there is no ForkJoinPoolWorkerThread stacks in the thread dump from the heap dump. From my understanding, the only time when there is no such thread is when there is no tasks to run. But there are quite a lot of tasks in the queue. Here are our JVM arguments: ``` -Xms1G -Xmx1G -Djava.util.logging.config.file=/var/lib/andc/config/params/sender.logging.properties -Djavax.net.ssl.trustStore=/var/lib/andc/wallet/client.trust -Doracle.kv.security=/var/lib/andc/config/security/login.properties -Doci.javasdk.extra.stream.logs.enabled=false -XX:G1HeapRegionSize=32m -XX:+DisableExplicitGC -Xlog:all=warning,gc*=info,safepoint=info:file=/var/lib/andc/log/sender/sender.gc:utctime:filecount=10,filesize=10000000 -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/var/lib/andc/log/sender/ ``` We have creation and termination timestamps in the NioEndpointHandler object. >From what I can see in the heap dump, the SSL tasks in the ForkJoinPool are associated with NioEndpointHandler that are created at an interval on the magnitude of seconds (retry attempt with second-magnitude backoff). Each NioEndpointHandler are terminated after a fixed 5-second timeout due to unable to connect. The time span for those NioEndpointHandler is about 2 hours. This creates ``` 2 hours * 3600 seconds / hour * 1 NioEndpointHandler / second * 1 SSLDataChannel / NioEndpointHandler * 65K bytes / SSLDataChannel ~= 468M bytes. ``` With 1G heap size, this eventually caused OOME. We are adding fixes so that the SSL tasks would not preventing the NioEndpointHandler from being garbage collected. However, the root cause is still a mystery and I am wondering if I am on the right tracker to figure it out. Thanks a lot for your time and patience. Xiao Yu On Fri, Feb 2, 2024 at 5:35?AM Jaikiran Pai wrote: > Hello Xiao, > > I don't have enough knowledge of this area to provide any insight into > the issue. However, just to try and get the discussion started, do you > have any sample code of your application which shows how the application > uses the ForkJoinPool? More specifically what APIs do you use in the > application? > > Few other questions inline below. > > On 12/01/24 11:30 am, Xiao Yu wrote: > > .... > > Here is the full background. One of our process experienced an OOME > > and a heap > > dump was obtained. We know there was a concurrent issue of our system > > happening > > on some other machines such that network failure and retries occurred > > in this > > process at the same time. Upon analyzing the heap dump, we observed a > > lot of > > our network connection handlers being frequently created and > > terminated which > > is expected due to the network failure and retry attempts mentioned > above. > > However, those terminated handlers are not being GC'ed because of > > there were > > references to tasks submitted to the ForkJoinPool during the connection > > attempts. The tasks stayed in the queue until OOME happened as there is > no > > threads to execute them. > > What are these handlers? Are they classes which implement Runnable or > are they something else? What does termination of handler mean in this > context? Do you use any java.util.concurrent.* APIs to "cancel" such > terminated handlers? > > Finally, what does the OutOfMemoryError exception stacktrace look like > and what is the JVM parameters (heap size for example) used to launch > this application? > > -Jaikiran > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alanb at openjdk.org Sun Feb 4 06:58:03 2024 From: alanb at openjdk.org (Alan Bateman) Date: Sun, 4 Feb 2024 06:58:03 GMT Subject: RFR: JDK-8325189: Enable this-escape javac warning in java.base In-Reply-To: References: Message-ID: On Fri, 2 Feb 2024 23:36:41 GMT, Joe Darcy wrote: > After the "this-escape" lint warning was added to javac (JDK-8015831), the base module was not updated to be able to compile with this warning enabled. This PR makes the necessary changes to allow the base module to build with the warning enabled. I skimmed through the use sites and don't see any issues. There is one bucket of escaping "this" that will go away once the support for running with the SM goes away. ------------- Marked as reviewed by alanb (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17692#pullrequestreview-1861282672 From pminborg at openjdk.org Sun Feb 4 08:44:07 2024 From: pminborg at openjdk.org (Per Minborg) Date: Sun, 4 Feb 2024 08:44:07 GMT Subject: RFR: 8316493: Remove the caching fields in AbstractMap [v11] In-Reply-To: <4tW3v7m0W_M4bmmLcywMRC5Gm26VhCt6pb16Bg7idTA=.c85a1df3-2208-439a-ac82-e9d16c537196@github.com> References: <4tW3v7m0W_M4bmmLcywMRC5Gm26VhCt6pb16Bg7idTA=.c85a1df3-2208-439a-ac82-e9d16c537196@github.com> Message-ID: On Fri, 10 Nov 2023 08:17:22 GMT, Per Minborg wrote: >> This PR outlines a solution for making immutable maps `@ValueBased` by removing cacheing of certain values in `AbstractMap`. >> >> By removing these caching fields in `AbstractMap`, we can make the immutable maps `@ValueBased` and at the same time, performance is likely improved because the JVM is probably able to optimize away object creation anyway via escape analysis. Also, all maps will occupy less space as we get rid of a number of objects and references stored for each map. >> >> We need to benchmark this solution to better understand its implications. > > Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The 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 keep alive ------------- PR Comment: https://git.openjdk.org/jdk/pull/15614#issuecomment-1925639031 From mli at openjdk.org Sun Feb 4 10:31:05 2024 From: mli at openjdk.org (Hamlin Li) Date: Sun, 4 Feb 2024 10:31:05 GMT Subject: RFR: 8325169: Reduce String::indexOf overheads [v3] In-Reply-To: References: Message-ID: On Sat, 3 Feb 2024 14:36:14 GMT, Claes Redestad wrote: >> This patch streamlines and specializes various `String::indexOf` methods. Mainly avoids the need for clamping and doing checks that are redundant in almost all cases, moving the checks to the API boundary where they are needed. >> >> This improves performance both at peak and during startup/warmup. Since indexOf is heavily used in bootstrapping code it makes sense to slightly dial back abstraction and delegation, which in this case also brought some benefit to peak performance. >> >> Testing: tier1-3 > > Claes Redestad has updated the pull request incrementally with two additional commits since the last revision: > > - Update comments regarding bounds checks > - Clamp fromIndex to be in range Looks good! ------------- Marked as reviewed by mli (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17685#pullrequestreview-1861368718 From jpai at openjdk.org Sun Feb 4 14:13:00 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Sun, 4 Feb 2024 14:13:00 GMT Subject: RFR: JDK-8324930: java/lang/StringBuilder problem with concurrent jtreg runs In-Reply-To: References: Message-ID: <1-13K94bIVviSRdAx7bHr6V8FkIguSP37jbT2I5egBU=.b1618387-1b14-4a98-a11b-088269da26a6@github.com> On Tue, 30 Jan 2024 09:08:28 GMT, Matthias Baesken wrote: > On some Windows machines we see sometimes OOM errors because of high resource (memory/swap) consumption. This is especially seen when the jtreg runs have higher concurrency. A solution is to put the java/lang/StringBuilder tests in the exclusiveAccess.dirs group so that they are not executed concurrently, which helps to mitigate the resource shortages. > Of course this has the downside that on very large machines the concurrent execution is not done any more. Hello Matthias, would you be able to include a stacktrace from one such failure? The tests you mention as failing: java/lang/StringBuilder/StringBufferRepeat.java java/lang/StringBuilder/CompactStringBuilderSerialization.java java/lang/StringBuilder/Insert.java are all "othervm" tests, so I'm curious what kind of OOM is being reported. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17625#issuecomment-1925764255 From aturbanov at openjdk.org Sun Feb 4 17:21:01 2024 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Sun, 4 Feb 2024 17:21:01 GMT Subject: RFR: JDK-8318761: MessageFormat pattern support for CompactNumberFormat, ListFormat, and DateTimeFormatter [v3] In-Reply-To: References: Message-ID: <4UeIXBQjejYi22l0L9vWbdBDKk07s4gISoE6ruLg-XM=.ad60be8f-693c-4ba7-94fe-7b7ffbc9ae18@github.com> On Fri, 2 Feb 2024 22:43:28 GMT, Justin Lu wrote: >> Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8319344) which adds MessageFormat pattern support for the following subformats: ListFormat, CompactNumberFormat, and DateTimeFormatter. This change is intended to provide pattern support for the more recently added JDK Format subclasses, as well as improving java.time formatting within i18n. The draft javadoc can be viewed here: https://cr.openjdk.org/~jlu/docs/api/java.base/java/text/MessageFormat.html. Please see the CSR for more in-depth behavioral changes, as well as limitations. >> >> The `FormatTypes`: dtf_date, dtf_time, dtf_datetime, pre-defined DateTimeFormatter(s), and list are added. >> The `FormatStyles`: compact_short, compact_long, or, and unit are added. >> >> For example, previously, >> >> >> Object[] args = {LocalDate.of(2023, 11, 16), LocalDate.of(2023, 11, 27)}; >> MessageFormat.format("It was {0,date,full}, now it is {1,date,full}", args); >> >> >> would throw `Exception java.lang.IllegalArgumentException: Cannot format given Object as a Date` >> >> Now, a user can call >> >> >> MessageFormat.format("It was {0,dtf_date,full}, now it is {1,dtf_date,full}", args); >> >> >> which returns "It was Thursday, November 16, 2023, now it is Friday, November 17, 2023" > > Justin Lu has updated the pull request incrementally with one additional commit since the last revision: > > Use Naoto's recommended example src/java.base/share/classes/java/text/MessageFormat.java line 1771: > 1769: String type = fType.name().charAt(0) + fType.name().substring(1).toLowerCase(Locale.ROOT); > 1770: try { > 1771: return switch(fType) { Suggestion: return switch (fType) { src/java.base/share/classes/java/text/MessageFormat.java line 1777: > 1775: DateTimeFormatter.ofPattern(pattern).toFormat(); > 1776: case CHOICE -> new ChoiceFormat(pattern); > 1777: default -> throw new IllegalArgumentException(String.format( Suggestion: default -> throw new IllegalArgumentException(String.format( ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17663#discussion_r1477385804 PR Review Comment: https://git.openjdk.org/jdk/pull/17663#discussion_r1477386232 From ihse at openjdk.org Sun Feb 4 17:27:00 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Sun, 4 Feb 2024 17:27:00 GMT Subject: RFR: 8325163: Enable -Wpedantic on clang In-Reply-To: References: Message-ID: On Fri, 2 Feb 2024 15:22:03 GMT, Magnus Ihse Bursie wrote: > Inspired by (the later backed-out) [JDK-8296115](https://bugs.openjdk.org/browse/JDK-8296115), I propose to enable `-Wpedantic` for clang. This has already found some irregularities in the code, like mistakenly using `#import` instead of `#include`. In this patch, I disable warnings for these individual buggy or badly written files, but I intend to post follow-up issues on the respective teams to have them properly fixed. > > Unfortunately, it is not possible to enable `-Wpedantic` on gcc, since individual warnings in `-Wpedantic` cannot be disabled. This means that code like this: > > > #define DEBUG_ONLY(code) code; > > DEBUG_ONLY(foo()); > > > will result in a `; ;`. This breaks the C standard, but is benign, and we use it all over the place. On clang, we can ignore this by `-Wno-extra-semi`, but this is not available on gcc. Ah, dtrace triggers `dollar-in-identifier-extension`. Of course... *sigh* I actually had this disabled for hotspot on an earlier version of the patch (that had lied dormant in my personal fork for about a year), but I could not reproduce the problem it was supposed to solve now, so I removed it again. Now I know why I had it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17687#issuecomment-1925848001 From dholmes at openjdk.org Sun Feb 4 22:50:17 2024 From: dholmes at openjdk.org (David Holmes) Date: Sun, 4 Feb 2024 22:50:17 GMT Subject: [jdk22] RFR: 8322066: Update troff manpages in JDK 22 before RC Message-ID: This update drops the "ea" from the version string. We also propagate the following fixes from the markdown sources to the troff manpage file: JDK-8322478: Update java manpage for multi-file source-code launcher JDK-8302233: HSS/LMS: keytool and jarsigner changes JDK-8318971: Better Error Handling for Jar Tool When Processing Non-existent Files Thanks. ------------- Commit messages: - 8322066: Update troff pages in JDK 22 before RC Changes: https://git.openjdk.org/jdk22/pull/104/files Webrev: https://webrevs.openjdk.org/?repo=jdk22&pr=104&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8322066 Stats: 160 lines in 28 files changed: 63 ins; 15 del; 82 mod Patch: https://git.openjdk.org/jdk22/pull/104.diff Fetch: git fetch https://git.openjdk.org/jdk22.git pull/104/head:pull/104 PR: https://git.openjdk.org/jdk22/pull/104 From ihse at openjdk.org Sun Feb 4 22:55:01 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Sun, 4 Feb 2024 22:55:01 GMT Subject: RFR: 8325163: Enable -Wpedantic on clang In-Reply-To: References: Message-ID: <94Ifly9StBGB9Qnoatj1MLo4txRcerzPx9-D2Am1b7U=.6a80b6f5-50ec-4b63-b1b1-8035fb6948db@github.com> On Fri, 2 Feb 2024 15:59:56 GMT, Julian Waters wrote: > Guess I could work on the gcc counterpart and find a way around the inability to disable -Wpedantic with it in tandem with this change... I don't think that is possible. The double semicolon rule can only be disabled by disabling pedantic completely. This is not the first time we've run into trouble because gcc do not have fine-grained enough warnings. :( (While clang has always excelled in this area.) ------------- PR Comment: https://git.openjdk.org/jdk/pull/17687#issuecomment-1925954578 From kbarrett at openjdk.org Mon Feb 5 03:12:01 2024 From: kbarrett at openjdk.org (Kim Barrett) Date: Mon, 5 Feb 2024 03:12:01 GMT Subject: RFR: 8325163: Enable -Wpedantic on clang In-Reply-To: References: Message-ID: On Fri, 2 Feb 2024 15:22:03 GMT, Magnus Ihse Bursie wrote: > #define DEBUG_ONLY(code) code; > > DEBUG_ONLY(foo()); > ``` > > will result in a `; ;`. This breaks the C standard, but is benign, and we use it all over the place. On clang, we can ignore this by `-Wno-extra-semi`, but this is not available on gcc. All of the -Wpedantic warnings for extra ';' in C++ code I looked at look to me like a gcc bug (or bugs). C++11 added "empty-declaration", which is permitted anywhere a normal declaration is permitted (C++14 7), as well as for class member declarations (C++14 9.2). https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96068 seems to have fixed some, but not all, cases. It looks like it only removed the warnings for empty declarations at namespace scope. I couldn't find anything for other cases, including empty class member declarations. I consider the "format '%p' expects argument of type 'void*" warnings to be not at all helpful. Fortunately we don't use '%p' in HotSpot, but I don't know how other groups might feel having this inflicted on them. Because of the vast numbers of those, I ran out of patience trying to find and examine other warnings triggered by this option. Based on that, I'm not feeling very keen on this change, at least not for a future version applying to gcc builds. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17687#issuecomment-1926154325 From kbarrett at openjdk.org Mon Feb 5 03:24:01 2024 From: kbarrett at openjdk.org (Kim Barrett) Date: Mon, 5 Feb 2024 03:24:01 GMT Subject: RFR: 8325163: Enable -Wpedantic on clang In-Reply-To: References: Message-ID: <5YoWExp50qGIjilv-9yq38jGsb3Fw7MJCQ8Sfc3Wp3c=.189956da-6f76-4723-9d4a-11d20b43eeb4@github.com> On Fri, 2 Feb 2024 15:22:03 GMT, Magnus Ihse Bursie wrote: > Inspired by (the later backed-out) [JDK-8296115](https://bugs.openjdk.org/browse/JDK-8296115), I propose to enable `-Wpedantic` for clang. This has already found some irregularities in the code, like mistakenly using `#import` instead of `#include`. In this patch, I disable warnings for these individual buggy or badly written files, but I intend to post follow-up issues on the respective teams to have them properly fixed. Rather than first turning on pedantic warnings and then (maybe) going back and perhaps fixing things, I'd really prefer things be done in the other order. (That's how I handled the recent `-Wparentheses` changes, for example.) ------------- PR Comment: https://git.openjdk.org/jdk/pull/17687#issuecomment-1926164327 From dholmes at openjdk.org Mon Feb 5 06:18:03 2024 From: dholmes at openjdk.org (David Holmes) Date: Mon, 5 Feb 2024 06:18:03 GMT Subject: RFR: 8325163: Enable -Wpedantic on clang In-Reply-To: References: Message-ID: On Mon, 5 Feb 2024 03:07:43 GMT, Kim Barrett wrote: > I consider the "format '%p' expects argument of type 'void*" warnings to be not at all helpful. Fortunately we don't use '%p' in HotSpot, We do use it in hotspot. Not a huge amount as we have the legacy format specifiers for PTR_FORMAT etc. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17687#issuecomment-1926298655 From jwaters at openjdk.org Mon Feb 5 07:00:01 2024 From: jwaters at openjdk.org (Julian Waters) Date: Mon, 5 Feb 2024 07:00:01 GMT Subject: RFR: 8325163: Enable -Wpedantic on clang In-Reply-To: <94Ifly9StBGB9Qnoatj1MLo4txRcerzPx9-D2Am1b7U=.6a80b6f5-50ec-4b63-b1b1-8035fb6948db@github.com> References: <94Ifly9StBGB9Qnoatj1MLo4txRcerzPx9-D2Am1b7U=.6a80b6f5-50ec-4b63-b1b1-8035fb6948db@github.com> Message-ID: <_M36efmD8eSGI9KzSC7DJdtQkRnfnA2x7kO0syzXAks=.37fc99bc-9d21-4b48-96fb-b5da431c95ad@github.com> On Sun, 4 Feb 2024 22:52:19 GMT, Magnus Ihse Bursie wrote: > > Guess I could work on the gcc counterpart and find a way around the inability to disable -Wpedantic with it in tandem with this change... > > I don't think that is possible. The double semicolon rule can only be disabled by disabling pedantic completely. This is not the first time we've run into trouble because gcc do not have fine-grained enough warnings. :( (While clang has always excelled in this area.) I tried compiling this on both Linux and Windows, and it seems like there are only a few places where the double semicolons are actually a problem (The strangest case was in a NOT_LP64 macro in mallocHeader.hpp where gcc exploded when parsing a perfectly valid semicolon). This is more of a code style cleanliness check than anything, but as Kim said, it is probably a bug within gcc somewhere. I'll file a gcc bug for this in the meantime ------------- PR Comment: https://git.openjdk.org/jdk/pull/17687#issuecomment-1926339574 From jwaters at openjdk.org Mon Feb 5 07:21:01 2024 From: jwaters at openjdk.org (Julian Waters) Date: Mon, 5 Feb 2024 07:21:01 GMT Subject: RFR: 8325163: Enable -Wpedantic on clang In-Reply-To: References: Message-ID: On Fri, 2 Feb 2024 15:22:03 GMT, Magnus Ihse Bursie wrote: > Inspired by (the later backed-out) [JDK-8296115](https://bugs.openjdk.org/browse/JDK-8296115), I propose to enable `-Wpedantic` for clang. This has already found some irregularities in the code, like mistakenly using `#import` instead of `#include`. In this patch, I disable warnings for these individual buggy or badly written files, but I intend to post follow-up issues on the respective teams to have them properly fixed. > > Unfortunately, it is not possible to enable `-Wpedantic` on gcc, since individual warnings in `-Wpedantic` cannot be disabled. This means that code like this: > > > #define DEBUG_ONLY(code) code; > > DEBUG_ONLY(foo()); > > > will result in a `; ;`. This breaks the C standard, but is benign, and we use it all over the place. On clang, we can ignore this by `-Wno-extra-semi`, but this is not available on gcc. Created https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113760 Interestingly a gcc maintainer cannot reproduce the issue at all ------------- PR Comment: https://git.openjdk.org/jdk/pull/17687#issuecomment-1926361490 From jwaters at openjdk.org Mon Feb 5 07:30:01 2024 From: jwaters at openjdk.org (Julian Waters) Date: Mon, 5 Feb 2024 07:30:01 GMT Subject: RFR: 8325163: Enable -Wpedantic on clang In-Reply-To: <5YoWExp50qGIjilv-9yq38jGsb3Fw7MJCQ8Sfc3Wp3c=.189956da-6f76-4723-9d4a-11d20b43eeb4@github.com> References: <5YoWExp50qGIjilv-9yq38jGsb3Fw7MJCQ8Sfc3Wp3c=.189956da-6f76-4723-9d4a-11d20b43eeb4@github.com> Message-ID: <2KKteHViBJ4B5J2FCpGBFuy1tfoC7kaQWMKq3Ncimes=.d4bed0e1-e307-4b2e-b12e-f495514a4158@github.com> On Mon, 5 Feb 2024 03:21:35 GMT, Kim Barrett wrote: >> Inspired by (the later backed-out) [JDK-8296115](https://bugs.openjdk.org/browse/JDK-8296115), I propose to enable `-Wpedantic` for clang. This has already found some irregularities in the code, like mistakenly using `#import` instead of `#include`. In this patch, I disable warnings for these individual buggy or badly written files, but I intend to post follow-up issues on the respective teams to have them properly fixed. >> >> Unfortunately, it is not possible to enable `-Wpedantic` on gcc, since individual warnings in `-Wpedantic` cannot be disabled. This means that code like this: >> >> >> #define DEBUG_ONLY(code) code; >> >> DEBUG_ONLY(foo()); >> >> >> will result in a `; ;`. This breaks the C standard, but is benign, and we use it all over the place. On clang, we can ignore this by `-Wno-extra-semi`, but this is not available on gcc. > >> Inspired by (the later backed-out) [JDK-8296115](https://bugs.openjdk.org/browse/JDK-8296115), I propose to enable `-Wpedantic` for clang. This has already found some irregularities in the code, like mistakenly using `#import` instead of `#include`. In this patch, I disable warnings for these individual buggy or badly written files, but I intend to post follow-up issues on the respective teams to have them properly fixed. > > Rather than first turning on pedantic warnings and then (maybe) going back and perhaps fixing things, I'd really prefer > things be done in the other order. (That's how I handled the recent `-Wparentheses` changes, for example.) @kimbarrett quoting the gcc maintainers > Yes because the C++ defect report was only for `Spurious semicolons at namespace scope should be allowed`. See https://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#569 . > > > ``` > struct f > { > int t; ; > }; > ``` > > Is not allowed by the C++ standard currently and is a GCC extension, maybe it should have a seperate flag to control that but I am not 100% sure. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17687#issuecomment-1926372614 From mbaesken at openjdk.org Mon Feb 5 08:29:06 2024 From: mbaesken at openjdk.org (Matthias Baesken) Date: Mon, 5 Feb 2024 08:29:06 GMT Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v7] In-Reply-To: References: Message-ID: <7R-vR6xRkCutTiGye-lVtYvEjWVKLFYDWFCaj-Drcbc=.963a2048-d87a-4f4e-b93e-79a62b432138@github.com> On Fri, 2 Feb 2024 06:55:19 GMT, Magnus Ihse Bursie wrote: >> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK native libraries. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Add kludge to BufferedRenderPipe.c for AIX I noticed that in the file src/java.base/share/native/libzip/zlib/zconf.h we seem to still use `off64_t` , is this okay (at most other locations it was replaced) https://github.com/openjdk/jdk/blob/master/src/java.base/share/native/libzip/zlib/zconf.h#L541 ------------- PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1926448109 From rrich at openjdk.org Mon Feb 5 09:06:24 2024 From: rrich at openjdk.org (Richard Reingruber) Date: Mon, 5 Feb 2024 09:06:24 GMT Subject: RFR: 8323782: Race: Thread::interrupt vs. AbstractInterruptibleChannel.begin [v3] In-Reply-To: References: Message-ID: > Set `interrupted` in `Thread::interrupt` before reading `nioBlocker` for correct (Dekker scheme) synchronization with concurrent execution of [`AbstractInterruptibleChannel::begin`](https://github.com/openjdk/jdk/blob/59062402b9c5ed5612a13c1c40eb22cf1b97c41a/src/java.base/share/classes/java/nio/channels/spi/AbstractInterruptibleChannel.java#L176). > > The change passed our CI functional testing: JTReg tests: tier1-4 of hotspot and jdk. All of Langtools and jaxp. SPECjvm2008, SPECjbb2015, Renaissance Suite, and SAP specific tests. > Testing was done with fastdebug and release builds on the main platforms and also on Linux/PPC64le and AIX. Richard Reingruber has updated the pull request with a new target base 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 8323782__Race__Thread__interrupt_vs__AbstractInterruptibleChannel_begin - Review Alan - New version of LotsOfInterrupts.java supporting virtual threads - Add Alan's LotsOfInterrupts.java test - Must checkAccess before changing interrupt state of other thread - 8323782: Race: Thread::interrupt vs. AbstractInterruptibleChannel.begin ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17444/files - new: https://git.openjdk.org/jdk/pull/17444/files/ab3513c1..81a9f812 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17444&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17444&range=01-02 Stats: 32138 lines in 1713 files changed: 15466 ins; 4449 del; 12223 mod Patch: https://git.openjdk.org/jdk/pull/17444.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17444/head:pull/17444 PR: https://git.openjdk.org/jdk/pull/17444 From ihse at openjdk.org Mon Feb 5 09:19:07 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 5 Feb 2024 09:19:07 GMT Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v7] In-Reply-To: References: Message-ID: On Fri, 2 Feb 2024 06:55:19 GMT, Magnus Ihse Bursie wrote: >> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK native libraries. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Add kludge to BufferedRenderPipe.c for AIX zlib is 3rd party source, I did not touch those. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1926532998 From ihse at openjdk.org Mon Feb 5 09:31:01 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 5 Feb 2024 09:31:01 GMT Subject: RFR: 8325163: Enable -Wpedantic on clang In-Reply-To: <5YoWExp50qGIjilv-9yq38jGsb3Fw7MJCQ8Sfc3Wp3c=.189956da-6f76-4723-9d4a-11d20b43eeb4@github.com> References: <5YoWExp50qGIjilv-9yq38jGsb3Fw7MJCQ8Sfc3Wp3c=.189956da-6f76-4723-9d4a-11d20b43eeb4@github.com> Message-ID: On Mon, 5 Feb 2024 03:21:35 GMT, Kim Barrett wrote: >> Inspired by (the later backed-out) [JDK-8296115](https://bugs.openjdk.org/browse/JDK-8296115), I propose to enable `-Wpedantic` for clang. This has already found some irregularities in the code, like mistakenly using `#import` instead of `#include`. In this patch, I disable warnings for these individual buggy or badly written files, but I intend to post follow-up issues on the respective teams to have them properly fixed. >> >> Unfortunately, it is not possible to enable `-Wpedantic` on gcc, since individual warnings in `-Wpedantic` cannot be disabled. This means that code like this: >> >> >> #define DEBUG_ONLY(code) code; >> >> DEBUG_ONLY(foo()); >> >> >> will result in a `; ;`. This breaks the C standard, but is benign, and we use it all over the place. On clang, we can ignore this by `-Wno-extra-semi`, but this is not available on gcc. > >> Inspired by (the later backed-out) [JDK-8296115](https://bugs.openjdk.org/browse/JDK-8296115), I propose to enable `-Wpedantic` for clang. This has already found some irregularities in the code, like mistakenly using `#import` instead of `#include`. In this patch, I disable warnings for these individual buggy or badly written files, but I intend to post follow-up issues on the respective teams to have them properly fixed. > > Rather than first turning on pedantic warnings and then (maybe) going back and perhaps fixing things, I'd really prefer > things be done in the other order. (That's how I handled the recent `-Wparentheses` changes, for example.) @kimbarrett > Rather than first turning on pedantic warnings and then (maybe) going back and perhaps fixing things, I'd really prefer things be done in the other order. I hear what you are saying, but I respectfully disagree. If we do things in the order you suggest, the global flag cannot be turned on until all component teams have fixed their source code. That essentially makes the most overworked group putting an effective veto to this change (when your workload is too high, fixing warnings is not on top of your priority.) In contrast, if the global warning can be turned on now, it will have a positive effect on all new and modified code from now on. And the teams can work on their individual warnings, and remove them in their own time. This is the same method I used for turning on -Wall and -Wextra. Some teams are very eager to fix warnings, and others still have almost all their "DISABLED_WARNINGS" left several years later. (I will not mention any names; you both know who you are ;-)). If I had followed the route you suggest, we would not have -Wall -Wextra on all source code (sans a few, marked files) now. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17687#issuecomment-1926553386 From ihse at openjdk.org Mon Feb 5 09:35:03 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 5 Feb 2024 09:35:03 GMT Subject: RFR: 8325163: Enable -Wpedantic on clang In-Reply-To: References: Message-ID: On Mon, 5 Feb 2024 03:07:43 GMT, Kim Barrett wrote: > at least not for a future version applying to gcc builds. @kimbarrett @TheShermanTanker Please do not drag gcc into this PR. This is just about clang. Unless gcc makes a serious effort to shape up their inferior warning handling, I don't think we will ever be able to do something similar for gcc. But that is not a reason to avoid doing it on clang. In general, we have tried to utilize the strength of every compiler, regardless of if all the other compilers could detect the same problem or not. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17687#issuecomment-1926559951 From ihse at openjdk.org Mon Feb 5 09:40:02 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 5 Feb 2024 09:40:02 GMT Subject: RFR: 8325163: Enable -Wpedantic on clang In-Reply-To: References: Message-ID: <2eBjcv6yofxCGu0-QfWUdsMPBXcy-XEcm_d2ajzXbjg=.c4f93413-339f-4a39-aab9-cb8a4b4a7528@github.com> On Fri, 2 Feb 2024 15:22:03 GMT, Magnus Ihse Bursie wrote: > Inspired by (the later backed-out) [JDK-8296115](https://bugs.openjdk.org/browse/JDK-8296115), I propose to enable `-Wpedantic` for clang. This has already found some irregularities in the code, like mistakenly using `#import` instead of `#include`. In this patch, I disable warnings for these individual buggy or badly written files, but I intend to post follow-up issues on the respective teams to have them properly fixed. > > Unfortunately, it is not possible to enable `-Wpedantic` on gcc, since individual warnings in `-Wpedantic` cannot be disabled. This means that code like this: > > > #define DEBUG_ONLY(code) code; > > DEBUG_ONLY(foo()); > > > will result in a `; ;`. This breaks the C standard, but is benign, and we use it all over the place. On clang, we can ignore this by `-Wno-extra-semi`, but this is not available on gcc. Also, a general note about the parts of `pedantic` that is globally disabled in this PR (like `extra-semi` and `format-pedantic`). It might very well be that the offending code is restricted to a few places (if these places are in commonly included header files, I was forced to disable the warning globally), and that it can be rather easily fixed. All the better! But there is still no reason to do that *before* checking in this PR. Let's just get the minimum bar raised first. Then we can adress the issue of fixing the code to get rid of the exceptions for `extra-semi` and `format-pedantic`, if it is possible and if we want it. The latter is not at all clear; the rest of the list of globally disabled warnings (like `unused-parameter`) are warnings that we have agreed is useless, and only unfortunately dragged in with a catch-all flag like `-Wall` or `-Wextra`. From my PoV, the same could be said about `extra-semi`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17687#issuecomment-1926569091 From jwaters at openjdk.org Mon Feb 5 10:20:04 2024 From: jwaters at openjdk.org (Julian Waters) Date: Mon, 5 Feb 2024 10:20:04 GMT Subject: RFR: 8325163: Enable -Wpedantic on clang In-Reply-To: References: Message-ID: On Mon, 5 Feb 2024 09:32:09 GMT, Magnus Ihse Bursie wrote: > > at least not for a future version applying to gcc builds. > > @kimbarrett @TheShermanTanker Please do not drag gcc into this PR. This is just about clang. Unless gcc makes a serious effort to shape up their inferior warning handling, I don't think we will ever be able to do something similar for gcc. > > But that is not a reason to avoid doing it on clang. In general, we have tried to utilize the strength of every compiler, regardless of if all the other compilers could detect the same problem or not. Hey, I never said anything about gcc compatibility being a blocker for this changeset :) (I do have however a couple a questions which are listed above) ------------- PR Comment: https://git.openjdk.org/jdk/pull/17687#issuecomment-1926642510 From ihse at openjdk.org Mon Feb 5 10:48:01 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 5 Feb 2024 10:48:01 GMT Subject: RFR: 8325163: Enable -Wpedantic on clang In-Reply-To: References: Message-ID: On Fri, 2 Feb 2024 15:22:03 GMT, Magnus Ihse Bursie wrote: > Inspired by (the later backed-out) [JDK-8296115](https://bugs.openjdk.org/browse/JDK-8296115), I propose to enable `-Wpedantic` for clang. This has already found some irregularities in the code, like mistakenly using `#import` instead of `#include`. In this patch, I disable warnings for these individual buggy or badly written files, but I intend to post follow-up issues on the respective teams to have them properly fixed. > > Unfortunately, it is not possible to enable `-Wpedantic` on gcc, since individual warnings in `-Wpedantic` cannot be disabled. This means that code like this: > > > #define DEBUG_ONLY(code) code; > > DEBUG_ONLY(foo()); > > > will result in a `; ;`. This breaks the C standard, but is benign, and we use it all over the place. On clang, we can ignore this by `-Wno-extra-semi`, but this is not available on gcc. I am sorry, but all I can see is: > Just a few questions... and then your comment ends. And I can't find any other comment with a list of questions. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17687#issuecomment-1926693945 From ihse at openjdk.org Mon Feb 5 10:58:17 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 5 Feb 2024 10:58:17 GMT Subject: RFR: 8325163: Enable -Wpedantic on clang [v2] In-Reply-To: References: Message-ID: > Inspired by (the later backed-out) [JDK-8296115](https://bugs.openjdk.org/browse/JDK-8296115), I propose to enable `-Wpedantic` for clang. This has already found some irregularities in the code, like mistakenly using `#import` instead of `#include`. In this patch, I disable warnings for these individual buggy or badly written files, but I intend to post follow-up issues on the respective teams to have them properly fixed. > > Unfortunately, it is not possible to enable `-Wpedantic` on gcc, since individual warnings in `-Wpedantic` cannot be disabled. This means that code like this: > > > #define DEBUG_ONLY(code) code; > > DEBUG_ONLY(foo()); > > > will result in a `; ;`. This breaks the C standard, but is benign, and we use it all over the place. On clang, we can ignore this by `-Wno-extra-semi`, but this is not available on gcc. Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: FIx dtrace build ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17687/files - new: https://git.openjdk.org/jdk/pull/17687/files/4de3c446..ffa70af6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17687&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17687&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/17687.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17687/head:pull/17687 PR: https://git.openjdk.org/jdk/pull/17687 From jwaters at openjdk.org Mon Feb 5 10:58:17 2024 From: jwaters at openjdk.org (Julian Waters) Date: Mon, 5 Feb 2024 10:58:17 GMT Subject: RFR: 8325163: Enable -Wpedantic on clang In-Reply-To: References: Message-ID: On Mon, 5 Feb 2024 10:44:59 GMT, Magnus Ihse Bursie wrote: > I am sorry, but all I can see is: > > > Just a few questions... > > and then your comment ends. And I can't find any other comment with a list of questions. Eh? Aren't they in the code review section? But in any case: > Shouldn't this be -pedantic -Wpedantic, and wouldn't this be better positioned at where HotSpot currently sets -permissive- for Microsoft Visual C++ (In other words, TOOLCHAIN_CFLAGS_JVM and TOOLCHAIN_CFLAGS_JDK)? The 2 options are not the same, at least on gcc, and I'm unsure if the same is true for clang The other concern I had was that there are a ton of disabled warnings added by this change, but I guess that's already been answered by that other reply ------------- PR Comment: https://git.openjdk.org/jdk/pull/17687#issuecomment-1926701211 From mbaesken at openjdk.org Mon Feb 5 12:10:08 2024 From: mbaesken at openjdk.org (Matthias Baesken) Date: Mon, 5 Feb 2024 12:10:08 GMT Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v7] In-Reply-To: References: Message-ID: On Fri, 2 Feb 2024 06:55:19 GMT, Magnus Ihse Bursie wrote: >> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK native libraries. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Add kludge to BufferedRenderPipe.c for AIX Current commit compiles nicely on AIX. One issue we might still have statvfs/statvfs64 is not mentioned here in the table of functions/structs redefined on AIX https://www.ibm.com/docs/en/aix/7.1?topic=volumes-writing-programs-that-access-large-files so would we fall back to statvfs from the *64 - variant ? The define _LARGE_FILES might not help in this case on AIX . ------------- PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1926848063 From ihse at openjdk.org Mon Feb 5 12:18:04 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 5 Feb 2024 12:18:04 GMT Subject: RFR: 8325163: Enable -Wpedantic on clang In-Reply-To: References: Message-ID: On Mon, 5 Feb 2024 10:49:07 GMT, Julian Waters wrote: > Shouldn't this be -pedantic -Wpedantic, and wouldn't this be better positioned at where HotSpot currently sets -permissive- for Microsoft Visual C++ (In other words, TOOLCHAIN_CFLAGS_JVM and TOOLCHAIN_CFLAGS_JDK)? The 2 options are not the same, at least on gcc, and I'm unsure if the same is true for clang (It is really weird, I cannot find that original comment anywhere in the Github PR :-() As far as I have been able to determine, -Wpedantic and -pedantic are aliases on gcc > 5, and the same is true for clang. -Wpedantic seems to be the preferred way nowadays. `TOOLCHAIN_CFLAGS_JVM` is arguably if not wrong so at least not the best place to put `-permissive-`. `-Wpermissive` belongs with `-Wall -Wextra`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17687#issuecomment-1926861360 From jkern at openjdk.org Mon Feb 5 12:20:07 2024 From: jkern at openjdk.org (Joachim Kern) Date: Mon, 5 Feb 2024 12:20:07 GMT Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v7] In-Reply-To: References: Message-ID: On Mon, 5 Feb 2024 12:07:45 GMT, Matthias Baesken wrote: > Current commit compiles nicely on AIX. One issue we might still have statvfs/statvfs64 is not mentioned here in the table of functions/structs redefined on AIX https://www.ibm.com/docs/en/aix/7.1?topic=volumes-writing-programs-that-access-large-files so would we fall back to statvfs from the *64 - variant ? The define _LARGE_FILES might not help in this case on AIX . Yes, if statvfs64() is replaced by statvfs() in the code, we will fallback on AIX to 32-Bit. _LARGE_FILES really does not help in this case! ------------- PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1926865295 From ihse at openjdk.org Mon Feb 5 12:21:01 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 5 Feb 2024 12:21:01 GMT Subject: RFR: 8325163: Enable -Wpedantic on clang In-Reply-To: References: Message-ID: On Mon, 5 Feb 2024 10:49:07 GMT, Julian Waters wrote: > The other concern I had was that there are a ton of disabled warnings added by this change, but I guess that's already been answered by that other reply Just to be clear: these warnings have never been turned on. They are implicitly turned on by `-Wpedantic`; and this works fine with most files, but this improved scrutiny catches issues in some files. My idea is to file bugs on these individual disabled warnings, to have the actual problem fixed, but as follow up to this PR. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17687#issuecomment-1926867260 From mbaesken at openjdk.org Mon Feb 5 12:25:07 2024 From: mbaesken at openjdk.org (Matthias Baesken) Date: Mon, 5 Feb 2024 12:25:07 GMT Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v7] In-Reply-To: References: Message-ID: On Mon, 5 Feb 2024 12:17:33 GMT, Joachim Kern wrote: > Yes, if statvfs64() is replaced by statvfs() in the code, we will fallback on AIX to 32-Bit. _LARGE_FILES really does not help in this case! Thanks for confirming. I think we do not want to fallback on AIX, so the <*>64 variant needs to stay on AIX. Seems the other symbols are covered by _LARGE_FILES according to the table in the linked IBM AIX doc (table in https://www.ibm.com/docs/en/aix/7.1?topic=volumes-writing-programs-that-access-large-files ) , is that correct (Joachim?) or did I miss something ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1926874075 From jpai at openjdk.org Mon Feb 5 12:30:13 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 5 Feb 2024 12:30:13 GMT Subject: RFR: 8303866: Allow ZipInputStream.readEnd to parse small Zip64 ZIP files [v15] In-Reply-To: References: Message-ID: On Fri, 26 Jan 2024 14:32:58 GMT, Eirik Bj?rsn?s 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 AND at least one of the 'compressed size' and 'uncompressed size' have the expected Zip64 "magic" value 0xFFFFFFFF. 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 Bj?rsn?s has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 228 commits: > > - Merge branch 'master' into data-descriptor > - Update comment of expect64BitDataDescriptor to reflect relaxed validation > - Dial down validation of the Zip64 extra field > - 8321712: C2: "failed: Multiple uses of register" in C2_MacroAssembler::vminmax_fp > > Co-authored-by: Volodymyr Paprotski > Reviewed-by: kvn, thartmann, epeter, jbhateja > - 8319128: sun/security/pkcs11 tests fail on OL 7.9 aarch64 > > Reviewed-by: mbaesken > - 8322971: KEM.getInstance() should check if a 3rd-party security provider is signed > > Reviewed-by: mullan, valeriep > - 8320890: [AIX] Find a better way to mimic dl handle equality > > Reviewed-by: stuefe, mdoerr > - 8323276: StressDirListings.java fails on AIX > > Reviewed-by: jpai, dfuchs > - 8319793: C2 compilation fails with "Bad graph detected in build_loop_late" after JDK-8279888 > > Reviewed-by: chagedorn, epeter > - 8314515: java/util/concurrent/SynchronousQueue/Fairness.java failed with "Error: fair=false i=8 j=0" > > Reviewed-by: alanb > - ... and 218 more: https://git.openjdk.org/jdk/compare/e10d1400...4af7f500 Hello Eirik, thank you for the latest round of updates. These latest changes in commit `4af7f500` look good to me. I just have a trivial suggestion for the test which I've added inline. ------------- Marked as reviewed by jpai (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/12524#pullrequestreview-1862618593 From jpai at openjdk.org Mon Feb 5 12:34:13 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 5 Feb 2024 12:34:13 GMT Subject: RFR: 8303866: Allow ZipInputStream.readEnd to parse small Zip64 ZIP files [v15] In-Reply-To: References: Message-ID: On Fri, 26 Jan 2024 14:32:58 GMT, Eirik Bj?rsn?s 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 AND at least one of the 'compressed size' and 'uncompressed size' have the expected Zip64 "magic" value 0xFFFFFFFF. 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 Bj?rsn?s has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 228 commits: > > - Merge branch 'master' into data-descriptor > - Update comment of expect64BitDataDescriptor to reflect relaxed validation > - Dial down validation of the Zip64 extra field > - 8321712: C2: "failed: Multiple uses of register" in C2_MacroAssembler::vminmax_fp > > Co-authored-by: Volodymyr Paprotski > Reviewed-by: kvn, thartmann, epeter, jbhateja > - 8319128: sun/security/pkcs11 tests fail on OL 7.9 aarch64 > > Reviewed-by: mbaesken > - 8322971: KEM.getInstance() should check if a 3rd-party security provider is signed > > Reviewed-by: mullan, valeriep > - 8320890: [AIX] Find a better way to mimic dl handle equality > > Reviewed-by: stuefe, mdoerr > - 8323276: StressDirListings.java fails on AIX > > Reviewed-by: jpai, dfuchs > - 8319793: C2 compilation fails with "Bad graph detected in build_loop_late" after JDK-8279888 > > Reviewed-by: chagedorn, epeter > - 8314515: java/util/concurrent/SynchronousQueue/Fairness.java failed with "Error: fair=false i=8 j=0" > > Reviewed-by: alanb > - ... and 218 more: https://git.openjdk.org/jdk/compare/e10d1400...4af7f500 test/jdk/java/util/zip/ZipInputStream/Zip64DataDescriptor.java line 270: > 268: try (ZipInputStream in = new ZipInputStream(new ByteArrayInputStream(zip))) { > 269: ZipEntry e; > 270: while ( (e = in.getNextEntry()) != null) { The zip is expected to have a single ZipEntry. Would it be better to do something like this, so that if the ZipEntry is missing, then the test fails? (I haven't tested this code below) ZipEntry e = in.getNextEntry(); assertNotNull(e, "missing zip entry"); assertEquals("hello\n", new String(in.readAllBytes(), StandardCharsets.UTF_8)); assertNull(in.getNextEntry(), "unexpected additional zip entry"); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/12524#discussion_r1478134704 From jlaskey at openjdk.org Mon Feb 5 12:37:14 2024 From: jlaskey at openjdk.org (Jim Laskey) Date: Mon, 5 Feb 2024 12:37:14 GMT Subject: RFR: JDK-8310913 Move ReferencedKeyMap to jdk.internal so it may be shared [v10] In-Reply-To: References: Message-ID: On Sat, 3 Feb 2024 07:20:14 GMT, ExE Boss 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 17 commits: >> >> - Merge branch 'master' into 8310913 >> - Update implNote for intern >> - Merge branch 'master' into 8310913 >> - Requested changes. >> >> Added intern with UnaryOperator interning function to prepare key before adding to set. >> - Update test to check for gc. >> - Update ReferencedKeyTest.java >> - Simple versions of create >> - Add flag for reference queue type >> - Merge branch 'master' into 8310913 >> - Update to use VirtualThread friendly stale queue. >> - ... and 7 more: https://git.openjdk.org/jdk/compare/408987e1...af95e5ae > > src/java.base/share/classes/jdk/internal/util/ReferencedKeySet.java line 151: > >> 149: @Override >> 150: public boolean add(T e) { >> 151: return intern(e) == null; > > This?line is?wrong, as?`intern(?)` will?never return?`null`. > > -------------------------------------------------------------------------------- > > This?is the?closest to?the?correct implementation, > Suggestion: > > return !contains(e) & intern(e) == e; > > > but?may incorrectly return?`true` in?case of?the?following data?race, assuming?`t1e ==?t2e`: > > 1. **Thread?1** calls `contains(t1e)` and gets `false`. > 2. **Thread 2** calls `intern(t2e)` and successfully adds `t2e`. > 3. **Thread?1** calls `intern(t1e)` and gets back `t2e`, which?is?`==` to?`t1e`. > 4. **Thread?1** returns `true`, even?though it?was **Thread?2** which?modified the?`ReferencedKeySet`. Good catch. Your solution might be correct but I think `!contains(e)` is redundant since that is how intern starts out. static T intern(ReferencedKeyMap> setMap, T key, UnaryOperator interner) { T value = existingKey(setMap, key); if (value != null) { return value; } key = interner.apply(key); return internKey(setMap, key); } Agree? So changing to `return intern(e) == e;` should be sufficient. The other aspect of this is that `internKey` uses `putIfAbsent` which should prevent the race (assuming `ConcurrentHashMap`). /** * Attempt to add key to map. * * @param setMap {@link ReferencedKeyMap} where interning takes place * @param key key to add * * @param type of key * * @return the old key instance if found otherwise the new key instance */ private static T internKey(ReferencedKeyMap> setMap, T key) { ReferenceKey entryKey = setMap.entryKey(key); T interned; do { setMap.removeStaleReferences(); ReferenceKey existing = setMap.map.putIfAbsent(entryKey, entryKey); if (existing == null) { return key; } else { // If {@code putIfAbsent} returns non-null then was actually a // {@code replace} and older key was used. In that case the new // key was not used and the reference marked stale. interned = existing.get(); if (interned != null) { entryKey.unused(); } } } while (interned == null); return interned; } Agree? Anyone else want to pipe in? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14684#discussion_r1478137517 From ihse at openjdk.org Mon Feb 5 12:41:11 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 5 Feb 2024 12:41:11 GMT Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v7] In-Reply-To: References: Message-ID: On Fri, 2 Feb 2024 06:55:19 GMT, Magnus Ihse Bursie wrote: >> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK native libraries. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Add kludge to BufferedRenderPipe.c for AIX It seems like the statvfs64 is a pre-existing bug in AIX in that case. I have not removed any statvfs64 for AIX; all such changes are guarded by `#ifdef _ALLBSD_SOURCE`, which I presume is not defined on AIX. I recommend that I push this PR as-is first, and then you can do a follow-up fix to define statvfs to statvfs64 on AIX. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1926903203 From mbaesken at openjdk.org Mon Feb 5 12:51:08 2024 From: mbaesken at openjdk.org (Matthias Baesken) Date: Mon, 5 Feb 2024 12:51:08 GMT Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v7] In-Reply-To: References: Message-ID: <_bDxv8SN2pD8KNWdhQ4SsTJMkbNyA2m9ERs87kg_yIk=.d76dcb5f-8f11-4515-ab0c-ceff66c09ffa@github.com> On Mon, 5 Feb 2024 12:38:03 GMT, Magnus Ihse Bursie wrote: > It seems like the statvfs64 is a pre-existing bug in AIX in that case. I have not removed any statvfs64 for AIX; all such changes are guarded by `#ifdef _ALLBSD_SOURCE`, which I presume is not defined on AIX. > > I recommend that I push this PR as-is first, and then you can do a follow-up fix to define statvfs to statvfs64 on AIX. Java_sun_nio_fs_UnixNativeDispatcher_statvfs0 is changed from statvfs64 to statvfs, did I miss something ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1926925394 From jwaters at openjdk.org Mon Feb 5 12:51:06 2024 From: jwaters at openjdk.org (Julian Waters) Date: Mon, 5 Feb 2024 12:51:06 GMT Subject: RFR: 8325163: Enable -Wpedantic on clang In-Reply-To: References: Message-ID: On Mon, 5 Feb 2024 12:15:50 GMT, Magnus Ihse Bursie wrote: > > Shouldn't this be -pedantic -Wpedantic, and wouldn't this be better positioned at where HotSpot currently sets -permissive- for Microsoft Visual C++ (In other words, TOOLCHAIN_CFLAGS_JVM and TOOLCHAIN_CFLAGS_JDK)? The 2 options are not the same, at least on gcc, and I'm unsure if the same is true for clang > > (It is really weird, I cannot find that original comment anywhere in the Github PR :-() > > As far as I have been able to determine, -Wpedantic and -pedantic are aliases on gcc > 5, and the same is true for clang. -Wpedantic seems to be the preferred way nowadays. > > `TOOLCHAIN_CFLAGS_JVM` is arguably if not wrong so at least not the best place to put `-permissive-`. `-Wpermissive` belongs with `-Wall -Wextra`. TOOLCHAIN_CFLAGS_JVM and TOOLCHAIN_CFLAGS_JDK have, until now, been where the -Zc: conformance options are passed, which is why I recommended adding them there, to match what Visual C++ does at the moment. Maybe I have it the other way around, and it is Visual C++ that needs to be changed to match clang (Both for permissive- and -Zc: options) ------------- PR Comment: https://git.openjdk.org/jdk/pull/17687#issuecomment-1926925644 From jwaters at openjdk.org Mon Feb 5 13:03:01 2024 From: jwaters at openjdk.org (Julian Waters) Date: Mon, 5 Feb 2024 13:03:01 GMT Subject: RFR: 8325163: Enable -Wpedantic on clang [v2] In-Reply-To: References: Message-ID: On Mon, 5 Feb 2024 10:58:17 GMT, Magnus Ihse Bursie wrote: >> Inspired by (the later backed-out) [JDK-8296115](https://bugs.openjdk.org/browse/JDK-8296115), I propose to enable `-Wpedantic` for clang. This has already found some irregularities in the code, like mistakenly using `#import` instead of `#include`. In this patch, I disable warnings for these individual buggy or badly written files, but I intend to post follow-up issues on the respective teams to have them properly fixed. >> >> Unfortunately, it is not possible to enable `-Wpedantic` on gcc, since individual warnings in `-Wpedantic` cannot be disabled. This means that code like this: >> >> >> #define DEBUG_ONLY(code) code; >> >> DEBUG_ONLY(foo()); >> >> >> will result in a `; ;`. This breaks the C standard, but is benign, and we use it all over the place. On clang, we can ignore this by `-Wno-extra-semi`, but this is not available on gcc. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > FIx dtrace build The following is all that I was able to find, on the latest gcc docs. Nothing came up for clang for the search term "-pedantic vs -Wpedantic" > -pedantic-errors > Give an error whenever the base standard (see -Wpedantic) requires a diagnostic, in some cases where there is undefined behavior at compile-time and in some other cases that do not prevent compilation of programs that are valid according to the standard. This is not equivalent to -Werror=pedantic: the latter option is unlikely to be useful, as it only makes errors of the diagnostics that are controlled by -Wpedantic, whereas this option also affects required diagnostics that are always enabled or controlled by options other than -Wpedantic. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17687#issuecomment-1926946873 From eirbjo at openjdk.org Mon Feb 5 13:14:39 2024 From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=) Date: Mon, 5 Feb 2024 13:14:39 GMT Subject: RFR: 8303866: Allow ZipInputStream.readEnd to parse small Zip64 ZIP files [v15] In-Reply-To: References: Message-ID: On Mon, 5 Feb 2024 12:31:37 GMT, Jaikiran Pai wrote: >> Eirik Bj?rsn?s has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 228 commits: >> >> - Merge branch 'master' into data-descriptor >> - Update comment of expect64BitDataDescriptor to reflect relaxed validation >> - Dial down validation of the Zip64 extra field >> - 8321712: C2: "failed: Multiple uses of register" in C2_MacroAssembler::vminmax_fp >> >> Co-authored-by: Volodymyr Paprotski >> Reviewed-by: kvn, thartmann, epeter, jbhateja >> - 8319128: sun/security/pkcs11 tests fail on OL 7.9 aarch64 >> >> Reviewed-by: mbaesken >> - 8322971: KEM.getInstance() should check if a 3rd-party security provider is signed >> >> Reviewed-by: mullan, valeriep >> - 8320890: [AIX] Find a better way to mimic dl handle equality >> >> Reviewed-by: stuefe, mdoerr >> - 8323276: StressDirListings.java fails on AIX >> >> Reviewed-by: jpai, dfuchs >> - 8319793: C2 compilation fails with "Bad graph detected in build_loop_late" after JDK-8279888 >> >> Reviewed-by: chagedorn, epeter >> - 8314515: java/util/concurrent/SynchronousQueue/Fairness.java failed with "Error: fair=false i=8 j=0" >> >> Reviewed-by: alanb >> - ... and 218 more: https://git.openjdk.org/jdk/compare/e10d1400...4af7f500 > > test/jdk/java/util/zip/ZipInputStream/Zip64DataDescriptor.java line 270: > >> 268: try (ZipInputStream in = new ZipInputStream(new ByteArrayInputStream(zip))) { >> 269: ZipEntry e; >> 270: while ( (e = in.getNextEntry()) != null) { > > The zip is expected to have a single ZipEntry. Would it be better to do something like this, so that if the ZipEntry is missing, then the test fails? > > (I haven't tested this code below) > > > ZipEntry e = in.getNextEntry(); > assertNotNull(e, "missing zip entry"); > assertEquals("hello\n", new String(in.readAllBytes(), StandardCharsets.UTF_8)); > assertNull(in.getNextEntry(), "unexpected additional zip entry"); Thanks @jaikiran, I updated the method based on your suggesion, and also added some comments to help explain what happens where. Perhaps useful for someone not intimately familiar with ZipInputStream. I'll hold on integrating this until Lance finds time to have a final look. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/12524#discussion_r1478219071 From eirbjo at openjdk.org Mon Feb 5 13:14:39 2024 From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=) Date: Mon, 5 Feb 2024 13:14:39 GMT Subject: RFR: 8303866: Allow ZipInputStream.readEnd to parse small Zip64 ZIP files [v16] 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 AND at least one of the 'compressed size' and 'uncompressed size' have the expected Zip64 "magic" value 0xFFFFFFFF. 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 Bj?rsn?s has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 230 commits: - Update readZipInputStream to verify that the ZipInputStream finds a single zip entry with the expected contents - Merge branch 'master' into data-descriptor - Merge branch 'master' into data-descriptor - Update comment of expect64BitDataDescriptor to reflect relaxed validation - Dial down validation of the Zip64 extra field - 8321712: C2: "failed: Multiple uses of register" in C2_MacroAssembler::vminmax_fp Co-authored-by: Volodymyr Paprotski Reviewed-by: kvn, thartmann, epeter, jbhateja - 8319128: sun/security/pkcs11 tests fail on OL 7.9 aarch64 Reviewed-by: mbaesken - 8322971: KEM.getInstance() should check if a 3rd-party security provider is signed Reviewed-by: mullan, valeriep - 8320890: [AIX] Find a better way to mimic dl handle equality Reviewed-by: stuefe, mdoerr - 8323276: StressDirListings.java fails on AIX Reviewed-by: jpai, dfuchs - ... and 220 more: https://git.openjdk.org/jdk/compare/692c9f88...e8d3b904 ------------- Changes: https://git.openjdk.org/jdk/pull/12524/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12524&range=15 Stats: 342 lines in 2 files changed: 338 ins; 0 del; 4 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 jpai at openjdk.org Mon Feb 5 13:19:13 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 5 Feb 2024 13:19:13 GMT Subject: RFR: 8303866: Allow ZipInputStream.readEnd to parse small Zip64 ZIP files [v16] In-Reply-To: References: Message-ID: On Mon, 5 Feb 2024 13:14:39 GMT, Eirik Bj?rsn?s 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 AND at least one of the 'compressed size' and 'uncompressed size' have the expected Zip64 "magic" value 0xFFFFFFFF. 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 Bj?rsn?s has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 230 commits: > > - Update readZipInputStream to verify that the ZipInputStream finds a single zip entry with the expected contents > - Merge branch 'master' into data-descriptor > - Merge branch 'master' into data-descriptor > - Update comment of expect64BitDataDescriptor to reflect relaxed validation > - Dial down validation of the Zip64 extra field > - 8321712: C2: "failed: Multiple uses of register" in C2_MacroAssembler::vminmax_fp > > Co-authored-by: Volodymyr Paprotski > Reviewed-by: kvn, thartmann, epeter, jbhateja > - 8319128: sun/security/pkcs11 tests fail on OL 7.9 aarch64 > > Reviewed-by: mbaesken > - 8322971: KEM.getInstance() should check if a 3rd-party security provider is signed > > Reviewed-by: mullan, valeriep > - 8320890: [AIX] Find a better way to mimic dl handle equality > > Reviewed-by: stuefe, mdoerr > - 8323276: StressDirListings.java fails on AIX > > Reviewed-by: jpai, dfuchs > - ... and 220 more: https://git.openjdk.org/jdk/compare/692c9f88...e8d3b904 Thank you for the update, looks good to me. ------------- Marked as reviewed by jpai (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/12524#pullrequestreview-1862767326 From ihse at openjdk.org Mon Feb 5 13:37:03 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 5 Feb 2024 13:37:03 GMT Subject: RFR: 8325163: Enable -Wpedantic on clang [v2] In-Reply-To: References: Message-ID: On Mon, 5 Feb 2024 10:58:17 GMT, Magnus Ihse Bursie wrote: >> Inspired by (the later backed-out) [JDK-8296115](https://bugs.openjdk.org/browse/JDK-8296115), I propose to enable `-Wpedantic` for clang. This has already found some irregularities in the code, like mistakenly using `#import` instead of `#include`. In this patch, I disable warnings for these individual buggy or badly written files, but I intend to post follow-up issues on the respective teams to have them properly fixed. >> >> Unfortunately, it is not possible to enable `-Wpedantic` on gcc, since individual warnings in `-Wpedantic` cannot be disabled. This means that code like this: >> >> >> #define DEBUG_ONLY(code) code; >> >> DEBUG_ONLY(foo()); >> >> >> will result in a `; ;`. This breaks the C standard, but is benign, and we use it all over the place. On clang, we can ignore this by `-Wno-extra-semi`, but this is not available on gcc. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > FIx dtrace build The split in different categories of flags is perhaps not perfect, and more a heuristic to help us manage them. However, I think we are talking about two different categories here. The `/Z` flags change the behavior of the compiler to be more standards compliant (similar to `-std=c++1` on gcc/clang). The `-Wpedantic" flag enables a batch of additional warnings on top of `-Wall` and `-Wextra`. The only way this makes it more "standards compliant" is that the standard requires the compiler to produce a warning in these situations. But that is not really why we want to turn it on; we want it to be able to catch bad or suboptimal code. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17687#issuecomment-1927025804 From ihse at openjdk.org Mon Feb 5 13:58:08 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 5 Feb 2024 13:58:08 GMT Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v7] In-Reply-To: References: Message-ID: On Fri, 2 Feb 2024 06:55:19 GMT, Magnus Ihse Bursie wrote: >> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK native libraries. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Add kludge to BufferedRenderPipe.c for AIX RIght, my bad. I apologize, you are completely correct, I turned the defines around in my head. I will add a redefine for AIX that turns statvfs into statvfs64. Thanks for noticing! ------------- PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1927065583 From ihse at openjdk.org Mon Feb 5 14:06:21 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 5 Feb 2024 14:06:21 GMT Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v8] In-Reply-To: References: Message-ID: > Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK native libraries. Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: Redefine statvfs as statvfs64 on AIX ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17538/files - new: https://git.openjdk.org/jdk/pull/17538/files/3c404183..2de377cd Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17538&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17538&range=06-07 Stats: 9 lines in 3 files changed: 9 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/17538.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17538/head:pull/17538 PR: https://git.openjdk.org/jdk/pull/17538 From ihse at openjdk.org Mon Feb 5 14:06:21 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 5 Feb 2024 14:06:21 GMT Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v7] In-Reply-To: References: Message-ID: On Fri, 2 Feb 2024 06:55:19 GMT, Magnus Ihse Bursie wrote: >> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK native libraries. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Add kludge to BufferedRenderPipe.c for AIX I hope finally the AIX part of this PR is done. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1927082091 From mbaesken at openjdk.org Mon Feb 5 14:18:08 2024 From: mbaesken at openjdk.org (Matthias Baesken) Date: Mon, 5 Feb 2024 14:18:08 GMT Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v7] In-Reply-To: References: Message-ID: On Mon, 5 Feb 2024 14:03:45 GMT, Magnus Ihse Bursie wrote: > I hope finally the AIX part of this PR is done. Thanks for the AIX related effort ; I put it again into our internal build/test queue. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1927105669 From kbarrett at openjdk.org Mon Feb 5 14:59:03 2024 From: kbarrett at openjdk.org (Kim Barrett) Date: Mon, 5 Feb 2024 14:59:03 GMT Subject: RFR: 8325163: Enable -Wpedantic on clang In-Reply-To: <5YoWExp50qGIjilv-9yq38jGsb3Fw7MJCQ8Sfc3Wp3c=.189956da-6f76-4723-9d4a-11d20b43eeb4@github.com> References: <5YoWExp50qGIjilv-9yq38jGsb3Fw7MJCQ8Sfc3Wp3c=.189956da-6f76-4723-9d4a-11d20b43eeb4@github.com> Message-ID: <3AE9BcnKj566JJ4k4SyxWqOHcG-WBmg3IvuM2LRS1zk=.49557d58-19ce-41f6-88fc-8042e184f380@github.com> On Mon, 5 Feb 2024 03:21:35 GMT, Kim Barrett wrote: >> Inspired by (the later backed-out) [JDK-8296115](https://bugs.openjdk.org/browse/JDK-8296115), I propose to enable `-Wpedantic` for clang. This has already found some irregularities in the code, like mistakenly using `#import` instead of `#include`. In this patch, I disable warnings for these individual buggy or badly written files, but I intend to post follow-up issues on the respective teams to have them properly fixed. >> >> Unfortunately, it is not possible to enable `-Wpedantic` on gcc, since individual warnings in `-Wpedantic` cannot be disabled. This means that code like this: >> >> >> #define DEBUG_ONLY(code) code; >> >> DEBUG_ONLY(foo()); >> >> >> will result in a `; ;`. This breaks the C standard, but is benign, and we use it all over the place. On clang, we can ignore this by `-Wno-extra-semi`, but this is not available on gcc. > >> Inspired by (the later backed-out) [JDK-8296115](https://bugs.openjdk.org/browse/JDK-8296115), I propose to enable `-Wpedantic` for clang. This has already found some irregularities in the code, like mistakenly using `#import` instead of `#include`. In this patch, I disable warnings for these individual buggy or badly written files, but I intend to post follow-up issues on the respective teams to have them properly fixed. > > Rather than first turning on pedantic warnings and then (maybe) going back and perhaps fixing things, I'd really prefer > things be done in the other order. (That's how I handled the recent `-Wparentheses` changes, for example.) > @kimbarrett quoting the gcc maintainers > > > Yes because the C++ defect report was only for `Spurious semicolons at namespace scope should be allowed`. See https://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#569 . > > ``` > > struct f > > { > > int t; ; > > }; > > ``` > > > > Is not allowed by the C++ standard currently and is a GCC extension, maybe it should have a seperate flag to control that but I am not 100% sure. That's incorrect, and I've replied in the gcc bug. C++14 added "empty-declaration" to "member-declaration" (C++ 9.2). ------------- PR Comment: https://git.openjdk.org/jdk/pull/17687#issuecomment-1927189316 From erikj at openjdk.org Mon Feb 5 15:12:01 2024 From: erikj at openjdk.org (Erik Joelsson) Date: Mon, 5 Feb 2024 15:12:01 GMT Subject: RFR: JDK-8325189: Enable this-escape javac warning in java.base In-Reply-To: References: Message-ID: On Fri, 2 Feb 2024 23:36:41 GMT, Joe Darcy wrote: > After the "this-escape" lint warning was added to javac (JDK-8015831), the base module was not updated to be able to compile with this warning enabled. This PR makes the necessary changes to allow the base module to build with the warning enabled. Marked as reviewed by erikj (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/17692#pullrequestreview-1863050713 From rriggs at openjdk.org Mon Feb 5 15:15:07 2024 From: rriggs at openjdk.org (Roger Riggs) Date: Mon, 5 Feb 2024 15:15:07 GMT Subject: RFR: 8325169: Reduce String::indexOf overheads [v3] In-Reply-To: References: Message-ID: On Sat, 3 Feb 2024 14:36:14 GMT, Claes Redestad wrote: >> This patch streamlines and specializes various `String::indexOf` methods. Mainly avoids the need for clamping and doing checks that are redundant in almost all cases, moving the checks to the API boundary where they are needed. >> >> This improves performance both at peak and during startup/warmup. Since indexOf is heavily used in bootstrapping code it makes sense to slightly dial back abstraction and delegation, which in this case also brought some benefit to peak performance. >> >> Testing: tier1-3 > > Claes Redestad has updated the pull request incrementally with two additional commits since the last revision: > > - Update comments regarding bounds checks > - Clamp fromIndex to be in range Marked as reviewed by rriggs (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/17685#pullrequestreview-1863061296 From kim.barrett at oracle.com Mon Feb 5 15:30:02 2024 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 5 Feb 2024 15:30:02 +0000 Subject: RFR: 8325163: Enable -Wpedantic on clang In-Reply-To: References: <5YoWExp50qGIjilv-9yq38jGsb3Fw7MJCQ8Sfc3Wp3c=.189956da-6f76-4723-9d4a-11d20b43eeb4@github.com> Message-ID: <1AD04C4D-E8E0-461B-99E4-0FDABBF48F4D@oracle.com> > On Feb 5, 2024, at 4:31 AM, Magnus Ihse Bursie wrote: > > On Mon, 5 Feb 2024 03:21:35 GMT, Kim Barrett wrote: > >>> Inspired by (the later backed-out) [JDK-8296115](https://bugs.openjdk.org/browse/JDK-8296115), I propose to enable `-Wpedantic` for clang. This has already found some irregularities in the code, like mistakenly using `#import` instead of `#include`. In this patch, I disable warnings for these individual buggy or badly written files, but I intend to post follow-up issues on the respective teams to have them properly fixed. >>> >>> Unfortunately, it is not possible to enable `-Wpedantic` on gcc, since individual warnings in `-Wpedantic` cannot be disabled. This means that code like this: >>> >>> >>> #define DEBUG_ONLY(code) code; >>> >>> DEBUG_ONLY(foo()); >>> >>> >>> will result in a `; ;`. This breaks the C standard, but is benign, and we use it all over the place. On clang, we can ignore this by `-Wno-extra-semi`, but this is not available on gcc. >> >>> Inspired by (the later backed-out) [JDK-8296115](https://bugs.openjdk.org/browse/JDK-8296115), I propose to enable `-Wpedantic` for clang. This has already found some irregularities in the code, like mistakenly using `#import` instead of `#include`. In this patch, I disable warnings for these individual buggy or badly written files, but I intend to post follow-up issues on the respective teams to have them properly fixed. >> >> Rather than first turning on pedantic warnings and then (maybe) going back and perhaps fixing things, I'd really prefer >> things be done in the other order. (That's how I handled the recent `-Wparentheses` changes, for example.) > > @kimbarrett >> Rather than first turning on pedantic warnings and then (maybe) going back and perhaps fixing things, I'd really prefer > things be done in the other order. > > I hear what you are saying, but I respectfully disagree. If we do things in the order you suggest, the global flag cannot be turned on until all component teams have fixed their source code. That essentially makes the most overworked group putting an effective veto to this change (when your workload is too high, fixing warnings is not on top of your priority.) In contrast, if the global warning can be turned on now, it will have a positive effect on all new and modified code from now on. And the teams can work on their individual warnings, and remove them in their own time. Without knowing what the actual warnings are that are being triggered and then suppressed, I can't even begin to evaluate this change. Not all warnings are good and useful. Sometimes the avoidance effort is really not worth the benefit. Sometimes there is a future change to the Standard that is already supported as an extension. Sometimes there is a widely supported extension that has perhaps just not yet made it into the Standard. Sometimes platform-specific code uses platform-specific extensions. And so on. Enabling -Wpedantic requires an evaluation of the costs and benefits and a decision that there's a good tradeoff there. So far, this PR doesn't do that. Fixing the warnings first, or at least having the relevant bug reports, would provide that information. > This is the same method I used for turning on -Wall and -Wextra. Some teams are very eager to fix warnings, and others still have almost all their "DISABLED_WARNINGS" left several years later. (I will not mention any names; you both know who you are ;-)). If I had followed the route you suggest, we would not have -Wall -Wextra on all source code (sans a few, marked files) now. For -Wparentheses I took the opposite approach and fixed all occurrences (finding and fixing a couple of bugs in the process) before enabling them. We've also been approaching -Wconversion from that direction. I think the enabled but then suppressed warnings has led to an out-of-sight out-of-mind situation for the suppressed warnings. I was not particularly happy with adding -Wextra, for example, because I think some of the warnings it triggers are questionable. You and I went through a very similar discussion for enabling that option for HotSpot. Right now I don't even have the information needed for such a discussion. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From kbarrett at openjdk.org Mon Feb 5 15:45:02 2024 From: kbarrett at openjdk.org (Kim Barrett) Date: Mon, 5 Feb 2024 15:45:02 GMT Subject: RFR: 8325163: Enable -Wpedantic on clang In-Reply-To: References: Message-ID: On Mon, 5 Feb 2024 06:15:08 GMT, David Holmes wrote: > > I consider the "format '%p' expects argument of type 'void*" warnings to be not at all helpful. Fortunately we don't use '%p' in HotSpot, > > We do use it in hotspot. Not a huge amount as we have the legacy format specifiers for PTR_FORMAT etc. You are correct, we do use "%p" a fair amount (107 lines today). I thought we didn't, because we were instead supposed to use INTPTR_FORMAT and the (currently?) equivalent PTR_FORMAT. Those macros aren't legacy, they are to provide consistent output across platforms. "%p" provides implementation defined output. For example, if I remember correctly, gcc "%p" prints "(null)" for nullptr, with no mechanism (such as a conversion flag) to control that. If you are printing a table of pointers, and you expect only numeric values because you are going to be processing the table or copying it into a spreadsheet or the like, that gcc-specific behavior isn't very helpful. Instead, we're "supposed" to use the `p2i` function and PTR_FORMAT for printing pointers, to get the same output on all platforms. That idiom also avoids the not very helpful -Wpedantic warnings. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17687#issuecomment-1927288508 From kbarrett at openjdk.org Mon Feb 5 15:50:04 2024 From: kbarrett at openjdk.org (Kim Barrett) Date: Mon, 5 Feb 2024 15:50:04 GMT Subject: RFR: 8325163: Enable -Wpedantic on clang In-Reply-To: References: Message-ID: On Mon, 5 Feb 2024 15:42:40 GMT, Kim Barrett wrote: >>> I consider the "format '%p' expects argument of type 'void*" warnings to be not at all helpful. Fortunately we don't use '%p' in HotSpot, >> >> We do use it in hotspot. Not a huge amount as we have the legacy format specifiers for PTR_FORMAT etc. > >> > I consider the "format '%p' expects argument of type 'void*" warnings to be not at all helpful. Fortunately we don't use '%p' in HotSpot, >> >> We do use it in hotspot. Not a huge amount as we have the legacy format specifiers for PTR_FORMAT etc. > > You are correct, we do use "%p" a fair amount (107 lines today). > > I thought we didn't, because we were instead supposed to use INTPTR_FORMAT and > the (currently?) equivalent PTR_FORMAT. Those macros aren't legacy, they are > to provide consistent output across platforms. "%p" provides implementation > defined output. For example, if I remember correctly, gcc "%p" prints "(null)" > for nullptr, with no mechanism (such as a conversion flag) to control that. If > you are printing a table of pointers, and you expect only numeric values > because you are going to be processing the table or copying it into a > spreadsheet or the like, that gcc-specific behavior isn't very helpful. > > Instead, we're "supposed" to use the `p2i` function and PTR_FORMAT for > printing pointers, to get the same output on all platforms. That idiom also > avoids the not very helpful -Wpedantic warnings. > > @kimbarrett quoting the gcc maintainers > > > Yes because the C++ defect report was only for `Spurious semicolons at namespace scope should be allowed`. See https://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#569 . > > > ``` > > > struct f > > > { > > > int t; ; > > > }; > > > ``` > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Is not allowed by the C++ standard currently and is a GCC extension, maybe it should have a seperate flag to control that but I am not 100% sure. > > That's incorrect, and I've replied in the gcc bug. C++14 added "empty-declaration" to "member-declaration" (C++ 9.2). With my additional information the gcc bug has now been confirmed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17687#issuecomment-1927299264 From mbaesken at openjdk.org Mon Feb 5 16:00:01 2024 From: mbaesken at openjdk.org (Matthias Baesken) Date: Mon, 5 Feb 2024 16:00:01 GMT Subject: RFR: JDK-8324930: java/lang/StringBuilder problem with concurrent jtreg runs In-Reply-To: References: Message-ID: On Tue, 30 Jan 2024 09:08:28 GMT, Matthias Baesken wrote: > On some Windows machines we see sometimes OOM errors because of high resource (memory/swap) consumption. This is especially seen when the jtreg runs have higher concurrency. A solution is to put the java/lang/StringBuilder tests in the exclusiveAccess.dirs group so that they are not executed concurrently, which helps to mitigate the resource shortages. > Of course this has the downside that on very large machines the concurrent execution is not done any more. This is what the thread stack looks like in hs_err for example for java\lang\StringBuilder\Insert\hs_err_pid910208.log we had on Sun Jan 07 20:32:56 CET 2024 such an hs err file with thread stack : # # There is insufficient memory for the Java Runtime Environment to continue. # Native memory allocation (mmap) failed to map 536870912 bytes. Error detail: G1 virtual space # Possible reasons: # The system is out of physical RAM or swap space # This process is running with CompressedOops enabled, and the Java Heap may be blocking the growth of the native heap # Possible solutions: # Reduce memory load on the system # Increase physical memory or swap space # Check if swap backing store is full # Decrease Java heap size (-Xmx/-Xms) # Decrease number of Java threads # Decrease Java thread stack sizes (-Xss) # Set larger code cache with -XX:ReservedCodeCacheSize= # JVM is running with Unscaled Compressed Oops mode in which the Java heap is # placed in the first 4GB address space. The Java Heap base address is the # maximum limit for the native heap growth. Please use -XX:HeapBaseMinAddress # to set the Java Heap base and to place the Java Heap above 4GB virtual address. # This output file may be truncated or incomplete. # # Out of Memory Error (c:\openjdk-jdk-dev-windows_x86_64-dbg\jdk\src\hotspot\os\windows\os_windows.cpp:3627), pid=910208, tid=910648 # # JRE version: (23.0) (fastdebug build ) # Java VM: OpenJDK 64-Bit Server VM (fastdebug 23-internal-adhoc.GLOBALsapmachine.jdk, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, windows-amd64) # CreateCoredumpOnCrash turned off, no core file dumped # ... --------------- T H R E A D --------------- Current thread (0x000002178c5a44c0): JavaThread "Unknown thread" [_thread_in_vm, id=910648, stack(0x000000eeec500000,0x000000eeec600000) (1024K)] Stack: [0x000000eeec500000,0x000000eeec600000] Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [jvm.dll+0xc96581] os::win32::platform_print_native_stack+0x101 (os_windows_x86.cpp:236) V [jvm.dll+0xfe7b31] VMError::report+0x1491 (vmError.cpp:1005) V [jvm.dll+0xfea055] VMError::report_and_die+0x645 (vmError.cpp:1834) V [jvm.dll+0xfea7cf] VMError::report_and_die+0x5f (vmError.cpp:1604) V [jvm.dll+0x559d4f] report_vm_out_of_memory+0x5f (debug.cpp:225) V [jvm.dll+0xc91c5d] os::pd_commit_memory_or_exit+0xad (os_windows.cpp:3635) V [jvm.dll+0xc82a2e] os::commit_memory_or_exit+0x6e (os.cpp:2051) V [jvm.dll+0x6de800] G1PageBasedVirtualSpace::commit+0x100 (g1PageBasedVirtualSpace.cpp:192) V [jvm.dll+0x6f0aff] G1RegionsLargerThanCommitSizeMapper::commit_regions+0x7f (g1RegionToSpaceMapper.cpp:100) V [jvm.dll+0x7806da] HeapRegionManager::expand+0x8a (heapRegionManager.cpp:164) V [jvm.dll+0x780be6] HeapRegionManager::expand_by+0xf6 (heapRegionManager.cpp:361) V [jvm.dll+0x6812e4] G1CollectedHeap::expand+0xf4 (g1CollectedHeap.cpp:1014) V [jvm.dll+0x682dc6] G1CollectedHeap::initialize+0x596 (g1CollectedHeap.cpp:1389) V [jvm.dll+0xf823e0] universe_init+0x140 (universe.cpp:794) V [jvm.dll+0x79c8c1] init_globals+0x31 (init.cpp:126) V [jvm.dll+0xf5c20e] Threads::create_vm+0x2ae (threads.cpp:552) V [jvm.dll+0x8c17b2] JNI_CreateJavaVM_inner+0x82 (jni.cpp:3576) V [jvm.dll+0x8c5d9f] JNI_CreateJavaVM+0x1f (jni.cpp:3667) C [jli.dll+0x539f] JavaMain+0x113 (java.c:491) C [ucrtbase.dll+0x2268a] (no source info available) C [KERNEL32.DLL+0x17ac4] (no source info available) C [ntdll.dll+0x5a4e1] (no source info available) ------------- PR Comment: https://git.openjdk.org/jdk/pull/17625#issuecomment-1927319309 From jwaters at openjdk.org Mon Feb 5 16:03:02 2024 From: jwaters at openjdk.org (Julian Waters) Date: Mon, 5 Feb 2024 16:03:02 GMT Subject: RFR: 8325163: Enable -Wpedantic on clang [v2] In-Reply-To: References: Message-ID: On Mon, 5 Feb 2024 10:58:17 GMT, Magnus Ihse Bursie wrote: >> Inspired by (the later backed-out) [JDK-8296115](https://bugs.openjdk.org/browse/JDK-8296115), I propose to enable `-Wpedantic` for clang. This has already found some irregularities in the code, like mistakenly using `#import` instead of `#include`. In this patch, I disable warnings for these individual buggy or badly written files, but I intend to post follow-up issues on the respective teams to have them properly fixed. >> >> Unfortunately, it is not possible to enable `-Wpedantic` on gcc, since individual warnings in `-Wpedantic` cannot be disabled. This means that code like this: >> >> >> #define DEBUG_ONLY(code) code; >> >> DEBUG_ONLY(foo()); >> >> >> will result in a `; ;`. This breaks the C standard, but is benign, and we use it all over the place. On clang, we can ignore this by `-Wno-extra-semi`, but this is not available on gcc. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > FIx dtrace build I can't seem to find the post now but there was one mentioning about needing information on what warnings -Wpedantic enables, and well... It's quite a lot: https://clang.llvm.org/docs/DiagnosticsReference.html#wpedantic I also have Jonathan Wakely's confirmation that -pedantic and -Wpedantic aren't the same, but this may not be as relevant to the discussion at hand ------------- PR Comment: https://git.openjdk.org/jdk/pull/17687#issuecomment-1927325037 From ihse at openjdk.org Mon Feb 5 16:23:02 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 5 Feb 2024 16:23:02 GMT Subject: RFR: 8325163: Enable -Wpedantic on clang [v2] In-Reply-To: References: Message-ID: On Mon, 5 Feb 2024 10:58:17 GMT, Magnus Ihse Bursie wrote: >> Inspired by (the later backed-out) [JDK-8296115](https://bugs.openjdk.org/browse/JDK-8296115), I propose to enable `-Wpedantic` for clang. This has already found some irregularities in the code, like mistakenly using `#import` instead of `#include`. In this patch, I disable warnings for these individual buggy or badly written files, but I intend to post follow-up issues on the respective teams to have them properly fixed. >> >> Unfortunately, it is not possible to enable `-Wpedantic` on gcc, since individual warnings in `-Wpedantic` cannot be disabled. This means that code like this: >> >> >> #define DEBUG_ONLY(code) code; >> >> DEBUG_ONLY(foo()); >> >> >> will result in a `; ;`. This breaks the C standard, but is benign, and we use it all over the place. On clang, we can ignore this by `-Wno-extra-semi`, but this is not available on gcc. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > FIx dtrace build This PR triggered a lot of discussion about C++ standards, gcc behavior, and possible breaches of coding standards in Hotspot -- but not a lot of discussion about the actual content of the PR. Is there anything in this proposed PR that you gentlemen disagree with or object to? Or is this fine to push as a step in our ongoing pursuit of increasing the code quality, that can (and will) be followed by many more? ------------- PR Comment: https://git.openjdk.org/jdk/pull/17687#issuecomment-1927365995 From redestad at openjdk.org Mon Feb 5 16:33:12 2024 From: redestad at openjdk.org (Claes Redestad) Date: Mon, 5 Feb 2024 16:33:12 GMT Subject: RFR: 8325169: Reduce String::indexOf overheads [v3] In-Reply-To: References: Message-ID: <3ApYlswpP1exy5Cl7RBS9XneGy7Y-cS_wKJaYyZj1fI=.056e124b-17c2-4665-a4a2-7a451e085737@github.com> On Sat, 3 Feb 2024 14:36:14 GMT, Claes Redestad wrote: >> This patch streamlines and specializes various `String::indexOf` methods. Mainly avoids the need for clamping and doing checks that are redundant in almost all cases, moving the checks to the API boundary where they are needed. >> >> This improves performance both at peak and during startup/warmup. Since indexOf is heavily used in bootstrapping code it makes sense to slightly dial back abstraction and delegation, which in this case also brought some benefit to peak performance. >> >> Testing: tier1-3 > > Claes Redestad has updated the pull request incrementally with two additional commits since the last revision: > > - Update comments regarding bounds checks > - Clamp fromIndex to be in range Thanks for the reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/17685#issuecomment-1927384314 From redestad at openjdk.org Mon Feb 5 16:33:13 2024 From: redestad at openjdk.org (Claes Redestad) Date: Mon, 5 Feb 2024 16:33:13 GMT Subject: Integrated: 8325169: Reduce String::indexOf overheads In-Reply-To: References: Message-ID: On Fri, 2 Feb 2024 13:54:46 GMT, Claes Redestad wrote: > This patch streamlines and specializes various `String::indexOf` methods. Mainly avoids the need for clamping and doing checks that are redundant in almost all cases, moving the checks to the API boundary where they are needed. > > This improves performance both at peak and during startup/warmup. Since indexOf is heavily used in bootstrapping code it makes sense to slightly dial back abstraction and delegation, which in this case also brought some benefit to peak performance. > > Testing: tier1-3 This pull request has now been integrated. Changeset: 19e92201 Author: Claes Redestad URL: https://git.openjdk.org/jdk/commit/19e92201b4873954c04cead9a3a456445b3ef289 Stats: 38 lines in 4 files changed: 19 ins; 15 del; 4 mod 8325169: Reduce String::indexOf overheads Reviewed-by: rriggs, rgiulietti, mli ------------- PR: https://git.openjdk.org/jdk/pull/17685 From redestad at openjdk.org Mon Feb 5 16:33:10 2024 From: redestad at openjdk.org (Claes Redestad) Date: Mon, 5 Feb 2024 16:33:10 GMT Subject: RFR: 8321468: Remove StringUTF16::equals In-Reply-To: References: Message-ID: On Wed, 6 Dec 2023 14:20:14 GMT, Claes Redestad wrote: > https://bugs.openjdk.org/browse/JDK-8215017 removed the only use of `StringUTF16::equals`. At the time I did some performance verification focused on x86 showing that simplifying and only using `StringLatin1::equals` was either neutral or a win. > > I repeated this experiment recently, adding some focused tests on aarch64 where the code generation actually tries to take advantage and generate slightly more efficient code for `StringUTF16::equals`: > https://github.com/openjdk/jdk/pull/16933#discussion_r1414118658 > > The indication here is that disabling use of `StringUTF16::equals` was the right choice: any effect from the low-level optimization (one less branch at the tail end) was offset by the `isLatin1()` branch and added code generation (that all gets inlined). > > In a `-XX:-CompactStrings` configuration the slightly improved code generation in `StringUTF16::equals` might help, since the `isLatin1()` test and subsequent call to `StringLatin1::equals` would be DCEd. To get the best of both worlds the code in `String::equals` _could_ be sharpened so that we statically pick the best implementation based on `CompactStrings` mode (see comment below). This shows a tiny win when testing with `-XX:-CompactStrings` on M1 (up to -0.2ns/op per `String::equals`; neutral on x86). But is all this complexity worth it for a gain that will get lost in the noise on anything realistic? > > This PR instead proposes removing `StringUTF16::equals` and simplifying the mechanisms to support the `StringLatin1/UTF16::equals` pair of intrinsics in hotspot. Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/16995#issuecomment-1927385726 From redestad at openjdk.org Mon Feb 5 16:33:11 2024 From: redestad at openjdk.org (Claes Redestad) Date: Mon, 5 Feb 2024 16:33:11 GMT Subject: Integrated: 8321468: Remove StringUTF16::equals In-Reply-To: References: Message-ID: On Wed, 6 Dec 2023 14:20:14 GMT, Claes Redestad wrote: > https://bugs.openjdk.org/browse/JDK-8215017 removed the only use of `StringUTF16::equals`. At the time I did some performance verification focused on x86 showing that simplifying and only using `StringLatin1::equals` was either neutral or a win. > > I repeated this experiment recently, adding some focused tests on aarch64 where the code generation actually tries to take advantage and generate slightly more efficient code for `StringUTF16::equals`: > https://github.com/openjdk/jdk/pull/16933#discussion_r1414118658 > > The indication here is that disabling use of `StringUTF16::equals` was the right choice: any effect from the low-level optimization (one less branch at the tail end) was offset by the `isLatin1()` branch and added code generation (that all gets inlined). > > In a `-XX:-CompactStrings` configuration the slightly improved code generation in `StringUTF16::equals` might help, since the `isLatin1()` test and subsequent call to `StringLatin1::equals` would be DCEd. To get the best of both worlds the code in `String::equals` _could_ be sharpened so that we statically pick the best implementation based on `CompactStrings` mode (see comment below). This shows a tiny win when testing with `-XX:-CompactStrings` on M1 (up to -0.2ns/op per `String::equals`; neutral on x86). But is all this complexity worth it for a gain that will get lost in the noise on anything realistic? > > This PR instead proposes removing `StringUTF16::equals` and simplifying the mechanisms to support the `StringLatin1/UTF16::equals` pair of intrinsics in hotspot. This pull request has now been integrated. Changeset: 55c1446b Author: Claes Redestad URL: https://git.openjdk.org/jdk/commit/55c1446b68db6c4734420124b5f26278389fdf2b Stats: 138 lines in 14 files changed: 0 ins; 113 del; 25 mod 8321468: Remove StringUTF16::equals Reviewed-by: rriggs, kvn ------------- PR: https://git.openjdk.org/jdk/pull/16995 From jwaters at openjdk.org Mon Feb 5 16:36:04 2024 From: jwaters at openjdk.org (Julian Waters) Date: Mon, 5 Feb 2024 16:36:04 GMT Subject: RFR: 8325163: Enable -Wpedantic on clang [v2] In-Reply-To: References: Message-ID: On Mon, 5 Feb 2024 10:58:17 GMT, Magnus Ihse Bursie wrote: >> Inspired by (the later backed-out) [JDK-8296115](https://bugs.openjdk.org/browse/JDK-8296115), I propose to enable `-Wpedantic` for clang. This has already found some irregularities in the code, like mistakenly using `#import` instead of `#include`. In this patch, I disable warnings for these individual buggy or badly written files, but I intend to post follow-up issues on the respective teams to have them properly fixed. >> >> Unfortunately, it is not possible to enable `-Wpedantic` on gcc, since individual warnings in `-Wpedantic` cannot be disabled. This means that code like this: >> >> >> #define DEBUG_ONLY(code) code; >> >> DEBUG_ONLY(foo()); >> >> >> will result in a `; ;`. This breaks the C standard, but is benign, and we use it all over the place. On clang, we can ignore this by `-Wno-extra-semi`, but this is not available on gcc. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > FIx dtrace build No objections from me, though I still think -pedantic -Wpedantic should be placed where Visual Studio currently places -permissive- for HotSpot ------------- Marked as reviewed by jwaters (Committer). PR Review: https://git.openjdk.org/jdk/pull/17687#pullrequestreview-1863251939 From briangoetz at openjdk.org Mon Feb 5 16:38:03 2024 From: briangoetz at openjdk.org (Brian Goetz) Date: Mon, 5 Feb 2024 16:38:03 GMT Subject: RFR: 8323058: Revisit j.l.classfile.CodeBuilder API surface In-Reply-To: References: Message-ID: On Fri, 5 Jan 2024 15:17:13 GMT, Adam Sotona wrote: > `java.lang.classfile.CodeBuilder` contains more than 230 API methods. > Existing ClassFile API use cases proved the concept one big CodeBuilder is comfortable. However there are some redundancies, glitches in the naming conventions, some frequently used methods are hard to find and some methods have low practical use. > > This patch revisits the `CodeBuilder` API methods and introduces some changes. > > For more details, please, visit the [CSR ](https://bugs.openjdk.org/browse/JDK-8323067) > > Please review. > > Thank you, > Adam Marked as reviewed by briangoetz (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/17282#pullrequestreview-1863257120 From rriggs at openjdk.org Mon Feb 5 16:42:13 2024 From: rriggs at openjdk.org (Roger Riggs) Date: Mon, 5 Feb 2024 16:42:13 GMT Subject: RFR: JDK-8310913 Move ReferencedKeyMap to jdk.internal so it may be shared [v10] In-Reply-To: References: Message-ID: <4h2Z1vQnTnCmFGv0K0Ji7nbgBR_FerkVP11U9ZnzDy4=.9c361fd3-8780-4a7e-a0bc-91e82ce1eb28@github.com> On Mon, 5 Feb 2024 12:34:02 GMT, Jim Laskey wrote: >> src/java.base/share/classes/jdk/internal/util/ReferencedKeySet.java line 151: >> >>> 149: @Override >>> 150: public boolean add(T e) { >>> 151: return intern(e) == null; >> >> This?line is?wrong, as?`intern(?)` will?never return?`null`. >> >> -------------------------------------------------------------------------------- >> >> This?is the?closest to?the?correct implementation, >> Suggestion: >> >> return !contains(e) & intern(e) == e; >> >> >> but?may incorrectly return?`true` in?case of?the?following data?race, assuming?`t1e ==?t2e`: >> >> 1. **Thread?1** calls `contains(t1e)` and gets `false`. >> 2. **Thread 2** calls `intern(t2e)` and successfully adds `t2e`. >> 3. **Thread?1** calls `intern(t1e)` and gets back `t2e`, which?is?`==` to?`t1e`. >> 4. **Thread?1** returns `true`, even?though it?was **Thread?2** which?modified the?`ReferencedKeySet`. > > Good catch. Your solution might be correct but I think `!contains(e)` is redundant since that is how intern starts out. > > > static T intern(ReferencedKeyMap> setMap, T key, UnaryOperator interner) { > T value = existingKey(setMap, key); > if (value != null) { > return value; > } > key = interner.apply(key); > return internKey(setMap, key); > } > > > Agree? So changing to `return intern(e) == e;` should be sufficient. > > The other aspect of this is that `internKey` uses `putIfAbsent` which should prevent the race (assuming `ConcurrentHashMap`). > > > /** > * Attempt to add key to map. > * > * @param setMap {@link ReferencedKeyMap} where interning takes place > * @param key key to add > * > * @param type of key > * > * @return the old key instance if found otherwise the new key instance > */ > private static T internKey(ReferencedKeyMap> setMap, T key) { > ReferenceKey entryKey = setMap.entryKey(key); > T interned; > do { > setMap.removeStaleReferences(); > ReferenceKey existing = setMap.map.putIfAbsent(entryKey, entryKey); > if (existing == null) { > return key; > } else { > // If {@code putIfAbsent} returns non-null then was actually a > // {@code replace} and older key was used. In that case the new > // key was not used and the reference marked stale. > interned = existing.get(); > if (interned != null) { > entryKey.unused(); > } > } > } while (interned == null); > return interned; > } > > > Agree? Anyone else want to pipe in? ok, `intern(e) == e` is sufficient. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14684#discussion_r1478541091 From jlaskey at openjdk.org Mon Feb 5 17:02:16 2024 From: jlaskey at openjdk.org (Jim Laskey) Date: Mon, 5 Feb 2024 17:02:16 GMT Subject: RFR: JDK-8310913 Move ReferencedKeyMap to jdk.internal so it may be shared [v10] In-Reply-To: <4h2Z1vQnTnCmFGv0K0Ji7nbgBR_FerkVP11U9ZnzDy4=.9c361fd3-8780-4a7e-a0bc-91e82ce1eb28@github.com> References: <4h2Z1vQnTnCmFGv0K0Ji7nbgBR_FerkVP11U9ZnzDy4=.9c361fd3-8780-4a7e-a0bc-91e82ce1eb28@github.com> Message-ID: On Mon, 5 Feb 2024 16:38:59 GMT, Roger Riggs wrote: >> Good catch. Your solution might be correct but I think `!contains(e)` is redundant since that is how intern starts out. >> >> >> static T intern(ReferencedKeyMap> setMap, T key, UnaryOperator interner) { >> T value = existingKey(setMap, key); >> if (value != null) { >> return value; >> } >> key = interner.apply(key); >> return internKey(setMap, key); >> } >> >> >> Agree? So changing to `return intern(e) == e;` should be sufficient. >> >> The other aspect of this is that `internKey` uses `putIfAbsent` which should prevent the race (assuming `ConcurrentHashMap`). >> >> >> /** >> * Attempt to add key to map. >> * >> * @param setMap {@link ReferencedKeyMap} where interning takes place >> * @param key key to add >> * >> * @param type of key >> * >> * @return the old key instance if found otherwise the new key instance >> */ >> private static T internKey(ReferencedKeyMap> setMap, T key) { >> ReferenceKey entryKey = setMap.entryKey(key); >> T interned; >> do { >> setMap.removeStaleReferences(); >> ReferenceKey existing = setMap.map.putIfAbsent(entryKey, entryKey); >> if (existing == null) { >> return key; >> } else { >> // If {@code putIfAbsent} returns non-null then was actually a >> // {@code replace} and older key was used. In that case the new >> // key was not used and the reference marked stale. >> interned = existing.get(); >> if (interned != null) { >> entryKey.unused(); >> } >> } >> } while (interned == null); >> return interned; >> } >> >> >> Agree? Anyone else want to pipe in? > > ok, `intern(e) == e` is sufficient. Created https://bugs.openjdk.org/browse/JDK-8325255 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14684#discussion_r1478583967 From smarks at openjdk.org Mon Feb 5 23:49:52 2024 From: smarks at openjdk.org (Stuart Marks) Date: Mon, 5 Feb 2024 23:49:52 GMT Subject: RFR: JDK-8325189: Enable this-escape javac warning in java.base In-Reply-To: References: Message-ID: <3ItCUEGtxTObo5TxNsOIPfMr15fWdQPm3CAi7eNcOv4=.506a52bb-ad1a-429a-9906-5ae1dccfdad2@github.com> On Fri, 2 Feb 2024 23:36:41 GMT, Joe Darcy wrote: > After the "this-escape" lint warning was added to javac (JDK-8015831), the base module was not updated to be able to compile with this warning enabled. This PR makes the necessary changes to allow the base module to build with the warning enabled. Changes in java.util and java.util.concurrent look fine. There are a startling number of places where `this` is potentially leaked to a subclass. It would be interesting to analyze the pathologies and have a discussion of potential fixes. There may also be compatibility issues with potential fixes (nothing in this PR that I can see) because the behavior can change from the point of view of subclasses. ------------- Marked as reviewed by smarks (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17692#pullrequestreview-1863853251 From naoto at openjdk.org Mon Feb 5 23:49:48 2024 From: naoto at openjdk.org (Naoto Sato) Date: Mon, 5 Feb 2024 23:49:48 GMT Subject: RFR: JDK-8325189: Enable this-escape javac warning in java.base In-Reply-To: References: Message-ID: On Fri, 2 Feb 2024 23:36:41 GMT, Joe Darcy wrote: > After the "this-escape" lint warning was added to javac (JDK-8015831), the base module was not updated to be able to compile with this warning enabled. This PR makes the necessary changes to allow the base module to build with the warning enabled. Marked as reviewed by naoto (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/17692#pullrequestreview-1863359999 From darcy at openjdk.org Mon Feb 5 23:49:58 2024 From: darcy at openjdk.org (Joe Darcy) Date: Mon, 5 Feb 2024 23:49:58 GMT Subject: RFR: JDK-8325189: Enable this-escape javac warning in java.base In-Reply-To: References: Message-ID: On Fri, 2 Feb 2024 23:38:41 GMT, Joe Darcy wrote: > In its initial form, the changes are tested on Linux. Later on, I'll do cross-platform builds to make sure there aren't any, say, windows-specific changes that are needed as well. > > I can file a follow-up umbrella bug with the original list of ~200 warnings so the constructors and initializers in question can be examined to see if they should be updated. Filed [JDK-8325263](https://bugs.openjdk.org/browse/JDK-8325263) . ------------- PR Comment: https://git.openjdk.org/jdk/pull/17692#issuecomment-1928049947 From ihse at openjdk.org Mon Feb 5 23:50:13 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 5 Feb 2024 23:50:13 GMT Subject: RFR: 8325163: Enable -Wpedantic on clang [v2] In-Reply-To: References: Message-ID: <56uYGhLCcDFBfuEV2TpDDYcOzLjBtKKerH03q-L_wlk=.37ca1c75-45e9-42ad-af40-7cfb34c77725@github.com> On Mon, 5 Feb 2024 10:58:17 GMT, Magnus Ihse Bursie wrote: >> Inspired by (the later backed-out) [JDK-8296115](https://bugs.openjdk.org/browse/JDK-8296115), I propose to enable `-Wpedantic` for clang. This has already found some irregularities in the code, like mistakenly using `#import` instead of `#include`. In this patch, I disable warnings for these individual buggy or badly written files, but I intend to post follow-up issues on the respective teams to have them properly fixed. >> >> Unfortunately, it is not possible to enable `-Wpedantic` on gcc, since individual warnings in `-Wpedantic` cannot be disabled. This means that code like this: >> >> >> #define DEBUG_ONLY(code) code; >> >> DEBUG_ONLY(foo()); >> >> >> will result in a `; ;`. This breaks the C standard, but is benign, and we use it all over the place. On clang, we can ignore this by `-Wno-extra-semi`, but this is not available on gcc. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > FIx dtrace build Here is the full list: https://clang.llvm.org/docs/DiagnosticsReference.html#wpedantic ------------- PR Comment: https://git.openjdk.org/jdk/pull/17687#issuecomment-1928141600 From kbarrett at openjdk.org Mon Feb 5 23:50:01 2024 From: kbarrett at openjdk.org (Kim Barrett) Date: Mon, 5 Feb 2024 23:50:01 GMT Subject: RFR: 8325163: Enable -Wpedantic on clang [v2] In-Reply-To: References: Message-ID: On Mon, 5 Feb 2024 16:19:59 GMT, Magnus Ihse Bursie wrote: > Is there anything in this proposed PR that you gentlemen disagree with or object to? Or is this fine to push as a step in our ongoing pursuit of increasing the code quality, that can (and will) be followed by many more? Yes. As I said earlier: "Without knowing what the actual warnings are that are being triggered and then suppressed, I can't even begin to evaluate this change." ------------- PR Comment: https://git.openjdk.org/jdk/pull/17687#issuecomment-1928006901 From mchung at openjdk.org Mon Feb 5 23:50:36 2024 From: mchung at openjdk.org (Mandy Chung) Date: Mon, 5 Feb 2024 23:50:36 GMT Subject: RFR: 8321703: jdeps generates illegal dot file containing nodesep=0,500000 Message-ID: <6RMmqYVc4VhHGiGmSZFLF0bHhgxIIeCDtlOOidcbDHw=.e7a82fb3-883f-40b1-bad7-a083a8223ffe@github.com> Trivial fix. Call `PrintWriter::format` with null `Locale` to format with no localization. This PR also fixes JDK-8325262 to print `FindException` message without the stack trace to indicate clearer that the given module path is incorrect. ------------- Commit messages: - update copyright header - 8321703: jdeps generates illegal dot file containing nodesep=0,500000 Changes: https://git.openjdk.org/jdk/pull/17713/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17713&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8321703 Stats: 5 lines in 2 files changed: 1 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/17713.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17713/head:pull/17713 PR: https://git.openjdk.org/jdk/pull/17713 From jlu at openjdk.org Mon Feb 5 23:51:00 2024 From: jlu at openjdk.org (Justin Lu) Date: Mon, 5 Feb 2024 23:51:00 GMT Subject: RFR: JDK-8318761: MessageFormat pattern support for CompactNumberFormat, ListFormat, and DateTimeFormatter [v4] In-Reply-To: References: Message-ID: > Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8319344) which adds MessageFormat pattern support for the following subformats: ListFormat, CompactNumberFormat, and DateTimeFormatter. This change is intended to provide pattern support for the more recently added JDK Format subclasses, as well as improving java.time formatting within i18n. The draft javadoc can be viewed here: https://cr.openjdk.org/~jlu/docs/api/java.base/java/text/MessageFormat.html. Please see the CSR for more in-depth behavioral changes, as well as limitations. > > The `FormatTypes`: dtf_date, dtf_time, dtf_datetime, pre-defined DateTimeFormatter(s), and list are added. > The `FormatStyles`: compact_short, compact_long, or, and unit are added. > > For example, previously, > > > Object[] args = {LocalDate.of(2023, 11, 16), LocalDate.of(2023, 11, 27)}; > MessageFormat.format("It was {0,date,full}, now it is {1,date,full}", args); > > > would throw `Exception java.lang.IllegalArgumentException: Cannot format given Object as a Date` > > Now, a user can call > > > MessageFormat.format("It was {0,dtf_date,full}, now it is {1,dtf_date,full}", args); > > > which returns "It was Thursday, November 16, 2023, now it is Friday, November 17, 2023" Justin Lu has updated the pull request incrementally with two additional commits since the last revision: - Apply spacing suggestions Co-authored-by: Andrey Turbanov - add expected message to exception checking ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17663/files - new: https://git.openjdk.org/jdk/pull/17663/files/bf0174ff..5ae60000 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17663&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17663&range=02-03 Stats: 18 lines in 3 files changed: 9 ins; 0 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/17663.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17663/head:pull/17663 PR: https://git.openjdk.org/jdk/pull/17663 From acobbs at openjdk.org Mon Feb 5 23:53:06 2024 From: acobbs at openjdk.org (Archie Cobbs) Date: Mon, 5 Feb 2024 23:53:06 GMT Subject: RFR: 7036144: GZIPInputStream readTrailer uses faulty available() test for end-of-stream [v6] In-Reply-To: References: Message-ID: <7eCX4Yx0qM7Ipug5NI-A8I10-22Iyyk-eMh6ELcHV2c=.bd909779-025d-4e71-816d-e4d6539e85ed@github.com> > `GZIPInputStream`, when looking for a concatenated stream, relies on what the underlying `InputStream` says is how many bytes are `available()`. But this is inappropriate because `InputStream.available()` is just an estimate and is allowed (for example) to always return zero. > > The fix is to ignore what's `available()` and just proceed and see what happens. If fewer bytes are available than required, the attempt to extend to another stream is canceled just as it was before, e.g., when the next stream header couldn't be read. Archie Cobbs has updated the pull request with a new target base 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-7036144 - Merge branch 'master' into JDK-7036144 - Address third round of review comments. - Address second round of review comments. - Address review comments. - Fix bug in GZIPInputStream when underlying available() returns short. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17113/files - new: https://git.openjdk.org/jdk/pull/17113/files/4f1a0459..f4178acc Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17113&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17113&range=04-05 Stats: 38832 lines in 1817 files changed: 17181 ins; 8675 del; 12976 mod Patch: https://git.openjdk.org/jdk/pull/17113.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17113/head:pull/17113 PR: https://git.openjdk.org/jdk/pull/17113 From asotona at openjdk.org Mon Feb 5 23:52:57 2024 From: asotona at openjdk.org (Adam Sotona) Date: Mon, 5 Feb 2024 23:52:57 GMT Subject: RFR: 8323058: Revisit j.l.classfile.CodeBuilder API surface [v2] In-Reply-To: References: Message-ID: > `java.lang.classfile.CodeBuilder` contains more than 230 API methods. > Existing ClassFile API use cases proved the concept one big CodeBuilder is comfortable. However there are some redundancies, glitches in the naming conventions, some frequently used methods are hard to find and some methods have low practical use. > > This patch revisits the `CodeBuilder` API methods and introduces some changes. > > For more details, please, visit the [CSR ](https://bugs.openjdk.org/browse/JDK-8323067) > > Please review. > > Thank you, > Adam Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: removed CodeBuilder::newObject methods ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17282/files - new: https://git.openjdk.org/jdk/pull/17282/files/d5491d36..150393c7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17282&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17282&range=00-01 Stats: 24 lines in 4 files changed: 0 ins; 19 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/17282.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17282/head:pull/17282 PR: https://git.openjdk.org/jdk/pull/17282 From liach at openjdk.org Mon Feb 5 23:53:36 2024 From: liach at openjdk.org (Chen Liang) Date: Mon, 5 Feb 2024 23:53:36 GMT Subject: RFR: 8319463: ClassSignature should have superclass and superinterfaces as ClassTypeSig [v4] In-Reply-To: <29zEQ23lx0wqPTXz_cx872tlG_ZGuAuGdlaCwe8E-0E=.f004f965-ce19-40b3-9cde-234904b9824a@github.com> References: <2MCObzp9MbPwugbIm1pP80wU0OXlmrQMr7CRsgxah7s=.78d4b9a3-9f19-4bcf-ad03-58fb6faa64fb@github.com> <29zEQ23lx0wqPTXz_cx872tlG_ZGuAuGdlaCwe8E-0E=.f004f965-ce19-40b3-9cde-234904b9824a@github.com> Message-ID: On Mon, 8 Jan 2024 11:38:54 GMT, Adam Sotona wrote: >> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: >> >> 8319463: ClassSignature should have superclass and superinterfaces as ClassTypeSig > > The patch looks good to me. Hmm, @asotona how do you think of Joe Darcy's concerns in the CSR? If you think this works with Valhalla too, I can move the CSR to finalized for approval. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16514#issuecomment-1928050759 From psandoz at openjdk.org Mon Feb 5 23:53:12 2024 From: psandoz at openjdk.org (Paul Sandoz) Date: Mon, 5 Feb 2024 23:53:12 GMT Subject: RFR: 8323058: Revisit j.l.classfile.CodeBuilder API surface [v2] In-Reply-To: References: Message-ID: On Mon, 5 Feb 2024 18:31:44 GMT, Adam Sotona wrote: >> `java.lang.classfile.CodeBuilder` contains more than 230 API methods. >> Existing ClassFile API use cases proved the concept one big CodeBuilder is comfortable. However there are some redundancies, glitches in the naming conventions, some frequently used methods are hard to find and some methods have low practical use. >> >> This patch revisits the `CodeBuilder` API methods and introduces some changes. >> >> For more details, please, visit the [CSR ](https://bugs.openjdk.org/browse/JDK-8323067) >> >> Please review. >> >> Thank you, >> Adam > > Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: > > removed CodeBuilder::newObject methods Marked as reviewed by psandoz (Reviewer). src/java.base/share/classes/java/lang/classfile/CodeBuilder.java line 507: > 505: * @return this builder > 506: */ > 507: default CodeBuilder newObject(ClassEntry type) { The two `newObject` methods seem to fit in the pattern of methods that are being removed, since they don't differentiate sufficiently with the `new_` methods that defer to them. ------------- PR Review: https://git.openjdk.org/jdk/pull/17282#pullrequestreview-1863531162 PR Review Comment: https://git.openjdk.org/jdk/pull/17282#discussion_r1478611886 From asotona at openjdk.org Mon Feb 5 23:53:29 2024 From: asotona at openjdk.org (Adam Sotona) Date: Mon, 5 Feb 2024 23:53:29 GMT Subject: RFR: 8323058: Revisit j.l.classfile.CodeBuilder API surface [v2] In-Reply-To: References: Message-ID: On Mon, 5 Feb 2024 17:23:54 GMT, Paul Sandoz wrote: >> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: >> >> removed CodeBuilder::newObject methods > > src/java.base/share/classes/java/lang/classfile/CodeBuilder.java line 507: > >> 505: * @return this builder >> 506: */ >> 507: default CodeBuilder newObject(ClassEntry type) { > > The two `newObject` methods seem to fit in the pattern of methods that are being removed, since they don't differentiate sufficiently with the `new_` methods that defer to them. Right, we can remove also the `newObject` and keep `new_` methods, thanks. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17282#discussion_r1478638191 From duke at openjdk.org Mon Feb 5 23:55:28 2024 From: duke at openjdk.org (Vladimir Yaroslavskiy) Date: Mon, 5 Feb 2024 23:55:28 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> <-bYhysKjQVb_ZS0I0YutJZ7umfYwbs74rtK6-d2qL9U=.f9981e59-f0c4-48f3-ad7e-5627aad00919@github.com> <91Zv361kqKOjCSJPu20-yhKOb4lBIZVyVTm9f79dkcQ=.745c271d-3cb1-4ff3-9d71-5cad85ff4f14@github.com> <9q8Gg6DQnrf0HLW3oxwfpoUP9639drr1BIQMc1rxDFo=.eb4ea73c-b632-446a-8d50-b51838f67f69@github.com> Message-ID: On Fri, 2 Feb 2024 20:09:57 GMT, Srinivas Vamsi Parasa wrote: >> Hi Vamsi (@vamsi-parasa), Laurent(@bourgesl), >> >> The latest benchmarking compares compares the following versions: >> jdk - direct call of Arrays.sort(); >> a15 - the current source of DualPivotQuicksort from the latest build (except renaming) >> https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/DualPivotQuicksort.java >> https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_a15.java >> r20s - new version without Radix sort >> r20p - new version with Radix sort in parallel case only >> >> It is expected that timing of jdk and a15 should be more or less the same, but please look at the results: >> >> Benchmark | Data Type | Array Size | Arrays.sort() from jdk | Current source (a15) >> -- | -- | -- | -- | -- >> ArraysSort.Int.testSort | RANDOM ? | ? ? 600 | 1.612 ? ? | 7.096 >> ArraysSort.Int.testSort | RANDOM ? | ? ?2000 | 6.893 ? ? | 44.014 >> ArraysSort.Int.testSort | RANDOM ? | ? 90000 | 522.749 ? | 4451.444 >> ArraysSort.Int.testSort | RANDOM ? | ?400000 | 2424.204 ?| 22751.966 >> ArraysSort.Int.testSort | RANDOM ? | 3000000 | 21000.434 | 190326.306 >> ArraysSort.Int.testSort | REPEATED | ? ? 600 | 0.496 ? ? | 1.044 >> ArraysSort.Int.testSort | REPEATED | ? ?2000 | 1.037 ? ? | 2.272 >> ArraysSort.Int.testSort | REPEATED | ? 90000 | 57.763 ? ?| 412.331 >> ArraysSort.Int.testSort | REPEATED | ?400000 | 182.238 ? | 1908.978 >> ArraysSort.Int.testSort | REPEATED | 3000000 | 1708.082 ?| 15163.443 >> ArraysSort.Int.testSort | STAGGER ?| ? ? 600 | 1.038 ? ? | 1.055 >> ArraysSort.Int.testSort | STAGGER ?| ? ?2000 | 3.434 ? ? | 3.408 >> ArraysSort.Int.testSort | STAGGER ?| ? 90000 | 148.638 ? | 149.220 >> ArraysSort.Int.testSort | STAGGER ?| ?400000 | 663.076 ? | 663.096 >> ArraysSort.Int.testSort | STAGGER ?| 3000000 | 5212.821 ?| 5206.890 >> ArraysSort.Int.testSort | SHUFFLE ?| ? ? 600 | 1.926 ? ? | 4.611 >> ArraysSort.Int.testSort | SHUFFLE ?| ? ?2000 | 6.858 ? ? | 17.955 >> ArraysSort.Int.testSort | SHUFFLE ?| ? 90000 | 473.441 ? | 1410.357 >> ArraysSort.Int.testSort | SHUFFLE ?| ?400000 | 2153.779 ?| 5739.311 >> ArraysSort.Int.testSort | SHUFFLE ?| 3000000 | 18180.141 | 41501.980 >> >> You can see that a15 (current source) works extremly slower than Arrays.sort(), but the code is the same >> with minor differences: renaming and repackaging (I put the class to the test package org.openjdk.bench.java.util). >> How does other package org.openjdk.bench.java.util effect so much? >> >> I use this pom.xml file https://github.com/iarosla... > > Hi Vladimir (@iaroslavski), > > Please see the data below. All tests were run after putting the DPQS code in java.util package and recompiling the JDK for each case. > > 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 | a15 | r20p | r20s > -- | -- | -- | -- | -- | -- | -- > ArraysSort.Int.testParallelSort | RANDOM | 600 | 2.24 | 2.201 | 2.423 | 2.389 > ArraysSort.Int.testParallelSort | RANDOM | 9000 | 35.318 | 35.961 | 79.028 | 83.774 > ArraysSort.Int.testParallelSort | RANDOM | 20000 | 118.729 | 120.872 | 134.829 | 138.349 > ArraysSort.Int.testParallelSort | RANDOM | 400000 | 822.676 | 822.44 | 1200.858 | 872.264 > ArraysSort.Int.testParallelSort | RANDOM | 3000000 | 5864.514 | 5948.82 | 8800.391 | 6020.616 > ArraysSort.Int.testParallelSort | REPEATED | 600 | 0.924 | 0.936 | 0.752 | 0.733 > ArraysSort.Int.testParallelSort | REPEATED | 9000 | 9.896 | 9.317 | 31.409 | 24.896 > ArraysSort.Int.testParallelSort | REPEATED | 20000 | 58.265 | 42.189 | 40.92 | 40.101 > ArraysSort.Int.testParallelSort | REPEATED | 400000 | 256.952 | 253.217 | 236.568 | 239.163 > ArraysSort.Int.testParallelSort | REPEATED | 3000000 | 2844.107 | 2851.088 | 2752.939 | 3040.423 > ArraysSort.Int.testParallelSort | STAGGER | 600 | 2.245 | 2.296 | 2.15 | 2.219 > ArraysSort.Int.testParallelSort | STAGGER | 9000 | 29.278 | 29.119 | 28.288 | 28.141 > ArraysSort.Int.testParallelSort | STAGGER | 20000 | 50.129 | 50.442 | 49.746 | 49.686 > ArraysSort.Int.testParallelSort | STAGGER | 400000 | 463.309 | 413.619 | 418.077 | 407.519 > ArraysSort.Int.testParallelSort | STAGGER | 3000000 | 3687.198 | 4363.242 | 3732.777 | 3769.898 > ArraysSort.Int.testParallelSort | SHUFFLE | 600 | 1.715 | 1.698 | 2.799 | 2.733 > ArraysSort.Int.testParallelSort | SHUFFLE | 9000 | 27.69 | 27.183 | 32.883 | 32.373 > ArraysSort.Int.testParallelSort | SHUFFLE | 20000 | 62.067 | 60.987 | 63.281 | 52.89 > ArraysSort.Int.testParallelSort | SHUFFLE | 400000 | 467.213 | 495.14 | 650.173 | 476.403 > ArraysSort.Int.testParallelS... Hello Vamsi (@vamsi-parasa), Many thanks for the results! Now we can see that intrinsics are applied in all cases, but there are big differences between the same code. For example, parallelSort REPEATED 20000: 58.265(Stock JDK) and 42.189(a15) with speedup x1.38 parallelSort STAGGER 3000000: 3687.198(Stock JDK) 4363.242(a15) with speedup x0.85 Case a15 is the current source code from JDK, but in one benchmarking it is faster, in other benchmarking it is slower (~15-30%). Other strange behaviour with new sorting: r20p and r20s have the same code for sequential sorting (no radix sort at all), but we can see that on case works much slower sort STAGGER 3000000: 34406.74(r20p) and 10467.03(r20s) - 3.3 times slower, whereas other sizes show more or less equal values. Vamsi (@vamsi-parasa), Could you please run benchmarking of 5 cases with **updated** test class **ArraysSortNew**? https://github.com/iaroslavski/sorting/blob/master/radixsort/ArraysSortNew.java Put the DPQS code in java.util package and recompiling the JDK for each case as you did before, but run new ArraysSortNew. Find the sources there: https://github.com/iaroslavski/sorting/blob/master/radixsort/ArraysSortNew.java https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_jdk.java https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_r20p.java https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_r20s.java https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_r25p.java https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_r25s.java Thank you, Vladimir ------------- PR Comment: https://git.openjdk.org/jdk/pull/13568#issuecomment-1928130680 From darcy at openjdk.org Mon Feb 5 23:56:08 2024 From: darcy at openjdk.org (Joe Darcy) Date: Mon, 5 Feb 2024 23:56:08 GMT Subject: [jdk22] RFR: 8322066: Update troff manpages in JDK 22 before RC In-Reply-To: References: Message-ID: On Sun, 4 Feb 2024 22:43:28 GMT, David Holmes wrote: > This update drops the "ea" from the version string. > > We also propagate the following fixes from the markdown sources to the troff manpage file: > > JDK-8322478: Update java manpage for multi-file source-code launcher > JDK-8302233: HSS/LMS: keytool and jarsigner changes > JDK-8318971: Better Error Handling for Jar Tool When Processing Non-existent Files > > > Thanks. Marked as reviewed by darcy (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk22/pull/104#pullrequestreview-1863882694 From acobbs at openjdk.org Mon Feb 5 23:57:13 2024 From: acobbs at openjdk.org (Archie Cobbs) Date: Mon, 5 Feb 2024 23:57:13 GMT Subject: Integrated: 8323699: MessageFormat.toPattern() generates non-equivalent MessageFormat pattern In-Reply-To: References: Message-ID: On Sun, 14 Jan 2024 15:32:12 GMT, Archie Cobbs wrote: > Please consider this fix to ensure that going from `MessageFormat` to pattern string via `toPattern()` and then back via `new MessageFormat()` results in a format that is equivalent to the original. > > The quoting and escaping rules for `MessageFormat` pattern strings are really tricky. I admit not completely understanding them. At a high level, they work like this: The normal way one would "nest" strings containing special characters is with straightforward recursive escaping like with the `bash` command line. For example, if you want to echo `a "quoted string" example` then you enter `echo "a "quoted string" example"`. With this scheme it's always the "outer" layer's job to (un)escape special characters as needed. That is, the echo command never sees the backslash characters. > > In contrast, with `MessageFormat` and friends, nested subformat pattern strings are always provided "pre-escaped". So to build an "outer" string (e.g., for `ChoiceFormat`) the "inner" subformat pattern strings are more or less just concatenated, and then only the `ChoiceFormat` option separator characters (e.g., `<`, `#`, `|`, etc.) are escaped. > > The "pre-escape" escaping algorithm escapes `{` characters, because `{` indicates the beginning of a format argument. However, it doesn't escape `}` characters. This is OK because the format string parser treats any "extra" closing braces (where "extra" means not matching an opening brace) as plain characters. > > So far, so good... at least, until a format string containing an extra closing brace is nested inside a larger format string, where the extra closing brace, which was previously "extra", can now suddenly match an opening brace in the outer pattern containing it, thus truncating it by "stealing" the match from some subsequent closing brace. > > An example is the `MessageFormat` string `"{0,choice,0.0#option A: {1}|1.0#option B: {1}'}'}"`. Note the second option format string has a trailing closing brace in plain text. If you create a `MessageFormat` with this string, you see a trailing `}` only with the second option. > > However, if you then invoke `toPattern()`, the result is `"{0,choice,0.0#option A: {1}|1.0#option B: {1}}}"`. Oops, now because the "extra" closing brace is no longer quoted, it matches the opening brace at the beginning of the string, and the following closing brace, which was the previous match, is now just plain text in the outer `MessageFormat` string. > > As a result, invoking `f.format(new Object{} { 0, 5 })` will retur... This pull request has now been integrated. Changeset: f1f93988 Author: Archie Cobbs Committer: Justin Lu URL: https://git.openjdk.org/jdk/commit/f1f93988fba3de0665fc7f69a5219dd04323c6f5 Stats: 442 lines in 4 files changed: 430 ins; 0 del; 12 mod 8323699: MessageFormat.toPattern() generates non-equivalent MessageFormat pattern Reviewed-by: jlu, naoto ------------- PR: https://git.openjdk.org/jdk/pull/17416 From bpb at openjdk.org Mon Feb 5 23:57:45 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Mon, 5 Feb 2024 23:57:45 GMT Subject: Integrated: 8324960: Unsafe.allocateMemory documentation incorrect regarding zero return value In-Reply-To: References: Message-ID: On Wed, 31 Jan 2024 01:17:07 GMT, Brian Burkhalter wrote: > Align the specification of `Unsafe.allocateMemory` with its implementation and with the specification of `Unsafe.reallocateMemory`. This pull request has now been integrated. Changeset: 209d87a8 Author: Brian Burkhalter URL: https://git.openjdk.org/jdk/commit/209d87a856b1a7bd60910b517d8ff5beb322ec0b Stats: 10 lines in 2 files changed: 2 ins; 0 del; 8 mod 8324960: Unsafe.allocateMemory documentation incorrect regarding zero return value Reviewed-by: rriggs ------------- PR: https://git.openjdk.org/jdk/pull/17643 From duke at openjdk.org Mon Feb 5 23:58:33 2024 From: duke at openjdk.org (duke) Date: Mon, 5 Feb 2024 23:58:33 GMT Subject: Withdrawn: 8312425: [vectorapi] AArch64: Optimize vector math operations with SLEEF In-Reply-To: References: Message-ID: On Wed, 18 Oct 2023 06:12:29 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 This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/16234 From iris at openjdk.org Tue Feb 6 03:11:03 2024 From: iris at openjdk.org (Iris Clark) Date: Tue, 6 Feb 2024 03:11:03 GMT Subject: [jdk22] RFR: 8322066: Update troff manpages in JDK 22 before RC In-Reply-To: References: Message-ID: <4cRyPED3qle_BVYZkKe7WqzTTTypo6nFookYaFGeCDw=.a49cec00-d0b4-4f09-85f0-e5c2ce730792@github.com> On Sun, 4 Feb 2024 22:43:28 GMT, David Holmes wrote: > This update drops the "ea" from the version string. > > We also propagate the following fixes from the markdown sources to the troff manpage file: > > JDK-8322478: Update java manpage for multi-file source-code launcher > JDK-8302233: HSS/LMS: keytool and jarsigner changes > JDK-8318971: Better Error Handling for Jar Tool When Processing Non-existent Files > > > Thanks. Marked as reviewed by iris (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk22/pull/104#pullrequestreview-1864200734 From dholmes at openjdk.org Tue Feb 6 04:58:53 2024 From: dholmes at openjdk.org (David Holmes) Date: Tue, 6 Feb 2024 04:58:53 GMT Subject: [jdk22] RFR: 8322066: Update troff manpages in JDK 22 before RC In-Reply-To: References: Message-ID: On Mon, 5 Feb 2024 21:58:23 GMT, Joe Darcy wrote: >> This update drops the "ea" from the version string. >> >> We also propagate the following fixes from the markdown sources to the troff manpage file: >> >> JDK-8322478: Update java manpage for multi-file source-code launcher >> JDK-8302233: HSS/LMS: keytool and jarsigner changes >> JDK-8318971: Better Error Handling for Jar Tool When Processing Non-existent Files >> >> >> Thanks. > > Marked as reviewed by darcy (Reviewer). Thanks for the reviews @jddarcy and @irisclark ! ------------- PR Comment: https://git.openjdk.org/jdk22/pull/104#issuecomment-1928783920 From dholmes at openjdk.org Tue Feb 6 04:58:54 2024 From: dholmes at openjdk.org (David Holmes) Date: Tue, 6 Feb 2024 04:58:54 GMT Subject: [jdk22] Integrated: 8322066: Update troff manpages in JDK 22 before RC In-Reply-To: References: Message-ID: <43aREZ6MAFvrQojZi3ALfLy7yqlrS76R3HUs5lil8xE=.2471360a-6946-4dbc-91e8-386b5d31df58@github.com> On Sun, 4 Feb 2024 22:43:28 GMT, David Holmes wrote: > This update drops the "ea" from the version string. > > We also propagate the following fixes from the markdown sources to the troff manpage file: > > JDK-8322478: Update java manpage for multi-file source-code launcher > JDK-8302233: HSS/LMS: keytool and jarsigner changes > JDK-8318971: Better Error Handling for Jar Tool When Processing Non-existent Files > > > Thanks. This pull request has now been integrated. Changeset: ac7a3c00 Author: David Holmes URL: https://git.openjdk.org/jdk22/commit/ac7a3c00bbfde173ced08d8745b308bc0ac9649b Stats: 160 lines in 28 files changed: 63 ins; 15 del; 82 mod 8322066: Update troff manpages in JDK 22 before RC Reviewed-by: darcy, iris ------------- PR: https://git.openjdk.org/jdk22/pull/104 From dholmes at openjdk.org Tue Feb 6 05:33:29 2024 From: dholmes at openjdk.org (David Holmes) Date: Tue, 6 Feb 2024 05:33:29 GMT Subject: RFR: 8325163: Enable -Wpedantic on clang In-Reply-To: References: Message-ID: On Mon, 5 Feb 2024 15:42:40 GMT, Kim Barrett wrote: > I thought we didn't, because we were instead supposed to use INTPTR_FORMAT and the (currently?) equivalent PTR_FORMAT. Those macros aren't legacy, they are to provide consistent output across platforms. "%p" provides implementation defined output. My understanding/recollection was that those issues with `%p` had gone away and so we could start using it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17687#issuecomment-1928814503 From dholmes at openjdk.org Tue Feb 6 05:47:59 2024 From: dholmes at openjdk.org (David Holmes) Date: Tue, 6 Feb 2024 05:47:59 GMT Subject: RFR: 8325163: Enable -Wpedantic on clang [v2] In-Reply-To: References: Message-ID: On Mon, 5 Feb 2024 10:58:17 GMT, Magnus Ihse Bursie wrote: >> Inspired by (the later backed-out) [JDK-8296115](https://bugs.openjdk.org/browse/JDK-8296115), I propose to enable `-Wpedantic` for clang. This has already found some irregularities in the code, like mistakenly using `#import` instead of `#include`. In this patch, I disable warnings for these individual buggy or badly written files, but I intend to post follow-up issues on the respective teams to have them properly fixed. >> >> Unfortunately, it is not possible to enable `-Wpedantic` on gcc, since individual warnings in `-Wpedantic` cannot be disabled. This means that code like this: >> >> >> #define DEBUG_ONLY(code) code; >> >> DEBUG_ONLY(foo()); >> >> >> will result in a `; ;`. This breaks the C standard, but is benign, and we use it all over the place. On clang, we can ignore this by `-Wno-extra-semi`, but this is not available on gcc. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > FIx dtrace build I think given the warnings have been enabled globally, but disabled locally where they cause build failures, and JBS issues will be filed for each of those special cases, then this is a reasonable change to make. It is then up to component teams to fix code where applicable, and enable disabled warnings in the future. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17687#issuecomment-1928824757 From jpai at openjdk.org Tue Feb 6 06:18:54 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 6 Feb 2024 06:18:54 GMT Subject: RFR: 8321703: jdeps generates illegal dot file containing nodesep=0,500000 In-Reply-To: <6RMmqYVc4VhHGiGmSZFLF0bHhgxIIeCDtlOOidcbDHw=.e7a82fb3-883f-40b1-bad7-a083a8223ffe@github.com> References: <6RMmqYVc4VhHGiGmSZFLF0bHhgxIIeCDtlOOidcbDHw=.e7a82fb3-883f-40b1-bad7-a083a8223ffe@github.com> Message-ID: On Mon, 5 Feb 2024 20:11:43 GMT, Mandy Chung wrote: > Trivial fix. Call `PrintWriter::format` with null `Locale` to format with no localization. > > This PR also fixes JDK-8325262 to print `FindException` message without the stack trace to indicate clearer that the given module path is incorrect. Hello Mandy, the changes look OK to me. ------------- Marked as reviewed by jpai (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17713#pullrequestreview-1864354980 From alanb at openjdk.org Tue Feb 6 07:38:53 2024 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 6 Feb 2024 07:38:53 GMT Subject: RFR: 8321703: jdeps generates illegal dot file containing nodesep=0,500000 In-Reply-To: <6RMmqYVc4VhHGiGmSZFLF0bHhgxIIeCDtlOOidcbDHw=.e7a82fb3-883f-40b1-bad7-a083a8223ffe@github.com> References: <6RMmqYVc4VhHGiGmSZFLF0bHhgxIIeCDtlOOidcbDHw=.e7a82fb3-883f-40b1-bad7-a083a8223ffe@github.com> Message-ID: On Mon, 5 Feb 2024 20:11:43 GMT, Mandy Chung wrote: > Trivial fix. Call `PrintWriter::format` with null `Locale` to format with no localization. > > This PR also fixes JDK-8325262 to print `FindException` message without the stack trace to indicate clearer that the given module path is incorrect. Looks okay. (JDK-8325262 should probably be changed to be Bug rather than Enhancement) ------------- Marked as reviewed by alanb (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17713#pullrequestreview-1864453326 From mbaesken at openjdk.org Tue Feb 6 08:07:22 2024 From: mbaesken at openjdk.org (Matthias Baesken) Date: Tue, 6 Feb 2024 08:07:22 GMT Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v7] In-Reply-To: References: Message-ID: On Mon, 5 Feb 2024 14:15:44 GMT, Matthias Baesken wrote: > > Thanks for the AIX related effort ; I put it again into our internal build/test queue. With the latest commit the build again fails on AIX with this error /jdk/src/java.base/unix/native/libnio/ch/UnixFileDispatcherImpl.c:381:27: error: incompatible pointer types passing 'struct statvfs64 *' to parameter of type 'struct statvfs *' [-Werror,-Wincompatible-pointer-types] result = fstatvfs(fd, &file_stat); ^~~~~~~~~~ /usr/include/sys/statvfs.h:102:42: note: passing argument to parameter here extern int fstatvfs(int, struct statvfs *); ------------- PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1928972961 From ihse at openjdk.org Tue Feb 6 08:07:28 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 6 Feb 2024 08:07:28 GMT Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations with SLEEF [v9] In-Reply-To: References: Message-ID: On Fri, 8 Dec 2023 00:50:59 GMT, Xiaohong Gong wrote: >> Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix potential attribute issue > >> Build changes finally look good. Great, actually! Thanks for persisting, despite the many rounds of review. >> >> You will still need the 2 hotspot reviews for the hotspot part of the patch. >> >> /reviewers 3 > > Thanks for the review and all the comments! @XiaohongGong What happened? Did you not intend to continue working to get this integrated? ------------- PR Comment: https://git.openjdk.org/jdk/pull/16234#issuecomment-1928968764 From xgong at openjdk.org Tue Feb 6 08:15:08 2024 From: xgong at openjdk.org (Xiaohong Gong) Date: Tue, 6 Feb 2024 08:15:08 GMT Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations with SLEEF [v9] In-Reply-To: References: Message-ID: On Thu, 7 Dec 2023 09:30:01 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: > > Fix potential attribute issue Yeah, I,m so sorry for that due to some uncontrollable changes to my work. I have to stop it. Maybe others from Arm will revisit this feature in future. Thanks for your time on this PR and all your comments! ---- Replied Message ---- | From | Magnus Ihse ***@***.***> | | Date | 02/06/2024 16:02 | | To | openjdk/jdk ***@***.***> | | Cc | XiaohongGong ***@***.***>, Mention ***@***.***> | | Subject | Re: [openjdk/jdk] 8312425: [vectorapi] AArch64: Optimize vector math operations with SLEEF (PR #16234) | @XiaohongGong What happened? Did you not intend to continue working to get this integrated? ? 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/16234#issuecomment-1928983785 From ihse at openjdk.org Tue Feb 6 08:18:14 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 6 Feb 2024 08:18:14 GMT Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v8] In-Reply-To: References: Message-ID: On Mon, 5 Feb 2024 14:06:21 GMT, Magnus Ihse Bursie wrote: >> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK native libraries. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Redefine statvfs as statvfs64 on AIX Yeah, I missed `fstatvfs`. ? Now, then maybe `n`th time's a charm? ------------- PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1928987789 From ihse at openjdk.org Tue Feb 6 08:18:14 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 6 Feb 2024 08:18:14 GMT Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v9] In-Reply-To: References: Message-ID: > Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK native libraries. Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: Also fix fstatvfs on AIX ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17538/files - new: https://git.openjdk.org/jdk/pull/17538/files/2de377cd..1fd34b10 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17538&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17538&range=07-08 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/17538.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17538/head:pull/17538 PR: https://git.openjdk.org/jdk/pull/17538 From ihse at openjdk.org Tue Feb 6 08:20:05 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 6 Feb 2024 08:20:05 GMT Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations with SLEEF [v9] In-Reply-To: References: Message-ID: <_Md9YBUxFkpVBHq4CwX1S5qFkQKiqiQ40rem3OA_zUU=.20785d53-06ad-4d15-9b06-42ed1061a818@github.com> On Thu, 7 Dec 2023 09:30:01 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: > > Fix potential attribute issue Ooookay. I hope someone picks it up. I've spent quite a lot of time trying to get this PR into shape. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16234#issuecomment-1928991506 From ihse at openjdk.org Tue Feb 6 08:23:05 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 6 Feb 2024 08:23:05 GMT Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations with SLEEF [v6] In-Reply-To: References: <3cK9QjVQNIgZoWWhrWKEb3XxfbLjprjRMBbStWegH7M=.6df92651-b97d-445a-aa42-302ea791bbea@github.com> Message-ID: <3jgZL57F_aikTsAnrGINeQgFHryGBNJZI24-WusdYKM=.f1f64b34-bfbb-4222-afba-c200152075dc@github.com> On Mon, 11 Dec 2023 18:25:09 GMT, Ludovic Henry wrote: >> @theRealAph >>> Or is there likely to be a plan to e.g. build Oracle's releases with SLEEF support? >> >> I can't say anything for sure, but I picked up some positive vibes from our internal chat. I think the idea was that libsleef could potentially cover up vector math for all platforms that the current Intel lib solution is missing (basically, everything but linux+windows x64). So I this can be seen as a bit of a trial balloon if it is worth a more complete integration of libsleef in the JDK. >> >> And I can't say anything at all about what Oracle JDKs are going to release with, but I am fully open towards adding libsleef to the GHA builds. And I'm guessing that Adoptium has no reason not to include libsleef, but then again, I cannot of course speak for them. > >> I can't say anything for sure, but I picked up some positive vibes from our internal chat. I think the idea was that libsleef could potentially cover up vector math for all platforms that the current Intel lib solution is missing (basically, everything but linux+windows x64). So I this can be seen as a bit of a trial balloon if it is worth a more complete integration of libsleef in the JDK. > > I can add that we are interested to use that for Linux + RISC-V support given the RISC-V support was recently merged into sleef upstream. https://github.com/shibatch/sleef/pull/477 @luhenry Maybe you are interested in helping with bringing this forward? I can assist with risc-v related fixes in the makefiles. I'd just hate to see all this work go to waste. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16234#issuecomment-1928995458 From jpai at openjdk.org Tue Feb 6 10:11:15 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 6 Feb 2024 10:11:15 GMT Subject: RFR: 8325304: Several classes in java.util.jar and java.util.zip don't specify the behaviour for null arguments Message-ID: <0mhiZJQ0aX8ZOjukPSrmwSNyqr8ix9ejT-BkjtbIjSU=.e9df8cd6-1267-4b3e-a2f8-ab215360f68a@github.com> Can I please get a review of this doc-only change which updates the javadoc of several classes in `java.util.jar` and `java.util.zip` to specify their behaviour when `null` arguments are passed to the constructor or methods of those classes? For these updated classes, I have individually checked that they indeed throw a `NullPointerException` when `null` is passed to their constructor or methods. The couple of places where `null` is accepted have been updated to mention that `null` is allowed. ------------- Commit messages: - 8325304: Several classes in java.util.jar and java.util.zip don't specify the behaviour for null arguments Changes: https://git.openjdk.org/jdk/pull/17728/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17728&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8325304 Stats: 75 lines in 15 files changed: 53 ins; 0 del; 22 mod Patch: https://git.openjdk.org/jdk/pull/17728.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17728/head:pull/17728 PR: https://git.openjdk.org/jdk/pull/17728 From jpai at openjdk.org Tue Feb 6 10:11:15 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 6 Feb 2024 10:11:15 GMT Subject: RFR: 8325304: Several classes in java.util.jar and java.util.zip don't specify the behaviour for null arguments In-Reply-To: <0mhiZJQ0aX8ZOjukPSrmwSNyqr8ix9ejT-BkjtbIjSU=.e9df8cd6-1267-4b3e-a2f8-ab215360f68a@github.com> References: <0mhiZJQ0aX8ZOjukPSrmwSNyqr8ix9ejT-BkjtbIjSU=.e9df8cd6-1267-4b3e-a2f8-ab215360f68a@github.com> Message-ID: On Tue, 6 Feb 2024 10:05:52 GMT, Jaikiran Pai wrote: > Can I please get a review of this doc-only change which updates the javadoc of several classes in `java.util.jar` and `java.util.zip` to specify their behaviour when `null` arguments are passed to the constructor or methods of those classes? > > For these updated classes, I have individually checked that they indeed throw a `NullPointerException` when `null` is passed to their constructor or methods. The couple of places where `null` is accepted have been updated to mention that `null` is allowed. A CSR has been created for this change https://bugs.openjdk.org/browse/JDK-8325305 ------------- PR Comment: https://git.openjdk.org/jdk/pull/17728#issuecomment-1929174410 From jpai at openjdk.org Tue Feb 6 10:31:06 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 6 Feb 2024 10:31:06 GMT Subject: RFR: 8325304: Several classes in java.util.jar and java.util.zip don't specify the behaviour for null arguments [v2] In-Reply-To: <0mhiZJQ0aX8ZOjukPSrmwSNyqr8ix9ejT-BkjtbIjSU=.e9df8cd6-1267-4b3e-a2f8-ab215360f68a@github.com> References: <0mhiZJQ0aX8ZOjukPSrmwSNyqr8ix9ejT-BkjtbIjSU=.e9df8cd6-1267-4b3e-a2f8-ab215360f68a@github.com> Message-ID: > Can I please get a review of this doc-only change which updates the javadoc of several classes in `java.util.jar` and `java.util.zip` to specify their behaviour when `null` arguments are passed to the constructor or methods of those classes? > > For these updated classes, I have individually checked that they indeed throw a `NullPointerException` when `null` is passed to their constructor or methods. The couple of places where `null` is accepted have been updated to mention that `null` is allowed. Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: include CheckedInputStream and CheckedOutputStream ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17728/files - new: https://git.openjdk.org/jdk/pull/17728/files/298d0a0a..e4c724fc Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17728&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17728&range=00-01 Stats: 13 lines in 2 files changed: 7 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/17728.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17728/head:pull/17728 PR: https://git.openjdk.org/jdk/pull/17728 From sgehwolf at openjdk.org Tue Feb 6 11:16:53 2024 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Tue, 6 Feb 2024 11:16:53 GMT Subject: RFR: 8322420: [Linux] cgroup v2: Limits in parent nested control groups are not detected [v2] In-Reply-To: References: Message-ID: On Wed, 31 Jan 2024 15:33:01 GMT, Jan Kratochvil wrote: >> It looks like this patch needs a bit more discussion. Generally, it would be good to have the functionality, but I'm unsure about the proposed implementation. >> >> Walking the directory hierarchy (**and** interface files) on every call of `physical_memory()` (or `active_processor_count()` for CPU) seems concerning. Since it seems unlikely for cgroup interface file paths changing during runtime, walking the hierarchy for every look-up seems overkill. Note that the prime users of this feature are in-container use, where most runtimes have the limit settings at the leaf. A few more comments below: >> >> - After this patch, AFAIUI for a cgroup path like `/foo/bar/baz/memory.max` the following files are being looked at for the memory limit (for example for the interface file `memory.max`): >> ``` >> /foo/bar/baz/memory.max >> /foo/bar/memory.max >> /foo/memory.max >> ``` >> This used to be just one file at the leaf, `/foo/bar/baz/memory.max` (prior this patch). So this change has an effect on file IO. `N` files per metric to look at where it used to be one file (i.e. constant). Note that switches like `UseDynamicNumberOfCompilerThreads` make this particularly worrying. I wonder if it would be sufficient to "lock" into the cgroup path where the lowest limits are set in the hierarchy and only use the interface files at that path of a specific controller. This would mean adjusting `CgroupsV2Subsystem` similar to `CgroupsV1Subsystem` to have unique controller paths (i.e. `cpu` and `memory` controller paths could potentially be different). But the code would already be mostly there for this. The idea would be to do the initial walk of the tree at JVM startup, and from then on, only look at the path with a limit set (if any) for subsequent calls. That is `controller->subsystem_path()` would return the correct path at runtime when initialization is done . Thoughts? >> - There seems to be an inconsistency between cgroups v1 (no recursive look-up) and cgroups v2 (recursive look-up). Why? I think we should employ the same semantics to both versions (and drop the hierarchical work-around - [JDK-8217338](https://bugs.openjdk.java.net/browse/JDK-8217338) - for cg v1). >> - There also seems to be an inconsistency between metrics being iterated. `memory.max` and `memory.swap.max` and `memory.swap.current` are being iterated, others, like CPU quotas (`cpu.max` or >> `cpu.weight`) not. Why? Both limits could potentially be one path up the hierarchy, meaning that cp... > >> Walking the directory hierarchy (**and** interface files) on every call of `physical_memory()` (or `active_processor_count()` for CPU) seems concerning. > > I have therefore implemented a hierarchical `memory.stat` extension for cgroup2 which already exists for cgroup1 - if the patch is agreed upon I will submit it to Linux kernel: [cgroup2-hierarchical_memory_limit.patch.txt](https://github.com/openjdk/jdk/files/14113452/cgroup2-hierarchical_memory_limit.patch.txt) > >> Since it seems unlikely for cgroup interface file paths changing during runtime, walking the hierarchy for every look-up seems overkill. Note that the prime users of this feature are in-container use, where most runtimes have the limit settings at the leaf. > > While I understand the most common change of the limits is at the leaf technically any parent group limit can change. Which is also what this patch is implementing. For the performance issue I have implemented the Linux kernel extension above. > >> `N` files per metric to look at where it used to be one file (i.e. constant). > > The problem is any of the files can change. But to fix the performance I have implemented the Linux kernel patch above. > >> I wonder if it would be sufficient to "lock" into the cgroup path where the lowest limits are set in the hierarchy and only use the interface files at that path of a specific controller. > > That mostly disables the functionality of this patch. > > >> * There seems to be an inconsistency between cgroups v1 (no recursive look-up) and cgroups v2 (recursive look-up). Why? I think we should employ the same semantics to both versions (and drop the hierarchical work-around - [JDK-8217338](https://bugs.openjdk.java.net/browse/JDK-8217338) - for cg v1). > > I did not much expect anyone still uses cgroup1. Plus customer was also interested in cgroup2. AFAIK a last OS using cgroup1 was RHEL-7 which will have EOL in a few months. But then I tried to implement cgroup1 but there it sort of already worked thanks for your [JDK-8217338](https://bugs.openjdk.java.net/browse/JDK-8217338). I just fixed there to prefer the hierarchical limit over the leaf limit (and the testcase does test it now) as that is what is used by Linux kernel. > > And then my Linux kernel patch implements the same `memory.stat` way even for cgroup2. > >> * There also seems to be an inconsistency between metrics being iterated. `memory.max` and `memory.swap.max` and `memory.swap.current` are being iterated, others, like CPU quotas (`cpu.max` or... @jankratochvil The "use hierarchical limit" was a work-around that bites us now. So instead we should attempt to unify cgv1 and cgv2 by walking the hierarchy and find the place in the hierarchy where the interface files - with actual limits imposed - are to be found. Since this patch attempts to solve a similar goal to what the old work-around solved for cg v1, we should re-think how to solve it properly. My suggestion would be to go with walking the hierarchy for both: cg v1 and cg v2. As to the walking the hierarchy on every invocation problem, I don't think fixing it by relying on a kernel patch is the way to go. It'll take time for the ecosystem to pick those up and existing cg v2 systems won't be fixed (consider RHEL 8 or RHEL 9 systems and their derivatives). Therefore, the idea would be to do the iteration **once** when the `OSContainer` code initializes. Specifically, in `OSContainer::init()` or `CgroupSubsystemFactory::create()`. There is the off-chance that somebody "migrating" a JVM process from one cgroup hierarchy to another, but I'm not sure this is something we need to support. Restarting the JVM seems OK. After all, the GC and other subsystems aren't really ready for dynamic updates anyway. We will address that problem when it actually becomes one. Once `CgroupSubsystemFactory::create()` is done, the individual controllers would return the correct path to the interface file by asking `CgroupController::subsystem_path()` where it is. This also has a nice symmetry with `memory` vs. `cpu` and other controllers. All of them could have their own `subsystem_path()`. This would shift the iterating-over-paths to init time and would then keep them fixed, addressing the performance concern. Overall this would reduce complexity IMO and would also fit well with a solution I'm working on for [JDK-8261242](https://bugs.openjdk.org/browse/JDK-8261242) which we need to solve for other reasons. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17198#issuecomment-1929296749 From lancea at openjdk.org Tue Feb 6 11:27:54 2024 From: lancea at openjdk.org (Lance Andersen) Date: Tue, 6 Feb 2024 11:27:54 GMT Subject: RFR: 8325304: Several classes in java.util.jar and java.util.zip don't specify the behaviour for null arguments [v2] In-Reply-To: References: <0mhiZJQ0aX8ZOjukPSrmwSNyqr8ix9ejT-BkjtbIjSU=.e9df8cd6-1267-4b3e-a2f8-ab215360f68a@github.com> Message-ID: <7UNzPvlv7CNUQ5kWN9RCnrcxLDfjLzGk6bfYxPL-uhI=.e1846f96-6ad8-4e48-95c3-18d940ef599b@github.com> On Tue, 6 Feb 2024 10:31:06 GMT, Jaikiran Pai wrote: >> Can I please get a review of this doc-only change which updates the javadoc of several classes in `java.util.jar` and `java.util.zip` to specify their behaviour when `null` arguments are passed to the constructor or methods of those classes? >> >> For these updated classes, I have individually checked that they indeed throw a `NullPointerException` when `null` is passed to their constructor or methods. The couple of places where `null` is accepted have been updated to mention that `null` is allowed. > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > include CheckedInputStream and CheckedOutputStream Hi Jai, Thank you for tackling this. An initial comment on a quick read I noticed you use "can cause" here and later use "will cause". I think we should try to be consistent. Perhaps we should use "will result in a..." ------------- PR Review: https://git.openjdk.org/jdk/pull/17728#pullrequestreview-1864907969 From ihse at openjdk.org Tue Feb 6 11:39:57 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 6 Feb 2024 11:39:57 GMT Subject: RFR: 8325109: Sort method modifiers in canonical order In-Reply-To: References: Message-ID: On Thu, 1 Feb 2024 11:57:04 GMT, Magnus Ihse Bursie wrote: > This is a follow-up on [JDK-8324053](https://bugs.openjdk.org/browse/JDK-8324053). I have run the bin/blessed-modifier-order.sh on the entire code base, and manually checked the result. I have reverted all but these trivial and uncontroversial changes. > > Almost all of these are about moving `static` to its proper position; a few do not involve `static` but instead puts `final` or `abstract` in the correct place. > > I have deliberately stayed away from `default` in this PR, since they should probably get a more thorough treatment, see https://github.com/openjdk/jdk/pull/17468#pullrequestreview-1829238473. @DougLea Doug, do you have anything to say about the changes in `java.util.concurrent`? ------------- PR Comment: https://git.openjdk.org/jdk/pull/17670#issuecomment-1929336942 From ihse at openjdk.org Tue Feb 6 12:27:56 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 6 Feb 2024 12:27:56 GMT Subject: RFR: JDK-8325189: Enable this-escape javac warning in java.base In-Reply-To: References: Message-ID: On Fri, 2 Feb 2024 23:36:41 GMT, Joe Darcy wrote: > After the "this-escape" lint warning was added to javac (JDK-8015831), the base module was not updated to be able to compile with this warning enabled. This PR makes the necessary changes to allow the base module to build with the warning enabled. Build changes look fine, but there is really a *lot* of places where the warning is individually disabled. This indicates either that the warning is too broad, or that the code base is potentially very buggy; neither of which sounds very good. :( ------------- Marked as reviewed by ihse (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17692#pullrequestreview-1865022402 From jpai at openjdk.org Tue Feb 6 12:30:10 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 6 Feb 2024 12:30:10 GMT Subject: RFR: 8325304: Several classes in java.util.jar and java.util.zip don't specify the behaviour for null arguments [v3] In-Reply-To: <0mhiZJQ0aX8ZOjukPSrmwSNyqr8ix9ejT-BkjtbIjSU=.e9df8cd6-1267-4b3e-a2f8-ab215360f68a@github.com> References: <0mhiZJQ0aX8ZOjukPSrmwSNyqr8ix9ejT-BkjtbIjSU=.e9df8cd6-1267-4b3e-a2f8-ab215360f68a@github.com> Message-ID: > Can I please get a review of this doc-only change which updates the javadoc of several classes in `java.util.jar` and `java.util.zip` to specify their behaviour when `null` arguments are passed to the constructor or methods of those classes? > > For these updated classes, I have individually checked that they indeed throw a `NullPointerException` when `null` is passed to their constructor or methods. The couple of places where `null` is accepted have been updated to mention that `null` is allowed. Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: Lance's review - replace can cause with will cause ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17728/files - new: https://git.openjdk.org/jdk/pull/17728/files/e4c724fc..f92c5726 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17728&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17728&range=01-02 Stats: 6 lines in 2 files changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/17728.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17728/head:pull/17728 PR: https://git.openjdk.org/jdk/pull/17728 From jpai at openjdk.org Tue Feb 6 12:36:53 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 6 Feb 2024 12:36:53 GMT Subject: RFR: 8325304: Several classes in java.util.jar and java.util.zip don't specify the behaviour for null arguments [v3] In-Reply-To: References: <0mhiZJQ0aX8ZOjukPSrmwSNyqr8ix9ejT-BkjtbIjSU=.e9df8cd6-1267-4b3e-a2f8-ab215360f68a@github.com> Message-ID: On Tue, 6 Feb 2024 12:30:10 GMT, Jaikiran Pai wrote: >> Can I please get a review of this doc-only change which updates the javadoc of several classes in `java.util.jar` and `java.util.zip` to specify their behaviour when `null` arguments are passed to the constructor or methods of those classes? >> >> For these updated classes, I have individually checked that they indeed throw a `NullPointerException` when `null` is passed to their constructor or methods. The couple of places where `null` is accepted have been updated to mention that `null` is allowed. > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > Lance's review - replace can cause with will cause Hello Lance, > I noticed you use "can cause" here and later use "will cause". I think we should try to be consistent. > Perhaps we should use "will result in a..." My use of "can cause" was indeed inconsistent. I had used it in a couple of places. I have now updated the PR to replace with "will cause". I decided to use this "will cause" for consistency, since the text: > "Unless otherwise noted, passing a {@code null} argument to a constructor or method in this class will cause a {@link NullPointerException} to be thrown." has been already in use in various other classes (for example `JarFile`'s javadoc) in the JDK even before the proposed changes in this PR. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17728#issuecomment-1929434263 From ngasson at openjdk.org Tue Feb 6 12:48:06 2024 From: ngasson at openjdk.org (Nick Gasson) Date: Tue, 6 Feb 2024 12:48:06 GMT Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations with SLEEF [v9] In-Reply-To: References: Message-ID: On Thu, 7 Dec 2023 09:30:01 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: > > Fix potential attribute issue We are planning to pick this up again later in the year, thanks for your help so far! ------------- PR Comment: https://git.openjdk.org/jdk/pull/16234#issuecomment-1929451905 From jlaskey at openjdk.org Tue Feb 6 12:57:04 2024 From: jlaskey at openjdk.org (Jim Laskey) Date: Tue, 6 Feb 2024 12:57:04 GMT Subject: RFR: JDK-8325255 jdk.internal.util.ReferencedKeySet::add using wrong test Message-ID: Currently, add is returning intern(e) == null which will always be false. The correct test is intern(e) == e , that is, true when element is newly added. ------------- Commit messages: - Correct test Changes: https://git.openjdk.org/jdk/pull/17732/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17732&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8325255 Stats: 6 lines in 2 files changed: 5 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/17732.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17732/head:pull/17732 PR: https://git.openjdk.org/jdk/pull/17732 From alanb at openjdk.org Tue Feb 6 12:57:54 2024 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 6 Feb 2024 12:57:54 GMT Subject: RFR: 8325304: Several classes in java.util.jar and java.util.zip don't specify the behaviour for null arguments [v3] In-Reply-To: References: <0mhiZJQ0aX8ZOjukPSrmwSNyqr8ix9ejT-BkjtbIjSU=.e9df8cd6-1267-4b3e-a2f8-ab215360f68a@github.com> Message-ID: <4NPhNHLZWM18ESOdPe-C3fuIKs5WVi104LZIipFvizQ=.ff9040d5-2b46-4688-ad75-787c8eaaf4a0@github.com> On Tue, 6 Feb 2024 12:30:10 GMT, Jaikiran Pai wrote: >> Can I please get a review of this doc-only change which updates the javadoc of several classes in `java.util.jar` and `java.util.zip` to specify their behaviour when `null` arguments are passed to the constructor or methods of those classes? >> >> For these updated classes, I have individually checked that they indeed throw a `NullPointerException` when `null` is passed to their constructor or methods. The couple of places where `null` is accepted have been updated to mention that `null` is allowed. > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > Lance's review - replace can cause with will cause The changes means that NPE is specified in both the class description and method descriptions in some cases, e.g. JarInputStream. I assume you meant to remove the NPE from methods where you've added a statement in the class description. Minor nit is some of the usages of `

` in the change are inconsistent with the usages close by, you probably want to keep them consistent if you can. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17728#issuecomment-1929465055 From rgiulietti at openjdk.org Tue Feb 6 13:42:00 2024 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Tue, 6 Feb 2024 13:42:00 GMT Subject: RFR: 8316704: Regex-free parsing of Formatter and FormatProcessor specifiers [v7] In-Reply-To: References: <9UsU73B_0Tc03SRJoJFOxsQrmhTUdSPJAi-S0nTD_lk=.7b6782f9-b578-47a0-a0c6-a6f384f60785@github.com> Message-ID: On Sun, 21 Jan 2024 13:48:49 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 with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 41 additional commits since the last revision: > > - Merge remote-tracking branch 'upstream/master' into optim_for_string_format > - Merge remote-tracking branch 'upstream/master' into optim_for_string_format > - fix from @rgiulietti 's review > - add document > - fix FormatterBuilder testcase handle lineSeparator on windows > - fix from @rgiulietti 's review > - move testcases to Basic.java > - move testcase from BasicInt to Basic-X > - add copyright info > - Improve the readability, suggestion from @rgiulietti > - ... and 31 more: https://git.openjdk.org/jdk/compare/19fcf1fa...a5f1a4f7 Marked as reviewed by rgiulietti (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/15776#pullrequestreview-1865210169 From jlaskey at openjdk.org Tue Feb 6 13:56:09 2024 From: jlaskey at openjdk.org (Jim Laskey) Date: Tue, 6 Feb 2024 13:56:09 GMT Subject: RFR: JDK-8325255 jdk.internal.util.ReferencedKeySet::add using wrong test [v2] In-Reply-To: References: Message-ID: > Currently, add is returning intern(e) == null which will always be false. The correct test is intern(e) == e , that is, true when element is newly added. 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 two additional commits since the last revision: - Merge remote-tracking branch 'upstream/master' into 8325255 - Correct test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17732/files - new: https://git.openjdk.org/jdk/pull/17732/files/d119fb97..b8d2d97d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17732&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17732&range=00-01 Stats: 30 lines in 5 files changed: 19 ins; 1 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/17732.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17732/head:pull/17732 PR: https://git.openjdk.org/jdk/pull/17732 From mbaesken at openjdk.org Tue Feb 6 14:01:00 2024 From: mbaesken at openjdk.org (Matthias Baesken) Date: Tue, 6 Feb 2024 14:01:00 GMT Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v9] In-Reply-To: References: Message-ID: On Tue, 6 Feb 2024 08:18:14 GMT, Magnus Ihse Bursie wrote: >> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK native libraries. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Also fix fstatvfs on AIX AIX build is fixed now after latest commit, thanks for handling the AIX special cases. ------------- Marked as reviewed by mbaesken (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17538#pullrequestreview-1865270571 From luhenry at openjdk.org Tue Feb 6 14:20:05 2024 From: luhenry at openjdk.org (Ludovic Henry) Date: Tue, 6 Feb 2024 14:20:05 GMT Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations with SLEEF [v6] In-Reply-To: <3jgZL57F_aikTsAnrGINeQgFHryGBNJZI24-WusdYKM=.f1f64b34-bfbb-4222-afba-c200152075dc@github.com> References: <3cK9QjVQNIgZoWWhrWKEb3XxfbLjprjRMBbStWegH7M=.6df92651-b97d-445a-aa42-302ea791bbea@github.com> <3jgZL57F_aikTsAnrGINeQgFHryGBNJZI24-WusdYKM=.f1f64b34-bfbb-4222-afba-c200152075dc@github.com> Message-ID: On Tue, 6 Feb 2024 08:20:39 GMT, Magnus Ihse Bursie wrote: > I'd just hate to see all this work go to waste. Same here! ------------- PR Comment: https://git.openjdk.org/jdk/pull/16234#issuecomment-1929780538 From dfuchs at openjdk.org Tue Feb 6 14:41:56 2024 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Tue, 6 Feb 2024 14:41:56 GMT Subject: RFR: JDK-8325189: Enable this-escape javac warning in java.base In-Reply-To: References: Message-ID: On Fri, 2 Feb 2024 23:36:41 GMT, Joe Darcy wrote: > After the "this-escape" lint warning was added to javac (JDK-8015831), the base module was not updated to be able to compile with this warning enabled. This PR makes the necessary changes to allow the base module to build with the warning enabled. I looked at the modifications in java.net / sun.net. Looks generally good though I have some comments. src/java.base/share/classes/java/net/Socket.java line 323: > 321: * @see SecurityManager#checkConnect > 322: */ > 323: @SuppressWarnings("this-escape") This is a weird one. I guess the issue here is that the escape happens in the chained constructor, and is propagated recursively up the constructor chain. Is the suppress warning here still needed after disabling this-escape warning at line 358? Actually - these are all weird since the only place where the escape happens is in the private constructor at line 548 - and it doesn't even get flagged there (presumably because it's a private constructor?) I guess that the rationale is that subclasses cannot override the private constructor (where the escape happen), but can override the public constructor that calls the private constructor where the escape happen. I can't help feeling that the warning would be better placed on the private constructor though. Seeing it here confused me a lot. src/java.base/share/classes/sun/net/www/MessageHeader.java line 53: > 51: } > 52: > 53: @SuppressWarnings("this-escape") An alternative here could be to make the class final. AFAICS it's not subclassed anywhere. If you'd prefer not to do this here then maybe a followup issue could be logged? ------------- PR Review: https://git.openjdk.org/jdk/pull/17692#pullrequestreview-1865378355 PR Review Comment: https://git.openjdk.org/jdk/pull/17692#discussion_r1479922189 PR Review Comment: https://git.openjdk.org/jdk/pull/17692#discussion_r1479936447 From duke at openjdk.org Tue Feb 6 15:19:02 2024 From: duke at openjdk.org (Shaojin Wen) Date: Tue, 6 Feb 2024 15:19:02 GMT Subject: Integrated: 8316704: Regex-free parsing of Formatter and FormatProcessor specifiers In-Reply-To: <9UsU73B_0Tc03SRJoJFOxsQrmhTUdSPJAi-S0nTD_lk=.7b6782f9-b578-47a0-a0c6-a6f384f60785@github.com> References: <9UsU73B_0Tc03SRJoJFOxsQrmhTUdSPJAi-S0nTD_lk=.7b6782f9-b578-47a0-a0c6-a6f384f60785@github.com> Message-ID: On Sun, 17 Sep 2023 16:01:33 GMT, Shaojin Wen wrote: > @cl4es made performance optimizations for the simple specifiers of String.format in PR https://github.com/openjdk/jdk/pull/2830. Based on the same idea, I continued to make improvements. I made patterns like %2d %02d also be optimized. > > The following are the test results based on MacBookPro M1 Pro: > > > -Benchmark Mode Cnt Score Error Units > -StringFormat.complexFormat avgt 15 1862.233 ? 217.479 ns/op > -StringFormat.int02Format avgt 15 312.491 ? 26.021 ns/op > -StringFormat.intFormat avgt 15 84.432 ? 4.145 ns/op > -StringFormat.longFormat avgt 15 87.330 ? 6.111 ns/op > -StringFormat.stringFormat avgt 15 63.985 ? 11.366 ns/op > -StringFormat.stringIntFormat avgt 15 87.422 ? 0.147 ns/op > -StringFormat.widthStringFormat avgt 15 250.740 ? 32.639 ns/op > -StringFormat.widthStringIntFormat avgt 15 312.474 ? 16.309 ns/op > > +Benchmark Mode Cnt Score Error Units > +StringFormat.complexFormat avgt 15 740.626 ? 66.671 ns/op (+151.45) > +StringFormat.int02Format avgt 15 131.049 ? 0.432 ns/op (+138.46) > +StringFormat.intFormat avgt 15 67.229 ? 4.155 ns/op (+25.59) > +StringFormat.longFormat avgt 15 66.444 ? 0.614 ns/op (+31.44) > +StringFormat.stringFormat avgt 15 62.619 ? 4.652 ns/op (+2.19) > +StringFormat.stringIntFormat avgt 15 89.606 ? 13.966 ns/op (-2.44) > +StringFormat.widthStringFormat avgt 15 52.462 ? 15.649 ns/op (+377.95) > +StringFormat.widthStringIntFormat avgt 15 101.814 ? 3.147 ns/op (+206.91) This pull request has now been integrated. Changeset: 50b17d98 Author: Shaojin Wen Committer: Raffaello Giulietti URL: https://git.openjdk.org/jdk/commit/50b17d9846f7727a5f7225e1b093b6bdff909478 Stats: 307 lines in 5 files changed: 269 ins; 14 del; 24 mod 8316704: Regex-free parsing of Formatter and FormatProcessor specifiers Reviewed-by: redestad, rgiulietti ------------- PR: https://git.openjdk.org/jdk/pull/15776 From rriggs at openjdk.org Tue Feb 6 15:53:57 2024 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 6 Feb 2024 15:53:57 GMT Subject: RFR: JDK-8318761: MessageFormat pattern support for CompactNumberFormat, ListFormat, and DateTimeFormatter [v4] In-Reply-To: References: Message-ID: <87ZK-yMy308dxThFS9M0d_8CdgnCkthVwYaAzjMB8wU=.72750bb8-3750-411a-bd30-ebdd18e2a3f3@github.com> On Mon, 5 Feb 2024 23:51:00 GMT, Justin Lu wrote: >> Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8319344) which adds MessageFormat pattern support for the following subformats: ListFormat, CompactNumberFormat, and DateTimeFormatter. This change is intended to provide pattern support for the more recently added JDK Format subclasses, as well as improving java.time formatting within i18n. The draft javadoc can be viewed here: https://cr.openjdk.org/~jlu/docs/api/java.base/java/text/MessageFormat.html. Please see the CSR for more in-depth behavioral changes, as well as limitations. >> >> The `FormatTypes`: dtf_date, dtf_time, dtf_datetime, pre-defined DateTimeFormatter(s), and list are added. >> The `FormatStyles`: compact_short, compact_long, or, and unit are added. >> >> For example, previously, >> >> >> Object[] args = {LocalDate.of(2023, 11, 16), LocalDate.of(2023, 11, 27)}; >> MessageFormat.format("It was {0,date,full}, now it is {1,date,full}", args); >> >> >> would throw `Exception java.lang.IllegalArgumentException: Cannot format given Object as a Date` >> >> Now, a user can call >> >> >> MessageFormat.format("It was {0,dtf_date,full}, now it is {1,dtf_date,full}", args); >> >> >> which returns "It was Thursday, November 16, 2023, now it is Friday, November 17, 2023" > > Justin Lu has updated the pull request incrementally with two additional commits since the last revision: > > - Apply spacing suggestions > > Co-authored-by: Andrey Turbanov > - add expected message to exception checking src/java.base/share/classes/java/text/MessageFormat.java line 90: > 88: * dtf_time > 89: * dtf_datetime > 90: * pre-defined DateTimeFormatter(s) Its not clear why these new options are inserted before the existing formats. (And also the order of the table below). src/java.base/share/classes/java/text/MessageFormat.java line 219: > 217: * {@code pre-defined DateTimeFormatter(s)} > 218: * (none) > 219: * The {@code pre-defined DateTimeFormatter(s)} are used as a {@code FormatType} | {@link DateTimeFormatter#BASIC_ISO_DATE BASIC_ISO_DATE}, {@link DateTimeFormatter#ISO_LOCAL_DATE ISO_LOCAL_DATE}, {@link DateTimeFormatter#ISO_OFFSET_DATE ISO_OFFSET_DATE}, {@link DateTimeFormatter#ISO_DATE ISO_DATE}, {@link DateTimeFormatter#ISO_LOCAL_TIME ISO_LOCAL_TIME}, {@link DateTimeFormatter#ISO_OFFSET_TIME ISO_OFFSET_TIME}, {@link DateTimeFormatter#ISO_TIME ISO_TIME}, {@link DateTimeFormatter#ISO_LOCAL_DATE_TIME ISO_LOCAL_DATE_TIME}, {@link DateTimeFormatter#ISO_OFFSET_DATE_TIME ISO_OFFSET_DATE_TIME}, {@link DateTimeFormatter#ISO_ZONED_DATE_TIME ISO_ZONED_DATE_TIME}, {@link DateTimeFormatter#ISO_DATE_TIME ISO_DATE_TIME}, {@link DateTimeFormatter#ISO_ORDINAL_DATE ISO_ORDINAL_DATE}, {@link DateTimeFormatter#ISO_WEEK_DATE ISO_WEEK_DATE}, {@link DateTimeFormatter#ISO_INSTANT ISO_INSTANT}, {@link DateTimeFormatter#RFC_1123_DATE_TIME RFC_1123_DATE_TIME} The "|" is out of place; its not a common delimiter. Perhaps ":" colon instead. This source line is too long (80-100 is typical). Breaking the line should not break the table formatting. src/java.base/share/classes/java/text/MessageFormat.java line 335: > 333: * {@code result} returns the following: > 334: * 

> 335:  * At 12:30 PM on Jul 3, 2053, there was a disturbance in the Force on planet 7.

An explicit date `new Date(7,3,2053)` would give predictable results between the code and the result string.

src/java.base/share/classes/java/text/MessageFormat.java line 681:

> 679:         if (fmt instanceof NumberFormat) {
> 680:             // Add any instances returned from the NumberFormat factory methods
> 681:             if (fmt.equals(NumberFormat.getInstance(locale))) {

This looks like wack-a-mole code, no good design; likely to be hard to maintain.
(I don't have a better idea at the moment though).

src/java.base/share/classes/java/text/MessageFormat.java line 1881:

> 1879:             for (FormatStyle style : values()) {
> 1880:                 // Also check trimmed case-insensitive for historical reasons
> 1881:                 if (text.trim().toLowerCase(Locale.ROOT).equals(style.text)) {

`String.compareIgnoreCase(....)` might be clearer and not need to allocate for a converted string.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17663#discussion_r1479979607
PR Review Comment: https://git.openjdk.org/jdk/pull/17663#discussion_r1479989358
PR Review Comment: https://git.openjdk.org/jdk/pull/17663#discussion_r1479999184
PR Review Comment: https://git.openjdk.org/jdk/pull/17663#discussion_r1480020800
PR Review Comment: https://git.openjdk.org/jdk/pull/17663#discussion_r1480039800

From rriggs at openjdk.org  Tue Feb  6 15:53:57 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 6 Feb 2024 15:53:57 GMT
Subject: RFR: JDK-8318761: MessageFormat pattern support for
 CompactNumberFormat, ListFormat, and DateTimeFormatter [v4]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Fri, 2 Feb 2024 22:24:49 GMT, Naoto Sato  wrote:

>> We discussed this separately, but will go over again here in case others are interested. Since DTF does not implement `equals()`, even if we implement `equals()` for the `ClassicFormat`, we would basically still need to implement our own `equals()` for a DTF to effectively compare the ClassicFormats.
>> 
>> I had also mentioned that we could reference check the pre-defined DTFs, but this won't work either actually. This is because we cannot reference check the DTFs, but rather the Format adapted DTFs, which mean they are now new ClassicFormats every time since we don't store them.
>
> Thanks. I think it is fine.

The comment "does not implement equals and thus cannot be represented as a pattern" doesn't explain why it can be represented as a pattern. Can that be explained better?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17663#discussion_r1480011093

From rriggs at openjdk.org  Tue Feb  6 15:57:56 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 6 Feb 2024 15:57:56 GMT
Subject: RFR: JDK-8325255 jdk.internal.util.ReferencedKeySet::add using
 wrong test [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 6 Feb 2024 13:56:09 GMT, Jim Laskey  wrote:

>> Currently, add is returning intern(e) == null which will always be false. The correct test is intern(e) == e , that is, true when element is newly added.
>
> 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 two additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'upstream/master' into 8325255
>  - Correct test

LGTM

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

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17732#pullrequestreview-1865626163

From ihse at openjdk.org  Tue Feb  6 16:13:01 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 6 Feb 2024 16:13:01 GMT
Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v9]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Fri, 2 Feb 2024 07:01:33 GMT, Sam James  wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Also fix fstatvfs on AIX
>
> make/modules/jdk.hotspot.agent/Lib.gmk line 31:
> 
>> 29: 
>> 30: ifeq ($(call isTargetOs, linux), true)
>> 31:   SA_CFLAGS := -D_FILE_OFFSET_BITS=64
> 
> We have two choices to feel a bit more comfortable:
> 1) We unconditionally `static_assert` in a few places for large `off_t`, or
> 2) We only do it for platforms we know definitely support F_O_B and aren't AIX (which we've handled separately).
> 
> Not sure that's strictly necessary though. Also, if something understands LARGEFILE*_SOURCE, then it probably understood F_O_B, or at least has some macro to control it. Just thinking aloud.

@thesamesam Do you want a `static_assert`? As I said, please let me know where you want to put it. I don't think it provides much, but if it makes you feel more comfortable, I'm okay with adding it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17538#discussion_r1480125790

From psandoz at openjdk.org  Tue Feb  6 16:57:14 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Tue, 6 Feb 2024 16:57:14 GMT
Subject: [jdk22] RFR: 8324858: [vectorapi] Bounds checking issues when
 accessing memory segments
Message-ID: 

This pull request contains a backport of commit [1ae85138](https://github.com/openjdk/jdk/commit/1ae851387f881263ccc6aeace5afdd0f49d41d33) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

The commit being backported was authored by Paul Sandoz on 2 Feb 2024 and was reviewed by Maurizio Cimadamore and Jatin Bhateja.

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

Commit messages:
 - Backport 1ae851387f881263ccc6aeace5afdd0f49d41d33

Changes: https://git.openjdk.org/jdk22/pull/109/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk22&pr=109&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8324858
  Stats: 248 lines in 39 files changed: 132 ins; 8 del; 108 mod
  Patch: https://git.openjdk.org/jdk22/pull/109.diff
  Fetch: git fetch https://git.openjdk.org/jdk22.git pull/109/head:pull/109

PR: https://git.openjdk.org/jdk22/pull/109

From mchung at openjdk.org  Tue Feb  6 17:06:57 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 6 Feb 2024 17:06:57 GMT
Subject: RFR: 8321703: jdeps generates illegal dot file containing
 nodesep=0,500000
In-Reply-To: <6RMmqYVc4VhHGiGmSZFLF0bHhgxIIeCDtlOOidcbDHw=.e7a82fb3-883f-40b1-bad7-a083a8223ffe@github.com>
References: <6RMmqYVc4VhHGiGmSZFLF0bHhgxIIeCDtlOOidcbDHw=.e7a82fb3-883f-40b1-bad7-a083a8223ffe@github.com>
Message-ID: 

On Mon, 5 Feb 2024 20:11:43 GMT, Mandy Chung  wrote:

> Trivial fix.  Call `PrintWriter::format` with null `Locale` to format with no localization.
>  
> This PR also fixes JDK-8325262 to print `FindException` message without the stack trace to indicate clearer that the given module path is incorrect.

Thanks for the review.

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

PR Comment: https://git.openjdk.org/jdk/pull/17713#issuecomment-1930373370

From mchung at openjdk.org  Tue Feb  6 17:06:57 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 6 Feb 2024 17:06:57 GMT
Subject: Integrated: 8321703: jdeps generates illegal dot file containing
 nodesep=0,500000
In-Reply-To: <6RMmqYVc4VhHGiGmSZFLF0bHhgxIIeCDtlOOidcbDHw=.e7a82fb3-883f-40b1-bad7-a083a8223ffe@github.com>
References: <6RMmqYVc4VhHGiGmSZFLF0bHhgxIIeCDtlOOidcbDHw=.e7a82fb3-883f-40b1-bad7-a083a8223ffe@github.com>
Message-ID: 

On Mon, 5 Feb 2024 20:11:43 GMT, Mandy Chung  wrote:

> Trivial fix.  Call `PrintWriter::format` with null `Locale` to format with no localization.
>  
> This PR also fixes JDK-8325262 to print `FindException` message without the stack trace to indicate clearer that the given module path is incorrect.

This pull request has now been integrated.

Changeset: b814c318
Author:    Mandy Chung 
URL:       https://git.openjdk.org/jdk/commit/b814c3184e5975e2556911c3a386e6d9bc114d24
Stats:     5 lines in 2 files changed: 1 ins; 0 del; 4 mod

8321703: jdeps generates illegal dot file containing nodesep=0,500000
8325262: jdeps can drop printing stack trace when FindException is thrown due to modules not found

Reviewed-by: jpai, alanb

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

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

From darcy at openjdk.org  Tue Feb  6 17:31:54 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 6 Feb 2024 17:31:54 GMT
Subject: RFR: JDK-8325189: Enable this-escape javac warning in java.base
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 6 Feb 2024 14:35:52 GMT, Daniel Fuchs  wrote:

>> After the "this-escape" lint warning was added to javac (JDK-8015831), the base module was not updated to be able to compile with this warning enabled. This PR makes the necessary changes to allow the base module to build with the warning enabled.
>
> src/java.base/share/classes/sun/net/www/MessageHeader.java line 53:
> 
>> 51:     }
>> 52: 
>> 53:     @SuppressWarnings("this-escape")
> 
> An alternative here could be to make the class final. AFAICS it's not subclassed anywhere. If you'd prefer not to do this here then maybe a followup issue could be logged?

I'd prefer if that kind of change were done as a subtask of

[JDK-8325263](https://bugs.openjdk.org/browse/JDK-8325263): Address this-escape lint warnings java.base (umbrella)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17692#discussion_r1480307107

From darcy at openjdk.org  Tue Feb  6 17:43:56 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 6 Feb 2024 17:43:56 GMT
Subject: RFR: JDK-8325189: Enable this-escape javac warning in java.base
In-Reply-To: 
References: 
Message-ID: 

On Fri, 2 Feb 2024 23:36:41 GMT, Joe Darcy  wrote:

> After the "this-escape" lint warning was added to javac (JDK-8015831), the base module was not updated to be able to compile with this warning enabled. This PR makes the necessary changes to allow the base module to build with the warning enabled.

> Build changes look fine, but there is really a _lot_ of places where the warning is individually disabled. This indicates either that the warning is too broad, or that the code base is potentially very buggy; neither of which sounds very good. :(

I deliberately choose to suppress the warning at each constructor location rather than at the class level so there are more SuppressWarnings annotations than strictly needed to get the build to be clean. However, I thought limiting the scope of the annotations was preferable for several reasons, including more precisely indicating where any code updates are needed.

This is a new warning run over old code, in some cases very old code. I don't find it surprising that there were several hundred instances of this warning in java.base given the amount of code there.

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

PR Comment: https://git.openjdk.org/jdk/pull/17692#issuecomment-1930451875

From naoto at openjdk.org  Tue Feb  6 17:46:06 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 6 Feb 2024 17:46:06 GMT
Subject: Integrated: 8324665: Loose matching of space separators in the lenient
 date/time parsing mode
In-Reply-To: 
References: 
Message-ID: 

On Thu, 1 Feb 2024 23:12:46 GMT, Naoto Sato  wrote:

> Implementing "loose matching" of space separators in both `java.time.format.DateTimeFormatter` and `java.text.DateFormat` on lenient parsing. This will effectively fix the NNBSP issues on parsing time with am/pm markers introduced with CLDR version 42 (https://inside.java/2023/03/28/quality-heads-up/). A draft CSR has also been drafted.

This pull request has now been integrated.

Changeset: 96eb0390
Author:    Naoto Sato 
URL:       https://git.openjdk.org/jdk/commit/96eb0390d69ed2e0c3e59f77fb65fbb79615a11c
Stats:     177 lines in 4 files changed: 171 ins; 0 del; 6 mod

8324665: Loose matching of space separators in the lenient date/time parsing mode

Reviewed-by: joehw, jlu

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

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

From joehw at openjdk.org  Tue Feb  6 18:07:56 2024
From: joehw at openjdk.org (Joe Wang)
Date: Tue, 6 Feb 2024 18:07:56 GMT
Subject: RFR: JDK-8325189: Enable this-escape javac warning in java.base
In-Reply-To: 
References: 
Message-ID: 

On Fri, 2 Feb 2024 23:36:41 GMT, Joe Darcy  wrote:

> After the "this-escape" lint warning was added to javac (JDK-8015831), the base module was not updated to be able to compile with this warning enabled. This PR makes the necessary changes to allow the base module to build with the warning enabled.

The two XML changes look good to me. There would be a lot of warnings in the java.xml module as well, if we had to do it in the future.

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

Marked as reviewed by joehw (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17692#pullrequestreview-1866004351

From lancea at openjdk.org  Tue Feb  6 18:13:54 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 6 Feb 2024 18:13:54 GMT
Subject: RFR: JDK-8325189: Enable this-escape javac warning in java.base
In-Reply-To: 
References: 
Message-ID: 

On Fri, 2 Feb 2024 23:36:41 GMT, Joe Darcy  wrote:

> After the "this-escape" lint warning was added to javac (JDK-8015831), the base module was not updated to be able to compile with this warning enabled. This PR makes the necessary changes to allow the base module to build with the warning enabled.

Marked as reviewed by lancea (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17692#pullrequestreview-1866015274

From dfuchs at openjdk.org  Tue Feb  6 18:20:54 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 6 Feb 2024 18:20:54 GMT
Subject: RFR: JDK-8325189: Enable this-escape javac warning in java.base
In-Reply-To: 
References: 
 
 
Message-ID: 

On Tue, 6 Feb 2024 17:29:25 GMT, Joe Darcy  wrote:

>> src/java.base/share/classes/sun/net/www/MessageHeader.java line 53:
>> 
>>> 51:     }
>>> 52: 
>>> 53:     @SuppressWarnings("this-escape")
>> 
>> An alternative here could be to make the class final. AFAICS it's not subclassed anywhere. If you'd prefer not to do this here then maybe a followup issue could be logged?
>
> I'd prefer if that kind of change were done as a subtask of
> 
> [JDK-8325263](https://bugs.openjdk.org/browse/JDK-8325263): Address this-escape lint warnings java.base (umbrella)

Thanks Joe. I logged [JDK-8325361](https://bugs.openjdk.org/browse/JDK-8325361): Make sun.net.www.MessageHeader final

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17692#discussion_r1480362736

From liach at openjdk.org  Tue Feb  6 18:31:56 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 6 Feb 2024 18:31:56 GMT
Subject: RFR: JDK-8325255 jdk.internal.util.ReferencedKeySet::add using
 wrong test [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 6 Feb 2024 13:56:09 GMT, Jim Laskey  wrote:

>> Currently, add is returning intern(e) == null which will always be false. The correct test is intern(e) == e , that is, true when element is newly added.
>
> 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 two additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'upstream/master' into 8325255
>  - Correct test

With the current code, if we have code like:

var s = "test failed";
add(s);
add(s);

The last 2 calls will both return `true`, right? We should add a test for consecutively adding the same items too.

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

PR Comment: https://git.openjdk.org/jdk/pull/17732#issuecomment-1930526916

From jlaskey at openjdk.org  Tue Feb  6 18:43:09 2024
From: jlaskey at openjdk.org (Jim Laskey)
Date: Tue, 6 Feb 2024 18:43:09 GMT
Subject: RFR: JDK-8325255 jdk.internal.util.ReferencedKeySet::add using
 wrong test [v3]
In-Reply-To: 
References: 
Message-ID: 

> Currently, add is returning intern(e) == null which will always be false. The correct test is intern(e) == e , that is, true when element is newly added.

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

  Update ReferencedKeyTest.java

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17732/files
  - new: https://git.openjdk.org/jdk/pull/17732/files/b8d2d97d..51cf3e4a

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

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

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

From jlaskey at openjdk.org  Tue Feb  6 18:43:09 2024
From: jlaskey at openjdk.org (Jim Laskey)
Date: Tue, 6 Feb 2024 18:43:09 GMT
Subject: RFR: JDK-8325255 jdk.internal.util.ReferencedKeySet::add using
 wrong test [v2]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Tue, 6 Feb 2024 18:29:17 GMT, Chen Liang  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 two additional commits since the last revision:
>> 
>>  - Merge remote-tracking branch 'upstream/master' into 8325255
>>  - Correct test
>
> With the current code, if we have code like:
> 
> var s = "test failed";
> add(s);
> add(s);
> 
> The last 2 calls will both return `true`, right? We should add a test for consecutively adding the same items too.

@liach I can agree to that. Updated.

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

PR Comment: https://git.openjdk.org/jdk/pull/17732#issuecomment-1930542529

From bpb at openjdk.org  Tue Feb  6 19:37:57 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 6 Feb 2024 19:37:57 GMT
Subject: Integrated: 8325152: Clarify specification of
 java.io.RandomAccessFile.setLength
In-Reply-To: <6s1H_WwYoHtrO9N7-BhmsW6HvUhdtJUYzQyxJMeu3DI=.73712304-befe-4da2-8243-328774f9724f@github.com>
References: <6s1H_WwYoHtrO9N7-BhmsW6HvUhdtJUYzQyxJMeu3DI=.73712304-befe-4da2-8243-328774f9724f@github.com>
Message-ID: 

On Fri, 2 Feb 2024 00:38:51 GMT, Brian Burkhalter  wrote:

> Modify the specification verbiage of `java.io.RandomAccessFile.setLength` to account for the effect of the method on the file offset as returned by `getFilePointer`.

This pull request has now been integrated.

Changeset: 4b1e367e
Author:    Brian Burkhalter 
URL:       https://git.openjdk.org/jdk/commit/4b1e367edabb3c12359abc2d7815559b9ece9fe3
Stats:     20 lines in 1 file changed: 9 ins; 2 del; 9 mod

8325152: Clarify specification of java.io.RandomAccessFile.setLength

Reviewed-by: alanb

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

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

From jlu at openjdk.org  Tue Feb  6 22:34:11 2024
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 6 Feb 2024 22:34:11 GMT
Subject: RFR: JDK-8318761: MessageFormat pattern support for
 CompactNumberFormat, ListFormat, and DateTimeFormatter [v5]
In-Reply-To: 
References: 
Message-ID: 

> Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8319344) which adds MessageFormat pattern support for the following subformats: ListFormat, CompactNumberFormat, and DateTimeFormatter. This change is intended to provide pattern support for the more recently added JDK Format subclasses, as well as improving java.time formatting within i18n. The draft javadoc can be viewed here: https://cr.openjdk.org/~jlu/docs/api/java.base/java/text/MessageFormat.html. Please see the CSR for more in-depth behavioral changes, as well as limitations.
> 
> The `FormatTypes`:  dtf_date, dtf_time, dtf_datetime, pre-defined DateTimeFormatter(s), and list are added.
> The `FormatStyles`: compact_short, compact_long, or, and unit are added.
> 
> For example, previously,
> 
> 
> Object[] args = {LocalDate.of(2023, 11, 16), LocalDate.of(2023, 11, 27)};
> MessageFormat.format("It was {0,date,full}, now it is {1,date,full}", args);
> 
> 
> would throw `Exception java.lang.IllegalArgumentException: Cannot format given Object as a Date`
> 
> Now, a user can call
> 
> 
> MessageFormat.format("It was {0,dtf_date,full}, now it is {1,dtf_date,full}", args);
> 
> 
> which returns "It was Thursday, November 16, 2023, now it is Friday, November 17, 2023"

Justin Lu 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 remote-tracking branch 'origin/JDK-8318761-j.text.MessageFormat-pattern-enh' into JDK-8318761-j.text.MessageFormat-pattern-enh
 - Apply spacing suggestions
   
   Co-authored-by: Andrey Turbanov 
 - implement some feedback from Roger's comments
 - merge master and resolve conflicts stemming from 8323699
 - add expected message to exception checking
 - Use Naoto's recommended example
 - reflect Naoto's comments
 - init

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

Changes: https://git.openjdk.org/jdk/pull/17663/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17663&range=04
  Stats: 1250 lines in 6 files changed: 923 ins; 205 del; 122 mod
  Patch: https://git.openjdk.org/jdk/pull/17663.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17663/head:pull/17663

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

From jlu at openjdk.org  Tue Feb  6 22:34:12 2024
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 6 Feb 2024 22:34:12 GMT
Subject: RFR: JDK-8318761: MessageFormat pattern support for
 CompactNumberFormat, ListFormat, and DateTimeFormatter [v4]
In-Reply-To: <87ZK-yMy308dxThFS9M0d_8CdgnCkthVwYaAzjMB8wU=.72750bb8-3750-411a-bd30-ebdd18e2a3f3@github.com>
References: 
 
 <87ZK-yMy308dxThFS9M0d_8CdgnCkthVwYaAzjMB8wU=.72750bb8-3750-411a-bd30-ebdd18e2a3f3@github.com>
Message-ID: 

On Tue, 6 Feb 2024 14:59:22 GMT, Roger Riggs  wrote:

>> Justin Lu has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Apply spacing suggestions
>>    
>>    Co-authored-by: Andrey Turbanov 
>>  - add expected message to exception checking
>
> src/java.base/share/classes/java/text/MessageFormat.java line 90:
> 
>> 88:  *         dtf_time
>> 89:  *         dtf_datetime
>> 90:  *         pre-defined DateTimeFormatter(s)
> 
> Its not clear why these new options are inserted before the existing formats.
> (And also the order of the table below).

I moved these new types before the existing formats because I wanted them

1. To be grouped with the other date/time related formats
2. To appear before the existing the other date/time related formats, as java.time takes precedence over util.Date

However, I can update it so that the new types/table are chronologically ordered; please let me know if you would prefer that.

> src/java.base/share/classes/java/text/MessageFormat.java line 219:
> 
>> 217:  *       {@code pre-defined DateTimeFormatter(s)}
>> 218:  *       (none)
>> 219:  *       The {@code pre-defined DateTimeFormatter(s)} are used as a {@code FormatType} | {@link DateTimeFormatter#BASIC_ISO_DATE BASIC_ISO_DATE}, {@link DateTimeFormatter#ISO_LOCAL_DATE ISO_LOCAL_DATE}, {@link DateTimeFormatter#ISO_OFFSET_DATE ISO_OFFSET_DATE}, {@link DateTimeFormatter#ISO_DATE ISO_DATE}, {@link DateTimeFormatter#ISO_LOCAL_TIME ISO_LOCAL_TIME}, {@link DateTimeFormatter#ISO_OFFSET_TIME ISO_OFFSET_TIME}, {@link DateTimeFormatter#ISO_TIME ISO_TIME}, {@link DateTimeFormatter#ISO_LOCAL_DATE_TIME ISO_LOCAL_DATE_TIME}, {@link DateTimeFormatter#ISO_OFFSET_DATE_TIME ISO_OFFSET_DATE_TIME}, {@link DateTimeFormatter#ISO_ZONED_DATE_TIME ISO_ZONED_DATE_TIME}, {@link DateTimeFormatter#ISO_DATE_TIME ISO_DATE_TIME}, {@link DateTimeFormatter#ISO_ORDINAL_DATE ISO_ORDINAL_DATE}, {@link DateTimeFormatter#ISO_WEEK_DATE ISO_WEEK_DATE}, {@link DateTimeFormatter#ISO_INSTANT ISO_INSTANT}, {@link DateTimeFormatter#RFC_1123_DATE_TIME RFC_1123_DATE_TIME}
> 
> The "|" is out of place; its not a common delimiter.  Perhaps ":" colon instead.
> This source line is too long (80-100 is typical). Breaking the line should not break the table formatting.

Replaced with a `:` as suggested. Also truncated the lines here as well as in the other new Format entries.

> src/java.base/share/classes/java/text/MessageFormat.java line 335:
> 
>> 333:  * {@code result} returns the following:
>> 334:  * 
>> 335:  * At 12:30 PM on Jul 3, 2053, there was a disturbance in the Force on planet 7.
> 
> An explicit date `new Date(7,3,2053)` would give predictable results between the code and the result string.

Right, replaced with `new GregorianCalendar(2053, Calendar.JULY, 3, 12, 30).getTime()` since the Date constructor is deprecated. Also turns out the existing example output was wrong, so updated that as well.

> src/java.base/share/classes/java/text/MessageFormat.java line 681:
> 
>> 679:         if (fmt instanceof NumberFormat) {
>> 680:             // Add any instances returned from the NumberFormat factory methods
>> 681:             if (fmt.equals(NumberFormat.getInstance(locale))) {
> 
> This looks like wack-a-mole code, no good design; likely to be hard to maintain.
> (I don't have a better idea at the moment though).

I agree, it was the existing design that caused for example, CompactNumberFormat to not automatically be supported by MessageFormat. A simple alternative would be storing the potential pre-defined NumberFormats in some data structure that we could just iterate through to feel less ?whack a mole? like, but that array would still suffer from the same maintenance issues. I?ll try to think of something better.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17663#discussion_r1480614155
PR Review Comment: https://git.openjdk.org/jdk/pull/17663#discussion_r1480614912
PR Review Comment: https://git.openjdk.org/jdk/pull/17663#discussion_r1480615799
PR Review Comment: https://git.openjdk.org/jdk/pull/17663#discussion_r1480617769

From mchung at openjdk.org  Tue Feb  6 22:51:53 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 6 Feb 2024 22:51:53 GMT
Subject: RFR: JDK-8322218: Better escaping of single and double quotes in
 annotation toString() results
In-Reply-To: 
References: 
Message-ID: <8PSpH8hbcCCKFrjf_ekb28VgCXzBB8CCW3i6PH8X-bQ=.49de5890-029c-42c1-8325-0058b59015ca@github.com>

On Thu, 1 Feb 2024 01:32:42 GMT, Joe Darcy  wrote:

> A double quote character doesn't need to be escaped when it is a char literal and single quote character doesn't need to be escaped when it is in a string. This change updates the toString() output of annotations to account for the different escaping requirements of strings and characters.
> 
> Corresponding issue filed for javac's compile-time annotations: JDK-8325078.

This looks good to me.

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

Marked as reviewed by mchung (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17664#pullrequestreview-1866468044

From rriggs at openjdk.org  Tue Feb  6 23:12:54 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 6 Feb 2024 23:12:54 GMT
Subject: RFR: JDK-8318761: MessageFormat pattern support for
 CompactNumberFormat, ListFormat, and DateTimeFormatter [v4]
In-Reply-To: 
References: 
 
 <87ZK-yMy308dxThFS9M0d_8CdgnCkthVwYaAzjMB8wU=.72750bb8-3750-411a-bd30-ebdd18e2a3f3@github.com>
 
Message-ID: <5Rq91Y67WeTIMojjm9q9m4yUUK4AFrQA83qDs-D2xDY=.692eff59-f49e-44d7-9f02-66ad0909642c@github.com>

On Tue, 6 Feb 2024 22:31:32 GMT, Justin Lu  wrote:

>> src/java.base/share/classes/java/text/MessageFormat.java line 681:
>> 
>>> 679:         if (fmt instanceof NumberFormat) {
>>> 680:             // Add any instances returned from the NumberFormat factory methods
>>> 681:             if (fmt.equals(NumberFormat.getInstance(locale))) {
>> 
>> This looks like wack-a-mole code, no good design; likely to be hard to maintain.
>> (I don't have a better idea at the moment though).
>
> I agree, it was the existing design that caused for example, CompactNumberFormat to not automatically be supported by MessageFormat. A simple alternative would be storing the potential pre-defined NumberFormats in some data structure that we could just iterate through to feel less ?whack a mole? like, but that array would still suffer from the same maintenance issues. I?ll try to think of something better.

One idea would be to delegate to a (package-private) method in the formatXXX class. 
That would localize to the respective class the details.
(An abstract protected method might be preferred, but its not worth creating extra public API surface area for this).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17663#discussion_r1480644067

From darcy at openjdk.org  Tue Feb  6 23:25:56 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 6 Feb 2024 23:25:56 GMT
Subject: Integrated: JDK-8322218: Better escaping of single and double quotes
 in annotation toString() results
In-Reply-To: 
References: 
Message-ID: 

On Thu, 1 Feb 2024 01:32:42 GMT, Joe Darcy  wrote:

> A double quote character doesn't need to be escaped when it is a char literal and single quote character doesn't need to be escaped when it is in a string. This change updates the toString() output of annotations to account for the different escaping requirements of strings and characters.
> 
> Corresponding issue filed for javac's compile-time annotations: JDK-8325078.

This pull request has now been integrated.

Changeset: 1797efd6
Author:    Joe Darcy 
URL:       https://git.openjdk.org/jdk/commit/1797efd68d4f30cc38a96fc5902999ee504e182f
Stats:     18 lines in 2 files changed: 6 ins; 0 del; 12 mod

8322218: Better escaping of single and double quotes in annotation toString() results

Reviewed-by: mchung

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

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

From naoto at openjdk.org  Wed Feb  7 00:50:58 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 7 Feb 2024 00:50:58 GMT
Subject: RFR: JDK-8318761: MessageFormat pattern support for
 CompactNumberFormat, ListFormat, and DateTimeFormatter [v4]
In-Reply-To: <5Rq91Y67WeTIMojjm9q9m4yUUK4AFrQA83qDs-D2xDY=.692eff59-f49e-44d7-9f02-66ad0909642c@github.com>
References: 
 
 <87ZK-yMy308dxThFS9M0d_8CdgnCkthVwYaAzjMB8wU=.72750bb8-3750-411a-bd30-ebdd18e2a3f3@github.com>
 
 <5Rq91Y67WeTIMojjm9q9m4yUUK4AFrQA83qDs-D2xDY=.692eff59-f49e-44d7-9f02-66ad0909642c@github.com>
Message-ID: <4yxhU7UF26hYk8-1J-oBnGI78Ff-qZ_CkKY-adLHfYI=.36f4a434-49e1-4f2b-a3e3-a131a8de3198@github.com>

On Tue, 6 Feb 2024 23:07:49 GMT, Roger Riggs  wrote:

>> I agree, it was the existing design that caused for example, CompactNumberFormat to not automatically be supported by MessageFormat. A simple alternative would be storing the potential pre-defined NumberFormats in some data structure that we could just iterate through to feel less ?whack a mole? like, but that array would still suffer from the same maintenance issues. I?ll try to think of something better.
>
> One idea would be to delegate to a (package-private) method in the formatXXX class. 
> That would localize to the respective class the details.
> (An abstract protected method might be preferred, but its not worth creating extra public API surface area for this).

Would it work with custom implementations for say NumberFormat via the SPI?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17663#discussion_r1480743201

From jpai at openjdk.org  Wed Feb  7 01:38:09 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 7 Feb 2024 01:38:09 GMT
Subject: RFR: 8325304: Several classes in java.util.jar and java.util.zip
 don't specify the behaviour for null arguments [v4]
In-Reply-To: <0mhiZJQ0aX8ZOjukPSrmwSNyqr8ix9ejT-BkjtbIjSU=.e9df8cd6-1267-4b3e-a2f8-ab215360f68a@github.com>
References: <0mhiZJQ0aX8ZOjukPSrmwSNyqr8ix9ejT-BkjtbIjSU=.e9df8cd6-1267-4b3e-a2f8-ab215360f68a@github.com>
Message-ID: 

> Can I please get a review of this doc-only change which updates the javadoc of several classes in `java.util.jar` and `java.util.zip` to specify their behaviour when `null` arguments are passed to the constructor or methods of those classes?
> 
> For these updated classes, I have individually checked that they indeed throw a `NullPointerException` when `null` is passed to their constructor or methods. The couple of places where `null` is accepted have been updated to mention that `null` is allowed.

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

  Alan's review - don't repeat NullPointerException specification within same class

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17728/files
  - new: https://git.openjdk.org/jdk/pull/17728/files/f92c5726..59d4df6b

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

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

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

From jpai at openjdk.org  Wed Feb  7 01:52:06 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 7 Feb 2024 01:52:06 GMT
Subject: RFR: 8325304: Several classes in java.util.jar and java.util.zip
 don't specify the behaviour for null arguments [v5]
In-Reply-To: <0mhiZJQ0aX8ZOjukPSrmwSNyqr8ix9ejT-BkjtbIjSU=.e9df8cd6-1267-4b3e-a2f8-ab215360f68a@github.com>
References: <0mhiZJQ0aX8ZOjukPSrmwSNyqr8ix9ejT-BkjtbIjSU=.e9df8cd6-1267-4b3e-a2f8-ab215360f68a@github.com>
Message-ID: 

> Can I please get a review of this doc-only change which updates the javadoc of several classes in `java.util.jar` and `java.util.zip` to specify their behaviour when `null` arguments are passed to the constructor or methods of those classes?
> 
> For these updated classes, I have individually checked that they indeed throw a `NullPointerException` when `null` is passed to their constructor or methods. The couple of places where `null` is accepted have been updated to mention that `null` is allowed.

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

  make 
 usage consistent with other similar usages in the file

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17728/files
  - new: https://git.openjdk.org/jdk/pull/17728/files/59d4df6b..93bccb00

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

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

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

From jpai at openjdk.org  Wed Feb  7 01:57:53 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 7 Feb 2024 01:57:53 GMT
Subject: RFR: 8325304: Several classes in java.util.jar and java.util.zip
 don't specify the behaviour for null arguments [v5]
In-Reply-To: 
References: <0mhiZJQ0aX8ZOjukPSrmwSNyqr8ix9ejT-BkjtbIjSU=.e9df8cd6-1267-4b3e-a2f8-ab215360f68a@github.com>
 
Message-ID: 

On Wed, 7 Feb 2024 01:52:06 GMT, Jaikiran Pai  wrote:

>> Can I please get a review of this doc-only change which updates the javadoc of several classes in `java.util.jar` and `java.util.zip` to specify their behaviour when `null` arguments are passed to the constructor or methods of those classes?
>> 
>> For these updated classes, I have individually checked that they indeed throw a `NullPointerException` when `null` is passed to their constructor or methods. The couple of places where `null` is accepted have been updated to mention that `null` is allowed.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   make 
 usage consistent with other similar usages in the file

Hello Alan,

> The changes means that NPE is specified in both the class description and method descriptions in some cases, e.g. JarInputStream. I assume you meant to remove the NPE from methods where you've added a statement in the class description.

I wasn't sure if I should remove them from the pre-existing method javadocs, so I had left them without changes. I have now updated the PR to remove them from the method level javadoc where we have now added the class level specification.

> 
> Minor nit is some of the usages of `
` in the change are inconsistent with the usages close by, you probably want to keep them consistent if you can.

Updated the PR to address this as well. I have updated it to match whatever the existing style (if any) was in that particular file.

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

PR Comment: https://git.openjdk.org/jdk/pull/17728#issuecomment-1931109866

From liach at openjdk.org  Wed Feb  7 07:56:58 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 7 Feb 2024 07:56:58 GMT
Subject: Integrated: 8319463: ClassSignature should have superclass and
 superinterfaces as ClassTypeSig
In-Reply-To: <2MCObzp9MbPwugbIm1pP80wU0OXlmrQMr7CRsgxah7s=.78d4b9a3-9f19-4bcf-ad03-58fb6faa64fb@github.com>
References: <2MCObzp9MbPwugbIm1pP80wU0OXlmrQMr7CRsgxah7s=.78d4b9a3-9f19-4bcf-ad03-58fb6faa64fb@github.com>
Message-ID: 

On Mon, 6 Nov 2023 06:41:22 GMT, Chen Liang  wrote:

> 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.

This pull request has now been integrated.

Changeset: 3bffe223
Author:    Chen Liang 
Committer: Adam Sotona 
URL:       https://git.openjdk.org/jdk/commit/3bffe223a34e8077cb1ce11f64fc34fcb0751ac7
Stats:     203 lines in 6 files changed: 122 ins; 30 del; 51 mod

8319463: ClassSignature should have superclass and superinterfaces as ClassTypeSig

Reviewed-by: asotona

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

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

From duke at openjdk.org  Wed Feb  7 08:50:09 2024
From: duke at openjdk.org (Johny Jose)
Date: Wed, 7 Feb 2024 08:50:09 GMT
Subject: RFR: 8325150: (tz) Update Timezone Data to 2024a
Message-ID: 

Timezone data 2024a changes

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

Commit messages:
 - 8325150: (tz) Update Timezone Data to 2024a

Changes: https://git.openjdk.org/jdk/pull/17743/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17743&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8325150
  Stats: 195 lines in 10 files changed: 96 ins; 10 del; 89 mod
  Patch: https://git.openjdk.org/jdk/pull/17743.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17743/head:pull/17743

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

From shade at openjdk.org  Wed Feb  7 09:15:58 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 7 Feb 2024 09:15:58 GMT
Subject: [jdk22] RFR: 8324858: [vectorapi] Bounds checking issues when
 accessing memory segments
In-Reply-To: 
References: 
Message-ID: 

On Tue, 6 Feb 2024 16:50:10 GMT, Paul Sandoz  wrote:

> This pull request contains a backport of commit [1ae85138](https://github.com/openjdk/jdk/commit/1ae851387f881263ccc6aeace5afdd0f49d41d33) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Paul Sandoz on 2 Feb 2024 and was reviewed by Maurizio Cimadamore and Jatin Bhateja.

Looks fine.

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk22/pull/109#pullrequestreview-1867277615

From coffeys at openjdk.org  Wed Feb  7 09:46:54 2024
From: coffeys at openjdk.org (Sean Coffey)
Date: Wed, 7 Feb 2024 09:46:54 GMT
Subject: RFR: 8325150: (tz) Update Timezone Data to 2024a
In-Reply-To: 
References: 
Message-ID: 

On Wed, 7 Feb 2024 08:45:40 GMT, Johny Jose  wrote:

> Timezone data 2024a changes

LGTM

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

Marked as reviewed by coffeys (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17743#pullrequestreview-1867359537

From alanb at openjdk.org  Wed Feb  7 09:47:54 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 7 Feb 2024 09:47:54 GMT
Subject: RFR: 8325304: Several classes in java.util.jar and java.util.zip
 don't specify the behaviour for null arguments [v5]
In-Reply-To: 
References: <0mhiZJQ0aX8ZOjukPSrmwSNyqr8ix9ejT-BkjtbIjSU=.e9df8cd6-1267-4b3e-a2f8-ab215360f68a@github.com>
 
Message-ID: 

On Wed, 7 Feb 2024 01:52:06 GMT, Jaikiran Pai  wrote:

>> Can I please get a review of this doc-only change which updates the javadoc of several classes in `java.util.jar` and `java.util.zip` to specify their behaviour when `null` arguments are passed to the constructor or methods of those classes?
>> 
>> For these updated classes, I have individually checked that they indeed throw a `NullPointerException` when `null` is passed to their constructor or methods. The couple of places where `null` is accepted have been updated to mention that `null` is allowed.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   make 
 usage consistent with other similar usages in the file

This mostly looks okay, just a few comments.

src/java.base/share/classes/java/util/zip/CheckedOutputStream.java line 48:

> 46:      * value to either {@code out} or {@code cksum} will cause
> 47:      * a {@link NullPointerException} to be thrown from the
> 48:      * {@code write} methods of this {@code CheckedOutputStream}.

What is the reason for specifying the NPE in the method description rather than a throws?

src/java.base/share/classes/java/util/zip/DeflaterInputStream.java line 80:

> 78:         // "in" being null isn't allowed. we use a null check for "in"
> 79:         // merely to avoid an unnecessary instance creation of the Deflater
> 80:         // for such erroneous cases.

I see this same comment has been added in 3 places but it's not easy to read and I don't think is needed.

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

PR Review: https://git.openjdk.org/jdk/pull/17728#pullrequestreview-1867349428
PR Review Comment: https://git.openjdk.org/jdk/pull/17728#discussion_r1481197701
PR Review Comment: https://git.openjdk.org/jdk/pull/17728#discussion_r1481189478

From jpai at openjdk.org  Wed Feb  7 10:05:08 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 7 Feb 2024 10:05:08 GMT
Subject: RFR: 8325304: Several classes in java.util.jar and java.util.zip
 don't specify the behaviour for null arguments [v6]
In-Reply-To: <0mhiZJQ0aX8ZOjukPSrmwSNyqr8ix9ejT-BkjtbIjSU=.e9df8cd6-1267-4b3e-a2f8-ab215360f68a@github.com>
References: <0mhiZJQ0aX8ZOjukPSrmwSNyqr8ix9ejT-BkjtbIjSU=.e9df8cd6-1267-4b3e-a2f8-ab215360f68a@github.com>
Message-ID: 

> Can I please get a review of this doc-only change which updates the javadoc of several classes in `java.util.jar` and `java.util.zip` to specify their behaviour when `null` arguments are passed to the constructor or methods of those classes?
> 
> For these updated classes, I have individually checked that they indeed throw a `NullPointerException` when `null` is passed to their constructor or methods. The couple of places where `null` is accepted have been updated to mention that `null` is allowed.

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

  no need for code comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17728/files
  - new: https://git.openjdk.org/jdk/pull/17728/files/93bccb00..6a9a59c8

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

  Stats: 22 lines in 7 files changed: 0 ins; 21 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/17728.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17728/head:pull/17728

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

From jpai at openjdk.org  Wed Feb  7 10:10:54 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 7 Feb 2024 10:10:54 GMT
Subject: RFR: 8325304: Several classes in java.util.jar and java.util.zip
 don't specify the behaviour for null arguments [v5]
In-Reply-To: 
References: <0mhiZJQ0aX8ZOjukPSrmwSNyqr8ix9ejT-BkjtbIjSU=.e9df8cd6-1267-4b3e-a2f8-ab215360f68a@github.com>
 
 
Message-ID: 

On Wed, 7 Feb 2024 09:41:40 GMT, Alan Bateman  wrote:

>> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   make 
 usage consistent with other similar usages in the file
>
> src/java.base/share/classes/java/util/zip/DeflaterInputStream.java line 80:
> 
>> 78:         // "in" being null isn't allowed. we use a null check for "in"
>> 79:         // merely to avoid an unnecessary instance creation of the Deflater
>> 80:         // for such erroneous cases.
> 
> I see this same comment has been added in 3 places but it's not easy to read and I don't think is needed.

I've now updated the PR to remove this code comment.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17728#discussion_r1481231121

From jpai at openjdk.org  Wed Feb  7 10:16:53 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 7 Feb 2024 10:16:53 GMT
Subject: RFR: 8325304: Several classes in java.util.jar and java.util.zip
 don't specify the behaviour for null arguments [v5]
In-Reply-To: 
References: <0mhiZJQ0aX8ZOjukPSrmwSNyqr8ix9ejT-BkjtbIjSU=.e9df8cd6-1267-4b3e-a2f8-ab215360f68a@github.com>
 
 
Message-ID: 

On Wed, 7 Feb 2024 09:44:25 GMT, Alan Bateman  wrote:

>> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   make 
 usage consistent with other similar usages in the file
>
> src/java.base/share/classes/java/util/zip/CheckedOutputStream.java line 48:
> 
>> 46:      * value to either {@code out} or {@code cksum} will cause
>> 47:      * a {@link NullPointerException} to be thrown from the
>> 48:      * {@code write} methods of this {@code CheckedOutputStream}.
> 
> What is the reason for specifying the NPE in the method description rather than a throws?

These 2 classes, the `CheckedInputStream` and the `CheckedOutputStream` are slightly different from the rest of the classes in this changeset. This javadoc here is for the constructor of the `CheckedInputStream`. The implementation of the constructor just blindly assigns the passed argument to an internal member field and doesn't do any null check on the passed arguments (any subsequent usage of these instance fields within that class, then leads to a NullPointerException). So the constructor isn't throwing any `NullPointerException` here and thus adding a `@throws` here would be incorrect. In theory, we could just change the implementation of this constructor to throw a `NullPointerException` if either of these arguments were null, but that might mean a potential breakage of some weird usage of the CheckedInputStream. So I decided to add the `NullPointerException` detail to the constructor description.

Do you think we should instead do something like this for this class and the `CheckedOutputStream` class:


diff --git a/src/java.base/share/classes/java/util/zip/CheckedInputStream.java b/src/java.base/share/classes/java/util/zip/CheckedInputStream.java
index 10f72b416d1..76cba26986e 100644
--- a/src/java.base/share/classes/java/util/zip/CheckedInputStream.java
+++ b/src/java.base/share/classes/java/util/zip/CheckedInputStream.java
@@ -41,10 +41,7 @@ public class CheckedInputStream extends FilterInputStream {
     private final Checksum cksum;
 
     /**
-     * Creates an input stream using the specified Checksum. A null
-     * value to either {@code in} or {@code cksum} will cause
-     * a {@link NullPointerException} to be thrown from the
-     * {@code read} methods of this {@code CheckedInputStream}.
+     * Creates an input stream using the specified Checksum.
      * @param in the input stream
      * @param cksum the Checksum
      */
@@ -57,6 +54,8 @@ public CheckedInputStream(InputStream in, Checksum cksum) {
      * Reads a byte. Will block if no input is available.
      * @return the byte read, or -1 if the end of the stream is reached.
      * @throws    IOException if an I/O error has occurred
+     * @throws    NullPointerException if this {@code CheckedInputStream} was
+     *            constructed with a {@code null} value for {@code in} or {@code cksum}
      */
     public int read() throws IOException {
         int b = in.read();
@@ -75,7 +74,9 @@ public int read() throws IOException {
      * @param len the maximum number of bytes read
      * @return    the actual number of bytes read, or -1 if the end
      *            of the stream is reached.
-     * @throws     NullPointerException If {@code buf} is {@code null}.
+     * @throws     NullPointerException If {@code buf} is {@code null} or
+     *             if this {@code CheckedInputStream} was
+     *             constructed with a {@code null} value for {@code in} or {@code cksum}.
      * @throws     IndexOutOfBoundsException If {@code off} is negative,
      * {@code len} is negative, or {@code len} is greater than
      * {@code buf.length - off}

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17728#discussion_r1481237216

From alanb at openjdk.org  Wed Feb  7 10:50:53 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 7 Feb 2024 10:50:53 GMT
Subject: RFR: 8325304: Several classes in java.util.jar and java.util.zip
 don't specify the behaviour for null arguments [v5]
In-Reply-To: 
References: <0mhiZJQ0aX8ZOjukPSrmwSNyqr8ix9ejT-BkjtbIjSU=.e9df8cd6-1267-4b3e-a2f8-ab215360f68a@github.com>
 
 
 
Message-ID: 

On Wed, 7 Feb 2024 10:13:00 GMT, Jaikiran Pai  wrote:

> These 2 classes, the `CheckedInputStream` and the `CheckedOutputStream` are slightly different from the rest of the classes in this changeset. This javadoc here is for the constructor of the `CheckedInputStream`. The implementation of the constructor just blindly assigns the passed argument to an internal member field and doesn't do any null check on the passed arguments (any subsequent usage of these instance fields within that class, then leads to a NullPointerException). 

The superclasses FilterInputStream and FilterOutputStream have a a protected field for the underlying stream so it's possible for a subclass to set the underlying stream lazily. I can't recall seeing code in the wild availing of that but it is possible.

CheckedInputStream and CheckedOutputStream date from JDK 1.1 and it's not clear what the intention was. My guess is that it was an oversight/bug to not check for null when constructing directly. Fixing this will help catch buggy code but it does mean a behavior change. I think we have to keep existing behavior for the subclassing case because it is possible for the subclass to set the stream lazily.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17728#discussion_r1481280976

From jpai at openjdk.org  Wed Feb  7 11:16:58 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 7 Feb 2024 11:16:58 GMT
Subject: RFR: 8325304: Several classes in java.util.jar and java.util.zip
 don't specify the behaviour for null arguments [v5]
In-Reply-To: 
References: <0mhiZJQ0aX8ZOjukPSrmwSNyqr8ix9ejT-BkjtbIjSU=.e9df8cd6-1267-4b3e-a2f8-ab215360f68a@github.com>
 
 
 
 
Message-ID: 

On Wed, 7 Feb 2024 10:47:31 GMT, Alan Bateman  wrote:

>> These 2 classes, the `CheckedInputStream` and the `CheckedOutputStream` are slightly different from the rest of the classes in this changeset. This javadoc here is for the constructor of the `CheckedInputStream`. The implementation of the constructor just blindly assigns the passed argument to an internal member field and doesn't do any null check on the passed arguments (any subsequent usage of these instance fields within that class, then leads to a NullPointerException). So the constructor isn't throwing any `NullPointerException` here and thus adding a `@throws` here would be incorrect. In theory, we could just change the implementation of this constructor to throw a `NullPointerException` if either of these arguments were null, but that might mean a potential breakage of some weird usage of the CheckedInputStream. So I decided to add the `NullPointerException` detail to the constructor description.
>> 
>> Do you think we should instead do something like this for this class and the `CheckedOutputStream` class:
>> 
>> 
>> diff --git a/src/java.base/share/classes/java/util/zip/CheckedInputStream.java b/src/java.base/share/classes/java/util/zip/CheckedInputStream.java
>> index 10f72b416d1..76cba26986e 100644
>> --- a/src/java.base/share/classes/java/util/zip/CheckedInputStream.java
>> +++ b/src/java.base/share/classes/java/util/zip/CheckedInputStream.java
>> @@ -41,10 +41,7 @@ public class CheckedInputStream extends FilterInputStream {
>>      private final Checksum cksum;
>>  
>>      /**
>> -     * Creates an input stream using the specified Checksum. A null
>> -     * value to either {@code in} or {@code cksum} will cause
>> -     * a {@link NullPointerException} to be thrown from the
>> -     * {@code read} methods of this {@code CheckedInputStream}.
>> +     * Creates an input stream using the specified Checksum.
>>       * @param in the input stream
>>       * @param cksum the Checksum
>>       */
>> @@ -57,6 +54,8 @@ public CheckedInputStream(InputStream in, Checksum cksum) {
>>       * Reads a byte. Will block if no input is available.
>>       * @return the byte read, or -1 if the end of the stream is reached.
>>       * @throws    IOException if an I/O error has occurred
>> +     * @throws    NullPointerException if this {@code CheckedInputStream} was
>> +     *            constructed with a {@code null} value for {@code in} or {@code cksum}
>>       */
>>      public int read() throws IOException {
>>          int b = in.read();
>> @@ -75,7 +74,9 @@ public int read() thro...
>
>> These 2 classes, the `CheckedInputStream` and the `CheckedOutputStream` are slightly different from the rest of the classes in this changeset. This javadoc here is for the constructor of the `CheckedInputStream`. The implementation of the constructor just blindly assigns the passed argument to an internal member field and doesn't do any null check on the passed arguments (any subsequent usage of these instance fields within that class, then leads to a NullPointerException). 
> 
> The superclasses FilterInputStream and FilterOutputStream have a a protected field for the underlying stream so it's possible for a subclass to set the underlying stream lazily. I can't recall seeing code in the wild availing of that but it is possible.
> 
> CheckedInputStream and CheckedOutputStream date from JDK 1.1 and it's not clear what the intention was. My guess is that it was an oversight/bug to not check for null when constructing directly. Fixing this will help catch buggy code but it does mean a behavior change. I think we have to keep existing behavior for the subclassing case because it is possible for the subclass to set the stream lazily.

Given that subclasses could set these fields lazily (however remote the case might be), do you think we should then not specify the `NullPointerException` for the read methods on these 2 classes. In which case I can exclude these 2 classes from this PR.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17728#discussion_r1481314236

From alanb at openjdk.org  Wed Feb  7 11:33:53 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 7 Feb 2024 11:33:53 GMT
Subject: RFR: 8325304: Several classes in java.util.jar and java.util.zip
 don't specify the behaviour for null arguments [v5]
In-Reply-To: 
References: <0mhiZJQ0aX8ZOjukPSrmwSNyqr8ix9ejT-BkjtbIjSU=.e9df8cd6-1267-4b3e-a2f8-ab215360f68a@github.com>
 
 
 
 
 
Message-ID: 

On Wed, 7 Feb 2024 11:14:06 GMT, Jaikiran Pai  wrote:

>>> These 2 classes, the `CheckedInputStream` and the `CheckedOutputStream` are slightly different from the rest of the classes in this changeset. This javadoc here is for the constructor of the `CheckedInputStream`. The implementation of the constructor just blindly assigns the passed argument to an internal member field and doesn't do any null check on the passed arguments (any subsequent usage of these instance fields within that class, then leads to a NullPointerException). 
>> 
>> The superclasses FilterInputStream and FilterOutputStream have a a protected field for the underlying stream so it's possible for a subclass to set the underlying stream lazily. I can't recall seeing code in the wild availing of that but it is possible.
>> 
>> CheckedInputStream and CheckedOutputStream date from JDK 1.1 and it's not clear what the intention was. My guess is that it was an oversight/bug to not check for null when constructing directly. Fixing this will help catch buggy code but it does mean a behavior change. I think we have to keep existing behavior for the subclassing case because it is possible for the subclass to set the stream lazily.
>
> Given that subclasses could set these fields lazily (however remote the case might be), do you think we should then not specify the `NullPointerException` for the read methods on these 2 classes. In which case I can exclude these 2 classes from this PR.

It would be simpler to drop CheckedInputStream and CheckedOutputStream and deal with them separately. It's unfortunate that this current effort has run into this but that comes with touching some of the JDK 1.0/1.1 era classes.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17728#discussion_r1481333286

From jpai at openjdk.org  Wed Feb  7 12:37:23 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 7 Feb 2024 12:37:23 GMT
Subject: RFR: 8325304: Several classes in java.util.jar and java.util.zip
 don't specify the behaviour for null arguments [v7]
In-Reply-To: <0mhiZJQ0aX8ZOjukPSrmwSNyqr8ix9ejT-BkjtbIjSU=.e9df8cd6-1267-4b3e-a2f8-ab215360f68a@github.com>
References: <0mhiZJQ0aX8ZOjukPSrmwSNyqr8ix9ejT-BkjtbIjSU=.e9df8cd6-1267-4b3e-a2f8-ab215360f68a@github.com>
Message-ID: 

> Can I please get a review of this doc-only change which updates the javadoc of several classes in `java.util.jar` and `java.util.zip` to specify their behaviour when `null` arguments are passed to the constructor or methods of those classes?
> 
> For these updated classes, I have individually checked that they indeed throw a `NullPointerException` when `null` is passed to their constructor or methods. The couple of places where `null` is accepted have been updated to mention that `null` is allowed.

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

  undo changes to CheckedInputStream and CheckedOutputStream

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17728/files
  - new: https://git.openjdk.org/jdk/pull/17728/files/6a9a59c8..251e7c85

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

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

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

From jpai at openjdk.org  Wed Feb  7 12:40:54 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 7 Feb 2024 12:40:54 GMT
Subject: RFR: 8325304: Several classes in java.util.jar and java.util.zip
 don't specify the behaviour for null arguments [v5]
In-Reply-To: 
References: <0mhiZJQ0aX8ZOjukPSrmwSNyqr8ix9ejT-BkjtbIjSU=.e9df8cd6-1267-4b3e-a2f8-ab215360f68a@github.com>
 
 
 
 
 
 
Message-ID: 

On Wed, 7 Feb 2024 11:31:05 GMT, Alan Bateman  wrote:

>> Given that subclasses could set these fields lazily (however remote the case might be), do you think we should then not specify the `NullPointerException` for the read methods on these 2 classes. In which case I can exclude these 2 classes from this PR.
>
> It would be simpler to drop CheckedInputStream and CheckedOutputStream and deal with them separately. It's unfortunate that this current effort has run into this but that comes with touching some of the JDK 1.0/1.1 era classes.

Done. I've updated the PR to undo the changes that were proposed for `CheckedOutputStream` and `CheckedInputStream`. I've also updated the CSR with the latest specification diff from this PR.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17728#discussion_r1481410044

From alanb at openjdk.org  Wed Feb  7 12:55:57 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 7 Feb 2024 12:55:57 GMT
Subject: RFR: 8325304: Several classes in java.util.jar and java.util.zip
 don't specify the behaviour for null arguments [v7]
In-Reply-To: 
References: <0mhiZJQ0aX8ZOjukPSrmwSNyqr8ix9ejT-BkjtbIjSU=.e9df8cd6-1267-4b3e-a2f8-ab215360f68a@github.com>
 
Message-ID: 

On Wed, 7 Feb 2024 12:37:23 GMT, Jaikiran Pai  wrote:

>> Can I please get a review of this doc-only change which updates the javadoc of several classes in `java.util.jar` and `java.util.zip` to specify their behaviour when `null` arguments are passed to the constructor or methods of those classes?
>> 
>> For these updated classes, I have individually checked that they indeed throw a `NullPointerException` when `null` is passed to their constructor or methods. The couple of places where `null` is accepted have been updated to mention that `null` is allowed.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   undo changes to CheckedInputStream and CheckedOutputStream

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17728#pullrequestreview-1867740148

From lancea at openjdk.org  Wed Feb  7 13:26:55 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 7 Feb 2024 13:26:55 GMT
Subject: RFR: 8325304: Several classes in java.util.jar and java.util.zip
 don't specify the behaviour for null arguments [v7]
In-Reply-To: 
References: <0mhiZJQ0aX8ZOjukPSrmwSNyqr8ix9ejT-BkjtbIjSU=.e9df8cd6-1267-4b3e-a2f8-ab215360f68a@github.com>
 
Message-ID: 

On Wed, 7 Feb 2024 12:37:23 GMT, Jaikiran Pai  wrote:

>> Can I please get a review of this doc-only change which updates the javadoc of several classes in `java.util.jar` and `java.util.zip` to specify their behaviour when `null` arguments are passed to the constructor or methods of those classes?
>> 
>> For these updated classes, I have individually checked that they indeed throw a `NullPointerException` when `null` is passed to their constructor or methods. The couple of places where `null` is accepted have been updated to mention that `null` is allowed.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   undo changes to CheckedInputStream and CheckedOutputStream

Marked as reviewed by lancea (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17728#pullrequestreview-1867805176

From mli at openjdk.org  Wed Feb  7 14:43:06 2024
From: mli at openjdk.org (Hamlin Li)
Date: Wed, 7 Feb 2024 14:43:06 GMT
Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations
 with SLEEF [v9]
In-Reply-To: 
References: 
 
Message-ID: <1BPmeP4mK5G40pZ8X6Hu64DXMgQVvBk_CayhmP9Dj5I=.fafa29a2-3ad6-4ac0-9d89-244c739e4598@github.com>

On Thu, 7 Dec 2023 09:30:01 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:
> 
>   Fix potential attribute issue

I could also take a look at it by the end of this month if no one are going to do it.

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

PR Comment: https://git.openjdk.org/jdk/pull/16234#issuecomment-1932188622

From rriggs at openjdk.org  Wed Feb  7 15:20:58 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 7 Feb 2024 15:20:58 GMT
Subject: RFR: JDK-8318761: MessageFormat pattern support for
 CompactNumberFormat, ListFormat, and DateTimeFormatter [v4]
In-Reply-To: <4yxhU7UF26hYk8-1J-oBnGI78Ff-qZ_CkKY-adLHfYI=.36f4a434-49e1-4f2b-a3e3-a131a8de3198@github.com>
References: 
 
 <87ZK-yMy308dxThFS9M0d_8CdgnCkthVwYaAzjMB8wU=.72750bb8-3750-411a-bd30-ebdd18e2a3f3@github.com>
 
 <5Rq91Y67WeTIMojjm9q9m4yUUK4AFrQA83qDs-D2xDY=.692eff59-f49e-44d7-9f02-66ad0909642c@github.com>
 <4yxhU7UF26hYk8-1J-oBnGI78Ff-qZ_CkKY-adLHfYI=.36f4a434-49e1-4f2b-a3e3-a131a8de3198@github.com>
Message-ID: 

On Wed, 7 Feb 2024 00:48:30 GMT, Naoto Sato  wrote:

>> One idea would be to delegate to a (package-private) method in the formatXXX class. 
>> That would localize to the respective class the details.
>> (An abstract protected method might be preferred, but its not worth creating extra public API surface area for this).
>
> Would it work with custom implementations for say NumberFormat via the SPI?

Just moving the if...then... else code to a package-private static method in the respective XXFormat class would work the same.
I had not thought of an addition to the spi to delegate to/through the provider.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17663#discussion_r1481637904

From ihse at openjdk.org  Wed Feb  7 15:53:59 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 7 Feb 2024 15:53:59 GMT
Subject: RFR: 8325109: Sort method modifiers in canonical order
In-Reply-To: 
References: 
Message-ID: 

On Thu, 1 Feb 2024 11:57:04 GMT, Magnus Ihse Bursie  wrote:

> This is a follow-up on [JDK-8324053](https://bugs.openjdk.org/browse/JDK-8324053). I have run the bin/blessed-modifier-order.sh on the entire code base, and manually checked the result. I have reverted all but these trivial and uncontroversial changes.
> 
> Almost all of these are about moving `static` to its proper position; a few do not involve `static` but instead puts `final` or `abstract` in the correct place.
> 
> I have deliberately stayed away from `default` in this PR, since they should probably get a more thorough treatment, see https://github.com/openjdk/jdk/pull/17468#pullrequestreview-1829238473.

Just to confirm publicly, there is no need for any special handling of `java.util.concurrent` any longer; the JDK repo is the single source of truth nowadays.

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

PR Comment: https://git.openjdk.org/jdk/pull/17670#issuecomment-1932335281

From ihse at openjdk.org  Wed Feb  7 15:53:59 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 7 Feb 2024 15:53:59 GMT
Subject: Integrated: 8325109: Sort method modifiers in canonical order
In-Reply-To: 
References: 
Message-ID: 

On Thu, 1 Feb 2024 11:57:04 GMT, Magnus Ihse Bursie  wrote:

> This is a follow-up on [JDK-8324053](https://bugs.openjdk.org/browse/JDK-8324053). I have run the bin/blessed-modifier-order.sh on the entire code base, and manually checked the result. I have reverted all but these trivial and uncontroversial changes.
> 
> Almost all of these are about moving `static` to its proper position; a few do not involve `static` but instead puts `final` or `abstract` in the correct place.
> 
> I have deliberately stayed away from `default` in this PR, since they should probably get a more thorough treatment, see https://github.com/openjdk/jdk/pull/17468#pullrequestreview-1829238473.

This pull request has now been integrated.

Changeset: 18e24d06
Author:    Magnus Ihse Bursie 
URL:       https://git.openjdk.org/jdk/commit/18e24d0619ffef7c6dbfc419105faba9f7ba1874
Stats:     61 lines in 39 files changed: 0 ins; 0 del; 61 mod

8325109: Sort method modifiers in canonical order

Reviewed-by: aivanov, rriggs, darcy, prappo

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

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

From jkern at openjdk.org  Wed Feb  7 15:56:00 2024
From: jkern at openjdk.org (Joachim Kern)
Date: Wed, 7 Feb 2024 15:56:00 GMT
Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v9]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 6 Feb 2024 08:18:14 GMT, Magnus Ihse Bursie  wrote:

>> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK native libraries.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Also fix fstatvfs on AIX

My apologies the additional defines 
`#define DIR DIR64`
`#define dirent dirent64`
`#define opendir opendir64`
`#define readdir readdir64`
`#define closedir closedir64`
are not necessary. Indeed they do not react on _LARGE_FILES, but the DIR struct and the functions are automatically 64 when compiling in 64bit mode (-m64) as we do.

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

PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1932343048

From naoto at openjdk.org  Wed Feb  7 18:07:54 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 7 Feb 2024 18:07:54 GMT
Subject: RFR: 8325150: (tz) Update Timezone Data to 2024a
In-Reply-To: 
References: 
Message-ID: 

On Wed, 7 Feb 2024 08:45:40 GMT, Johny Jose  wrote:

> Timezone data 2024a changes

LGTM

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17743#pullrequestreview-1868470439

From jbhateja at openjdk.org  Wed Feb  7 18:38:29 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 7 Feb 2024 18:38:29 GMT
Subject: RFR: 8318650: Optimized subword gather for x86 targets. [v13]
In-Reply-To: 
References: 
Message-ID: <-jaGezbfx9ZylmA6EBQY2TxqjfIHNhT8TXI6_KCL11Y=.d48ef20a-21c1-4486-ada6-4e1acf86a9ea@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 using 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.5-10x 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.
> 
> 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/8d39f08a..2e3a6143

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

  Stats: 71 lines in 4 files changed: 20 ins; 7 del; 44 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  Wed Feb  7 18:57:55 2024
From: iris at openjdk.org (Iris Clark)
Date: Wed, 7 Feb 2024 18:57:55 GMT
Subject: RFR: 8325150: (tz) Update Timezone Data to 2024a
In-Reply-To: 
References: 
Message-ID: <0zAJvug_L46Nf-9uDOt_GWjWZh-_FffLHDmQxUmSK9o=.0f574fe4-99ac-47ef-b37c-9586feb6f776@github.com>

On Wed, 7 Feb 2024 08:45:40 GMT, Johny Jose  wrote:

> Timezone data 2024a changes

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17743#pullrequestreview-1868554271

From weijun at openjdk.org  Wed Feb  7 19:08:54 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 7 Feb 2024 19:08:54 GMT
Subject: RFR: JDK-8325189: Enable this-escape javac warning in java.base
In-Reply-To: 
References: 
Message-ID: <25rXR-RgzW2Qib1E4ngpo8oG3E6pGJYr42QEWLi1fJw=.75e7164c-04dd-4d73-a44d-85b3a9c50406@github.com>

On Fri, 2 Feb 2024 23:36:41 GMT, Joe Darcy  wrote:

> After the "this-escape" lint warning was added to javac (JDK-8015831), the base module was not updated to be able to compile with this warning enabled. This PR makes the necessary changes to allow the base module to build with the warning enabled.

Security changes look fine. Although I don't know how to remove those annotations later. A lot of compatibility impact.

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

Marked as reviewed by weijun (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17692#pullrequestreview-1868572210

From darcy at openjdk.org  Wed Feb  7 19:28:11 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 7 Feb 2024 19:28:11 GMT
Subject: RFR: JDK-8325189: Enable this-escape javac warning in java.base
 [v2]
In-Reply-To: 
References: 
Message-ID: 

> After the "this-escape" lint warning was added to javac (JDK-8015831), the base module was not updated to be able to compile with this warning enabled. This PR makes the necessary changes to allow the base module to build with the warning enabled.

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 two additional commits since the last revision:

 - Merge branch 'master' into JDK-8325189
 - JDK-8325189: Enable this-escape javac warning in java.base

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17692/files
  - new: https://git.openjdk.org/jdk/pull/17692/files/8a160a7c..e1d56388

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

  Stats: 5575 lines in 160 files changed: 3404 ins; 1290 del; 881 mod
  Patch: https://git.openjdk.org/jdk/pull/17692.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17692/head:pull/17692

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

From psandoz at openjdk.org  Wed Feb  7 20:02:01 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Wed, 7 Feb 2024 20:02:01 GMT
Subject: [jdk22] RFR: 8324858: [vectorapi] Bounds checking issues when
 accessing memory segments
In-Reply-To: 
References: 
 
Message-ID: <_5T9EFnUsh9fBoNRE1GTGkRUMCGF6WTIjwYYwTO5-OI=.49a6df9c-1dcc-4f3d-9c22-97531532a0da@github.com>

On Wed, 7 Feb 2024 09:13:33 GMT, Aleksey Shipilev  wrote:

> Looks fine.

Thanks!

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

PR Comment: https://git.openjdk.org/jdk22/pull/109#issuecomment-1932769043

From psandoz at openjdk.org  Wed Feb  7 20:02:02 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Wed, 7 Feb 2024 20:02:02 GMT
Subject: [jdk22] Integrated: 8324858: [vectorapi] Bounds checking issues when
 accessing memory segments
In-Reply-To: 
References: 
Message-ID: 

On Tue, 6 Feb 2024 16:50:10 GMT, Paul Sandoz  wrote:

> This pull request contains a backport of commit [1ae85138](https://github.com/openjdk/jdk/commit/1ae851387f881263ccc6aeace5afdd0f49d41d33) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Paul Sandoz on 2 Feb 2024 and was reviewed by Maurizio Cimadamore and Jatin Bhateja.

This pull request has now been integrated.

Changeset: 9cc260d3
Author:    Paul Sandoz 
URL:       https://git.openjdk.org/jdk22/commit/9cc260d3a10a4d31a2ee22be1715884e175f9679
Stats:     248 lines in 39 files changed: 132 ins; 8 del; 108 mod

8324858: [vectorapi] Bounds checking issues when accessing memory segments

Reviewed-by: shade
Backport-of: 1ae851387f881263ccc6aeace5afdd0f49d41d33

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

PR: https://git.openjdk.org/jdk22/pull/109

From darcy at openjdk.org  Wed Feb  7 20:08:18 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 7 Feb 2024 20:08:18 GMT
Subject: RFR: JDK-8325189: Enable this-escape javac warning in java.base
 [v3]
In-Reply-To: 
References: 
Message-ID: 

> After the "this-escape" lint warning was added to javac (JDK-8015831), the base module was not updated to be able to compile with this warning enabled. This PR makes the necessary changes to allow the base module to build with the warning enabled.

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

 - Merge branch 'master' into JDK-8325189
 - Merge branch 'master' into JDK-8325189
 - JDK-8325189: Enable this-escape javac warning in java.base

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17692/files
  - new: https://git.openjdk.org/jdk/pull/17692/files/e1d56388..bc6cdfc8

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

  Stats: 1057 lines in 91 files changed: 598 ins; 167 del; 292 mod
  Patch: https://git.openjdk.org/jdk/pull/17692.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17692/head:pull/17692

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

From darcy at openjdk.org  Wed Feb  7 20:08:19 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 7 Feb 2024 20:08:19 GMT
Subject: RFR: JDK-8325189: Enable this-escape javac warning in java.base
 [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 7 Feb 2024 19:28:11 GMT, Joe Darcy  wrote:

>> After the "this-escape" lint warning was added to javac (JDK-8015831), the base module was not updated to be able to compile with this warning enabled. This PR makes the necessary changes to allow the base module to build with the warning enabled.
>
> 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 two additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8325189
>  - JDK-8325189: Enable this-escape javac warning in java.base

Thanks all for the reviews. Will integrate now after a sync with mainline and successful cross-platform build run.

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

PR Comment: https://git.openjdk.org/jdk/pull/17692#issuecomment-1932778005

From darcy at openjdk.org  Wed Feb  7 20:08:19 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 7 Feb 2024 20:08:19 GMT
Subject: Integrated: JDK-8325189: Enable this-escape javac warning in java.base
In-Reply-To: 
References: 
Message-ID: 

On Fri, 2 Feb 2024 23:36:41 GMT, Joe Darcy  wrote:

> After the "this-escape" lint warning was added to javac (JDK-8015831), the base module was not updated to be able to compile with this warning enabled. This PR makes the necessary changes to allow the base module to build with the warning enabled.

This pull request has now been integrated.

Changeset: fbd15b20
Author:    Joe Darcy 
URL:       https://git.openjdk.org/jdk/commit/fbd15b20878b276ccd41128116f73b91b6d4c159
Stats:     151 lines in 93 files changed: 149 ins; 0 del; 2 mod

8325189: Enable this-escape javac warning in java.base

Reviewed-by: alanb, erikj, naoto, smarks, ihse, joehw, lancea, weijun

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

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

From darcy at openjdk.org  Wed Feb  7 20:40:59 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 7 Feb 2024 20:40:59 GMT
Subject: RFR: JDK-8325189: Enable this-escape javac warning in java.base
 [v3]
In-Reply-To: <25rXR-RgzW2Qib1E4ngpo8oG3E6pGJYr42QEWLi1fJw=.75e7164c-04dd-4d73-a44d-85b3a9c50406@github.com>
References: 
 <25rXR-RgzW2Qib1E4ngpo8oG3E6pGJYr42QEWLi1fJw=.75e7164c-04dd-4d73-a44d-85b3a9c50406@github.com>
Message-ID: 

On Wed, 7 Feb 2024 19:06:21 GMT, Weijun Wang  wrote:

> Security changes look fine. Although I don't know how to remove those annotations later. A lot of compatibility impact.

In case you didn't see it, the warning message are listed in an attachment on [JDK-8325263](https://bugs.openjdk.org/browse/JDK-8325263).

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

PR Comment: https://git.openjdk.org/jdk/pull/17692#issuecomment-1932829588

From smarks at openjdk.org  Wed Feb  7 20:53:56 2024
From: smarks at openjdk.org (Stuart Marks)
Date: Wed, 7 Feb 2024 20:53:56 GMT
Subject: RFR: 8324573: HashMap::putAll should resize to sum of both map
 sizes [v4]
In-Reply-To: <-eVaZ9AgZ_GzfN2yeTK8VdE3efeSyx1NqjPyOOkPZAI=.e1007274-1943-46eb-bfab-f796d461da31@github.com>
References: 
 <-eVaZ9AgZ_GzfN2yeTK8VdE3efeSyx1NqjPyOOkPZAI=.e1007274-1943-46eb-bfab-f796d461da31@github.com>
Message-ID: 

On Fri, 2 Feb 2024 17:38:13 GMT, Joshua Cao  wrote:

>> This change mirrors what we did for ConcurrentHashMap in https://github.com/openjdk/jdk/pull/17116. When we add all entries from one map to anther, we should resize that map to the size of the sum of both maps.
>> 
>> I used the command below to run the benchmarks. I set a high heap to reduce garbage collection noise.
>> 
>> java -Xms25G -jar benchmarks.jar -p size=100000 -p addSize=100000 -gc true org.openjdk.bench.java.util.HashMapBench
>> 
>> 
>> Before change
>> 
>> 
>> Benchmark            (addSize)        (mapType)  (size)  Mode  Cnt   Score   Error  Units
>> HashMapBench.putAll     100000         HASH_MAP  100000  avgt    4  22.927 ? 3.170  ms/op
>> HashMapBench.putAll     100000  LINKED_HASH_MAP  100000  avgt    4  25.198 ? 2.189  ms/op
>> 
>> 
>> After change
>> 
>> 
>> Benchmark            (addSize)        (mapType)  (size)  Mode  Cnt   Score   Error  Units
>> HashMapBench.putAll     100000         HASH_MAP  100000  avgt    4  16.780 ? 0.526  ms/op
>> HashMapBench.putAll     100000  LINKED_HASH_MAP  100000  avgt    4  19.721 ? 0.349  ms/op
>> 
>> 
>> We see about average time improvements of 26% in HashMap and 20% in LinkedHashMap.
>> 
>> ---
>> 
>> In the worse case, we may have two maps with identical keys. In this case, we would aggressively resize when we do not need to. I'm also adding an additional `putAllSameKeys` benchmark.
>> 
>> Before change:
>> 
>> 
>> Benchmark                                       (addSize)        (mapType)  (size)  Mode  Cnt        Score   Error   Units
>> HashMapBench.putAllSameKeys                        100000         HASH_MAP  100000  avgt             6.956           ms/op
>> HashMapBench.putAllSameKeys:gc.alloc.rate          100000         HASH_MAP  100000  avgt          1091.383          MB/sec
>> HashMapBench.putAllSameKeys:gc.alloc.rate.norm     100000         HASH_MAP  100000  avgt       7968871.917            B/op
>> HashMapBench.putAllSameKeys:gc.count               100000         HASH_MAP  100000  avgt               ? 0          counts
>> HashMapBench.putAllSameKeys                        100000  LINKED_HASH_MAP  100000  avgt             8.417           ms/op
>> HashMapBench.putAllSameKeys:gc.alloc.rate          100000  LINKED_HASH_MAP  100000  avgt           992.543          MB/sec
>> HashMapBench.putAllSameKeys:gc.alloc.rate.norm     100000  LINKED_HASH_MAP  100000  avgt       8768892.941            B/op
>> HashMapBench.putAllSameKeys:gc.count               100000  LINKED_HASH_MAP  100000  avgt               ? 0          counts
>> 
>> 
>> Af...
>
> Joshua Cao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   extract msize variable

I think we should step back from benchmarks a bit and examine the various tradeoffs occurring here. Certainly we can speed things up by pre-resizing the map to be larger. However, this can result in a map that is too large for the number of mappings it contains, in the case where this map and the argument map have keys in common. In other words, it might waste space. We really have little idea of how frequently this occurs. It's easy to imagine scenarios where there is no commonality (which this change will speed up) and also where there is 100% commonality (where this change will result in wasted space). What's the right tradeoff?

I've linked some older bugs to the bug report for some historical perspective. In particular, see [this comment](https://bugs.openjdk.org/browse/JDK-4710319?focusedId=12240692&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-12240692) from Josh Bloch on JDK-4710319:

> The conservatism of the resizing heuristic for putAll is intentional. It can cause at most one extra resizing, and can result in substantial footprint savings. This too should be documented in the code.

The comment he added to putAll() for this change is still visible [here](https://github.com/openjdk/jdk/blob/e1b3c5b5ba5cfb8243d760e99887bbe1015a9d69/jdk/src/share/classes/java/util/HashMap.java#L1271), but unfortunately it was removed by a later refactoring. The comment is:


        /*
         * Expand the map if the map if the number of mappings to be added
         * is greater than or equal to threshold.  This is conservative; the
         * obvious condition is (m.size() + size) >= threshold, but this
         * condition could result in a map with twice the appropriate capacity,
         * if the keys to be added overlap with the keys already in this map.
         * By using the conservative calculation, we subject ourself
         * to at most one extra resize.
         */


Note that this comment addresses fairly directly the essence of the change being discussed here. I think it's still applicable; the current code in putMapEntries() compares `m.size()` to `threshold` in deciding whether to resize immediately. We're not constrained by a 20-year-old comment, though. We can change the resizing policy if we have good reason to do so. 

However, I think the concern about space wastage is still relevant, even after 20 years of increased memory capacity and decreased memory cost. Memory is cheap but not free. Larger memory consumption has a real cost, as shown by current cloud pricing.

>From the perspective of users of the current API, most collections grow automatically but never shrink. If a HashMap's capacity ends up being too large, there's no way to shrink it (aside from copying all the mappings into a new, smaller HashMap). However, most collections -- including HashMap -- offer the ability to pre-size a map at construction time. Thus, an application that wanted to merge several disjoint maps could pre-size the destination appropriately in order to avoid resizing overhead.

To me, this indicates that we probably don't want to change the size policy to make things bigger while incurring the risk of wasting more space, even if some operations get faster. Meanwhile, applications that are suffering from excess resizing overhead have at least some means of adjusting the initial capacity to avoid resizing. If there are use cases that indicate otherwise, or that indicate a need for additional controls (perhaps like `trimToSize` or `ensureCapacity`) then maybe we could discuss them. I don't think we should proceed with this policy change in isolation, though, merely because it makes some cases go faster.

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

PR Comment: https://git.openjdk.org/jdk/pull/17544#issuecomment-1932858114

From sviswanathan at openjdk.org  Wed Feb  7 21:06:57 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Wed, 7 Feb 2024 21:06:57 GMT
Subject: RFR: 8318650: Optimized subword gather for x86 targets. [v13]
In-Reply-To: <-jaGezbfx9ZylmA6EBQY2TxqjfIHNhT8TXI6_KCL11Y=.d48ef20a-21c1-4486-ada6-4e1acf86a9ea@github.com>
References: 
 <-jaGezbfx9ZylmA6EBQY2TxqjfIHNhT8TXI6_KCL11Y=.d48ef20a-21c1-4486-ada6-4e1acf86a9ea@github.com>
Message-ID: 

On Wed, 7 Feb 2024 18:38:29 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 using 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.5-10x 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.
>> 
>> 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 look good to me.

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

Marked as reviewed by sviswanathan (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16354#pullrequestreview-1868793624

From duke at openjdk.org  Thu Feb  8 01:57:02 2024
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Thu, 8 Feb 2024 01:57:02 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>
 
 
 
 
 
 <-bYhysKjQVb_ZS0I0YutJZ7umfYwbs74rtK6-d2qL9U=.f9981e59-f0c4-48f3-ad7e-5627aad00919@github.com>
 <91Zv361kqKOjCSJPu20-yhKOb4lBIZVyVTm9f79dkcQ=.745c271d-3cb1-4ff3-9d71-5cad85ff4f14@github.com>
 
 <9q8Gg6DQnrf0HLW3oxwfpoUP9639drr1BIQMc1rxDFo=.eb4ea73c-b632-446a-8d50-b51838f67f69@github.com>
 
 
Message-ID: 

On Mon, 5 Feb 2024 21:31:36 GMT, Vladimir Yaroslavskiy  wrote:

>> Hi Vladimir (@iaroslavski),
>> 
>> Please see the data below. All tests were run after putting the DPQS code in java.util package and recompiling the JDK for each case.
>> 
>> > 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 | a15 | r20p | r20s
>> -- | -- | -- | -- | -- | -- | --
>> ArraysSort.Int.testParallelSort | RANDOM | 600 | 2.24 | 2.201 | 2.423 | 2.389
>> ArraysSort.Int.testParallelSort | RANDOM | 9000 | 35.318 | 35.961 | 79.028 | 83.774
>> ArraysSort.Int.testParallelSort | RANDOM | 20000 | 118.729 | 120.872 | 134.829 | 138.349
>> ArraysSort.Int.testParallelSort | RANDOM | 400000 | 822.676 | 822.44 | 1200.858 | 872.264
>> ArraysSort.Int.testParallelSort | RANDOM | 3000000 | 5864.514 | 5948.82 | 8800.391 | 6020.616
>> ArraysSort.Int.testParallelSort | REPEATED | 600 | 0.924 | 0.936 | 0.752 | 0.733
>> ArraysSort.Int.testParallelSort | REPEATED | 9000 | 9.896 | 9.317 | 31.409 | 24.896
>> ArraysSort.Int.testParallelSort | REPEATED | 20000 | 58.265 | 42.189 | 40.92 | 40.101
>> ArraysSort.Int.testParallelSort | REPEATED | 400000 | 256.952 | 253.217 | 236.568 | 239.163
>> ArraysSort.Int.testParallelSort | REPEATED | 3000000 | 2844.107 | 2851.088 | 2752.939 | 3040.423
>> ArraysSort.Int.testParallelSort | STAGGER | 600 | 2.245 | 2.296 | 2.15 | 2.219
>> ArraysSort.Int.testParallelSort | STAGGER | 9000 | 29.278 | 29.119 | 28.288 | 28.141
>> ArraysSort.Int.testParallelSort | STAGGER | 20000 | 50.129 | 50.442 | 49.746 | 49.686
>> ArraysSort.Int.testParallelSort | STAGGER | 400000 | 463.309 | 413.619 | 418.077 | 407.519
>> ArraysSort.Int.testParallelSort | STAGGER | 3000000 | 3687.198 | 4363.242 | 3732.777 | 3769.898
>> ArraysSort.Int.testParallelSort | SHUFFLE | 600 | 1.715 | 1.698 | 2.799 | 2.733
>> ArraysSort.Int.testParallelSort | SHUFFLE | 9000 | 27.69 | 27.183 | 32.883 | 32.373
>> ArraysSort.Int.testParallelSort | SHUFFLE | 20000 | 62.067 | 60.987 | 63.281 | 52.89
>> ArraysSort.Int.testParalle...
>
> Hello Vamsi (@vamsi-parasa),
> 
> Many thanks for the results! Now we can see that intrinsics are applied in all cases,
> but there are big differences between the same code.
> 
> For example,
> parallelSort REPEATED 20000:  58.265(Stock JDK) and 42.189(a15) with speedup x1.38
> parallelSort STAGGER 3000000:  3687.198(Stock JDK) 4363.242(a15) with speedup  x0.85
> 
> Case a15 is the current source code from JDK, but in one benchmarking it is faster,
> in other benchmarking it is slower (~15-30%).
> 
> Other strange behaviour with new sorting: r20p and r20s have the same code for
> sequential sorting (no radix sort at all), but we can see that on case works much slower
>  
> sort STAGGER 3000000: 34406.74(r20p) and 10467.03(r20s) - 3.3 times slower,
> whereas other sizes show more or less equal values.
> 
> Vamsi (@vamsi-parasa),
> Could you please run benchmarking of 5 cases with **updated** test class **ArraysSortNew**?
> https://github.com/iaroslavski/sorting/blob/master/radixsort/ArraysSortNew.java
> 
> Put the DPQS code in java.util package and recompiling the JDK for each case as you
> did before, but run new **ArraysSortNew**.
> 
> Find the sources there:
> 
> https://github.com/iaroslavski/sorting/blob/master/radixsort/ArraysSortNew.java
> https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_jdk.java
> https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_r20p.java
> https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_r20s.java
> https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_r25p.java
> https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_r25s.java
> 
> Thank you,
> Vladimir

Hi Vladimir (@iaroslavski),

The new ArraysSortNew.Java has compilation issues:


error: DualPivotQuicksort is not public in java.util; cannot be accessed from outside package
             java.util.DualPivotQuicksort.sort(b, PARALLELISM, 0, b.length);

Have you run into this issue? 

Thanks,
Vamsi

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

PR Comment: https://git.openjdk.org/jdk/pull/13568#issuecomment-1933243711

From duke at openjdk.org  Thu Feb  8 04:44:02 2024
From: duke at openjdk.org (Sam James)
Date: Thu, 8 Feb 2024 04:44:02 GMT
Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v7]
In-Reply-To: 
References: 
 
 
 <160IUiEFfgHTenlTpN4C2yL2oMdZPpV1fsK0YysXcr8=.cf71797d-9e10-4713-804e-368b481efde0@github.com>
 
Message-ID: 

On Fri, 2 Feb 2024 15:49:59 GMT, Magnus Ihse Bursie  wrote:

>> I wrote earlier:
>> 
>>> There is one change that merit highlighting: In src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c, I kept the dlsym lookup for openat64, fstatat64 and fdopendir64, on non-BSD OSes (i.e. Linux and AIX), and on AIX, respectively. This seems to me to be the safest choice, as we do not need to know if a lookup of openat would yield a 32-bit or a 64-bit version. (I frankly don't know, but I'm guessing it would yield the 32-bit version.)
>
> Basically, my understanding is that a call to "openat" in the source file will be converted into a call to openat64 on 32-bit platforms. When we look up the function using dlsym, I assume we need to find the 64-bit version directly. 
> 
> Even if this is incorrect, it seems at least *safe* to do it this way.

The redirection is done via aliases in the headers, so you're right. Thanks!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17538#discussion_r1482403071

From jpai at openjdk.org  Thu Feb  8 06:37:57 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 8 Feb 2024 06:37:57 GMT
Subject: RFR: 8325304: Several classes in java.util.jar and java.util.zip
 don't specify the behaviour for null arguments [v7]
In-Reply-To: 
References: <0mhiZJQ0aX8ZOjukPSrmwSNyqr8ix9ejT-BkjtbIjSU=.e9df8cd6-1267-4b3e-a2f8-ab215360f68a@github.com>
 
Message-ID: 

On Wed, 7 Feb 2024 12:37:23 GMT, Jaikiran Pai  wrote:

>> Can I please get a review of this doc-only change which updates the javadoc of several classes in `java.util.jar` and `java.util.zip` to specify their behaviour when `null` arguments are passed to the constructor or methods of those classes?
>> 
>> For these updated classes, I have individually checked that they indeed throw a `NullPointerException` when `null` is passed to their constructor or methods. The couple of places where `null` is accepted have been updated to mention that `null` is allowed.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   undo changes to CheckedInputStream and CheckedOutputStream

Thank you Alan and Lance for the reviews. tier1, tier2 and tier3 testing went fine for this change.

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

PR Comment: https://git.openjdk.org/jdk/pull/17728#issuecomment-1933441364

From jpai at openjdk.org  Thu Feb  8 06:37:57 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 8 Feb 2024 06:37:57 GMT
Subject: Integrated: 8325304: Several classes in java.util.jar and
 java.util.zip don't specify the behaviour for null arguments
In-Reply-To: <0mhiZJQ0aX8ZOjukPSrmwSNyqr8ix9ejT-BkjtbIjSU=.e9df8cd6-1267-4b3e-a2f8-ab215360f68a@github.com>
References: <0mhiZJQ0aX8ZOjukPSrmwSNyqr8ix9ejT-BkjtbIjSU=.e9df8cd6-1267-4b3e-a2f8-ab215360f68a@github.com>
Message-ID: 

On Tue, 6 Feb 2024 10:05:52 GMT, Jaikiran Pai  wrote:

> Can I please get a review of this doc-only change which updates the javadoc of several classes in `java.util.jar` and `java.util.zip` to specify their behaviour when `null` arguments are passed to the constructor or methods of those classes?
> 
> For these updated classes, I have individually checked that they indeed throw a `NullPointerException` when `null` is passed to their constructor or methods. The couple of places where `null` is accepted have been updated to mention that `null` is allowed.

This pull request has now been integrated.

Changeset: 1fb9e3d6
Author:    Jaikiran Pai 
URL:       https://git.openjdk.org/jdk/commit/1fb9e3d674229a2f1b464a09986ad055191966fe
Stats:     63 lines in 14 files changed: 36 ins; 6 del; 21 mod

8325304: Several classes in java.util.jar and java.util.zip don't specify the behaviour for null arguments

Reviewed-by: lancea, alanb

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

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

From ihse at openjdk.org  Thu Feb  8 07:44:18 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 8 Feb 2024 07:44:18 GMT
Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v10]
In-Reply-To: 
References: 
Message-ID: 

> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK native libraries.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Once more, remove AIX dirent64 et al defines

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17538/files
  - new: https://git.openjdk.org/jdk/pull/17538/files/1fd34b10..8a71e3b6

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

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

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

From duke at openjdk.org  Thu Feb  8 07:44:18 2024
From: duke at openjdk.org (Sam James)
Date: Thu, 8 Feb 2024 07:44:18 GMT
Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v10]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 8 Feb 2024 07:41:02 GMT, Magnus Ihse Bursie  wrote:

>> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK native libraries.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Once more, remove AIX dirent64 et al defines

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

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

PR Review: https://git.openjdk.org/jdk/pull/17538#pullrequestreview-1869449960

From ihse at openjdk.org  Thu Feb  8 07:44:18 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 8 Feb 2024 07:44:18 GMT
Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v7]
In-Reply-To: 
References: 
 
 
 
 
Message-ID: 

On Tue, 6 Feb 2024 08:05:14 GMT, Matthias Baesken  wrote:

>>> I hope finally the AIX part of this PR is done.
>> 
>> Thanks for the AIX related effort ; I put it again into our internal build/test queue.
>
>> 
>> Thanks for the AIX related effort ; I put it again into our internal build/test queue.
> 
> With the latest commit the build again fails on AIX with this error
> 
> /jdk/src/java.base/unix/native/libnio/ch/UnixFileDispatcherImpl.c:381:27: error: incompatible pointer types passing 'struct statvfs64 *' to parameter of type 'struct statvfs *' [-Werror,-Wincompatible-pointer-types]
>     result = fstatvfs(fd, &file_stat);
>                           ^~~~~~~~~~
> /usr/include/sys/statvfs.h:102:42: note: passing argument to parameter here
> extern int fstatvfs(int, struct statvfs *);

Well, well... The code at least looks cleaner without these AIX defines, so I really hope that this is the end of the AIX saga, at the `n+1`th time. @MBaesken Can you rerun AIX testing with the latest commit?

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

PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1933513366

From duke at openjdk.org  Thu Feb  8 07:44:18 2024
From: duke at openjdk.org (Sam James)
Date: Thu, 8 Feb 2024 07:44:18 GMT
Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v10]
In-Reply-To: 
References: 
 
 
 
Message-ID: <7tII90EgHAAJH2eHwSx0CFV5smD9VXSUx5ffVtUtnWc=.c39a6845-2f40-4c57-bd0e-200cf77ccb28@github.com>

On Tue, 6 Feb 2024 16:10:38 GMT, Magnus Ihse Bursie  wrote:

>> make/modules/jdk.hotspot.agent/Lib.gmk line 31:
>> 
>>> 29: 
>>> 30: ifeq ($(call isTargetOs, linux), true)
>>> 31:   SA_CFLAGS := -D_FILE_OFFSET_BITS=64
>> 
>> We have two choices to feel a bit more comfortable:
>> 1) We unconditionally `static_assert` in a few places for large `off_t`, or
>> 2) We only do it for platforms we know definitely support F_O_B and aren't AIX (which we've handled separately).
>> 
>> Not sure that's strictly necessary though. Also, if something understands LARGEFILE*_SOURCE, then it probably understood F_O_B, or at least has some macro to control it. Just thinking aloud.
>
> @thesamesam Do you want a `static_assert`? As I said, please let me know where you want to put it. I don't think it provides much, but if it makes you feel more comfortable, I'm okay with adding it.

Sorry! I think I'm okay with it as-is.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17538#discussion_r1482529665

From mbaesken at openjdk.org  Thu Feb  8 08:16:03 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 8 Feb 2024 08:16:03 GMT
Subject: RFR: JDK-8324930: java/lang/StringBuilder problem with concurrent
 jtreg runs
In-Reply-To: 
References: 
Message-ID: 

On Tue, 30 Jan 2024 09:08:28 GMT, Matthias Baesken  wrote:

> On some Windows machines we see sometimes OOM errors because of high resource (memory/swap) consumption. This is especially seen when the jtreg runs have higher concurrency. A solution is to put the java/lang/StringBuilder tests in the exclusiveAccess.dirs group so that they are not executed concurrently, which helps to mitigate the resource shortages.
> Of course this has the downside that on very large machines the concurrent execution is not done any more.

Hello, any further comments on this ?
Or should we carry the discussion to jtreg on how to work with resource (in this case memory) issues in case of concurrent runs ?
Can we **_configure_** to execute some jtreg tests with higher mem requirements with less concurrency ?

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

PR Comment: https://git.openjdk.org/jdk/pull/17625#issuecomment-1933560174

From jkern at openjdk.org  Thu Feb  8 09:06:03 2024
From: jkern at openjdk.org (Joachim Kern)
Date: Thu, 8 Feb 2024 09:06:03 GMT
Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v10]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 8 Feb 2024 07:44:18 GMT, Magnus Ihse Bursie  wrote:

>> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK native libraries.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Once more, remove AIX dirent64 et al defines

And also `#define statvfs statvfs64` is not necessary with the same explanation as  for the `opendir` defines above -- sorry again.

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

PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1933630674

From pminborg at openjdk.org  Thu Feb  8 09:15:08 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 8 Feb 2024 09:15:08 GMT
Subject: RFR: 8323746: Add PathElement hashCode and equals [v3]
In-Reply-To: 
References: 
Message-ID: 

> This PR proposes to implement `hashCode()` and `equals()` methods for implementations of `PathElement`.
> 
> In doing so, the previous `PathElementImpl` was removed and replaced in favor of distinct `record` implementations, each reflecting its own path element selection type. This also allowed the `PathKind` to be removed as this piece of information is now carried in the sealed type hierarchy. 
> 
> It is worth noting, the implementations resides in the `jdk.internal` package and consequently, they are not exposed to clients. So, we could use pattern matching (for example) internally but not in client code.

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

  Rework hashCode implementations and add a test for hash codes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17651/files
  - new: https://git.openjdk.org/jdk/pull/17651/files/5685e31a..d6da6221

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

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

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

From pminborg at openjdk.org  Thu Feb  8 09:15:09 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 8 Feb 2024 09:15:09 GMT
Subject: RFR: 8323746: Add PathElement hashCode and equals [v2]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Sat, 3 Feb 2024 11:28:51 GMT, ExE Boss  wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Make all PathElements records
>
> src/java.base/share/classes/jdk/internal/foreign/LayoutPath.java line 494:
> 
>> 492:             return 63;
>> 493:         }
>> 494: 
> 
> Suggestion:

So, a record with no component will have a `hashCode()` of zero.  I didn't want the two singleton variants to have the same hash code. I've added a test for this and will remove one of the overrides.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17651#discussion_r1482636805

From duke at openjdk.org  Thu Feb  8 09:18:00 2024
From: duke at openjdk.org (Johny Jose)
Date: Thu, 8 Feb 2024 09:18:00 GMT
Subject: Integrated: 8325150: (tz) Update Timezone Data to 2024a
In-Reply-To: 
References: 
Message-ID: 

On Wed, 7 Feb 2024 08:45:40 GMT, Johny Jose  wrote:

> Timezone data 2024a changes

This pull request has now been integrated.

Changeset: 917838e0
Author:    Johny Jose 
Committer: Sean Coffey 
URL:       https://git.openjdk.org/jdk/commit/917838e0a564b1f2cbfb6cc214ccbfd1a237019f
Stats:     195 lines in 10 files changed: 96 ins; 10 del; 89 mod

8325150: (tz) Update Timezone Data to 2024a

Reviewed-by: coffeys, naoto, iris

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

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

From mbaesken at openjdk.org  Thu Feb  8 09:20:00 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 8 Feb 2024 09:20:00 GMT
Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v7]
In-Reply-To: 
References: 
 
 
 
 
Message-ID: <5GBUr8CF3X7ZZYPezmBQUzuWQZuk-pXRrdkS4PX6zeE=.28790345-6e6a-4b10-8767-1b3f8b44754b@github.com>

On Tue, 6 Feb 2024 08:05:14 GMT, Matthias Baesken  wrote:

>>> I hope finally the AIX part of this PR is done.
>> 
>> Thanks for the AIX related effort ; I put it again into our internal build/test queue.
>
>> 
>> Thanks for the AIX related effort ; I put it again into our internal build/test queue.
> 
> With the latest commit the build again fails on AIX with this error
> 
> /jdk/src/java.base/unix/native/libnio/ch/UnixFileDispatcherImpl.c:381:27: error: incompatible pointer types passing 'struct statvfs64 *' to parameter of type 'struct statvfs *' [-Werror,-Wincompatible-pointer-types]
>     result = fstatvfs(fd, &file_stat);
>                           ^~~~~~~~~~
> /usr/include/sys/statvfs.h:102:42: note: passing argument to parameter here
> extern int fstatvfs(int, struct statvfs *);

> Well, well... The code at least looks cleaner without these AIX defines, so I really hope that this is the end of the AIX saga, at the `n+1`th time. @MBaesken Can you rerun AIX testing with the latest commit?

Latest commit looks still good on AIX.

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

PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1933652124

From jlu at openjdk.org  Thu Feb  8 09:29:55 2024
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 8 Feb 2024 09:29:55 GMT
Subject: RFR: JDK-8318761: MessageFormat pattern support for
 CompactNumberFormat, ListFormat, and DateTimeFormatter [v4]
In-Reply-To: 
References: 
 
 <87ZK-yMy308dxThFS9M0d_8CdgnCkthVwYaAzjMB8wU=.72750bb8-3750-411a-bd30-ebdd18e2a3f3@github.com>
 
 <5Rq91Y67WeTIMojjm9q9m4yUUK4AFrQA83qDs-D2xDY=.692eff59-f49e-44d7-9f02-66ad0909642c@github.com>
 <4yxhU7UF26hYk8-1J-oBnGI78Ff-qZ_CkKY-adLHfYI=.36f4a434-49e1-4f2b-a3e3-a131a8de3198@github.com>
 
Message-ID: 

On Wed, 7 Feb 2024 15:18:09 GMT, Roger Riggs  wrote:

>> Would it work with custom implementations for say NumberFormat via the SPI?
>
> Just moving the if...then... else code to a package-private static method in the respective XXFormat class would work the same.
> I had not thought of an addition to the spi to delegate to/through the provider.

I'll limit this package-private method to only `NumberFormat`, since the other eligible XXFormat classes, `DateFormat` and `ListFormat` both utilize a style enum and thus such a method is not needed for them, as we can just iterate through the style enum values.

Since `NumberFormats` style enum only applies to compactNumberInstances, it can't be used in a similar fashion.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17663#discussion_r1482660820

From thomas.schatzl at oracle.com  Thu Feb  8 10:04:55 2024
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Thu, 8 Feb 2024 11:04:55 +0100
Subject: OpenJDK 17: Loitering AbstractQueuedSynchronizer$ConditionNode
 instances
In-Reply-To: 
References: <591b0e9c-1d7a-405d-ace1-bd94f8dbbe22@gmx.net>
 
Message-ID: 

Hi,

   since this looks like a suggestion for a change to the libraries 
similar to the mentioned JDK-6805775, and not actually GC, cc'ing the 
core-libs-dev mailing list.

Hth,
   Thomas

On 07.02.24 15:20, Frank Kretschmer wrote:
> Hi Java GC-experts,
> 
> I'm facing an interesting G1 garbage collector observation in OpenJDK
> 17.0.9+9, which I would like to share with you.
> 
> My application runs many asynchronous tasks in a fixed thread pool,
> utilizing its standard LinkedBlockingQueue. Usually, it generates just a
> little garbage, but from time to time, I observed that the survivor
> spaces grow unexpectedly, and minor collection times increase.
> 
> This being the case, many
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionNode
> instances can be found on the heap. In fact, the whole heap (rank 1 as
> shown in jmap) was filled up with ConditionNode instances after a while.
> 
> After some tests, I figured out that G1 seems to be able to collect
> ?dead? ConditionNode instances during minor collections only if no
> formerly alive ConditionNode instances were promoted to the old
> generation and died there.
> 
> To illustrate that, I've attached a ?G1LoiteringConditionNodes? class
> that can be run for demo purposes, e.g. under Linux with OpenJDK
> 17.0.9+9 (VM options see comments within the class), and its gc-log
> output. It shows that during the first two minutes, everything is fine,
> but after a promotion to the old generation, survivors grow and minor
> pause time increase from 3 to 10ms.
> 
> For me, it looks like an issue similar to
> https://bugs.openjdk.org/browse/JDK-6805775 ?LinkedBlockingQueue Nodes
> should unlink themselves before becoming garbage?, which was fixed in
> OpenJDK 7.
> 
> What?s your opinion about that? Wouldn?t it be worth to enable G1 to
> collect those AbstractQueuedSynchronizer$ConditionNode instances during
> minor collections, as it is done for LinkedBlockingQueue Nodes?
> 
> Best regards
> 
> Frank Kretschmer, Java Realtime Application Developer


From pminborg at openjdk.org  Thu Feb  8 10:57:00 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 8 Feb 2024 10:57:00 GMT
Subject: Integrated: 8323746: Add PathElement hashCode and equals
In-Reply-To: 
References: 
Message-ID: 

On Wed, 31 Jan 2024 13:04:07 GMT, Per Minborg  wrote:

> This PR proposes to implement `hashCode()` and `equals()` methods for implementations of `PathElement`.
> 
> In doing so, the previous `PathElementImpl` was removed and replaced in favor of distinct `record` implementations, each reflecting its own path element selection type. This also allowed the `PathKind` to be removed as this piece of information is now carried in the sealed type hierarchy. 
> 
> It is worth noting, the implementations resides in the `jdk.internal` package and consequently, they are not exposed to clients. So, we could use pattern matching (for example) internally but not in client code.

This pull request has now been integrated.

Changeset: b58d73b9
Author:    Per Minborg 
URL:       https://git.openjdk.org/jdk/commit/b58d73b915bd1b26e741e9a6f12d029d21e11145
Stats:     189 lines in 4 files changed: 113 ins; 34 del; 42 mod

8323746: Add PathElement hashCode and equals

Reviewed-by: mcimadamore

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

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

From mcimadamore at openjdk.org  Thu Feb  8 11:02:04 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 8 Feb 2024 11:02:04 GMT
Subject: [jdk22] RFR: 8325001: Typo in the javadocs for the Arena::ofShared
 method
In-Reply-To: 
References: 
Message-ID: 

On Thu, 1 Feb 2024 12:07:52 GMT, Per Minborg  wrote:

> 8325001: Typo in the javadocs for the Arena::ofShared method

Marked as reviewed by mcimadamore (Reviewer).

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

PR Review: https://git.openjdk.org/jdk22/pull/100#pullrequestreview-1869843579

From frank.kretschmer at gmx.net  Thu Feb  8 11:15:45 2024
From: frank.kretschmer at gmx.net (Frank Kretschmer)
Date: Thu, 8 Feb 2024 12:15:45 +0100
Subject: OpenJDK 17: Loitering AbstractQueuedSynchronizer$ConditionNode
 instances
In-Reply-To: 
References: <591b0e9c-1d7a-405d-ace1-bd94f8dbbe22@gmx.net>
 
 
Message-ID: <64bc8cbd-78f4-44f4-90ae-80466c563281@gmx.net>

Hello Thomas, hello Core-Libs-Dev,

thank you for cc'ing my email. In deed my idea/suggestion is to modify
the AbstractQueuedSynchronizer$ConditionNode handling in such a way that
it gets unlinked from the chain of condition nodes if it is not needed
any more (it might be the "nextWaiter" node), in order to be more
GC-friendly.

@core-libs-dev: I've just attached the ?G1LoiteringConditionNodes? demo
class and "gc.log" again so that you can have a look if you like.

Best regards

Frank


Am 08.02.2024 um 11:04 schrieb Thomas Schatzl:
> Hi,
>
> ? since this looks like a suggestion for a change to the libraries
> similar to the mentioned JDK-6805775, and not actually GC, cc'ing the
> core-libs-dev mailing list.
>
> Hth,
> ? Thomas
>
> On 07.02.24 15:20, Frank Kretschmer wrote:
>> Hi Java GC-experts,
>>
>> I'm facing an interesting G1 garbage collector observation in OpenJDK
>> 17.0.9+9, which I would like to share with you.
>>
>> My application runs many asynchronous tasks in a fixed thread pool,
>> utilizing its standard LinkedBlockingQueue. Usually, it generates just a
>> little garbage, but from time to time, I observed that the survivor
>> spaces grow unexpectedly, and minor collection times increase.
>>
>> This being the case, many
>> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionNode
>> instances can be found on the heap. In fact, the whole heap (rank 1 as
>> shown in jmap) was filled up with ConditionNode instances after a while.
>>
>> After some tests, I figured out that G1 seems to be able to collect
>> ?dead? ConditionNode instances during minor collections only if no
>> formerly alive ConditionNode instances were promoted to the old
>> generation and died there.
>>
>> To illustrate that, I've attached a ?G1LoiteringConditionNodes? class
>> that can be run for demo purposes, e.g. under Linux with OpenJDK
>> 17.0.9+9 (VM options see comments within the class), and its gc-log
>> output. It shows that during the first two minutes, everything is fine,
>> but after a promotion to the old generation, survivors grow and minor
>> pause time increase from 3 to 10ms.
>>
>> For me, it looks like an issue similar to
>> https://bugs.openjdk.org/browse/JDK-6805775 ?LinkedBlockingQueue Nodes
>> should unlink themselves before becoming garbage?, which was fixed in
>> OpenJDK 7.
>>
>> What?s your opinion about that? Wouldn?t it be worth to enable G1 to
>> collect those AbstractQueuedSynchronizer$ConditionNode instances during
>> minor collections, as it is done for LinkedBlockingQueue Nodes?
>>
>> Best regards
>>
>> Frank Kretschmer, Java Realtime Application Developer
>
-------------- next part --------------
import java.util.Arrays;
import java.util.concurrent.Callable;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
import java.util.concurrent.ScheduledExecutorService;
import java.util.concurrent.TimeUnit;

/**
 * Asynchronously execute tasks in a fixed thread pool, in order to demonstrate that
 * {@code java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionNode} instances are properly
 * collected during minor collections, but only if no instances were promoted to the old generation.
 * 

 * If such instances were promoted to old generation (here after 2 minutes),
 * ConditionNode instances are not collected during minor collections by G1 in OpenJDK 17.0.9+9 any more,
 * but promoted to survivor spaces and finally to the old generation, filling it up until a
 * mixed or full collection kicks in.
 * 

 * This increase minor collection pauses from 3ms to 10ms, and leads to earlier mixed collections later on.
 *
 * Recommended VM-options: -Xms2048m -Xmx2048m -XX:+UseG1GC -XX:+UnlockExperimentalVMOptions -XX:G1MaxNewSizePercent=20 -Xlog:gc*,gc+age*=trace
 *
 * @author Frank Kretschmer, Germany, email: frank.kretschmer at gmx.net
 */
public class G1LoiteringConditionNodes {
    
    private static final int NUM_OF_PRODUCERS = 16;
    private static final int NUM_OF_WORKERS = 32;
    
    private static final long TXNS_PER_SECOND = 1600;
    
    private static final long WORK_MILLISECONDS = 10;
    
    private static final long GC_AFTER_SECONDS = 120;

    public static void main(final String[] args) {

        // worker thread pool
        final ExecutorService workers = Executors.newFixedThreadPool(NUM_OF_WORKERS);
        final Callable work = () -> {
            try {
                // simulate work (just sleep for a while)
                TimeUnit.MILLISECONDS.sleep(WORK_MILLISECONDS);
                
            } catch (final InterruptedException e) {
                Thread.currentThread().interrupt();
            }
            // generate some garbage
            return Arrays.toString(new byte[4096]) + System.currentTimeMillis();
        };

        // produce tasks to be scheduled in the worker pool
        final ScheduledExecutorService producer = Executors.newScheduledThreadPool(NUM_OF_PRODUCERS);
        producer.scheduleWithFixedDelay(
                () -> workers.submit(work),
                0, TimeUnit.SECONDS.toNanos(1L) / TXNS_PER_SECOND,
                TimeUnit.NANOSECONDS);

        // trigger a full garbage collection, in order to promote ConditionNode objects to old generation for test purposes
        // in real live application, ConditionNode objects are promoted to old gen. on JVM startup
        // if many objects are created, more than can be hold in survivors
        producer.schedule(System::gc, GC_AFTER_SECONDS, TimeUnit.SECONDS);
    }

}
-------------- next part --------------
[0.002s][info][gc] Using G1
[0.014s][info][gc,init] Version: 17.0.9+9 (release)
[0.014s][info][gc,init] CPUs: 20 total, 20 available
[0.014s][info][gc,init] Memory: 31763M
[0.014s][info][gc,init] Large Page Support: Disabled
[0.014s][info][gc,init] NUMA Support: Disabled
[0.014s][info][gc,init] Compressed Oops: Enabled (32-bit)
[0.014s][info][gc,init] Heap Region Size: 1M
[0.014s][info][gc,init] Heap Min Capacity: 2G
[0.014s][info][gc,init] Heap Initial Capacity: 2G
[0.014s][info][gc,init] Heap Max Capacity: 2G
[0.014s][info][gc,init] Pre-touch: Disabled
[0.014s][info][gc,init] Parallel Workers: 15
[0.014s][info][gc,init] Concurrent Workers: 4
[0.014s][info][gc,init] Concurrent Refinement Workers: 15
[0.014s][info][gc,init] Periodic GC: Disabled
[0.019s][info][gc,metaspace] CDS archive(s) mapped at: [0x00007f28e3000000-0x00007f28e3bc8000-0x00007f28e3bc8000), size 12353536, SharedBaseAddress: 0x00007f28e3000000, ArchiveRelocationMode: 1.
[0.019s][info][gc,metaspace] Compressed class space mapped at: 0x00007f28e4000000-0x00007f2924000000, reserved size: 1073741824
[0.019s][info][gc,metaspace] Narrow klass base: 0x00007f28e3000000, Narrow klass shift: 0, Narrow klass range: 0x100000000
[0.880s][info][gc,start    ] GC(0) Pause Young (Normal) (G1 Evacuation Pause)
[0.883s][info][gc,task     ] GC(0) Using 15 workers of 15 for evacuation
[0.883s][debug][gc,age      ] GC(0) Desired survivor size 6815744 bytes, new threshold 15 (max threshold 15)
[0.885s][trace][gc,age      ] GC(0) Age table with threshold 15 (max threshold 15)
[0.885s][trace][gc,age      ] GC(0) - age   1:     429544 bytes,     429544 total
[0.885s][info ][gc,phases   ] GC(0)   Pre Evacuate Collection Set: 0.3ms
[0.885s][info ][gc,phases   ] GC(0)   Merge Heap Roots: 0.3ms
[0.885s][info ][gc,phases   ] GC(0)   Evacuate Collection Set: 0.9ms
[0.885s][info ][gc,phases   ] GC(0)   Post Evacuate Collection Set: 0.6ms
[0.885s][info ][gc,phases   ] GC(0)   Other: 3.4ms
[0.885s][info ][gc,heap     ] GC(0) Eden regions: 102->0(126)
[0.885s][info ][gc,heap     ] GC(0) Survivor regions: 0->1(13)
[0.885s][info ][gc,heap     ] GC(0) Old regions: 0->0
[0.885s][info ][gc,heap     ] GC(0) Archive regions: 2->2
[0.885s][info ][gc,heap     ] GC(0) Humongous regions: 0->0
[0.885s][info ][gc,metaspace] GC(0) Metaspace: 903K(1088K)->903K(1088K) NonClass: 820K(896K)->820K(896K) Class: 83K(192K)->83K(192K)
[0.885s][info ][gc          ] GC(0) Pause Young (Normal) (G1 Evacuation Pause) 102M->1M(2048M) 5.463ms
[0.885s][info ][gc,cpu      ] GC(0) User=0.02s Sys=0.00s Real=0.01s
[2.001s][info ][gc,start    ] GC(1) Pause Young (Normal) (G1 Evacuation Pause)
[2.001s][info ][gc,task     ] GC(1) Using 15 workers of 15 for evacuation
[2.002s][debug][gc,age      ] GC(1) Desired survivor size 8388608 bytes, new threshold 15 (max threshold 15)
[2.002s][trace][gc,age      ] GC(1) Age table with threshold 15 (max threshold 15)
[2.002s][trace][gc,age      ] GC(1) - age   1:       6144 bytes,       6144 total
[2.002s][trace][gc,age      ] GC(1) - age   2:     419440 bytes,     425584 total
[2.002s][info ][gc,phases   ] GC(1)   Pre Evacuate Collection Set: 0.2ms
[2.002s][info ][gc,phases   ] GC(1)   Merge Heap Roots: 0.0ms
[2.002s][info ][gc,phases   ] GC(1)   Evacuate Collection Set: 0.2ms
[2.002s][info ][gc,phases   ] GC(1)   Post Evacuate Collection Set: 0.2ms
[2.002s][info ][gc,phases   ] GC(1)   Other: 0.1ms
[2.002s][info ][gc,heap     ] GC(1) Eden regions: 126->0(408)
[2.002s][info ][gc,heap     ] GC(1) Survivor regions: 1->1(16)
[2.002s][info ][gc,heap     ] GC(1) Old regions: 0->0
[2.002s][info ][gc,heap     ] GC(1) Archive regions: 2->2
[2.002s][info ][gc,heap     ] GC(1) Humongous regions: 0->0
[2.002s][info ][gc,metaspace] GC(1) Metaspace: 904K(1088K)->904K(1088K) NonClass: 820K(896K)->820K(896K) Class: 83K(192K)->83K(192K)
[2.002s][info ][gc          ] GC(1) Pause Young (Normal) (G1 Evacuation Pause) 127M->1M(2048M) 0.774ms
[2.002s][info ][gc,cpu      ] GC(1) User=0.01s Sys=0.00s Real=0.00s
[5.745s][info ][gc,start    ] GC(2) Pause Young (Normal) (G1 Evacuation Pause)
[5.745s][info ][gc,task     ] GC(2) Using 15 workers of 15 for evacuation
[5.745s][debug][gc,age      ] GC(2) Desired survivor size 27262976 bytes, new threshold 15 (max threshold 15)
[5.748s][trace][gc,age      ] GC(2) Age table with threshold 15 (max threshold 15)
[5.748s][trace][gc,age      ] GC(2) - age   1:       8448 bytes,       8448 total
[5.748s][trace][gc,age      ] GC(2) - age   2:         56 bytes,       8504 total
[5.748s][trace][gc,age      ] GC(2) - age   3:     419440 bytes,     427944 total
[5.749s][info ][gc,phases   ] GC(2)   Pre Evacuate Collection Set: 0.4ms
[5.749s][info ][gc,phases   ] GC(2)   Merge Heap Roots: 0.4ms
[5.749s][info ][gc,phases   ] GC(2)   Evacuate Collection Set: 1.6ms
[5.749s][info ][gc,phases   ] GC(2)   Post Evacuate Collection Set: 1.2ms
[5.749s][info ][gc,phases   ] GC(2)   Other: 0.5ms
[5.749s][info ][gc,heap     ] GC(2) Eden regions: 408->0(408)
[5.749s][info ][gc,heap     ] GC(2) Survivor regions: 1->1(52)
[5.749s][info ][gc,heap     ] GC(2) Old regions: 0->0
[5.749s][info ][gc,heap     ] GC(2) Archive regions: 2->2
[5.749s][info ][gc,heap     ] GC(2) Humongous regions: 0->0
[5.749s][info ][gc,metaspace] GC(2) Metaspace: 904K(1088K)->904K(1088K) NonClass: 820K(896K)->820K(896K) Class: 83K(192K)->83K(192K)
[5.749s][info ][gc          ] GC(2) Pause Young (Normal) (G1 Evacuation Pause) 409M->1M(2048M) 4.118ms
[5.749s][info ][gc,cpu      ] GC(2) User=0.03s Sys=0.01s Real=0.00s
[9.508s][info ][gc,start    ] GC(3) Pause Young (Normal) (G1 Evacuation Pause)
[9.508s][info ][gc,task     ] GC(3) Using 15 workers of 15 for evacuation
[9.508s][debug][gc,age      ] GC(3) Desired survivor size 27262976 bytes, new threshold 15 (max threshold 15)
[9.511s][trace][gc,age      ] GC(3) Age table with threshold 15 (max threshold 15)
[9.511s][trace][gc,age      ] GC(3) - age   1:      14992 bytes,      14992 total
[9.511s][trace][gc,age      ] GC(3) - age   2:        368 bytes,      15360 total
[9.511s][trace][gc,age      ] GC(3) - age   3:         56 bytes,      15416 total
[9.511s][trace][gc,age      ] GC(3) - age   4:     419440 bytes,     434856 total
[9.511s][info ][gc,phases   ] GC(3)   Pre Evacuate Collection Set: 0.4ms
[9.511s][info ][gc,phases   ] GC(3)   Merge Heap Roots: 0.4ms
[9.511s][info ][gc,phases   ] GC(3)   Evacuate Collection Set: 1.3ms
[9.511s][info ][gc,phases   ] GC(3)   Post Evacuate Collection Set: 1.1ms
[9.511s][info ][gc,phases   ] GC(3)   Other: 0.3ms
[9.511s][info ][gc,heap     ] GC(3) Eden regions: 408->0(408)
[9.511s][info ][gc,heap     ] GC(3) Survivor regions: 1->1(52)
[9.511s][info ][gc,heap     ] GC(3) Old regions: 0->0
[9.511s][info ][gc,heap     ] GC(3) Archive regions: 2->2
[9.511s][info ][gc,heap     ] GC(3) Humongous regions: 0->0
[9.511s][info ][gc,metaspace] GC(3) Metaspace: 904K(1088K)->904K(1088K) NonClass: 820K(896K)->820K(896K) Class: 83K(192K)->83K(192K)
[9.511s][info ][gc          ] GC(3) Pause Young (Normal) (G1 Evacuation Pause) 409M->1M(2048M) 3.564ms
[9.511s][info ][gc,cpu      ] GC(3) User=0.02s Sys=0.01s Real=0.01s
[13.303s][info ][gc,start    ] GC(4) Pause Young (Normal) (G1 Evacuation Pause)
[13.303s][info ][gc,task     ] GC(4) Using 15 workers of 15 for evacuation
[13.303s][debug][gc,age      ] GC(4) Desired survivor size 27262976 bytes, new threshold 15 (max threshold 15)
[13.306s][trace][gc,age      ] GC(4) Age table with threshold 15 (max threshold 15)
[13.306s][trace][gc,age      ] GC(4) - age   1:      10384 bytes,      10384 total
[13.306s][trace][gc,age      ] GC(4) - age   3:        368 bytes,      10752 total
[13.306s][trace][gc,age      ] GC(4) - age   4:         56 bytes,      10808 total
[13.306s][trace][gc,age      ] GC(4) - age   5:     419440 bytes,     430248 total
[13.306s][info ][gc,phases   ] GC(4)   Pre Evacuate Collection Set: 0.4ms
[13.306s][info ][gc,phases   ] GC(4)   Merge Heap Roots: 0.3ms
[13.306s][info ][gc,phases   ] GC(4)   Evacuate Collection Set: 1.0ms
[13.306s][info ][gc,phases   ] GC(4)   Post Evacuate Collection Set: 1.1ms
[13.306s][info ][gc,phases   ] GC(4)   Other: 0.4ms
[13.306s][info ][gc,heap     ] GC(4) Eden regions: 408->0(408)
[13.306s][info ][gc,heap     ] GC(4) Survivor regions: 1->1(52)
[13.306s][info ][gc,heap     ] GC(4) Old regions: 0->0
[13.306s][info ][gc,heap     ] GC(4) Archive regions: 2->2
[13.306s][info ][gc,heap     ] GC(4) Humongous regions: 0->0
[13.306s][info ][gc,metaspace] GC(4) Metaspace: 904K(1088K)->904K(1088K) NonClass: 820K(896K)->820K(896K) Class: 83K(192K)->83K(192K)
[13.306s][info ][gc          ] GC(4) Pause Young (Normal) (G1 Evacuation Pause) 409M->1M(2048M) 3.134ms
[13.306s][info ][gc,cpu      ] GC(4) User=0.01s Sys=0.01s Real=0.00s
[17.084s][info ][gc,start    ] GC(5) Pause Young (Normal) (G1 Evacuation Pause)
[17.084s][info ][gc,task     ] GC(5) Using 15 workers of 15 for evacuation
[17.084s][debug][gc,age      ] GC(5) Desired survivor size 27262976 bytes, new threshold 15 (max threshold 15)
[17.086s][trace][gc,age      ] GC(5) Age table with threshold 15 (max threshold 15)
[17.086s][trace][gc,age      ] GC(5) - age   1:       1624 bytes,       1624 total
[17.086s][trace][gc,age      ] GC(5) - age   4:        368 bytes,       1992 total
[17.086s][trace][gc,age      ] GC(5) - age   5:         56 bytes,       2048 total
[17.086s][trace][gc,age      ] GC(5) - age   6:     419440 bytes,     421488 total
[17.086s][info ][gc,phases   ] GC(5)   Pre Evacuate Collection Set: 0.3ms
[17.086s][info ][gc,phases   ] GC(5)   Merge Heap Roots: 0.3ms
[17.086s][info ][gc,phases   ] GC(5)   Evacuate Collection Set: 0.9ms
[17.086s][info ][gc,phases   ] GC(5)   Post Evacuate Collection Set: 0.5ms
[17.086s][info ][gc,phases   ] GC(5)   Other: 0.2ms
[17.086s][info ][gc,heap     ] GC(5) Eden regions: 408->0(408)
[17.086s][info ][gc,heap     ] GC(5) Survivor regions: 1->1(52)
[17.086s][info ][gc,heap     ] GC(5) Old regions: 0->0
[17.086s][info ][gc,heap     ] GC(5) Archive regions: 2->2
[17.086s][info ][gc,heap     ] GC(5) Humongous regions: 0->0
[17.086s][info ][gc,metaspace] GC(5) Metaspace: 904K(1088K)->904K(1088K) NonClass: 820K(896K)->820K(896K) Class: 83K(192K)->83K(192K)
[17.087s][info ][gc          ] GC(5) Pause Young (Normal) (G1 Evacuation Pause) 409M->1M(2048M) 2.380ms
[17.087s][info ][gc,cpu      ] GC(5) User=0.01s Sys=0.01s Real=0.00s
[20.900s][info ][gc,start    ] GC(6) Pause Young (Normal) (G1 Evacuation Pause)
[20.900s][info ][gc,task     ] GC(6) Using 15 workers of 15 for evacuation
[20.900s][debug][gc,age      ] GC(6) Desired survivor size 27262976 bytes, new threshold 15 (max threshold 15)
[20.904s][trace][gc,age      ] GC(6) Age table with threshold 15 (max threshold 15)
[20.904s][trace][gc,age      ] GC(6) - age   1:      10440 bytes,      10440 total
[20.904s][trace][gc,age      ] GC(6) - age   5:        368 bytes,      10808 total
[20.904s][trace][gc,age      ] GC(6) - age   6:         56 bytes,      10864 total
[20.904s][trace][gc,age      ] GC(6) - age   7:     419440 bytes,     430304 total
[20.904s][info ][gc,phases   ] GC(6)   Pre Evacuate Collection Set: 0.4ms
[20.904s][info ][gc,phases   ] GC(6)   Merge Heap Roots: 0.5ms
[20.904s][info ][gc,phases   ] GC(6)   Evacuate Collection Set: 1.2ms
[20.904s][info ][gc,phases   ] GC(6)   Post Evacuate Collection Set: 1.2ms
[20.904s][info ][gc,phases   ] GC(6)   Other: 0.3ms
[20.904s][info ][gc,heap     ] GC(6) Eden regions: 408->0(408)
[20.904s][info ][gc,heap     ] GC(6) Survivor regions: 1->1(52)
[20.904s][info ][gc,heap     ] GC(6) Old regions: 0->0
[20.904s][info ][gc,heap     ] GC(6) Archive regions: 2->2
[20.904s][info ][gc,heap     ] GC(6) Humongous regions: 0->0
[20.904s][info ][gc,metaspace] GC(6) Metaspace: 904K(1088K)->904K(1088K) NonClass: 820K(896K)->820K(896K) Class: 83K(192K)->83K(192K)
[20.904s][info ][gc          ] GC(6) Pause Young (Normal) (G1 Evacuation Pause) 409M->1M(2048M) 3.688ms
[20.904s][info ][gc,cpu      ] GC(6) User=0.02s Sys=0.00s Real=0.00s
[24.716s][info ][gc,start    ] GC(7) Pause Young (Normal) (G1 Evacuation Pause)
[24.716s][info ][gc,task     ] GC(7) Using 15 workers of 15 for evacuation
[24.716s][debug][gc,age      ] GC(7) Desired survivor size 27262976 bytes, new threshold 15 (max threshold 15)
[24.719s][trace][gc,age      ] GC(7) Age table with threshold 15 (max threshold 15)
[24.720s][trace][gc,age      ] GC(7) - age   1:       6064 bytes,       6064 total
[24.720s][trace][gc,age      ] GC(7) - age   6:        368 bytes,       6432 total
[24.720s][trace][gc,age      ] GC(7) - age   7:         56 bytes,       6488 total
[24.720s][trace][gc,age      ] GC(7) - age   8:     419440 bytes,     425928 total
[24.720s][info ][gc,phases   ] GC(7)   Pre Evacuate Collection Set: 0.5ms
[24.720s][info ][gc,phases   ] GC(7)   Merge Heap Roots: 0.6ms
[24.720s][info ][gc,phases   ] GC(7)   Evacuate Collection Set: 1.5ms
[24.720s][info ][gc,phases   ] GC(7)   Post Evacuate Collection Set: 1.0ms
[24.720s][info ][gc,phases   ] GC(7)   Other: 0.5ms
[24.720s][info ][gc,heap     ] GC(7) Eden regions: 408->0(408)
[24.720s][info ][gc,heap     ] GC(7) Survivor regions: 1->1(52)
[24.720s][info ][gc,heap     ] GC(7) Old regions: 0->0
[24.720s][info ][gc,heap     ] GC(7) Archive regions: 2->2
[24.720s][info ][gc,heap     ] GC(7) Humongous regions: 0->0
[24.720s][info ][gc,metaspace] GC(7) Metaspace: 907K(1088K)->907K(1088K) NonClass: 823K(896K)->823K(896K) Class: 83K(192K)->83K(192K)
[24.720s][info ][gc          ] GC(7) Pause Young (Normal) (G1 Evacuation Pause) 409M->1M(2048M) 4.193ms
[24.720s][info ][gc,cpu      ] GC(7) User=0.03s Sys=0.01s Real=0.00s
[28.543s][info ][gc,start    ] GC(8) Pause Young (Normal) (G1 Evacuation Pause)
[28.543s][info ][gc,task     ] GC(8) Using 15 workers of 15 for evacuation
[28.543s][debug][gc,age      ] GC(8) Desired survivor size 27262976 bytes, new threshold 15 (max threshold 15)
[28.546s][trace][gc,age      ] GC(8) Age table with threshold 15 (max threshold 15)
[28.546s][trace][gc,age      ] GC(8) - age   1:      13952 bytes,      13952 total
[28.546s][trace][gc,age      ] GC(8) - age   7:        368 bytes,      14320 total
[28.546s][trace][gc,age      ] GC(8) - age   8:         56 bytes,      14376 total
[28.546s][trace][gc,age      ] GC(8) - age   9:     419440 bytes,     433816 total
[28.546s][info ][gc,phases   ] GC(8)   Pre Evacuate Collection Set: 0.4ms
[28.546s][info ][gc,phases   ] GC(8)   Merge Heap Roots: 0.4ms
[28.546s][info ][gc,phases   ] GC(8)   Evacuate Collection Set: 0.7ms
[28.546s][info ][gc,phases   ] GC(8)   Post Evacuate Collection Set: 0.7ms
[28.546s][info ][gc,phases   ] GC(8)   Other: 0.2ms
[28.546s][info ][gc,heap     ] GC(8) Eden regions: 408->0(408)
[28.546s][info ][gc,heap     ] GC(8) Survivor regions: 1->1(52)
[28.546s][info ][gc,heap     ] GC(8) Old regions: 0->0
[28.546s][info ][gc,heap     ] GC(8) Archive regions: 2->2
[28.546s][info ][gc,heap     ] GC(8) Humongous regions: 0->0
[28.546s][info ][gc,metaspace] GC(8) Metaspace: 907K(1088K)->907K(1088K) NonClass: 823K(896K)->823K(896K) Class: 83K(192K)->83K(192K)
[28.546s][info ][gc          ] GC(8) Pause Young (Normal) (G1 Evacuation Pause) 409M->1M(2048M) 2.496ms
[28.546s][info ][gc,cpu      ] GC(8) User=0.01s Sys=0.00s Real=0.00s
[32.377s][info ][gc,start    ] GC(9) Pause Young (Normal) (G1 Evacuation Pause)
[32.377s][info ][gc,task     ] GC(9) Using 15 workers of 15 for evacuation
[32.377s][debug][gc,age      ] GC(9) Desired survivor size 27262976 bytes, new threshold 15 (max threshold 15)
[32.381s][trace][gc,age      ] GC(9) Age table with threshold 15 (max threshold 15)
[32.381s][trace][gc,age      ] GC(9) - age   1:      13968 bytes,      13968 total
[32.381s][trace][gc,age      ] GC(9) - age   8:        368 bytes,      14336 total
[32.381s][trace][gc,age      ] GC(9) - age   9:         56 bytes,      14392 total
[32.381s][trace][gc,age      ] GC(9) - age  10:     419440 bytes,     433832 total
[32.381s][info ][gc,phases   ] GC(9)   Pre Evacuate Collection Set: 0.4ms
[32.381s][info ][gc,phases   ] GC(9)   Merge Heap Roots: 0.6ms
[32.381s][info ][gc,phases   ] GC(9)   Evacuate Collection Set: 1.3ms
[32.381s][info ][gc,phases   ] GC(9)   Post Evacuate Collection Set: 1.0ms
[32.381s][info ][gc,phases   ] GC(9)   Other: 0.4ms
[32.381s][info ][gc,heap     ] GC(9) Eden regions: 408->0(408)
[32.381s][info ][gc,heap     ] GC(9) Survivor regions: 1->1(52)
[32.381s][info ][gc,heap     ] GC(9) Old regions: 0->0
[32.381s][info ][gc,heap     ] GC(9) Archive regions: 2->2
[32.381s][info ][gc,heap     ] GC(9) Humongous regions: 0->0
[32.381s][info ][gc,metaspace] GC(9) Metaspace: 907K(1088K)->907K(1088K) NonClass: 823K(896K)->823K(896K) Class: 83K(192K)->83K(192K)
[32.381s][info ][gc          ] GC(9) Pause Young (Normal) (G1 Evacuation Pause) 409M->1M(2048M) 3.761ms
[32.381s][info ][gc,cpu      ] GC(9) User=0.02s Sys=0.00s Real=0.01s
[36.195s][info ][gc,start    ] GC(10) Pause Young (Normal) (G1 Evacuation Pause)
[36.195s][info ][gc,task     ] GC(10) Using 15 workers of 15 for evacuation
[36.195s][debug][gc,age      ] GC(10) Desired survivor size 27262976 bytes, new threshold 15 (max threshold 15)
[36.196s][trace][gc,age      ] GC(10) Age table with threshold 15 (max threshold 15)
[36.196s][trace][gc,age      ] GC(10) - age   1:      20096 bytes,      20096 total
[36.196s][trace][gc,age      ] GC(10) - age   9:        368 bytes,      20464 total
[36.196s][trace][gc,age      ] GC(10) - age  10:         56 bytes,      20520 total
[36.196s][trace][gc,age      ] GC(10) - age  11:     419440 bytes,     439960 total
[36.196s][info ][gc,phases   ] GC(10)   Pre Evacuate Collection Set: 0.2ms
[36.196s][info ][gc,phases   ] GC(10)   Merge Heap Roots: 0.1ms
[36.196s][info ][gc,phases   ] GC(10)   Evacuate Collection Set: 0.2ms
[36.196s][info ][gc,phases   ] GC(10)   Post Evacuate Collection Set: 0.4ms
[36.196s][info ][gc,phases   ] GC(10)   Other: 0.1ms
[36.196s][info ][gc,heap     ] GC(10) Eden regions: 408->0(408)
[36.196s][info ][gc,heap     ] GC(10) Survivor regions: 1->1(52)
[36.196s][info ][gc,heap     ] GC(10) Old regions: 0->0
[36.196s][info ][gc,heap     ] GC(10) Archive regions: 2->2
[36.196s][info ][gc,heap     ] GC(10) Humongous regions: 0->0
[36.196s][info ][gc,metaspace] GC(10) Metaspace: 907K(1088K)->907K(1088K) NonClass: 823K(896K)->823K(896K) Class: 83K(192K)->83K(192K)
[36.196s][info ][gc          ] GC(10) Pause Young (Normal) (G1 Evacuation Pause) 409M->1M(2048M) 1.104ms
[36.196s][info ][gc,cpu      ] GC(10) User=0.01s Sys=0.00s Real=0.00s
[40.024s][info ][gc,start    ] GC(11) Pause Young (Normal) (G1 Evacuation Pause)
[40.024s][info ][gc,task     ] GC(11) Using 15 workers of 15 for evacuation
[40.024s][debug][gc,age      ] GC(11) Desired survivor size 27262976 bytes, new threshold 15 (max threshold 15)
[40.027s][trace][gc,age      ] GC(11) Age table with threshold 15 (max threshold 15)
[40.027s][trace][gc,age      ] GC(11) - age   1:      14992 bytes,      14992 total
[40.027s][trace][gc,age      ] GC(11) - age  10:        368 bytes,      15360 total
[40.027s][trace][gc,age      ] GC(11) - age  11:         56 bytes,      15416 total
[40.027s][trace][gc,age      ] GC(11) - age  12:     419440 bytes,     434856 total
[40.027s][info ][gc,phases   ] GC(11)   Pre Evacuate Collection Set: 0.4ms
[40.027s][info ][gc,phases   ] GC(11)   Merge Heap Roots: 0.6ms
[40.027s][info ][gc,phases   ] GC(11)   Evacuate Collection Set: 1.0ms
[40.027s][info ][gc,phases   ] GC(11)   Post Evacuate Collection Set: 0.8ms
[40.027s][info ][gc,phases   ] GC(11)   Other: 0.4ms
[40.027s][info ][gc,heap     ] GC(11) Eden regions: 408->0(408)
[40.027s][info ][gc,heap     ] GC(11) Survivor regions: 1->1(52)
[40.027s][info ][gc,heap     ] GC(11) Old regions: 0->0
[40.027s][info ][gc,heap     ] GC(11) Archive regions: 2->2
[40.027s][info ][gc,heap     ] GC(11) Humongous regions: 0->0
[40.027s][info ][gc,metaspace] GC(11) Metaspace: 907K(1088K)->907K(1088K) NonClass: 823K(896K)->823K(896K) Class: 83K(192K)->83K(192K)
[40.027s][info ][gc          ] GC(11) Pause Young (Normal) (G1 Evacuation Pause) 409M->1M(2048M) 3.105ms
[40.027s][info ][gc,cpu      ] GC(11) User=0.02s Sys=0.00s Real=0.00s
[43.863s][info ][gc,start    ] GC(12) Pause Young (Normal) (G1 Evacuation Pause)
[43.863s][info ][gc,task     ] GC(12) Using 15 workers of 15 for evacuation
[43.863s][debug][gc,age      ] GC(12) Desired survivor size 27262976 bytes, new threshold 15 (max threshold 15)
[43.866s][trace][gc,age      ] GC(12) Age table with threshold 15 (max threshold 15)
[43.866s][trace][gc,age      ] GC(12) - age   1:       6928 bytes,       6928 total
[43.866s][trace][gc,age      ] GC(12) - age  11:        368 bytes,       7296 total
[43.866s][trace][gc,age      ] GC(12) - age  12:         56 bytes,       7352 total
[43.866s][trace][gc,age      ] GC(12) - age  13:     419440 bytes,     426792 total
[43.866s][info ][gc,phases   ] GC(12)   Pre Evacuate Collection Set: 0.4ms
[43.866s][info ][gc,phases   ] GC(12)   Merge Heap Roots: 0.4ms
[43.866s][info ][gc,phases   ] GC(12)   Evacuate Collection Set: 1.3ms
[43.866s][info ][gc,phases   ] GC(12)   Post Evacuate Collection Set: 1.2ms
[43.866s][info ][gc,phases   ] GC(12)   Other: 0.4ms
[43.866s][info ][gc,heap     ] GC(12) Eden regions: 408->0(408)
[43.866s][info ][gc,heap     ] GC(12) Survivor regions: 1->1(52)
[43.866s][info ][gc,heap     ] GC(12) Old regions: 0->0
[43.866s][info ][gc,heap     ] GC(12) Archive regions: 2->2
[43.866s][info ][gc,heap     ] GC(12) Humongous regions: 0->0
[43.866s][info ][gc,metaspace] GC(12) Metaspace: 907K(1088K)->907K(1088K) NonClass: 823K(896K)->823K(896K) Class: 83K(192K)->83K(192K)
[43.866s][info ][gc          ] GC(12) Pause Young (Normal) (G1 Evacuation Pause) 409M->1M(2048M) 3.694ms
[43.866s][info ][gc,cpu      ] GC(12) User=0.02s Sys=0.01s Real=0.00s
[47.697s][info ][gc,start    ] GC(13) Pause Young (Normal) (G1 Evacuation Pause)
[47.697s][info ][gc,task     ] GC(13) Using 15 workers of 15 for evacuation
[47.697s][debug][gc,age      ] GC(13) Desired survivor size 27262976 bytes, new threshold 15 (max threshold 15)
[47.698s][trace][gc,age      ] GC(13) Age table with threshold 15 (max threshold 15)
[47.698s][trace][gc,age      ] GC(13) - age   1:      14992 bytes,      14992 total
[47.698s][trace][gc,age      ] GC(13) - age  12:        368 bytes,      15360 total
[47.698s][trace][gc,age      ] GC(13) - age  13:         56 bytes,      15416 total
[47.698s][trace][gc,age      ] GC(13) - age  14:     419440 bytes,     434856 total
[47.698s][info ][gc,phases   ] GC(13)   Pre Evacuate Collection Set: 0.2ms
[47.698s][info ][gc,phases   ] GC(13)   Merge Heap Roots: 0.1ms
[47.698s][info ][gc,phases   ] GC(13)   Evacuate Collection Set: 0.5ms
[47.698s][info ][gc,phases   ] GC(13)   Post Evacuate Collection Set: 0.4ms
[47.698s][info ][gc,phases   ] GC(13)   Other: 0.1ms
[47.698s][info ][gc,heap     ] GC(13) Eden regions: 408->0(408)
[47.698s][info ][gc,heap     ] GC(13) Survivor regions: 1->1(52)
[47.698s][info ][gc,heap     ] GC(13) Old regions: 0->0
[47.698s][info ][gc,heap     ] GC(13) Archive regions: 2->2
[47.698s][info ][gc,heap     ] GC(13) Humongous regions: 0->0
[47.698s][info ][gc,metaspace] GC(13) Metaspace: 907K(1088K)->907K(1088K) NonClass: 823K(896K)->823K(896K) Class: 83K(192K)->83K(192K)
[47.698s][info ][gc          ] GC(13) Pause Young (Normal) (G1 Evacuation Pause) 409M->1M(2048M) 1.438ms
[47.698s][info ][gc,cpu      ] GC(13) User=0.01s Sys=0.01s Real=0.00s
[51.553s][info ][gc,start    ] GC(14) Pause Young (Normal) (G1 Evacuation Pause)
[51.553s][info ][gc,task     ] GC(14) Using 15 workers of 15 for evacuation
[51.553s][debug][gc,age      ] GC(14) Desired survivor size 27262976 bytes, new threshold 15 (max threshold 15)
[51.557s][trace][gc,age      ] GC(14) Age table with threshold 15 (max threshold 15)
[51.557s][trace][gc,age      ] GC(14) - age   1:       1592 bytes,       1592 total
[51.557s][trace][gc,age      ] GC(14) - age  13:        368 bytes,       1960 total
[51.557s][trace][gc,age      ] GC(14) - age  14:         56 bytes,       2016 total
[51.557s][trace][gc,age      ] GC(14) - age  15:     419440 bytes,     421456 total
[51.557s][info ][gc,phases   ] GC(14)   Pre Evacuate Collection Set: 0.4ms
[51.557s][info ][gc,phases   ] GC(14)   Merge Heap Roots: 0.5ms
[51.557s][info ][gc,phases   ] GC(14)   Evacuate Collection Set: 1.4ms
[51.557s][info ][gc,phases   ] GC(14)   Post Evacuate Collection Set: 1.3ms
[51.557s][info ][gc,phases   ] GC(14)   Other: 0.5ms
[51.557s][info ][gc,heap     ] GC(14) Eden regions: 408->0(408)
[51.557s][info ][gc,heap     ] GC(14) Survivor regions: 1->1(52)
[51.557s][info ][gc,heap     ] GC(14) Old regions: 0->0
[51.557s][info ][gc,heap     ] GC(14) Archive regions: 2->2
[51.557s][info ][gc,heap     ] GC(14) Humongous regions: 0->0
[51.557s][info ][gc,metaspace] GC(14) Metaspace: 907K(1088K)->907K(1088K) NonClass: 823K(896K)->823K(896K) Class: 83K(192K)->83K(192K)
[51.557s][info ][gc          ] GC(14) Pause Young (Normal) (G1 Evacuation Pause) 409M->1M(2048M) 4.279ms
[51.557s][info ][gc,cpu      ] GC(14) User=0.01s Sys=0.01s Real=0.00s
[55.383s][info ][gc,start    ] GC(15) Pause Young (Normal) (G1 Evacuation Pause)
[55.383s][info ][gc,task     ] GC(15) Using 15 workers of 15 for evacuation
[55.383s][debug][gc,age      ] GC(15) Desired survivor size 27262976 bytes, new threshold 15 (max threshold 15)
[55.387s][trace][gc,age      ] GC(15) Age table with threshold 15 (max threshold 15)
[55.387s][trace][gc,age      ] GC(15) - age   1:      14992 bytes,      14992 total
[55.387s][trace][gc,age      ] GC(15) - age  14:        368 bytes,      15360 total
[55.387s][trace][gc,age      ] GC(15) - age  15:         56 bytes,      15416 total
[55.387s][info ][gc,phases   ] GC(15)   Pre Evacuate Collection Set: 0.4ms
[55.387s][info ][gc,phases   ] GC(15)   Merge Heap Roots: 0.5ms
[55.387s][info ][gc,phases   ] GC(15)   Evacuate Collection Set: 1.3ms
[55.387s][info ][gc,phases   ] GC(15)   Post Evacuate Collection Set: 1.2ms
[55.387s][info ][gc,phases   ] GC(15)   Other: 0.4ms
[55.387s][info ][gc,heap     ] GC(15) Eden regions: 408->0(408)
[55.387s][info ][gc,heap     ] GC(15) Survivor regions: 1->1(52)
[55.387s][info ][gc,heap     ] GC(15) Old regions: 0->1
[55.387s][info ][gc,heap     ] GC(15) Archive regions: 2->2
[55.387s][info ][gc,heap     ] GC(15) Humongous regions: 0->0
[55.387s][info ][gc,metaspace] GC(15) Metaspace: 907K(1088K)->907K(1088K) NonClass: 823K(896K)->823K(896K) Class: 83K(192K)->83K(192K)
[55.387s][info ][gc          ] GC(15) Pause Young (Normal) (G1 Evacuation Pause) 409M->1M(2048M) 3.864ms
[55.387s][info ][gc,cpu      ] GC(15) User=0.02s Sys=0.00s Real=0.00s
[59.232s][info ][gc,start    ] GC(16) Pause Young (Normal) (G1 Evacuation Pause)
[59.233s][info ][gc,task     ] GC(16) Using 15 workers of 15 for evacuation
[59.233s][debug][gc,age      ] GC(16) Desired survivor size 27262976 bytes, new threshold 15 (max threshold 15)
[59.235s][trace][gc,age      ] GC(16) Age table with threshold 15 (max threshold 15)
[59.236s][trace][gc,age      ] GC(16) - age   1:       8080 bytes,       8080 total
[59.236s][trace][gc,age      ] GC(16) - age  15:        368 bytes,       8448 total
[59.236s][info ][gc,phases   ] GC(16)   Pre Evacuate Collection Set: 0.5ms
[59.236s][info ][gc,phases   ] GC(16)   Merge Heap Roots: 0.4ms
[59.236s][info ][gc,phases   ] GC(16)   Evacuate Collection Set: 0.7ms
[59.236s][info ][gc,phases   ] GC(16)   Post Evacuate Collection Set: 1.1ms
[59.236s][info ][gc,phases   ] GC(16)   Other: 0.5ms
[59.236s][info ][gc,heap     ] GC(16) Eden regions: 408->0(408)
[59.236s][info ][gc,heap     ] GC(16) Survivor regions: 1->1(52)
[59.236s][info ][gc,heap     ] GC(16) Old regions: 1->1
[59.236s][info ][gc,heap     ] GC(16) Archive regions: 2->2
[59.236s][info ][gc,heap     ] GC(16) Humongous regions: 0->0
[59.236s][info ][gc,metaspace] GC(16) Metaspace: 907K(1088K)->907K(1088K) NonClass: 823K(896K)->823K(896K) Class: 83K(192K)->83K(192K)
[59.236s][info ][gc          ] GC(16) Pause Young (Normal) (G1 Evacuation Pause) 409M->1M(2048M) 3.352ms
[59.236s][info ][gc,cpu      ] GC(16) User=0.01s Sys=0.00s Real=0.00s
[63.067s][info ][gc,start    ] GC(17) Pause Young (Normal) (G1 Evacuation Pause)
[63.067s][info ][gc,task     ] GC(17) Using 15 workers of 15 for evacuation
[63.067s][debug][gc,age      ] GC(17) Desired survivor size 27262976 bytes, new threshold 15 (max threshold 15)
[63.070s][trace][gc,age      ] GC(17) Age table with threshold 15 (max threshold 15)
[63.070s][trace][gc,age      ] GC(17) - age   1:       1592 bytes,       1592 total
[63.070s][info ][gc,phases   ] GC(17)   Pre Evacuate Collection Set: 0.3ms
[63.070s][info ][gc,phases   ] GC(17)   Merge Heap Roots: 0.3ms
[63.070s][info ][gc,phases   ] GC(17)   Evacuate Collection Set: 0.6ms
[63.070s][info ][gc,phases   ] GC(17)   Post Evacuate Collection Set: 0.8ms
[63.070s][info ][gc,phases   ] GC(17)   Other: 0.4ms
[63.070s][info ][gc,heap     ] GC(17) Eden regions: 408->0(408)
[63.070s][info ][gc,heap     ] GC(17) Survivor regions: 1->1(52)
[63.070s][info ][gc,heap     ] GC(17) Old regions: 1->1
[63.070s][info ][gc,heap     ] GC(17) Archive regions: 2->2
[63.070s][info ][gc,heap     ] GC(17) Humongous regions: 0->0
[63.070s][info ][gc,metaspace] GC(17) Metaspace: 907K(1088K)->907K(1088K) NonClass: 823K(896K)->823K(896K) Class: 83K(192K)->83K(192K)
[63.070s][info ][gc          ] GC(17) Pause Young (Normal) (G1 Evacuation Pause) 409M->1M(2048M) 2.541ms
[63.070s][info ][gc,cpu      ] GC(17) User=0.02s Sys=0.00s Real=0.00s
[66.905s][info ][gc,start    ] GC(18) Pause Young (Normal) (G1 Evacuation Pause)
[66.905s][info ][gc,task     ] GC(18) Using 15 workers of 15 for evacuation
[66.905s][debug][gc,age      ] GC(18) Desired survivor size 27262976 bytes, new threshold 15 (max threshold 15)
[66.908s][trace][gc,age      ] GC(18) Age table with threshold 15 (max threshold 15)
[66.908s][trace][gc,age      ] GC(18) - age   1:      14992 bytes,      14992 total
[66.908s][info ][gc,phases   ] GC(18)   Pre Evacuate Collection Set: 0.4ms
[66.908s][info ][gc,phases   ] GC(18)   Merge Heap Roots: 0.5ms
[66.908s][info ][gc,phases   ] GC(18)   Evacuate Collection Set: 0.5ms
[66.908s][info ][gc,phases   ] GC(18)   Post Evacuate Collection Set: 1.1ms
[66.908s][info ][gc,phases   ] GC(18)   Other: 0.5ms
[66.908s][info ][gc,heap     ] GC(18) Eden regions: 408->0(408)
[66.908s][info ][gc,heap     ] GC(18) Survivor regions: 1->1(52)
[66.908s][info ][gc,heap     ] GC(18) Old regions: 1->1
[66.908s][info ][gc,heap     ] GC(18) Archive regions: 2->2
[66.908s][info ][gc,heap     ] GC(18) Humongous regions: 0->0
[66.908s][info ][gc,metaspace] GC(18) Metaspace: 907K(1088K)->907K(1088K) NonClass: 823K(896K)->823K(896K) Class: 83K(192K)->83K(192K)
[66.908s][info ][gc          ] GC(18) Pause Young (Normal) (G1 Evacuation Pause) 409M->1M(2048M) 3.019ms
[66.908s][info ][gc,cpu      ] GC(18) User=0.02s Sys=0.00s Real=0.00s
[70.735s][info ][gc,start    ] GC(19) Pause Young (Normal) (G1 Evacuation Pause)
[70.735s][info ][gc,task     ] GC(19) Using 15 workers of 15 for evacuation
[70.735s][debug][gc,age      ] GC(19) Desired survivor size 27262976 bytes, new threshold 15 (max threshold 15)
[70.737s][trace][gc,age      ] GC(19) Age table with threshold 15 (max threshold 15)
[70.737s][trace][gc,age      ] GC(19) - age   1:      14992 bytes,      14992 total
[70.737s][info ][gc,phases   ] GC(19)   Pre Evacuate Collection Set: 0.5ms
[70.737s][info ][gc,phases   ] GC(19)   Merge Heap Roots: 0.4ms
[70.737s][info ][gc,phases   ] GC(19)   Evacuate Collection Set: 0.5ms
[70.738s][info ][gc,phases   ] GC(19)   Post Evacuate Collection Set: 1.2ms
[70.738s][info ][gc,phases   ] GC(19)   Other: 0.4ms
[70.738s][info ][gc,heap     ] GC(19) Eden regions: 408->0(408)
[70.738s][info ][gc,heap     ] GC(19) Survivor regions: 1->1(52)
[70.738s][info ][gc,heap     ] GC(19) Old regions: 1->1
[70.738s][info ][gc,heap     ] GC(19) Archive regions: 2->2
[70.738s][info ][gc,heap     ] GC(19) Humongous regions: 0->0
[70.738s][info ][gc,metaspace] GC(19) Metaspace: 907K(1088K)->907K(1088K) NonClass: 823K(896K)->823K(896K) Class: 83K(192K)->83K(192K)
[70.738s][info ][gc          ] GC(19) Pause Young (Normal) (G1 Evacuation Pause) 409M->1M(2048M) 2.987ms
[70.738s][info ][gc,cpu      ] GC(19) User=0.00s Sys=0.01s Real=0.00s
[74.569s][info ][gc,start    ] GC(20) Pause Young (Normal) (G1 Evacuation Pause)
[74.569s][info ][gc,task     ] GC(20) Using 15 workers of 15 for evacuation
[74.569s][debug][gc,age      ] GC(20) Desired survivor size 27262976 bytes, new threshold 15 (max threshold 15)
[74.572s][trace][gc,age      ] GC(20) Age table with threshold 15 (max threshold 15)
[74.572s][trace][gc,age      ] GC(20) - age   1:       1592 bytes,       1592 total
[74.572s][info ][gc,phases   ] GC(20)   Pre Evacuate Collection Set: 0.5ms
[74.572s][info ][gc,phases   ] GC(20)   Merge Heap Roots: 0.5ms
[74.572s][info ][gc,phases   ] GC(20)   Evacuate Collection Set: 0.6ms
[74.572s][info ][gc,phases   ] GC(20)   Post Evacuate Collection Set: 1.2ms
[74.572s][info ][gc,phases   ] GC(20)   Other: 0.4ms
[74.572s][info ][gc,heap     ] GC(20) Eden regions: 408->0(408)
[74.572s][info ][gc,heap     ] GC(20) Survivor regions: 1->1(52)
[74.572s][info ][gc,heap     ] GC(20) Old regions: 1->1
[74.572s][info ][gc,heap     ] GC(20) Archive regions: 2->2
[74.572s][info ][gc,heap     ] GC(20) Humongous regions: 0->0
[74.572s][info ][gc,metaspace] GC(20) Metaspace: 907K(1088K)->907K(1088K) NonClass: 823K(896K)->823K(896K) Class: 83K(192K)->83K(192K)
[74.572s][info ][gc          ] GC(20) Pause Young (Normal) (G1 Evacuation Pause) 409M->1M(2048M) 3.247ms
[74.573s][info ][gc,cpu      ] GC(20) User=0.01s Sys=0.00s Real=0.01s
[78.415s][info ][gc,start    ] GC(21) Pause Young (Normal) (G1 Evacuation Pause)
[78.416s][info ][gc,task     ] GC(21) Using 15 workers of 15 for evacuation
[78.416s][debug][gc,age      ] GC(21) Desired survivor size 27262976 bytes, new threshold 15 (max threshold 15)
[78.419s][trace][gc,age      ] GC(21) Age table with threshold 15 (max threshold 15)
[78.419s][trace][gc,age      ] GC(21) - age   1:      10352 bytes,      10352 total
[78.419s][info ][gc,phases   ] GC(21)   Pre Evacuate Collection Set: 0.4ms
[78.419s][info ][gc,phases   ] GC(21)   Merge Heap Roots: 0.4ms
[78.419s][info ][gc,phases   ] GC(21)   Evacuate Collection Set: 0.7ms
[78.419s][info ][gc,phases   ] GC(21)   Post Evacuate Collection Set: 1.3ms
[78.419s][info ][gc,phases   ] GC(21)   Other: 0.4ms
[78.419s][info ][gc,heap     ] GC(21) Eden regions: 408->0(408)
[78.419s][info ][gc,heap     ] GC(21) Survivor regions: 1->1(52)
[78.419s][info ][gc,heap     ] GC(21) Old regions: 1->1
[78.419s][info ][gc,heap     ] GC(21) Archive regions: 2->2
[78.419s][info ][gc,heap     ] GC(21) Humongous regions: 0->0
[78.419s][info ][gc,metaspace] GC(21) Metaspace: 907K(1088K)->907K(1088K) NonClass: 823K(896K)->823K(896K) Class: 83K(192K)->83K(192K)
[78.419s][info ][gc          ] GC(21) Pause Young (Normal) (G1 Evacuation Pause) 409M->1M(2048M) 3.332ms
[78.419s][info ][gc,cpu      ] GC(21) User=0.01s Sys=0.00s Real=0.00s
[82.258s][info ][gc,start    ] GC(22) Pause Young (Normal) (G1 Evacuation Pause)
[82.258s][info ][gc,task     ] GC(22) Using 15 workers of 15 for evacuation
[82.258s][debug][gc,age      ] GC(22) Desired survivor size 27262976 bytes, new threshold 15 (max threshold 15)
[82.261s][trace][gc,age      ] GC(22) Age table with threshold 15 (max threshold 15)
[82.261s][trace][gc,age      ] GC(22) - age   1:      20096 bytes,      20096 total
[82.261s][info ][gc,phases   ] GC(22)   Pre Evacuate Collection Set: 0.4ms
[82.261s][info ][gc,phases   ] GC(22)   Merge Heap Roots: 0.3ms
[82.261s][info ][gc,phases   ] GC(22)   Evacuate Collection Set: 0.5ms
[82.261s][info ][gc,phases   ] GC(22)   Post Evacuate Collection Set: 0.9ms
[82.261s][info ][gc,phases   ] GC(22)   Other: 0.4ms
[82.261s][info ][gc,heap     ] GC(22) Eden regions: 408->0(408)
[82.261s][info ][gc,heap     ] GC(22) Survivor regions: 1->1(52)
[82.261s][info ][gc,heap     ] GC(22) Old regions: 1->1
[82.261s][info ][gc,heap     ] GC(22) Archive regions: 2->2
[82.261s][info ][gc,heap     ] GC(22) Humongous regions: 0->0
[82.261s][info ][gc,metaspace] GC(22) Metaspace: 907K(1088K)->907K(1088K) NonClass: 823K(896K)->823K(896K) Class: 83K(192K)->83K(192K)
[82.261s][info ][gc          ] GC(22) Pause Young (Normal) (G1 Evacuation Pause) 409M->1M(2048M) 2.569ms
[82.261s][info ][gc,cpu      ] GC(22) User=0.01s Sys=0.00s Real=0.01s
[86.086s][info ][gc,start    ] GC(23) Pause Young (Normal) (G1 Evacuation Pause)
[86.086s][info ][gc,task     ] GC(23) Using 15 workers of 15 for evacuation
[86.086s][debug][gc,age      ] GC(23) Desired survivor size 27262976 bytes, new threshold 15 (max threshold 15)
[86.088s][trace][gc,age      ] GC(23) Age table with threshold 15 (max threshold 15)
[86.088s][trace][gc,age      ] GC(23) - age   1:      13968 bytes,      13968 total
[86.088s][info ][gc,phases   ] GC(23)   Pre Evacuate Collection Set: 0.3ms
[86.088s][info ][gc,phases   ] GC(23)   Merge Heap Roots: 0.3ms
[86.088s][info ][gc,phases   ] GC(23)   Evacuate Collection Set: 0.4ms
[86.088s][info ][gc,phases   ] GC(23)   Post Evacuate Collection Set: 0.8ms
[86.088s][info ][gc,phases   ] GC(23)   Other: 0.3ms
[86.088s][info ][gc,heap     ] GC(23) Eden regions: 408->0(408)
[86.088s][info ][gc,heap     ] GC(23) Survivor regions: 1->1(52)
[86.088s][info ][gc,heap     ] GC(23) Old regions: 1->1
[86.088s][info ][gc,heap     ] GC(23) Archive regions: 2->2
[86.088s][info ][gc,heap     ] GC(23) Humongous regions: 0->0
[86.088s][info ][gc,metaspace] GC(23) Metaspace: 907K(1088K)->907K(1088K) NonClass: 823K(896K)->823K(896K) Class: 83K(192K)->83K(192K)
[86.088s][info ][gc          ] GC(23) Pause Young (Normal) (G1 Evacuation Pause) 409M->1M(2048M) 2.052ms
[86.088s][info ][gc,cpu      ] GC(23) User=0.01s Sys=0.01s Real=0.00s
[89.918s][info ][gc,start    ] GC(24) Pause Young (Normal) (G1 Evacuation Pause)
[89.918s][info ][gc,task     ] GC(24) Using 15 workers of 15 for evacuation
[89.918s][debug][gc,age      ] GC(24) Desired survivor size 27262976 bytes, new threshold 15 (max threshold 15)
[89.920s][trace][gc,age      ] GC(24) Age table with threshold 15 (max threshold 15)
[89.920s][trace][gc,age      ] GC(24) - age   1:       1592 bytes,       1592 total
[89.920s][info ][gc,phases   ] GC(24)   Pre Evacuate Collection Set: 0.5ms
[89.920s][info ][gc,phases   ] GC(24)   Merge Heap Roots: 0.4ms
[89.920s][info ][gc,phases   ] GC(24)   Evacuate Collection Set: 0.6ms
[89.920s][info ][gc,phases   ] GC(24)   Post Evacuate Collection Set: 1.0ms
[89.920s][info ][gc,phases   ] GC(24)   Other: 0.5ms
[89.920s][info ][gc,heap     ] GC(24) Eden regions: 408->0(408)
[89.920s][info ][gc,heap     ] GC(24) Survivor regions: 1->1(52)
[89.920s][info ][gc,heap     ] GC(24) Old regions: 1->1
[89.920s][info ][gc,heap     ] GC(24) Archive regions: 2->2
[89.920s][info ][gc,heap     ] GC(24) Humongous regions: 0->0
[89.921s][info ][gc,metaspace] GC(24) Metaspace: 907K(1088K)->907K(1088K) NonClass: 823K(896K)->823K(896K) Class: 83K(192K)->83K(192K)
[89.921s][info ][gc          ] GC(24) Pause Young (Normal) (G1 Evacuation Pause) 409M->1M(2048M) 3.030ms
[89.921s][info ][gc,cpu      ] GC(24) User=0.01s Sys=0.01s Real=0.01s
[93.739s][info ][gc,start    ] GC(25) Pause Young (Normal) (G1 Evacuation Pause)
[93.739s][info ][gc,task     ] GC(25) Using 15 workers of 15 for evacuation
[93.739s][debug][gc,age      ] GC(25) Desired survivor size 27262976 bytes, new threshold 15 (max threshold 15)
[93.742s][trace][gc,age      ] GC(25) Age table with threshold 15 (max threshold 15)
[93.742s][trace][gc,age      ] GC(25) - age   1:      10384 bytes,      10384 total
[93.743s][info ][gc,phases   ] GC(25)   Pre Evacuate Collection Set: 0.5ms
[93.743s][info ][gc,phases   ] GC(25)   Merge Heap Roots: 0.4ms
[93.743s][info ][gc,phases   ] GC(25)   Evacuate Collection Set: 0.6ms
[93.743s][info ][gc,phases   ] GC(25)   Post Evacuate Collection Set: 1.4ms
[93.743s][info ][gc,phases   ] GC(25)   Other: 0.4ms
[93.743s][info ][gc,heap     ] GC(25) Eden regions: 408->0(408)
[93.743s][info ][gc,heap     ] GC(25) Survivor regions: 1->1(52)
[93.743s][info ][gc,heap     ] GC(25) Old regions: 1->1
[93.743s][info ][gc,heap     ] GC(25) Archive regions: 2->2
[93.743s][info ][gc,heap     ] GC(25) Humongous regions: 0->0
[93.743s][info ][gc,metaspace] GC(25) Metaspace: 907K(1088K)->907K(1088K) NonClass: 823K(896K)->823K(896K) Class: 83K(192K)->83K(192K)
[93.743s][info ][gc          ] GC(25) Pause Young (Normal) (G1 Evacuation Pause) 409M->1M(2048M) 3.383ms
[93.743s][info ][gc,cpu      ] GC(25) User=0.02s Sys=0.00s Real=0.01s
[97.567s][info ][gc,start    ] GC(26) Pause Young (Normal) (G1 Evacuation Pause)
[97.567s][info ][gc,task     ] GC(26) Using 15 workers of 15 for evacuation
[97.567s][debug][gc,age      ] GC(26) Desired survivor size 27262976 bytes, new threshold 15 (max threshold 15)
[97.569s][trace][gc,age      ] GC(26) Age table with threshold 15 (max threshold 15)
[97.569s][trace][gc,age      ] GC(26) - age   1:       6352 bytes,       6352 total
[97.569s][info ][gc,phases   ] GC(26)   Pre Evacuate Collection Set: 0.3ms
[97.569s][info ][gc,phases   ] GC(26)   Merge Heap Roots: 0.2ms
[97.569s][info ][gc,phases   ] GC(26)   Evacuate Collection Set: 0.4ms
[97.569s][info ][gc,phases   ] GC(26)   Post Evacuate Collection Set: 0.8ms
[97.569s][info ][gc,phases   ] GC(26)   Other: 0.3ms
[97.569s][info ][gc,heap     ] GC(26) Eden regions: 408->0(408)
[97.569s][info ][gc,heap     ] GC(26) Survivor regions: 1->1(52)
[97.569s][info ][gc,heap     ] GC(26) Old regions: 1->1
[97.569s][info ][gc,heap     ] GC(26) Archive regions: 2->2
[97.569s][info ][gc,heap     ] GC(26) Humongous regions: 0->0
[97.569s][info ][gc,metaspace] GC(26) Metaspace: 907K(1088K)->907K(1088K) NonClass: 823K(896K)->823K(896K) Class: 83K(192K)->83K(192K)
[97.569s][info ][gc          ] GC(26) Pause Young (Normal) (G1 Evacuation Pause) 409M->1M(2048M) 2.035ms
[97.569s][info ][gc,cpu      ] GC(26) User=0.01s Sys=0.00s Real=0.00s
[101.405s][info ][gc,start    ] GC(27) Pause Young (Normal) (G1 Evacuation Pause)
[101.405s][info ][gc,task     ] GC(27) Using 15 workers of 15 for evacuation
[101.405s][debug][gc,age      ] GC(27) Desired survivor size 27262976 bytes, new threshold 15 (max threshold 15)
[101.407s][trace][gc,age      ] GC(27) Age table with threshold 15 (max threshold 15)
[101.407s][trace][gc,age      ] GC(27) - age   1:       6928 bytes,       6928 total
[101.407s][info ][gc,phases   ] GC(27)   Pre Evacuate Collection Set: 0.4ms
[101.407s][info ][gc,phases   ] GC(27)   Merge Heap Roots: 0.6ms
[101.407s][info ][gc,phases   ] GC(27)   Evacuate Collection Set: 0.5ms
[101.407s][info ][gc,phases   ] GC(27)   Post Evacuate Collection Set: 0.7ms
[101.408s][info ][gc,phases   ] GC(27)   Other: 0.5ms
[101.408s][info ][gc,heap     ] GC(27) Eden regions: 408->0(408)
[101.408s][info ][gc,heap     ] GC(27) Survivor regions: 1->1(52)
[101.408s][info ][gc,heap     ] GC(27) Old regions: 1->1
[101.408s][info ][gc,heap     ] GC(27) Archive regions: 2->2
[101.408s][info ][gc,heap     ] GC(27) Humongous regions: 0->0
[101.408s][info ][gc,metaspace] GC(27) Metaspace: 907K(1088K)->907K(1088K) NonClass: 823K(896K)->823K(896K) Class: 83K(192K)->83K(192K)
[101.408s][info ][gc          ] GC(27) Pause Young (Normal) (G1 Evacuation Pause) 409M->1M(2048M) 2.770ms
[101.408s][info ][gc,cpu      ] GC(27) User=0.02s Sys=0.00s Real=0.00s
[105.260s][info ][gc,start    ] GC(28) Pause Young (Normal) (G1 Evacuation Pause)
[105.260s][info ][gc,task     ] GC(28) Using 15 workers of 15 for evacuation
[105.260s][debug][gc,age      ] GC(28) Desired survivor size 27262976 bytes, new threshold 15 (max threshold 15)
[105.262s][trace][gc,age      ] GC(28) Age table with threshold 15 (max threshold 15)
[105.262s][trace][gc,age      ] GC(28) - age   1:       1648 bytes,       1648 total
[105.262s][info ][gc,phases   ] GC(28)   Pre Evacuate Collection Set: 0.3ms
[105.262s][info ][gc,phases   ] GC(28)   Merge Heap Roots: 0.3ms
[105.262s][info ][gc,phases   ] GC(28)   Evacuate Collection Set: 0.5ms
[105.262s][info ][gc,phases   ] GC(28)   Post Evacuate Collection Set: 0.8ms
[105.262s][info ][gc,phases   ] GC(28)   Other: 0.3ms
[105.262s][info ][gc,heap     ] GC(28) Eden regions: 408->0(408)
[105.262s][info ][gc,heap     ] GC(28) Survivor regions: 1->1(52)
[105.262s][info ][gc,heap     ] GC(28) Old regions: 1->1
[105.262s][info ][gc,heap     ] GC(28) Archive regions: 2->2
[105.262s][info ][gc,heap     ] GC(28) Humongous regions: 0->0
[105.262s][info ][gc,metaspace] GC(28) Metaspace: 907K(1088K)->907K(1088K) NonClass: 823K(896K)->823K(896K) Class: 83K(192K)->83K(192K)
[105.262s][info ][gc          ] GC(28) Pause Young (Normal) (G1 Evacuation Pause) 409M->1M(2048M) 2.203ms
[105.263s][info ][gc,cpu      ] GC(28) User=0.01s Sys=0.00s Real=0.00s
[109.086s][info ][gc,start    ] GC(29) Pause Young (Normal) (G1 Evacuation Pause)
[109.086s][info ][gc,task     ] GC(29) Using 15 workers of 15 for evacuation
[109.086s][debug][gc,age      ] GC(29) Desired survivor size 27262976 bytes, new threshold 15 (max threshold 15)
[109.089s][trace][gc,age      ] GC(29) Age table with threshold 15 (max threshold 15)
[109.089s][trace][gc,age      ] GC(29) - age   1:      20064 bytes,      20064 total
[109.089s][info ][gc,phases   ] GC(29)   Pre Evacuate Collection Set: 0.4ms
[109.089s][info ][gc,phases   ] GC(29)   Merge Heap Roots: 0.5ms
[109.089s][info ][gc,phases   ] GC(29)   Evacuate Collection Set: 0.4ms
[109.089s][info ][gc,phases   ] GC(29)   Post Evacuate Collection Set: 1.0ms
[109.089s][info ][gc,phases   ] GC(29)   Other: 0.4ms
[109.089s][info ][gc,heap     ] GC(29) Eden regions: 408->0(408)
[109.089s][info ][gc,heap     ] GC(29) Survivor regions: 1->1(52)
[109.089s][info ][gc,heap     ] GC(29) Old regions: 1->1
[109.089s][info ][gc,heap     ] GC(29) Archive regions: 2->2
[109.089s][info ][gc,heap     ] GC(29) Humongous regions: 0->0
[109.089s][info ][gc,metaspace] GC(29) Metaspace: 907K(1088K)->907K(1088K) NonClass: 823K(896K)->823K(896K) Class: 83K(192K)->83K(192K)
[109.089s][info ][gc          ] GC(29) Pause Young (Normal) (G1 Evacuation Pause) 409M->1M(2048M) 2.798ms
[109.089s][info ][gc,cpu      ] GC(29) User=0.02s Sys=0.00s Real=0.00s
[112.934s][info ][gc,start    ] GC(30) Pause Young (Normal) (G1 Evacuation Pause)
[112.934s][info ][gc,task     ] GC(30) Using 15 workers of 15 for evacuation
[112.934s][debug][gc,age      ] GC(30) Desired survivor size 27262976 bytes, new threshold 15 (max threshold 15)
[112.937s][trace][gc,age      ] GC(30) Age table with threshold 15 (max threshold 15)
[112.937s][trace][gc,age      ] GC(30) - age   1:       8080 bytes,       8080 total
[112.937s][info ][gc,phases   ] GC(30)   Pre Evacuate Collection Set: 0.4ms
[112.937s][info ][gc,phases   ] GC(30)   Merge Heap Roots: 0.6ms
[112.937s][info ][gc,phases   ] GC(30)   Evacuate Collection Set: 0.6ms
[112.937s][info ][gc,phases   ] GC(30)   Post Evacuate Collection Set: 1.2ms
[112.937s][info ][gc,phases   ] GC(30)   Other: 0.5ms
[112.937s][info ][gc,heap     ] GC(30) Eden regions: 408->0(408)
[112.937s][info ][gc,heap     ] GC(30) Survivor regions: 1->1(52)
[112.937s][info ][gc,heap     ] GC(30) Old regions: 1->1
[112.937s][info ][gc,heap     ] GC(30) Archive regions: 2->2
[112.937s][info ][gc,heap     ] GC(30) Humongous regions: 0->0
[112.937s][info ][gc,metaspace] GC(30) Metaspace: 907K(1088K)->907K(1088K) NonClass: 823K(896K)->823K(896K) Class: 83K(192K)->83K(192K)
[112.937s][info ][gc          ] GC(30) Pause Young (Normal) (G1 Evacuation Pause) 409M->1M(2048M) 3.272ms
[112.937s][info ][gc,cpu      ] GC(30) User=0.02s Sys=0.00s Real=0.00s
[116.765s][info ][gc,start    ] GC(31) Pause Young (Normal) (G1 Evacuation Pause)
[116.765s][info ][gc,task     ] GC(31) Using 15 workers of 15 for evacuation
[116.765s][debug][gc,age      ] GC(31) Desired survivor size 27262976 bytes, new threshold 15 (max threshold 15)
[116.768s][trace][gc,age      ] GC(31) Age table with threshold 15 (max threshold 15)
[116.768s][trace][gc,age      ] GC(31) - age   1:       8080 bytes,       8080 total
[116.768s][info ][gc,phases   ] GC(31)   Pre Evacuate Collection Set: 0.4ms
[116.768s][info ][gc,phases   ] GC(31)   Merge Heap Roots: 0.6ms
[116.768s][info ][gc,phases   ] GC(31)   Evacuate Collection Set: 0.6ms
[116.768s][info ][gc,phases   ] GC(31)   Post Evacuate Collection Set: 0.9ms
[116.768s][info ][gc,phases   ] GC(31)   Other: 0.4ms
[116.768s][info ][gc,heap     ] GC(31) Eden regions: 408->0(408)
[116.768s][info ][gc,heap     ] GC(31) Survivor regions: 1->1(52)
[116.768s][info ][gc,heap     ] GC(31) Old regions: 1->1
[116.768s][info ][gc,heap     ] GC(31) Archive regions: 2->2
[116.768s][info ][gc,heap     ] GC(31) Humongous regions: 0->0
[116.768s][info ][gc,metaspace] GC(31) Metaspace: 907K(1088K)->907K(1088K) NonClass: 823K(896K)->823K(896K) Class: 83K(192K)->83K(192K)
[116.768s][info ][gc          ] GC(31) Pause Young (Normal) (G1 Evacuation Pause) 409M->1M(2048M) 2.948ms
[116.768s][info ][gc,cpu      ] GC(31) User=0.01s Sys=0.01s Real=0.00s
[120.047s][info ][gc,task     ] GC(32) Using 15 workers of 15 for full compaction
[120.048s][info ][gc,start    ] GC(32) Pause Full (System.gc())
[120.048s][info ][gc,phases,start] GC(32) Phase 1: Mark live objects
[120.052s][info ][gc,phases      ] GC(32) Phase 1: Mark live objects 3.597ms
[120.052s][info ][gc,phases,start] GC(32) Phase 2: Prepare for compaction
[120.056s][info ][gc,phases      ] GC(32) Phase 2: Prepare for compaction 4.355ms
[120.056s][info ][gc,phases,start] GC(32) Phase 3: Adjust pointers
[120.058s][info ][gc,phases      ] GC(32) Phase 3: Adjust pointers 1.678ms
[120.058s][info ][gc,phases,start] GC(32) Phase 4: Compact heap
[120.059s][info ][gc,phases      ] GC(32) Phase 4: Compact heap 0.693ms
[120.063s][info ][gc,heap        ] GC(32) Eden regions: 349->0(409)
[120.063s][info ][gc,heap        ] GC(32) Survivor regions: 1->0(52)
[120.063s][info ][gc,heap        ] GC(32) Old regions: 1->11
[120.063s][info ][gc,heap        ] GC(32) Archive regions: 2->2
[120.063s][info ][gc,heap        ] GC(32) Humongous regions: 0->0
[120.063s][info ][gc,metaspace   ] GC(32) Metaspace: 907K(1088K)->907K(1088K) NonClass: 823K(896K)->823K(896K) Class: 83K(192K)->83K(192K)
[120.064s][info ][gc             ] GC(32) Pause Full (System.gc()) 349M->1M(2048M) 15.641ms
[120.064s][info ][gc,cpu         ] GC(32) User=0.02s Sys=0.13s Real=0.02s
[123.897s][info ][gc,start       ] GC(33) Pause Young (Normal) (G1 Evacuation Pause)
[123.897s][info ][gc,task        ] GC(33) Using 15 workers of 15 for evacuation
[123.897s][debug][gc,age         ] GC(33) Desired survivor size 27262976 bytes, new threshold 15 (max threshold 15)
[123.902s][trace][gc,age         ] GC(33) Age table with threshold 15 (max threshold 15)
[123.902s][trace][gc,age         ] GC(33) - age   1:     532064 bytes,     532064 total
[123.902s][info ][gc,phases      ] GC(33)   Pre Evacuate Collection Set: 0.5ms
[123.902s][info ][gc,phases      ] GC(33)   Merge Heap Roots: 0.4ms
[123.902s][info ][gc,phases      ] GC(33)   Evacuate Collection Set: 2.8ms
[123.902s][info ][gc,phases      ] GC(33)   Post Evacuate Collection Set: 0.5ms
[123.902s][info ][gc,phases      ] GC(33)   Other: 0.3ms
[123.902s][info ][gc,heap        ] GC(33) Eden regions: 409->0(408)
[123.902s][info ][gc,heap        ] GC(33) Survivor regions: 0->1(52)
[123.902s][info ][gc,heap        ] GC(33) Old regions: 11->11
[123.902s][info ][gc,heap        ] GC(33) Archive regions: 2->2
[123.902s][info ][gc,heap        ] GC(33) Humongous regions: 0->0
[123.902s][info ][gc,metaspace   ] GC(33) Metaspace: 907K(1088K)->907K(1088K) NonClass: 823K(896K)->823K(896K) Class: 83K(192K)->83K(192K)
[123.902s][info ][gc             ] GC(33) Pause Young (Normal) (G1 Evacuation Pause) 410M->1M(2048M) 4.665ms
[123.902s][info ][gc,cpu         ] GC(33) User=0.01s Sys=0.00s Real=0.01s
[127.724s][info ][gc,start       ] GC(34) Pause Young (Normal) (G1 Evacuation Pause)
[127.725s][info ][gc,task        ] GC(34) Using 15 workers of 15 for evacuation
[127.725s][debug][gc,age         ] GC(34) Desired survivor size 27262976 bytes, new threshold 15 (max threshold 15)
[127.730s][trace][gc,age         ] GC(34) Age table with threshold 15 (max threshold 15)
[127.730s][trace][gc,age         ] GC(34) - age   1:     363192 bytes,     363192 total
[127.730s][trace][gc,age         ] GC(34) - age   2:     518160 bytes,     881352 total
[127.730s][info ][gc,phases      ] GC(34)   Pre Evacuate Collection Set: 0.4ms
[127.730s][info ][gc,phases      ] GC(34)   Merge Heap Roots: 0.6ms
[127.730s][info ][gc,phases      ] GC(34)   Evacuate Collection Set: 3.7ms
[127.730s][info ][gc,phases      ] GC(34)   Post Evacuate Collection Set: 0.7ms
[127.730s][info ][gc,phases      ] GC(34)   Other: 0.4ms
[127.730s][info ][gc,heap        ] GC(34) Eden regions: 408->0(408)
[127.730s][info ][gc,heap        ] GC(34) Survivor regions: 1->1(52)
[127.730s][info ][gc,heap        ] GC(34) Old regions: 11->11
[127.730s][info ][gc,heap        ] GC(34) Archive regions: 2->2
[127.730s][info ][gc,heap        ] GC(34) Humongous regions: 0->0
[127.730s][info ][gc,metaspace   ] GC(34) Metaspace: 907K(1088K)->907K(1088K) NonClass: 823K(896K)->823K(896K) Class: 83K(192K)->83K(192K)
[127.730s][info ][gc             ] GC(34) Pause Young (Normal) (G1 Evacuation Pause) 409M->2M(2048M) 5.944ms
[127.730s][info ][gc,cpu         ] GC(34) User=0.02s Sys=0.00s Real=0.01s
[131.550s][info ][gc,start       ] GC(35) Pause Young (Normal) (G1 Evacuation Pause)
[131.550s][info ][gc,task        ] GC(35) Using 15 workers of 15 for evacuation
[131.550s][debug][gc,age         ] GC(35) Desired survivor size 27262976 bytes, new threshold 15 (max threshold 15)
[131.557s][trace][gc,age         ] GC(35) Age table with threshold 15 (max threshold 15)
[131.557s][trace][gc,age         ] GC(35) - age   1:     344472 bytes,     344472 total
[131.557s][trace][gc,age         ] GC(35) - age   2:     344128 bytes,     688600 total
[131.557s][trace][gc,age         ] GC(35) - age   3:     518160 bytes,    1206760 total
[131.557s][info ][gc,phases      ] GC(35)   Pre Evacuate Collection Set: 0.5ms
[131.557s][info ][gc,phases      ] GC(35)   Merge Heap Roots: 0.4ms
[131.557s][info ][gc,phases      ] GC(35)   Evacuate Collection Set: 5.0ms
[131.557s][info ][gc,phases      ] GC(35)   Post Evacuate Collection Set: 1.0ms
[131.557s][info ][gc,phases      ] GC(35)   Other: 0.4ms
[131.557s][info ][gc,heap        ] GC(35) Eden regions: 408->0(407)
[131.557s][info ][gc,heap        ] GC(35) Survivor regions: 1->2(52)
[131.557s][info ][gc,heap        ] GC(35) Old regions: 11->11
[131.557s][info ][gc,heap        ] GC(35) Archive regions: 2->2
[131.557s][info ][gc,heap        ] GC(35) Humongous regions: 0->0
[131.557s][info ][gc,metaspace   ] GC(35) Metaspace: 907K(1088K)->907K(1088K) NonClass: 823K(896K)->823K(896K) Class: 83K(192K)->83K(192K)
[131.557s][info ][gc             ] GC(35) Pause Young (Normal) (G1 Evacuation Pause) 410M->2M(2048M) 7.443ms
[131.557s][info ][gc,cpu         ] GC(35) User=0.03s Sys=0.00s Real=0.01s
[135.359s][info ][gc,start       ] GC(36) Pause Young (Normal) (G1 Evacuation Pause)
[135.359s][info ][gc,task        ] GC(36) Using 15 workers of 15 for evacuation
[135.359s][debug][gc,age         ] GC(36) Desired survivor size 27262976 bytes, new threshold 15 (max threshold 15)
[135.366s][trace][gc,age         ] GC(36) Age table with threshold 15 (max threshold 15)
[135.366s][trace][gc,age         ] GC(36) - age   1:     356744 bytes,     356744 total
[135.366s][trace][gc,age         ] GC(36) - age   2:     343936 bytes,     700680 total
[135.366s][trace][gc,age         ] GC(36) - age   3:     344128 bytes,    1044808 total
[135.366s][trace][gc,age         ] GC(36) - age   4:     518160 bytes,    1562968 total
[135.366s][info ][gc,phases      ] GC(36)   Pre Evacuate Collection Set: 0.4ms
[135.366s][info ][gc,phases      ] GC(36)   Merge Heap Roots: 0.5ms
[135.366s][info ][gc,phases      ] GC(36)   Evacuate Collection Set: 4.8ms
[135.366s][info ][gc,phases      ] GC(36)   Post Evacuate Collection Set: 0.7ms
[135.366s][info ][gc,phases      ] GC(36)   Other: 0.5ms
[135.366s][info ][gc,heap        ] GC(36) Eden regions: 407->0(407)
[135.366s][info ][gc,heap        ] GC(36) Survivor regions: 2->2(52)
[135.366s][info ][gc,heap        ] GC(36) Old regions: 11->11
[135.366s][info ][gc,heap        ] GC(36) Archive regions: 2->2
[135.366s][info ][gc,heap        ] GC(36) Humongous regions: 0->0
[135.366s][info ][gc,metaspace   ] GC(36) Metaspace: 907K(1088K)->907K(1088K) NonClass: 823K(896K)->823K(896K) Class: 83K(192K)->83K(192K)
[135.366s][info ][gc             ] GC(36) Pause Young (Normal) (G1 Evacuation Pause) 409M->2M(2048M) 6.966ms
[135.366s][info ][gc,cpu         ] GC(36) User=0.02s Sys=0.01s Real=0.01s
[139.189s][info ][gc,start       ] GC(37) Pause Young (Normal) (G1 Evacuation Pause)
[139.189s][info ][gc,task        ] GC(37) Using 15 workers of 15 for evacuation
[139.189s][debug][gc,age         ] GC(37) Desired survivor size 27262976 bytes, new threshold 15 (max threshold 15)
[139.197s][trace][gc,age         ] GC(37) Age table with threshold 15 (max threshold 15)
[139.197s][trace][gc,age         ] GC(37) - age   1:     355912 bytes,     355912 total
[139.197s][trace][gc,age         ] GC(37) - age   2:     342784 bytes,     698696 total
[139.197s][trace][gc,age         ] GC(37) - age   3:     343936 bytes,    1042632 total
[139.197s][trace][gc,age         ] GC(37) - age   4:     344128 bytes,    1386760 total
[139.197s][trace][gc,age         ] GC(37) - age   5:     518160 bytes,    1904920 total
[139.197s][info ][gc,phases      ] GC(37)   Pre Evacuate Collection Set: 0.6ms
[139.197s][info ][gc,phases      ] GC(37)   Merge Heap Roots: 0.4ms
[139.197s][info ][gc,phases      ] GC(37)   Evacuate Collection Set: 5.9ms
[139.197s][info ][gc,phases      ] GC(37)   Post Evacuate Collection Set: 1.1ms
[139.197s][info ][gc,phases      ] GC(37)   Other: 0.4ms
[139.197s][info ][gc,heap        ] GC(37) Eden regions: 407->0(407)
[139.197s][info ][gc,heap        ] GC(37) Survivor regions: 2->2(52)
[139.197s][info ][gc,heap        ] GC(37) Old regions: 11->11
[139.197s][info ][gc,heap        ] GC(37) Archive regions: 2->2
[139.197s][info ][gc,heap        ] GC(37) Humongous regions: 0->0
[139.197s][info ][gc,metaspace   ] GC(37) Metaspace: 907K(1088K)->907K(1088K) NonClass: 823K(896K)->823K(896K) Class: 83K(192K)->83K(192K)
[139.197s][info ][gc             ] GC(37) Pause Young (Normal) (G1 Evacuation Pause) 409M->3M(2048M) 8.431ms
[139.197s][info ][gc,cpu         ] GC(37) User=0.02s Sys=0.00s Real=0.01s
[142.986s][info ][gc,start       ] GC(38) Pause Young (Normal) (G1 Evacuation Pause)
[142.987s][info ][gc,task        ] GC(38) Using 15 workers of 15 for evacuation
[142.987s][debug][gc,age         ] GC(38) Desired survivor size 27262976 bytes, new threshold 15 (max threshold 15)
[142.995s][trace][gc,age         ] GC(38) Age table with threshold 15 (max threshold 15)
[142.995s][trace][gc,age         ] GC(38) - age   1:     356616 bytes,     356616 total
[142.995s][trace][gc,age         ] GC(38) - age   2:     342976 bytes,     699592 total
[142.995s][trace][gc,age         ] GC(38) - age   3:     342784 bytes,    1042376 total
[142.995s][trace][gc,age         ] GC(38) - age   4:     343936 bytes,    1386312 total
[142.995s][trace][gc,age         ] GC(38) - age   5:     344128 bytes,    1730440 total
[142.995s][trace][gc,age         ] GC(38) - age   6:     518160 bytes,    2248600 total
[142.995s][info ][gc,phases      ] GC(38)   Pre Evacuate Collection Set: 0.4ms
[142.995s][info ][gc,phases      ] GC(38)   Merge Heap Roots: 0.6ms
[142.995s][info ][gc,phases      ] GC(38)   Evacuate Collection Set: 6.1ms
[142.995s][info ][gc,phases      ] GC(38)   Post Evacuate Collection Set: 1.1ms
[142.995s][info ][gc,phases      ] GC(38)   Other: 0.4ms
[142.995s][info ][gc,heap        ] GC(38) Eden regions: 407->0(406)
[142.995s][info ][gc,heap        ] GC(38) Survivor regions: 2->3(52)
[142.995s][info ][gc,heap        ] GC(38) Old regions: 11->11
[142.995s][info ][gc,heap        ] GC(38) Archive regions: 2->2
[142.995s][info ][gc,heap        ] GC(38) Humongous regions: 0->0
[142.995s][info ][gc,metaspace   ] GC(38) Metaspace: 907K(1088K)->907K(1088K) NonClass: 823K(896K)->823K(896K) Class: 83K(192K)->83K(192K)
[142.995s][info ][gc             ] GC(38) Pause Young (Normal) (G1 Evacuation Pause) 410M->3M(2048M) 8.523ms
[142.995s][info ][gc,cpu         ] GC(38) User=0.03s Sys=0.00s Real=0.01s
[146.775s][info ][gc,start       ] GC(39) Pause Young (Normal) (G1 Evacuation Pause)
[146.775s][info ][gc,task        ] GC(39) Using 15 workers of 15 for evacuation
[146.776s][debug][gc,age         ] GC(39) Desired survivor size 27262976 bytes, new threshold 15 (max threshold 15)
[146.783s][trace][gc,age         ] GC(39) Age table with threshold 15 (max threshold 15)
[146.783s][trace][gc,age         ] GC(39) - age   1:     342616 bytes,     342616 total
[146.783s][trace][gc,age         ] GC(39) - age   2:     342656 bytes,     685272 total
[146.783s][trace][gc,age         ] GC(39) - age   3:     342976 bytes,    1028248 total
[146.783s][trace][gc,age         ] GC(39) - age   4:     342784 bytes,    1371032 total
[146.783s][trace][gc,age         ] GC(39) - age   5:     343936 bytes,    1714968 total
[146.783s][trace][gc,age         ] GC(39) - age   6:     344128 bytes,    2059096 total
[146.783s][trace][gc,age         ] GC(39) - age   7:     518160 bytes,    2577256 total
[146.783s][info ][gc,phases      ] GC(39)   Pre Evacuate Collection Set: 0.5ms
[146.783s][info ][gc,phases      ] GC(39)   Merge Heap Roots: 0.4ms
[146.783s][info ][gc,phases      ] GC(39)   Evacuate Collection Set: 6.1ms
[146.783s][info ][gc,phases      ] GC(39)   Post Evacuate Collection Set: 0.4ms
[146.783s][info ][gc,phases      ] GC(39)   Other: 0.5ms
[146.783s][info ][gc,heap        ] GC(39) Eden regions: 406->0(406)
[146.783s][info ][gc,heap        ] GC(39) Survivor regions: 3->3(52)
[146.783s][info ][gc,heap        ] GC(39) Old regions: 11->11
[146.783s][info ][gc,heap        ] GC(39) Archive regions: 2->2
[146.783s][info ][gc,heap        ] GC(39) Humongous regions: 0->0
[146.783s][info ][gc,metaspace   ] GC(39) Metaspace: 907K(1088K)->907K(1088K) NonClass: 823K(896K)->823K(896K) Class: 83K(192K)->83K(192K)
[146.783s][info ][gc             ] GC(39) Pause Young (Normal) (G1 Evacuation Pause) 409M->4M(2048M) 7.884ms
[146.783s][info ][gc,cpu         ] GC(39) User=0.03s Sys=0.00s Real=0.01s
[150.571s][info ][gc,start       ] GC(40) Pause Young (Normal) (G1 Evacuation Pause)
[150.571s][info ][gc,task        ] GC(40) Using 15 workers of 15 for evacuation
[150.572s][debug][gc,age         ] GC(40) Desired survivor size 27262976 bytes, new threshold 15 (max threshold 15)
[150.580s][trace][gc,age         ] GC(40) Age table with threshold 15 (max threshold 15)
[150.581s][trace][gc,age         ] GC(40) - age   1:     348048 bytes,     348048 total
[150.581s][trace][gc,age         ] GC(40) - age   2:     342080 bytes,     690128 total
[150.581s][trace][gc,age         ] GC(40) - age   3:     342656 bytes,    1032784 total
[150.581s][trace][gc,age         ] GC(40) - age   4:     342976 bytes,    1375760 total
[150.581s][trace][gc,age         ] GC(40) - age   5:     342784 bytes,    1718544 total
[150.581s][trace][gc,age         ] GC(40) - age   6:     343936 bytes,    2062480 total
[150.581s][trace][gc,age         ] GC(40) - age   7:     344128 bytes,    2406608 total
[150.581s][trace][gc,age         ] GC(40) - age   8:     518160 bytes,    2924768 total
[150.581s][info ][gc,phases      ] GC(40)   Pre Evacuate Collection Set: 0.4ms
[150.581s][info ][gc,phases      ] GC(40)   Merge Heap Roots: 0.3ms
[150.581s][info ][gc,phases      ] GC(40)   Evacuate Collection Set: 7.4ms
[150.581s][info ][gc,phases      ] GC(40)   Post Evacuate Collection Set: 0.8ms
[150.581s][info ][gc,phases      ] GC(40)   Other: 0.4ms
[150.581s][info ][gc,heap        ] GC(40) Eden regions: 406->0(405)
[150.581s][info ][gc,heap        ] GC(40) Survivor regions: 3->4(52)
[150.581s][info ][gc,heap        ] GC(40) Old regions: 11->11
[150.581s][info ][gc,heap        ] GC(40) Archive regions: 2->2
[150.581s][info ][gc,heap        ] GC(40) Humongous regions: 0->0
[150.581s][info ][gc,metaspace   ] GC(40) Metaspace: 907K(1088K)->907K(1088K) NonClass: 823K(896K)->823K(896K) Class: 83K(192K)->83K(192K)
[150.581s][info ][gc             ] GC(40) Pause Young (Normal) (G1 Evacuation Pause) 410M->4M(2048M) 9.228ms
[150.581s][info ][gc,cpu         ] GC(40) User=0.03s Sys=0.00s Real=0.01s
[154.388s][info ][gc,start       ] GC(41) Pause Young (Normal) (G1 Evacuation Pause)
[154.388s][info ][gc,task        ] GC(41) Using 15 workers of 15 for evacuation
[154.388s][debug][gc,age         ] GC(41) Desired survivor size 27262976 bytes, new threshold 15 (max threshold 15)
[154.398s][trace][gc,age         ] GC(41) Age table with threshold 15 (max threshold 15)
[154.398s][trace][gc,age         ] GC(41) - age   1:     355664 bytes,     355664 total
[154.398s][trace][gc,age         ] GC(41) - age   2:     342208 bytes,     697872 total
[154.398s][trace][gc,age         ] GC(41) - age   3:     342080 bytes,    1039952 total
[154.398s][trace][gc,age         ] GC(41) - age   4:     342656 bytes,    1382608 total
[154.398s][trace][gc,age         ] GC(41) - age   5:     342976 bytes,    1725584 total
[154.398s][trace][gc,age         ] GC(41) - age   6:     342784 bytes,    2068368 total
[154.398s][trace][gc,age         ] GC(41) - age   7:     343936 bytes,    2412304 total
[154.398s][trace][gc,age         ] GC(41) - age   8:     344128 bytes,    2756432 total
[154.398s][trace][gc,age         ] GC(41) - age   9:     518160 bytes,    3274592 total
[154.398s][info ][gc,phases      ] GC(41)   Pre Evacuate Collection Set: 0.5ms
[154.398s][info ][gc,phases      ] GC(41)   Merge Heap Roots: 0.5ms
[154.398s][info ][gc,phases      ] GC(41)   Evacuate Collection Set: 7.8ms
[154.398s][info ][gc,phases      ] GC(41)   Post Evacuate Collection Set: 1.0ms
[154.398s][info ][gc,phases      ] GC(41)   Other: 0.4ms
[154.398s][info ][gc,heap        ] GC(41) Eden regions: 405->0(405)
[154.398s][info ][gc,heap        ] GC(41) Survivor regions: 4->4(52)
[154.398s][info ][gc,heap        ] GC(41) Old regions: 11->11
[154.398s][info ][gc,heap        ] GC(41) Archive regions: 2->2
[154.398s][info ][gc,heap        ] GC(41) Humongous regions: 0->0
[154.398s][info ][gc,metaspace   ] GC(41) Metaspace: 907K(1088K)->907K(1088K) NonClass: 823K(896K)->823K(896K) Class: 83K(192K)->83K(192K)
[154.398s][info ][gc             ] GC(41) Pause Young (Normal) (G1 Evacuation Pause) 409M->4M(2048M) 10.168ms
[154.398s][info ][gc,cpu         ] GC(41) User=0.04s Sys=0.00s Real=0.01s
[158.188s][info ][gc,start       ] GC(42) Pause Young (Normal) (G1 Evacuation Pause)
[158.188s][info ][gc,task        ] GC(42) Using 15 workers of 15 for evacuation
[158.188s][debug][gc,age         ] GC(42) Desired survivor size 27262976 bytes, new threshold 15 (max threshold 15)
[158.198s][trace][gc,age         ] GC(42) Age table with threshold 15 (max threshold 15)
[158.198s][trace][gc,age         ] GC(42) - age   1:     348560 bytes,     348560 total
[158.198s][trace][gc,age         ] GC(42) - age   2:     341760 bytes,     690320 total
[158.198s][trace][gc,age         ] GC(42) - age   3:     342208 bytes,    1032528 total
[158.198s][trace][gc,age         ] GC(42) - age   4:     342080 bytes,    1374608 total
[158.198s][trace][gc,age         ] GC(42) - age   5:     342656 bytes,    1717264 total
[158.198s][trace][gc,age         ] GC(42) - age   6:     342976 bytes,    2060240 total
[158.198s][trace][gc,age         ] GC(42) - age   7:     342784 bytes,    2403024 total
[158.198s][trace][gc,age         ] GC(42) - age   8:     343936 bytes,    2746960 total
[158.198s][trace][gc,age         ] GC(42) - age   9:     344128 bytes,    3091088 total
[158.198s][trace][gc,age         ] GC(42) - age  10:     518160 bytes,    3609248 total
[158.198s][info ][gc,phases      ] GC(42)   Pre Evacuate Collection Set: 0.5ms
[158.198s][info ][gc,phases      ] GC(42)   Merge Heap Roots: 0.4ms
[158.198s][info ][gc,phases      ] GC(42)   Evacuate Collection Set: 8.3ms
[158.198s][info ][gc,phases      ] GC(42)   Post Evacuate Collection Set: 0.7ms
[158.198s][info ][gc,phases      ] GC(42)   Other: 0.4ms
[158.198s][info ][gc,heap        ] GC(42) Eden regions: 405->0(405)
[158.198s][info ][gc,heap        ] GC(42) Survivor regions: 4->4(52)
[158.198s][info ][gc,heap        ] GC(42) Old regions: 11->11
[158.198s][info ][gc,heap        ] GC(42) Archive regions: 2->2
[158.198s][info ][gc,heap        ] GC(42) Humongous regions: 0->0
[158.198s][info ][gc,metaspace   ] GC(42) Metaspace: 907K(1088K)->907K(1088K) NonClass: 823K(896K)->823K(896K) Class: 83K(192K)->83K(192K)
[158.198s][info ][gc             ] GC(42) Pause Young (Normal) (G1 Evacuation Pause) 409M->5M(2048M) 10.142ms
[158.198s][info ][gc,cpu         ] GC(42) User=0.03s Sys=0.00s Real=0.01s
[162.006s][info ][gc,start       ] GC(43) Pause Young (Normal) (G1 Evacuation Pause)
[162.006s][info ][gc,task        ] GC(43) Using 15 workers of 15 for evacuation
[162.006s][debug][gc,age         ] GC(43) Desired survivor size 27262976 bytes, new threshold 15 (max threshold 15)
[162.016s][trace][gc,age         ] GC(43) Age table with threshold 15 (max threshold 15)
[162.016s][trace][gc,age         ] GC(43) - age   1:     346608 bytes,     346608 total
[162.016s][trace][gc,age         ] GC(43) - age   2:     341568 bytes,     688176 total
[162.016s][trace][gc,age         ] GC(43) - age   3:     341760 bytes,    1029936 total
[162.016s][trace][gc,age         ] GC(43) - age   4:     342208 bytes,    1372144 total
[162.016s][trace][gc,age         ] GC(43) - age   5:     342080 bytes,    1714224 total
[162.016s][trace][gc,age         ] GC(43) - age   6:     342656 bytes,    2056880 total
[162.016s][trace][gc,age         ] GC(43) - age   7:     342976 bytes,    2399856 total
[162.016s][trace][gc,age         ] GC(43) - age   8:     342784 bytes,    2742640 total
[162.016s][trace][gc,age         ] GC(43) - age   9:     343936 bytes,    3086576 total
[162.016s][trace][gc,age         ] GC(43) - age  10:     344128 bytes,    3430704 total
[162.016s][trace][gc,age         ] GC(43) - age  11:     518160 bytes,    3948864 total
[162.016s][info ][gc,phases      ] GC(43)   Pre Evacuate Collection Set: 0.5ms
[162.016s][info ][gc,phases      ] GC(43)   Merge Heap Roots: 0.4ms
[162.016s][info ][gc,phases      ] GC(43)   Evacuate Collection Set: 8.2ms
[162.016s][info ][gc,phases      ] GC(43)   Post Evacuate Collection Set: 0.6ms
[162.016s][info ][gc,phases      ] GC(43)   Other: 0.4ms
[162.016s][info ][gc,heap        ] GC(43) Eden regions: 405->0(404)
[162.016s][info ][gc,heap        ] GC(43) Survivor regions: 4->5(52)
[162.016s][info ][gc,heap        ] GC(43) Old regions: 11->11
[162.016s][info ][gc,heap        ] GC(43) Archive regions: 2->2
[162.016s][info ][gc,heap        ] GC(43) Humongous regions: 0->0
[162.016s][info ][gc,metaspace   ] GC(43) Metaspace: 907K(1088K)->907K(1088K) NonClass: 823K(896K)->823K(896K) Class: 83K(192K)->83K(192K)
[162.016s][info ][gc             ] GC(43) Pause Young (Normal) (G1 Evacuation Pause) 410M->5M(2048M) 10.029ms
[162.016s][info ][gc,cpu         ] GC(43) User=0.04s Sys=0.00s Real=0.01s
[165.793s][info ][gc,start       ] GC(44) Pause Young (Normal) (G1 Evacuation Pause)
[165.793s][info ][gc,task        ] GC(44) Using 15 workers of 15 for evacuation
[165.793s][debug][gc,age         ] GC(44) Desired survivor size 27262976 bytes, new threshold 15 (max threshold 15)
[165.802s][trace][gc,age         ] GC(44) Age table with threshold 15 (max threshold 15)
[165.802s][trace][gc,age         ] GC(44) - age   1:     355088 bytes,     355088 total
[165.802s][trace][gc,age         ] GC(44) - age   2:     341632 bytes,     696720 total
[165.802s][trace][gc,age         ] GC(44) - age   3:     341568 bytes,    1038288 total
[165.802s][trace][gc,age         ] GC(44) - age   4:     341760 bytes,    1380048 total
[165.802s][trace][gc,age         ] GC(44) - age   5:     342208 bytes,    1722256 total
[165.802s][trace][gc,age         ] GC(44) - age   6:     342080 bytes,    2064336 total
[165.802s][trace][gc,age         ] GC(44) - age   7:     342656 bytes,    2406992 total
[165.802s][trace][gc,age         ] GC(44) - age   8:     342976 bytes,    2749968 total
[165.802s][trace][gc,age         ] GC(44) - age   9:     342784 bytes,    3092752 total
[165.802s][trace][gc,age         ] GC(44) - age  10:     343936 bytes,    3436688 total
[165.802s][trace][gc,age         ] GC(44) - age  11:     344128 bytes,    3780816 total
[165.802s][trace][gc,age         ] GC(44) - age  12:     518160 bytes,    4298976 total
[165.802s][info ][gc,phases      ] GC(44)   Pre Evacuate Collection Set: 0.3ms
[165.802s][info ][gc,phases      ] GC(44)   Merge Heap Roots: 0.3ms
[165.802s][info ][gc,phases      ] GC(44)   Evacuate Collection Set: 7.5ms
[165.802s][info ][gc,phases      ] GC(44)   Post Evacuate Collection Set: 0.8ms
[165.802s][info ][gc,phases      ] GC(44)   Other: 0.3ms
[165.802s][info ][gc,heap        ] GC(44) Eden regions: 404->0(404)
[165.802s][info ][gc,heap        ] GC(44) Survivor regions: 5->5(52)
[165.802s][info ][gc,heap        ] GC(44) Old regions: 11->11
[165.802s][info ][gc,heap        ] GC(44) Archive regions: 2->2
[165.802s][info ][gc,heap        ] GC(44) Humongous regions: 0->0
[165.802s][info ][gc,metaspace   ] GC(44) Metaspace: 907K(1088K)->907K(1088K) NonClass: 823K(896K)->823K(896K) Class: 83K(192K)->83K(192K)
[165.802s][info ][gc             ] GC(44) Pause Young (Normal) (G1 Evacuation Pause) 409M->5M(2048M) 9.187ms
[165.802s][info ][gc,cpu         ] GC(44) User=0.03s Sys=0.00s Real=0.01s
[169.572s][info ][gc,start       ] GC(45) Pause Young (Normal) (G1 Evacuation Pause)
[169.572s][info ][gc,task        ] GC(45) Using 15 workers of 15 for evacuation
[169.572s][debug][gc,age         ] GC(45) Desired survivor size 27262976 bytes, new threshold 15 (max threshold 15)
[169.581s][trace][gc,age         ] GC(45) Age table with threshold 15 (max threshold 15)
[169.581s][trace][gc,age         ] GC(45) - age   1:     353440 bytes,     353440 total
[169.581s][trace][gc,age         ] GC(45) - age   2:     341216 bytes,     694656 total
[169.581s][trace][gc,age         ] GC(45) - age   3:     341632 bytes,    1036288 total
[169.581s][trace][gc,age         ] GC(45) - age   4:     341568 bytes,    1377856 total
[169.581s][trace][gc,age         ] GC(45) - age   5:     341760 bytes,    1719616 total
[169.581s][trace][gc,age         ] GC(45) - age   6:     342208 bytes,    2061824 total
[169.581s][trace][gc,age         ] GC(45) - age   7:     342080 bytes,    2403904 total
[169.581s][trace][gc,age         ] GC(45) - age   8:     342656 bytes,    2746560 total
[169.581s][trace][gc,age         ] GC(45) - age   9:     342976 bytes,    3089536 total
[169.581s][trace][gc,age         ] GC(45) - age  10:     342784 bytes,    3432320 total
[169.581s][trace][gc,age         ] GC(45) - age  11:     343936 bytes,    3776256 total
[169.581s][trace][gc,age         ] GC(45) - age  12:     344128 bytes,    4120384 total
[169.581s][trace][gc,age         ] GC(45) - age  13:     518160 bytes,    4638544 total
[169.581s][info ][gc,phases      ] GC(45)   Pre Evacuate Collection Set: 0.4ms
[169.581s][info ][gc,phases      ] GC(45)   Merge Heap Roots: 0.4ms
[169.581s][info ][gc,phases      ] GC(45)   Evacuate Collection Set: 7.8ms
[169.581s][info ][gc,phases      ] GC(45)   Post Evacuate Collection Set: 0.5ms
[169.581s][info ][gc,phases      ] GC(45)   Other: 0.3ms
[169.581s][info ][gc,heap        ] GC(45) Eden regions: 404->0(404)
[169.581s][info ][gc,heap        ] GC(45) Survivor regions: 5->5(52)
[169.581s][info ][gc,heap        ] GC(45) Old regions: 11->11
[169.581s][info ][gc,heap        ] GC(45) Archive regions: 2->2
[169.581s][info ][gc,heap        ] GC(45) Humongous regions: 0->0
[169.581s][info ][gc,metaspace   ] GC(45) Metaspace: 907K(1088K)->907K(1088K) NonClass: 823K(896K)->823K(896K) Class: 83K(192K)->83K(192K)
[169.581s][info ][gc             ] GC(45) Pause Young (Normal) (G1 Evacuation Pause) 409M->6M(2048M) 9.373ms
[169.581s][info ][gc,cpu         ] GC(45) User=0.04s Sys=0.00s Real=0.01s
[173.398s][info ][gc,start       ] GC(46) Pause Young (Normal) (G1 Evacuation Pause)
[173.398s][info ][gc,task        ] GC(46) Using 15 workers of 15 for evacuation
[173.398s][debug][gc,age         ] GC(46) Desired survivor size 27262976 bytes, new threshold 15 (max threshold 15)
[173.408s][trace][gc,age         ] GC(46) Age table with threshold 15 (max threshold 15)
[173.408s][trace][gc,age         ] GC(46) - age   1:     341464 bytes,     341464 total
[173.408s][trace][gc,age         ] GC(46) - age   2:     340576 bytes,     682040 total
[173.408s][trace][gc,age         ] GC(46) - age   3:     341216 bytes,    1023256 total
[173.408s][trace][gc,age         ] GC(46) - age   4:     341632 bytes,    1364888 total
[173.408s][trace][gc,age         ] GC(46) - age   5:     341568 bytes,    1706456 total
[173.408s][trace][gc,age         ] GC(46) - age   6:     341760 bytes,    2048216 total
[173.408s][trace][gc,age         ] GC(46) - age   7:     342208 bytes,    2390424 total
[173.408s][trace][gc,age         ] GC(46) - age   8:     342080 bytes,    2732504 total
[173.408s][trace][gc,age         ] GC(46) - age   9:     342656 bytes,    3075160 total
[173.408s][trace][gc,age         ] GC(46) - age  10:     342976 bytes,    3418136 total
[173.408s][trace][gc,age         ] GC(46) - age  11:     342784 bytes,    3760920 total
[173.408s][trace][gc,age         ] GC(46) - age  12:     343936 bytes,    4104856 total
[173.409s][trace][gc,age         ] GC(46) - age  13:     344128 bytes,    4448984 total
[173.409s][trace][gc,age         ] GC(46) - age  14:     518160 bytes,    4967144 total
[173.409s][info ][gc,phases      ] GC(46)   Pre Evacuate Collection Set: 0.4ms
[173.409s][info ][gc,phases      ] GC(46)   Merge Heap Roots: 0.6ms
[173.409s][info ][gc,phases      ] GC(46)   Evacuate Collection Set: 8.6ms
[173.409s][info ][gc,phases      ] GC(46)   Post Evacuate Collection Set: 0.4ms
[173.409s][info ][gc,phases      ] GC(46)   Other: 0.3ms
[173.409s][info ][gc,heap        ] GC(46) Eden regions: 404->0(403)
[173.409s][info ][gc,heap        ] GC(46) Survivor regions: 5->6(52)
[173.409s][info ][gc,heap        ] GC(46) Old regions: 11->11
[173.409s][info ][gc,heap        ] GC(46) Archive regions: 2->2
[173.409s][info ][gc,heap        ] GC(46) Humongous regions: 0->0
[173.409s][info ][gc,metaspace   ] GC(46) Metaspace: 907K(1088K)->907K(1088K) NonClass: 823K(896K)->823K(896K) Class: 83K(192K)->83K(192K)
[173.409s][info ][gc             ] GC(46) Pause Young (Normal) (G1 Evacuation Pause) 410M->6M(2048M) 10.361ms
[173.409s][info ][gc,cpu         ] GC(46) User=0.03s Sys=0.00s Real=0.01s
[177.198s][info ][gc,start       ] GC(47) Pause Young (Normal) (G1 Evacuation Pause)
[177.199s][info ][gc,task        ] GC(47) Using 15 workers of 15 for evacuation
[177.199s][debug][gc,age         ] GC(47) Desired survivor size 27262976 bytes, new threshold 15 (max threshold 15)
[177.207s][trace][gc,age         ] GC(47) Age table with threshold 15 (max threshold 15)
[177.207s][trace][gc,age         ] GC(47) - age   1:     353104 bytes,     353104 total
[177.207s][trace][gc,age         ] GC(47) - age   2:     340928 bytes,     694032 total
[177.207s][trace][gc,age         ] GC(47) - age   3:     340576 bytes,    1034608 total
[177.207s][trace][gc,age         ] GC(47) - age   4:     341216 bytes,    1375824 total
[177.207s][trace][gc,age         ] GC(47) - age   5:     341632 bytes,    1717456 total
[177.207s][trace][gc,age         ] GC(47) - age   6:     341568 bytes,    2059024 total
[177.207s][trace][gc,age         ] GC(47) - age   7:     341760 bytes,    2400784 total
[177.207s][trace][gc,age         ] GC(47) - age   8:     342208 bytes,    2742992 total
[177.207s][trace][gc,age         ] GC(47) - age   9:     342080 bytes,    3085072 total
[177.207s][trace][gc,age         ] GC(47) - age  10:     342656 bytes,    3427728 total
[177.207s][trace][gc,age         ] GC(47) - age  11:     342976 bytes,    3770704 total
[177.207s][trace][gc,age         ] GC(47) - age  12:     342784 bytes,    4113488 total
[177.207s][trace][gc,age         ] GC(47) - age  13:     343936 bytes,    4457424 total
[177.207s][trace][gc,age         ] GC(47) - age  14:     344128 bytes,    4801552 total
[177.207s][trace][gc,age         ] GC(47) - age  15:     518160 bytes,    5319712 total
[177.207s][info ][gc,phases      ] GC(47)   Pre Evacuate Collection Set: 0.5ms
[177.207s][info ][gc,phases      ] GC(47)   Merge Heap Roots: 0.4ms
[177.207s][info ][gc,phases      ] GC(47)   Evacuate Collection Set: 7.6ms
[177.207s][info ][gc,phases      ] GC(47)   Post Evacuate Collection Set: 0.3ms
[177.207s][info ][gc,phases      ] GC(47)   Other: 0.3ms
[177.207s][info ][gc,heap        ] GC(47) Eden regions: 403->0(403)
[177.207s][info ][gc,heap        ] GC(47) Survivor regions: 6->6(52)
[177.208s][info ][gc,heap        ] GC(47) Old regions: 11->11
[177.208s][info ][gc,heap        ] GC(47) Archive regions: 2->2
[177.208s][info ][gc,heap        ] GC(47) Humongous regions: 0->0
[177.208s][info ][gc,metaspace   ] GC(47) Metaspace: 907K(1088K)->907K(1088K) NonClass: 823K(896K)->823K(896K) Class: 83K(192K)->83K(192K)
[177.208s][info ][gc             ] GC(47) Pause Young (Normal) (G1 Evacuation Pause) 409M->7M(2048M) 9.023ms
[177.208s][info ][gc,cpu         ] GC(47) User=0.03s Sys=0.00s Real=0.01s
[180.983s][info ][gc,start       ] GC(48) Pause Young (Normal) (G1 Evacuation Pause)
[180.984s][info ][gc,task        ] GC(48) Using 15 workers of 15 for evacuation
[180.984s][debug][gc,age         ] GC(48) Desired survivor size 27262976 bytes, new threshold 15 (max threshold 15)
[180.994s][trace][gc,age         ] GC(48) Age table with threshold 15 (max threshold 15)
[180.994s][trace][gc,age         ] GC(48) - age   1:     347024 bytes,     347024 total
[180.994s][trace][gc,age         ] GC(48) - age   2:     340224 bytes,     687248 total
[180.994s][trace][gc,age         ] GC(48) - age   3:     340928 bytes,    1028176 total
[180.994s][trace][gc,age         ] GC(48) - age   4:     340576 bytes,    1368752 total
[180.994s][trace][gc,age         ] GC(48) - age   5:     341216 bytes,    1709968 total
[180.994s][trace][gc,age         ] GC(48) - age   6:     341632 bytes,    2051600 total
[180.994s][trace][gc,age         ] GC(48) - age   7:     341568 bytes,    2393168 total
[180.994s][trace][gc,age         ] GC(48) - age   8:     341760 bytes,    2734928 total
[180.994s][trace][gc,age         ] GC(48) - age   9:     342208 bytes,    3077136 total
[180.994s][trace][gc,age         ] GC(48) - age  10:     342080 bytes,    3419216 total
[180.994s][trace][gc,age         ] GC(48) - age  11:     342656 bytes,    3761872 total
[180.994s][trace][gc,age         ] GC(48) - age  12:     342976 bytes,    4104848 total
[180.994s][trace][gc,age         ] GC(48) - age  13:     342784 bytes,    4447632 total
[180.994s][trace][gc,age         ] GC(48) - age  14:     343936 bytes,    4791568 total
[180.994s][trace][gc,age         ] GC(48) - age  15:     344128 bytes,    5135696 total
[180.994s][info ][gc,phases      ] GC(48)   Pre Evacuate Collection Set: 0.5ms
[180.994s][info ][gc,phases      ] GC(48)   Merge Heap Roots: 0.5ms
[180.994s][info ][gc,phases      ] GC(48)   Evacuate Collection Set: 8.8ms
[180.994s][info ][gc,phases      ] GC(48)   Post Evacuate Collection Set: 0.4ms
[180.994s][info ][gc,phases      ] GC(48)   Other: 0.3ms
[180.994s][info ][gc,heap        ] GC(48) Eden regions: 403->0(403)
[180.994s][info ][gc,heap        ] GC(48) Survivor regions: 6->6(52)
[180.994s][info ][gc,heap        ] GC(48) Old regions: 11->12
[180.994s][info ][gc,heap        ] GC(48) Archive regions: 2->2
[180.994s][info ][gc,heap        ] GC(48) Humongous regions: 0->0
[180.994s][info ][gc,metaspace   ] GC(48) Metaspace: 907K(1088K)->907K(1088K) NonClass: 823K(896K)->823K(896K) Class: 83K(192K)->83K(192K)
[180.994s][info ][gc             ] GC(48) Pause Young (Normal) (G1 Evacuation Pause) 410M->7M(2048M) 10.447ms
[180.994s][info ][gc,cpu         ] GC(48) User=0.04s Sys=0.00s Real=0.01s

From pminborg at openjdk.org  Thu Feb  8 11:57:11 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 8 Feb 2024 11:57:11 GMT
Subject: [jdk22] Integrated: 8325001: Typo in the javadocs for the
 Arena::ofShared method
In-Reply-To: 
References: 
Message-ID: <7FUi0v4cIvIohRz9luCPFWTw7FhN6JzYPzijUWJGLCI=.fe3cf3de-d853-41ec-ab2d-62cc2c7fd36a@github.com>

On Thu, 1 Feb 2024 12:07:52 GMT, Per Minborg  wrote:

> 8325001: Typo in the javadocs for the Arena::ofShared method

This pull request has now been integrated.

Changeset: 6d9a50ea
Author:    Per Minborg 
URL:       https://git.openjdk.org/jdk22/commit/6d9a50ea148c1c37b9a1d0475d4aae78ea8f822b
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8325001: Typo in the javadocs for the Arena::ofShared method

Reviewed-by: mcimadamore
Backport-of: 6b84f9bb3ee4362bf9daa4fb3905b168f9035336

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

PR: https://git.openjdk.org/jdk22/pull/100

From asotona at openjdk.org  Thu Feb  8 13:23:39 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 8 Feb 2024 13:23:39 GMT
Subject: RFR: 8325485: IncrementInstructions.of(int,
 int) is not storing the args
Message-ID: 

ClassFile API provides two sets of instructions implementations (bound and unbound).
Unbound implementation of `IncrementInstruction::constant` returns invalid value. 
This bug discovered a hole in the ClassFile API test coverage.

This patch provides very simple fix of `IncrementInstruction`
and more complex fix of the test framework to cover all unbound instruction with automated tests.

The test framework fix includes correction of hash calculation of instructions in `ClassRecord` and
two-pass transformation in `RebuildingTransformation`. Second pass has been added to discover bugs in unbound-to-unbound instruction conversions.

Please review.

Thanks,
Adam

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

Commit messages:
 - 8325485: IncrementInstructions.of(int, int) is not storing the args

Changes: https://git.openjdk.org/jdk/pull/17770/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17770&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8325485
  Stats: 786 lines in 4 files changed: 391 ins; 379 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/17770.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17770/head:pull/17770

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

From ihse at openjdk.org  Thu Feb  8 13:42:07 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 8 Feb 2024 13:42:07 GMT
Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v10]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Thu, 8 Feb 2024 09:03:10 GMT, Joachim Kern  wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Once more, remove AIX dirent64 et al defines
>
> And also `#define statvfs statvfs64` is not necessary with the same explanation as  for the `opendir` defines above -- sorry again.
> The very only difference between statvfs and statvfs64 is that the filesystem ID field in statvfs has a width of 8 Bytes, while in statvfs64 it has a width of 16 Bytes.

@JoKern65 So what about `#define fstatvfs fstatvfs64`? Is that still needed? If so, I could not be bothered to make another change. Otherwise, we can get rid of *all* AIX 64-bit redefines, and then I'll (probably) do it.

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

PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1934144258

From eirbjo at openjdk.org  Thu Feb  8 14:09:35 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Thu, 8 Feb 2024 14:09:35 GMT
Subject: RFR: 8303891: Speed up Zip64SizeTest using a small ZIP64 file [v5]
In-Reply-To: 
References: 
Message-ID: 

> Please review this PR which suggests we speed up the `Zip64SizeTest` using a small-sized ZIP64 ZIP file specifically created to reproduce the issue being tested.
> 
> The disk space requirement of this test is known to cause problems in some builds, see [JDK-8259866](https://bugs.openjdk.org/browse/JDK-8259866)
> 
> By using a sparse file, we reduce consumed disk space from 5GB to 266 bytes and also reduce the runtime from ~35 seconds to ~1 seconds on my Macbook Pro.
> 
> The PR also fixes the `@summary` tag, which seems to have been copied from an unrelated test.

Eirik Bj?rsn?s has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 13 additional commits since the last revision:

 - Use a small ZIP64 file to reproduce the issue. Convert test to JUnit
 - Update copyright year for 2024
 - Use ENTRY instead of FILE when refering to names and sizes of file entries in the ZIP file
 - Merge branch 'master' into zip64-size-test-sparse
 - Merge branch 'master' into zip64-size-test-sparse
 - Sparse files must be created explicitly on NTFS
 - Merge branch 'master' into zip64-size-test-sparse
 - Merge branch 'master' into zip64-size-test-sparse
 - Make test method public
 - Add a missing "when" in Javadocs for SparseOutputStream
 - ... and 3 more: https://git.openjdk.org/jdk/compare/ae023a61...41b2ba5e

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12948/files
  - new: https://git.openjdk.org/jdk/pull/12948/files/adcca52c..41b2ba5e

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

  Stats: 1546371 lines in 16853 files changed: 754316 ins; 616810 del; 175245 mod
  Patch: https://git.openjdk.org/jdk/pull/12948.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12948/head:pull/12948

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

From eirbjo at openjdk.org  Thu Feb  8 14:14:11 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Thu, 8 Feb 2024 14:14:11 GMT
Subject: RFR: 8303891: Speed up Zip64SizeTest using a small ZIP64 file [v5]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 8 Feb 2024 14:09:35 GMT, Eirik Bj?rsn?s  wrote:

>> Please review this PR which suggests we speed up the `Zip64SizeTest` using a small-sized ZIP64 ZIP file specifically created to reproduce the issue being tested.
>> 
>> The disk space requirement of this test is known to cause problems in some builds, see [JDK-8259866](https://bugs.openjdk.org/browse/JDK-8259866)
>> 
>> By using a sparse file, we reduce consumed disk space from 5GB to 266 bytes and also reduce the runtime from ~35 seconds to ~1 seconds on my Macbook Pro.
>> 
>> The PR also fixes the `@summary` tag, which seems to have been copied from an unrelated test.
>
> Eirik Bj?rsn?s has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 13 additional commits since the last revision:
> 
>  - Use a small ZIP64 file to reproduce the issue. Convert test to JUnit
>  - Update copyright year for 2024
>  - Use ENTRY instead of FILE when refering to names and sizes of file entries in the ZIP file
>  - Merge branch 'master' into zip64-size-test-sparse
>  - Merge branch 'master' into zip64-size-test-sparse
>  - Sparse files must be created explicitly on NTFS
>  - Merge branch 'master' into zip64-size-test-sparse
>  - Merge branch 'master' into zip64-size-test-sparse
>  - Make test method public
>  - Add a missing "when" in Javadocs for SparseOutputStream
>  - ... and 3 more: https://git.openjdk.org/jdk/compare/adc5f068...41b2ba5e

Reopening this PR which was closed without review in May 2023.

Initially, this PR suggested to use a sparse file when creating the large ZIP file. After consideration, I have found it simpler to instead doctor a small-sized ZIP64-entry with the specific structure required to trigger the regression being tested.

I have verified that the test actually fails if `ZipFile` is updated to call `ZipEntry.setExtra0` with `isLoc: true`, meaning it still catches the regression.

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

PR Comment: https://git.openjdk.org/jdk/pull/12948#issuecomment-1934202567

From jkern at openjdk.org  Thu Feb  8 14:50:08 2024
From: jkern at openjdk.org (Joachim Kern)
Date: Thu, 8 Feb 2024 14:50:08 GMT
Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v10]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Thu, 8 Feb 2024 09:03:10 GMT, Joachim Kern  wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Once more, remove AIX dirent64 et al defines
>
> And also `#define statvfs statvfs64` is not necessary with the same explanation as  for the `opendir` defines above -- sorry again.
> The very only difference between statvfs and statvfs64 is that the filesystem ID field in statvfs has a width of 8 Bytes, while in statvfs64 it has a width of 16 Bytes.

> @JoKern65 So what about `#define fstatvfs fstatvfs64`? Is that still needed? If so, I could not be bothered to make another change. Otherwise, we can get rid of _all_ AIX 64-bit redefines, and then I'll (probably) do it.

Same as `statvfs`. Only the file system ID field is smaller.

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

PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1934275624

From duke at openjdk.org  Thu Feb  8 16:04:11 2024
From: duke at openjdk.org (Thiago Henrique =?UTF-8?B?SMO8cG5lcg==?=)
Date: Thu, 8 Feb 2024 16:04:11 GMT
Subject: RFR: 8325505: Fix Javadoc ResourceBundle::getString
Message-ID: 

8325505: Fix Javadoc ResourceBundle::getString

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

Commit messages:
 - Fix Javadoc ResourceBundle::getString

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

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

From weijun at openjdk.org  Thu Feb  8 16:38:22 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 8 Feb 2024 16:38:22 GMT
Subject: RFR: 8325506: Ensure randomness is only read from provided
 SecureRandom object
Message-ID: 

Many crypto service classes require a `SecureRandom` object at initialization. This test goes through each of them and calculates (generate, encrypt, sign,...) twice with the same `SecureRandom` object and ensures the output is the same.

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

Commit messages:
 - initial change

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

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

From duke at openjdk.org  Thu Feb  8 17:04:05 2024
From: duke at openjdk.org (Joshua Cao)
Date: Thu, 8 Feb 2024 17:04:05 GMT
Subject: RFR: 8324573: HashMap::putAll should resize to sum of both map
 sizes [v4]
In-Reply-To: 
References: 
 <-eVaZ9AgZ_GzfN2yeTK8VdE3efeSyx1NqjPyOOkPZAI=.e1007274-1943-46eb-bfab-f796d461da31@github.com>
 
Message-ID: 

On Wed, 7 Feb 2024 20:50:57 GMT, Stuart Marks  wrote:

>> Joshua Cao has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   extract msize variable
>
> I think we should step back from benchmarks a bit and examine the various tradeoffs occurring here. Certainly we can speed things up by pre-resizing the map to be larger. However, this can result in a map that is too large for the number of mappings it contains, in the case where this map and the argument map have keys in common. In other words, it might waste space. We really have little idea of how frequently this occurs. It's easy to imagine scenarios where there is no commonality (which this change will speed up) and also where there is 100% commonality (where this change will result in wasted space). What's the right tradeoff?
> 
> I've linked some older bugs to the bug report for some historical perspective. In particular, see [this comment](https://bugs.openjdk.org/browse/JDK-4710319?focusedId=12240692&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-12240692) from Josh Bloch on JDK-4710319:
> 
>> The conservatism of the resizing heuristic for putAll is intentional. It can cause at most one extra resizing, and can result in substantial footprint savings. This too should be documented in the code.
> 
> The comment he added to putAll() for this change is still visible [here](https://github.com/openjdk/jdk/blob/e1b3c5b5ba5cfb8243d760e99887bbe1015a9d69/jdk/src/share/classes/java/util/HashMap.java#L1271), but unfortunately it was removed by a later refactoring. The comment is:
> 
> 
>         /*
>          * Expand the map if the map if the number of mappings to be added
>          * is greater than or equal to threshold.  This is conservative; the
>          * obvious condition is (m.size() + size) >= threshold, but this
>          * condition could result in a map with twice the appropriate capacity,
>          * if the keys to be added overlap with the keys already in this map.
>          * By using the conservative calculation, we subject ourself
>          * to at most one extra resize.
>          */
> 
> 
> Note that this comment addresses fairly directly the essence of the change being discussed here. I think it's still applicable; the current code in putMapEntries() compares `m.size()` to `threshold` in deciding whether to resize immediately. We're not constrained by a 20-year-old comment, though. We can change the resizing policy if we have good reason to do so. 
> 
> However, I think the concern about space wastage is still relevant, even after 20 years of increased memory capacity and decreased memory cost. Memory is cheap but not free. Larger memory cons...

@stuart-marks Thanks for reviewing. I think there is some history that is hard to find right now. I'd suggest the following:

1. We don't need to close this PR. We can rename it to "Add comments for HashMap::putAll conservative expanding"
2. Undo the aggressive expanding in ConcurrentHashMap::putAll in a separate PR

@simonis what are your thoughts?

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

PR Comment: https://git.openjdk.org/jdk/pull/17544#issuecomment-1934554352

From jlu at openjdk.org  Thu Feb  8 17:25:04 2024
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 8 Feb 2024 17:25:04 GMT
Subject: RFR: 8325505: Fix Javadoc ResourceBundle::getString
In-Reply-To: 
References: 
Message-ID: 

On Wed, 10 Jan 2024 12:35:56 GMT, Thiago Henrique H?pner  wrote:

> 8325505: Fix Javadoc ResourceBundle::getString

Thanks for the fix, looks correct. In addition to the other comment I left, can you also bump the latter copyright year at the top of the file to 2024.

src/java.base/share/classes/java/util/ResourceBundle.java line 511:

> 509:      * Calling this method is equivalent to calling
> 510:      * {@snippet lang=java :
> 511:      *     // @link substring="getObject" target="#getObject(java.lang.String)"

Can you do a drive-by update for the comment in the snippet here,

Suggestion:

     *     // @link substring="getObject" target="#getObject(java.lang.String)" :


and also for the one in `getStringArray(String key)`

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

PR Review: https://git.openjdk.org/jdk/pull/17346#pullrequestreview-1870826863
PR Review Comment: https://git.openjdk.org/jdk/pull/17346#discussion_r1483334818

From duke at openjdk.org  Thu Feb  8 17:31:15 2024
From: duke at openjdk.org (Thiago Henrique =?UTF-8?B?SMO8cG5lcg==?=)
Date: Thu, 8 Feb 2024 17:31:15 GMT
Subject: RFR: 8325505: Fix Javadoc ResourceBundle::getString [v2]
In-Reply-To: 
References: 
Message-ID: 

> 8325505: Fix Javadoc ResourceBundle::getString

Thiago Henrique H?pner has updated the pull request incrementally with one additional commit since the last revision:

  Apply changes from review

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17346/files
  - new: https://git.openjdk.org/jdk/pull/17346/files/140d61dd..9f698ab6

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

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

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

From jvernee at openjdk.org  Thu Feb  8 17:50:03 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 8 Feb 2024 17:50:03 GMT
Subject: RFR: 8323552: AbstractMemorySegmentImpl#mismatch returns -1 when
 comparing distinct areas of the same instance of MemorySegment [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 11 Jan 2024 16:21:38 GMT, Peter Levart  wrote:

>> I belive there is a bug in `AbstractMemorySegmentImpl#mismatch` method. It returns `-1` (meaning that regions are equal) when passing the same instance of MemorySegment as both `srcSegment` and `dstSegment` parameters regardless of whether `srcFromOffset` and `dstFromOffset` as well as `srcToOffset` and `dstToOffset` are also equal.
>> 
>> Am I right?
>
> Peter Levart has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove special-case check from instance method - test pending

@plevart Are you planning to finish this? (add a test). Or maybe someone else can take over and do the rest?

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

PR Comment: https://git.openjdk.org/jdk/pull/17354#issuecomment-1934640546

From ihse at openjdk.org  Thu Feb  8 18:20:16 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 8 Feb 2024 18:20:16 GMT
Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v10]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 8 Feb 2024 07:44:18 GMT, Magnus Ihse Bursie  wrote:

>> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK native libraries.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Once more, remove AIX dirent64 et al defines

And the smaller file system ID is not a problem, I guess?

Do you want me to remove the redefines?

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

PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1934691860

From naoto at openjdk.org  Thu Feb  8 19:24:03 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 8 Feb 2024 19:24:03 GMT
Subject: RFR: 8325505: Fix Javadoc ResourceBundle::getString [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 8 Feb 2024 17:31:15 GMT, Thiago Henrique H?pner  wrote:

>> 8325505: Fix Javadoc ResourceBundle::getString
>
> Thiago Henrique H?pner has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Apply changes from review

LGTM

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17346#pullrequestreview-1871086540

From jlu at openjdk.org  Thu Feb  8 19:27:03 2024
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 8 Feb 2024 19:27:03 GMT
Subject: RFR: 8325505: Fix Javadoc ResourceBundle::getString [v2]
In-Reply-To: 
References: 
 
Message-ID: <37hF-oYU6GZQ7E-E8F4_QdZ0_bCgQeJ8FUFxHH5NOd8=.bc0d4764-1318-47e9-9828-5a619c5e3aad@github.com>

On Thu, 8 Feb 2024 17:31:15 GMT, Thiago Henrique H?pner  wrote:

>> 8325505: Fix Javadoc ResourceBundle::getString
>
> Thiago Henrique H?pner has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Apply changes from review

Marked as reviewed by jlu (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/17346#pullrequestreview-1871091731

From duke at openjdk.org  Thu Feb  8 20:07:08 2024
From: duke at openjdk.org (Vladimir Yaroslavskiy)
Date: Thu, 8 Feb 2024 20:07:08 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>
 
 
 
 
 
 <-bYhysKjQVb_ZS0I0YutJZ7umfYwbs74rtK6-d2qL9U=.f9981e59-f0c4-48f3-ad7e-5627aad00919@github.com>
 <91Zv361kqKOjCSJPu20-yhKOb4lBIZVyVTm9f79dkcQ=.745c271d-3cb1-4ff3-9d71-5cad85ff4f14@github.com>
 
 <9q8Gg6DQnrf0HLW3oxwfpoUP9639drr1BIQMc1rxDFo=.eb4ea73c-b632-446a-8d50-b51838f67f69@github.com>
 
 
 
Message-ID: <0OkFUL1UCNcLRNh4P2ZdKvMENJgFy8Tz2BA5l2QgDXE=.77152fca-3c03-46a0-9855-bcf1c9b8d152@github.com>

On Thu, 8 Feb 2024 01:54:45 GMT, Srinivas Vamsi Parasa  wrote:

>> Hello Vamsi (@vamsi-parasa),
>> 
>> Many thanks for the results! Now we can see that intrinsics are applied in all cases,
>> but there are big differences between the same code.
>> 
>> For example,
>> parallelSort REPEATED 20000:  58.265(Stock JDK) and 42.189(a15) with speedup x1.38
>> parallelSort STAGGER 3000000:  3687.198(Stock JDK) 4363.242(a15) with speedup  x0.85
>> 
>> Case a15 is the current source code from JDK, but in one benchmarking it is faster,
>> in other benchmarking it is slower (~15-30%).
>> 
>> Other strange behaviour with new sorting: r20p and r20s have the same code for
>> sequential sorting (no radix sort at all), but we can see that on case works much slower
>>  
>> sort STAGGER 3000000: 34406.74(r20p) and 10467.03(r20s) - 3.3 times slower,
>> whereas other sizes show more or less equal values.
>> 
>> Vamsi (@vamsi-parasa),
>> Could you please run benchmarking of 5 cases with **updated** test class **ArraysSortNew**?
>> https://github.com/iaroslavski/sorting/blob/master/radixsort/ArraysSortNew.java
>> 
>> Put the DPQS code in java.util package and recompiling the JDK for each case as you
>> did before, but run new **ArraysSortNew**.
>> 
>> Find the sources there:
>> 
>> https://github.com/iaroslavski/sorting/blob/master/radixsort/ArraysSortNew.java
>> https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_jdk.java
>> https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_r20p.java
>> https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_r20s.java
>> https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_r25p.java
>> https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_r25s.java
>> 
>> Thank you,
>> Vladimir
>
> Hi Vladimir (@iaroslavski),
> 
> The new ArraysSortNew.Java has compilation issues:
> 
> 
> error: DualPivotQuicksort is not public in java.util; cannot be accessed from outside package
>              java.util.DualPivotQuicksort.sort(b, PARALLELISM, 0, b.length);
> 
> Have you run into this issue? 
> 
> Thanks,
> Vamsi

Hi Vamsi (@vamsi-parasa),

My fault, there was an incorrect version of ArraysSortNew.java. Methods, of course, should be

@Benchmark
public void sort() {
    Arrays.sort(b);
}

@Benchmark
public void p_sort() {
    Arrays.parallelSort(b);
}

I uploaded correct version, see
https://github.com/iaroslavski/sorting/blob/master/radixsort/ArraysSortNew.java

I also comment that pom.xml contains additional options (I guess you have the same)
--add-exports=java.base/jdk.internal.misc=ALL-UNNAMED
--add-exports=java.base/jdk.internal.vm.annotation=ALL-UNNAMED
full text is there https://github.com/iaroslavski/sorting/blob/master/radixsort/pom.xml

and command to run test is
java --add-exports=java.base/jdk.internal.vm.annotation=ALL-UNNAMED --add-exports=java.base/jdk.internal.misc=ALL-UNNAMED -jar target/benchmarks.jar

I assume that each variant of DPQS (DualPivotQuicksort_jdk, DualPivotQuicksort_r20p, DualPivotQuicksort_r20s, DualPivotQuicksort_r25p, DualPivotQuicksort_r25s) is renamed to DualPivotQuicksort and put into
package java.util. Then benchmarking for a given variant with patched JDK is executed.

Thank you,
Vladimir

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

PR Comment: https://git.openjdk.org/jdk/pull/13568#issuecomment-1934851232

From jlu at openjdk.org  Thu Feb  8 20:37:18 2024
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 8 Feb 2024 20:37:18 GMT
Subject: RFR: JDK-8318761: MessageFormat pattern support for
 CompactNumberFormat, ListFormat, and DateTimeFormatter [v6]
In-Reply-To: 
References: 
Message-ID: <1wTWibxrs02puoWXDnNSm4_6crVB8bx9yzbWccS_Nv0=.fb323a11-8a53-4da6-af98-fba01709d452@github.com>

> Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8319344) which adds MessageFormat pattern support for the following subformats: ListFormat, CompactNumberFormat, and DateTimeFormatter. This change is intended to provide pattern support for the more recently added JDK Format subclasses, as well as improving java.time formatting within i18n. The draft javadoc can be viewed here: https://cr.openjdk.org/~jlu/docs/api/java.base/java/text/MessageFormat.html. Please see the CSR for more in-depth behavioral changes, as well as limitations.
> 
> The `FormatTypes`:  dtf_date, dtf_time, dtf_datetime, pre-defined DateTimeFormatter(s), and list are added.
> The `FormatStyles`: compact_short, compact_long, or, and unit are added.
> 
> For example, previously,
> 
> 
> Object[] args = {LocalDate.of(2023, 11, 16), LocalDate.of(2023, 11, 27)};
> MessageFormat.format("It was {0,date,full}, now it is {1,date,full}", args);
> 
> 
> would throw `Exception java.lang.IllegalArgumentException: Cannot format given Object as a Date`
> 
> Now, a user can call
> 
> 
> MessageFormat.format("It was {0,dtf_date,full}, now it is {1,dtf_date,full}", args);
> 
> 
> which returns "It was Thursday, November 16, 2023, now it is Friday, November 17, 2023"

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

  Move the if-else nFmt checking to a package-private method in NumberFormat

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17663/files
  - new: https://git.openjdk.org/jdk/pull/17663/files/9d7a5c05..8844848e

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

  Stats: 57 lines in 2 files changed: 28 ins; 12 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/17663.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17663/head:pull/17663

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

From kdriver at openjdk.org  Thu Feb  8 20:56:02 2024
From: kdriver at openjdk.org (Kevin Driver)
Date: Thu, 8 Feb 2024 20:56:02 GMT
Subject: RFR: 8325506: Ensure randomness is only read from provided
 SecureRandom object
In-Reply-To: 
References: 
Message-ID: 

On Thu, 8 Feb 2024 16:34:00 GMT, Weijun Wang  wrote:

> Many crypto service classes require a `SecureRandom` object at initialization. This test goes through each of them and calculates (generate, encrypt, sign,...) twice with the same `SecureRandom` object and ensures the output is the same.

See above comment, but otherwise, this looks solid.

test/lib/jdk/test/lib/security/SeededSecureRandom.java line 36:

> 34:  * system property to this recorded seed to reproduce the failure.
> 35:  */
> 36: public class SeededSecureRandom extends SecureRandom {

Do you see any value in bringing this "helper class" from test over to the actual public API? Just a suggestion.

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

Marked as reviewed by kdriver (Committer).

PR Review: https://git.openjdk.org/jdk/pull/17776#pullrequestreview-1871237962
PR Review Comment: https://git.openjdk.org/jdk/pull/17776#discussion_r1483577625

From asemenyuk at openjdk.org  Thu Feb  8 21:02:14 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 8 Feb 2024 21:02:14 GMT
Subject: RFR: 8325203: System.exit(0) kills the launched 3rd party application
Message-ID: 

Tested with the use case from the CR.

Filed a follow-up https://bugs.openjdk.org/browse/JDK-8325525 CR to track adding a jtreg test for the issue.

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

Commit messages:
 - 8325203: System.exit(0) kills the launched 3rd party application

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

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

From asemenyuk at openjdk.org  Thu Feb  8 21:06:01 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 8 Feb 2024 21:06:01 GMT
Subject: RFR: 8325203: System.exit(0) kills the launched 3rd party
 application
In-Reply-To: 
References: 
Message-ID: 

On Thu, 8 Feb 2024 20:57:51 GMT, Alexey Semenyuk  wrote:

> Tested with the use case from the CR.
> 
> The idea of the fix is to prevent grandchildren processes from being automatically attached to the job killing all processes attached to it when the job object is destroyed.
> 
> Filed a follow-up https://bugs.openjdk.org/browse/JDK-8325525 CR to track adding a jtreg test for the issue.

@sashamatveev please review

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

PR Comment: https://git.openjdk.org/jdk/pull/17779#issuecomment-1934929275

From naoto at openjdk.org  Thu Feb  8 21:20:57 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 8 Feb 2024 21:20:57 GMT
Subject: RFR: JDK-8318761: MessageFormat pattern support for
 CompactNumberFormat, ListFormat, and DateTimeFormatter [v6]
In-Reply-To: <1wTWibxrs02puoWXDnNSm4_6crVB8bx9yzbWccS_Nv0=.fb323a11-8a53-4da6-af98-fba01709d452@github.com>
References: 
 <1wTWibxrs02puoWXDnNSm4_6crVB8bx9yzbWccS_Nv0=.fb323a11-8a53-4da6-af98-fba01709d452@github.com>
Message-ID: 

On Thu, 8 Feb 2024 20:37:18 GMT, Justin Lu  wrote:

>> Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8319344) which adds MessageFormat pattern support for the following subformats: ListFormat, CompactNumberFormat, and DateTimeFormatter. This change is intended to provide pattern support for the more recently added JDK Format subclasses, as well as improving java.time formatting within i18n. The draft javadoc can be viewed here: https://cr.openjdk.org/~jlu/docs/api/java.base/java/text/MessageFormat.html. Please see the CSR for more in-depth behavioral changes, as well as limitations.
>> 
>> The `FormatTypes`:  dtf_date, dtf_time, dtf_datetime, pre-defined DateTimeFormatter(s), and list are added.
>> The `FormatStyles`: compact_short, compact_long, or, and unit are added.
>> 
>> For example, previously,
>> 
>> 
>> Object[] args = {LocalDate.of(2023, 11, 16), LocalDate.of(2023, 11, 27)};
>> MessageFormat.format("It was {0,date,full}, now it is {1,date,full}", args);
>> 
>> 
>> would throw `Exception java.lang.IllegalArgumentException: Cannot format given Object as a Date`
>> 
>> Now, a user can call
>> 
>> 
>> MessageFormat.format("It was {0,dtf_date,full}, now it is {1,dtf_date,full}", args);
>> 
>> 
>> which returns "It was Thursday, November 16, 2023, now it is Friday, November 17, 2023"
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move the if-else nFmt checking to a package-private method in NumberFormat

Looks much better. Left some nits.

src/java.base/share/classes/java/text/MessageFormat.java line 745:

> 743:             String nStyle = NumberFormat.matchToStyle(nFmt, locale);
> 744:             if (nStyle != null) {
> 745:                 return ",number" + (nStyle.equals("") ? nStyle : "," + nStyle);

`nStyle.isEmpty()` may read better

src/java.base/share/classes/java/text/MessageFormat.java line 780:

> 778:             }
> 779:         }
> 780:         else if (fmt != null) {

This `else if` does not seem necessary

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

PR Review: https://git.openjdk.org/jdk/pull/17663#pullrequestreview-1871266747
PR Review Comment: https://git.openjdk.org/jdk/pull/17663#discussion_r1483596204
PR Review Comment: https://git.openjdk.org/jdk/pull/17663#discussion_r1483599292

From jlu at openjdk.org  Thu Feb  8 21:29:19 2024
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 8 Feb 2024 21:29:19 GMT
Subject: RFR: JDK-8318761: MessageFormat pattern support for
 CompactNumberFormat, ListFormat, and DateTimeFormatter [v7]
In-Reply-To: 
References: 
Message-ID: 

> Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8319344) which adds MessageFormat pattern support for the following subformats: ListFormat, CompactNumberFormat, and DateTimeFormatter. This change is intended to provide pattern support for the more recently added JDK Format subclasses, as well as improving java.time formatting within i18n. The draft javadoc can be viewed here: https://cr.openjdk.org/~jlu/docs/api/java.base/java/text/MessageFormat.html. Please see the CSR for more in-depth behavioral changes, as well as limitations.
> 
> The `FormatTypes`:  dtf_date, dtf_time, dtf_datetime, pre-defined DateTimeFormatter(s), and list are added.
> The `FormatStyles`: compact_short, compact_long, or, and unit are added.
> 
> For example, previously,
> 
> 
> Object[] args = {LocalDate.of(2023, 11, 16), LocalDate.of(2023, 11, 27)};
> MessageFormat.format("It was {0,date,full}, now it is {1,date,full}", args);
> 
> 
> would throw `Exception java.lang.IllegalArgumentException: Cannot format given Object as a Date`
> 
> Now, a user can call
> 
> 
> MessageFormat.format("It was {0,dtf_date,full}, now it is {1,dtf_date,full}", args);
> 
> 
> which returns "It was Thursday, November 16, 2023, now it is Friday, November 17, 2023"

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

  implement Naoto's review

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17663/files
  - new: https://git.openjdk.org/jdk/pull/17663/files/8844848e..7ff52f8f

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

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

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

From jlu at openjdk.org  Thu Feb  8 21:29:19 2024
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 8 Feb 2024 21:29:19 GMT
Subject: RFR: JDK-8318761: MessageFormat pattern support for
 CompactNumberFormat, ListFormat, and DateTimeFormatter [v6]
In-Reply-To: 
References: 
 <1wTWibxrs02puoWXDnNSm4_6crVB8bx9yzbWccS_Nv0=.fb323a11-8a53-4da6-af98-fba01709d452@github.com>
 
Message-ID: 

On Thu, 8 Feb 2024 21:16:45 GMT, Naoto Sato  wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Move the if-else nFmt checking to a package-private method in NumberFormat
>
> src/java.base/share/classes/java/text/MessageFormat.java line 780:
> 
>> 778:             }
>> 779:         }
>> 780:         else if (fmt != null) {
> 
> This `else if` does not seem necessary

Originally this was needed to make patterns for ClassicFormat (since we could not instanceof check it due to visibility), but as ClassicFormat/DateTimeFormatter cannot be equality checked, this isn't needed. Removed, thanks for spotting.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17663#discussion_r1483609034

From naoto at openjdk.org  Thu Feb  8 21:56:06 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 8 Feb 2024 21:56:06 GMT
Subject: RFR: JDK-8318761: MessageFormat pattern support for
 CompactNumberFormat, ListFormat, and DateTimeFormatter [v7]
In-Reply-To: 
References: 
 
Message-ID: <1MdV6Q8OInb4EQ3csEqri-NOxJccYhnoioau1E1z0mc=.929c9448-4120-4dad-9090-e0a2b318a981@github.com>

On Thu, 8 Feb 2024 21:29:19 GMT, Justin Lu  wrote:

>> Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8319344) which adds MessageFormat pattern support for the following subformats: ListFormat, CompactNumberFormat, and DateTimeFormatter. This change is intended to provide pattern support for the more recently added JDK Format subclasses, as well as improving java.time formatting within i18n. The draft javadoc can be viewed here: https://cr.openjdk.org/~jlu/docs/api/java.base/java/text/MessageFormat.html. Please see the CSR for more in-depth behavioral changes, as well as limitations.
>> 
>> The `FormatTypes`:  dtf_date, dtf_time, dtf_datetime, pre-defined DateTimeFormatter(s), and list are added.
>> The `FormatStyles`: compact_short, compact_long, or, and unit are added.
>> 
>> For example, previously,
>> 
>> 
>> Object[] args = {LocalDate.of(2023, 11, 16), LocalDate.of(2023, 11, 27)};
>> MessageFormat.format("It was {0,date,full}, now it is {1,date,full}", args);
>> 
>> 
>> would throw `Exception java.lang.IllegalArgumentException: Cannot format given Object as a Date`
>> 
>> Now, a user can call
>> 
>> 
>> MessageFormat.format("It was {0,dtf_date,full}, now it is {1,dtf_date,full}", args);
>> 
>> 
>> which returns "It was Thursday, November 16, 2023, now it is Friday, November 17, 2023"
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   implement Naoto's review

LGTM

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17663#pullrequestreview-1871328637

From duke at openjdk.org  Thu Feb  8 22:00:09 2024
From: duke at openjdk.org (Thiago Henrique =?UTF-8?B?SMO8cG5lcg==?=)
Date: Thu, 8 Feb 2024 22:00:09 GMT
Subject: Integrated: 8325505: Fix Javadoc ResourceBundle::getString
In-Reply-To: 
References: 
Message-ID: 

On Wed, 10 Jan 2024 12:35:56 GMT, Thiago Henrique H?pner  wrote:

> 8325505: Fix Javadoc ResourceBundle::getString

This pull request has now been integrated.

Changeset: d91fb17a
Author:    Thiago Henrique H?pner 
Committer: Naoto Sato 
URL:       https://git.openjdk.org/jdk/commit/d91fb17a80f6a577fdc77843df358c77d701f221
Stats:     4 lines in 1 file changed: 0 ins; 0 del; 4 mod

8325505: Fix Javadoc ResourceBundle::getString

Reviewed-by: jlu, naoto

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

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

From lmesnik at openjdk.org  Thu Feb  8 23:31:09 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 8 Feb 2024 23:31:09 GMT
Subject: RFR: 8319578: Few java/lang/instrument ignore test.java.opts and
 accept test.vm.opts only
Message-ID: 

There are several .sh tests which use ${TESTVMOPTS}  only. Updated them to use  ${TESTJAVAOPTS}  also.
Tested by running them with different options and tier1.

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

Commit messages:
 - 8319578: Few java/lang/instrument ignore test.java.opts and accept test.vm.opts only

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

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

From lmesnik at openjdk.org  Thu Feb  8 23:35:26 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 8 Feb 2024 23:35:26 GMT
Subject: RFR: 8316451: 6 java/lang/instrument/PremainClass tests ignore VM
 flags
Message-ID: 

Tests updated to use jtreg vm flags.
Tested by running tests with different flags and tier1.

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

Commit messages:
 - 8316451

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

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

From almatvee at openjdk.org  Thu Feb  8 23:37:03 2024
From: almatvee at openjdk.org (Alexander Matveev)
Date: Thu, 8 Feb 2024 23:37:03 GMT
Subject: RFR: 8325203: System.exit(0) kills the launched 3rd party
 application
In-Reply-To: 
References: 
Message-ID: 

On Thu, 8 Feb 2024 20:57:51 GMT, Alexey Semenyuk  wrote:

> Tested with the use case from the CR.
> 
> The idea of the fix is to prevent grandchildren processes from being automatically attached to the job killing all processes attached to it when the job object is destroyed.
> 
> Filed a follow-up https://bugs.openjdk.org/browse/JDK-8325525 CR to track adding a jtreg test for the issue.

Looks good.

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

Marked as reviewed by almatvee (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17779#pullrequestreview-1871439784

From weijun at openjdk.org  Fri Feb  9 01:02:54 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 9 Feb 2024 01:02:54 GMT
Subject: RFR: 8325506: Ensure randomness is only read from provided
 SecureRandom object
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 8 Feb 2024 20:53:03 GMT, Kevin Driver  wrote:

>> Many crypto service classes require a `SecureRandom` object at initialization. This test goes through each of them and calculates (generate, encrypt, sign,...) twice with the same `SecureRandom` object and ensures the output is the same.
>
> test/lib/jdk/test/lib/security/SeededSecureRandom.java line 36:
> 
>> 34:  * system property to this recorded seed to reproduce the failure.
>> 35:  */
>> 36: public class SeededSecureRandom extends SecureRandom {
> 
> Do you see any value in bringing this "helper class" from test over to the actual public API? Just a suggestion.

Where do you want to use it other than in a test? Besides, it's based on `java.util.Random` and not cryptographically random enough.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17776#discussion_r1483753416

From weijun at openjdk.org  Fri Feb  9 01:21:22 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 9 Feb 2024 01:21:22 GMT
Subject: RFR: 8325506: Ensure randomness is only read from provided
 SecureRandom object [v2]
In-Reply-To: 
References: 
Message-ID: <4kUBwfJdhEPgt58b6yM4ItyxyqPNG32cHk_2ThV_-xs=.b418fa7a-148c-4054-8a7c-4e5d5423f0a1@github.com>

> Many crypto service classes require a `SecureRandom` object at initialization. This test goes through each of them and calculates (generate, encrypt, sign,...) twice with the same `SecureRandom` object and ensures the output is the same.

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

  cannot control randomness for SunMSCAPI provider

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17776/files
  - new: https://git.openjdk.org/jdk/pull/17776/files/4e7fc6a5..a1715f04

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

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

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

From mbalao at openjdk.org  Fri Feb  9 03:08:15 2024
From: mbalao at openjdk.org (Martin Balao)
Date: Fri, 9 Feb 2024 03:08:15 GMT
Subject: RFR: 8315487: Security Providers Filter [v8]
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:

  Minor changes to align with the JEP.
  
  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/b231a75d..e553cfd1

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

  Stats: 4 lines in 2 files changed: 2 ins; 0 del; 2 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 smarks at openjdk.org  Fri Feb  9 06:38:02 2024
From: smarks at openjdk.org (Stuart Marks)
Date: Fri, 9 Feb 2024 06:38:02 GMT
Subject: RFR: 8324573: HashMap::putAll should resize to sum of both map
 sizes [v4]
In-Reply-To: 
References: 
 <-eVaZ9AgZ_GzfN2yeTK8VdE3efeSyx1NqjPyOOkPZAI=.e1007274-1943-46eb-bfab-f796d461da31@github.com>
 
 
Message-ID: 

On Thu, 8 Feb 2024 17:01:15 GMT, Joshua Cao  wrote:

>> I think we should step back from benchmarks a bit and examine the various tradeoffs occurring here. Certainly we can speed things up by pre-resizing the map to be larger. However, this can result in a map that is too large for the number of mappings it contains, in the case where this map and the argument map have keys in common. In other words, it might waste space. We really have little idea of how frequently this occurs. It's easy to imagine scenarios where there is no commonality (which this change will speed up) and also where there is 100% commonality (where this change will result in wasted space). What's the right tradeoff?
>> 
>> I've linked some older bugs to the bug report for some historical perspective. In particular, see [this comment](https://bugs.openjdk.org/browse/JDK-4710319?focusedId=12240692&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-12240692) from Josh Bloch on JDK-4710319:
>> 
>>> The conservatism of the resizing heuristic for putAll is intentional. It can cause at most one extra resizing, and can result in substantial footprint savings. This too should be documented in the code.
>> 
>> The comment he added to putAll() for this change is still visible [here](https://github.com/openjdk/jdk/blob/e1b3c5b5ba5cfb8243d760e99887bbe1015a9d69/jdk/src/share/classes/java/util/HashMap.java#L1271), but unfortunately it was removed by a later refactoring. The comment is:
>> 
>> 
>>         /*
>>          * Expand the map if the map if the number of mappings to be added
>>          * is greater than or equal to threshold.  This is conservative; the
>>          * obvious condition is (m.size() + size) >= threshold, but this
>>          * condition could result in a map with twice the appropriate capacity,
>>          * if the keys to be added overlap with the keys already in this map.
>>          * By using the conservative calculation, we subject ourself
>>          * to at most one extra resize.
>>          */
>> 
>> 
>> Note that this comment addresses fairly directly the essence of the change being discussed here. I think it's still applicable; the current code in putMapEntries() compares `m.size()` to `threshold` in deciding whether to resize immediately. We're not constrained by a 20-year-old comment, though. We can change the resizing policy if we have good reason to do so. 
>> 
>> However, I think the concern about space wastage is still relevant, even after 20 years of increased memory capacity and decreased memory cost. Mem...
>
> @stuart-marks Thanks for reviewing. I think there is some history that is hard to find right now. I'd suggest the following:
> 
> 1. We don't need to close this PR. We can rename it to "Add comments for HashMap::putAll conservative expanding"
> 2. Undo the aggressive expanding in ConcurrentHashMap::putAll in a separate PR
> 
> @simonis what are your thoughts?

@caojoshua Sure, no need to close this right away or anything. My main point is to open up a different line of discussion and see where it leads us.

If we were to decide not to change HashMap as discussed here, I don't think it _necessarily_ follows that the ConcurrentHashMap::putAll change (https://github.com/openjdk/jdk/pull/17116, [JDK-8322149](https://bugs.openjdk.org/browse/JDK-8322149)) should be reverted. Maybe it should be, or maybe it shouldn't. There might be different circumstances around CHM. First, @DougLea said that the change was OK. :-) Second, although CHM allows updates to proceed concurrently with resizes, it may be that resizing CHM has additional overhead that is helpful to avoid. Third, users of CHM may have different expectations than users of HashMap; they might prefer higher throughput to lower memory usage, for example. I haven't looked at the CHM code in detail though. I'd caution against jumping to the conclusion that the other fix needs to be reverted.

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

PR Comment: https://git.openjdk.org/jdk/pull/17544#issuecomment-1935405832

From jpai at openjdk.org  Fri Feb  9 06:42:09 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 9 Feb 2024 06:42:09 GMT
Subject: RFR: 8303891: Speed up Zip64SizeTest using a small ZIP64 file [v5]
In-Reply-To: 
References: 
 
Message-ID: <2rbbCXHLEpdPrhf6jmXaPJV32_9cYwV8ra7KFEvBYrw=.ef926c3c-4381-42a2-a785-e47755078a69@github.com>

On Thu, 8 Feb 2024 14:09:35 GMT, Eirik Bj?rsn?s  wrote:

>> Please review this PR which suggests we speed up the `Zip64SizeTest` using a small-sized ZIP64 ZIP file specifically created to reproduce the issue being tested.
>> 
>> The disk space requirement of this test is known to cause problems in some builds, see [JDK-8259866](https://bugs.openjdk.org/browse/JDK-8259866)
>> 
>> By using a sparse file, we reduce consumed disk space from 5GB to 266 bytes and also reduce the runtime from ~35 seconds to ~1 seconds on my Macbook Pro.
>> 
>> The PR also fixes the `@summary` tag, which seems to have been copied from an unrelated test.
>
> Eirik Bj?rsn?s has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 13 additional commits since the last revision:
> 
>  - Use a small ZIP64 file to reproduce the issue. Convert test to JUnit
>  - Update copyright year for 2024
>  - Use ENTRY instead of FILE when refering to names and sizes of file entries in the ZIP file
>  - Merge branch 'master' into zip64-size-test-sparse
>  - Merge branch 'master' into zip64-size-test-sparse
>  - Sparse files must be created explicitly on NTFS
>  - Merge branch 'master' into zip64-size-test-sparse
>  - Merge branch 'master' into zip64-size-test-sparse
>  - Make test method public
>  - Add a missing "when" in Javadocs for SparseOutputStream
>  - ... and 3 more: https://git.openjdk.org/jdk/compare/7877fdf3...41b2ba5e

test/jdk/java/util/zip/ZipFile/Zip64SizeTest.java line 53:

> 51:     // ZIP file to create
> 52:     private static final Path ZIP_FILE = Path.of("Zip64SizeTest.zip");
> 53:     // ontents to write to ZIP entries

Typo - should have been "contents"

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

PR Review Comment: https://git.openjdk.org/jdk/pull/12948#discussion_r1483919822

From jpai at openjdk.org  Fri Feb  9 07:19:08 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 9 Feb 2024 07:19:08 GMT
Subject: RFR: 8303891: Speed up Zip64SizeTest using a small ZIP64 file [v5]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 8 Feb 2024 14:09:35 GMT, Eirik Bj?rsn?s  wrote:

>> Please review this PR which suggests we speed up the `Zip64SizeTest` using a small-sized ZIP64 ZIP file specifically created to reproduce the issue being tested.
>> 
>> The disk space requirement of this test is known to cause problems in some builds, see [JDK-8259866](https://bugs.openjdk.org/browse/JDK-8259866)
>> 
>> By using a sparse file, we reduce consumed disk space from 5GB to 266 bytes and also reduce the runtime from ~35 seconds to ~1 seconds on my Macbook Pro.
>> 
>> The PR also fixes the `@summary` tag, which seems to have been copied from an unrelated test.
>
> Eirik Bj?rsn?s has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 13 additional commits since the last revision:
> 
>  - Use a small ZIP64 file to reproduce the issue. Convert test to JUnit
>  - Update copyright year for 2024
>  - Use ENTRY instead of FILE when refering to names and sizes of file entries in the ZIP file
>  - Merge branch 'master' into zip64-size-test-sparse
>  - Merge branch 'master' into zip64-size-test-sparse
>  - Sparse files must be created explicitly on NTFS
>  - Merge branch 'master' into zip64-size-test-sparse
>  - Merge branch 'master' into zip64-size-test-sparse
>  - Make test method public
>  - Add a missing "when" in Javadocs for SparseOutputStream
>  - ... and 3 more: https://git.openjdk.org/jdk/compare/d01414fa...41b2ba5e

test/jdk/java/util/zip/ZipFile/Zip64SizeTest.java line 112:

> 110:             ZipEntry e1 = new ZipEntry("first");
> 111:             // Make room for an 8-byte ZIP64 extra field
> 112:             e1.setExtra(createOpaqueExtra((short) Long.BYTES));

Hello Eirik, I couldn't understand why we first add a opaque extra field first and then update it to be a zip64 extra field. Why do we do this?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/12948#discussion_r1483943970

From aturbanov at openjdk.org  Fri Feb  9 08:18:03 2024
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Fri, 9 Feb 2024 08:18:03 GMT
Subject: RFR: 8325485: IncrementInstructions.of(int,
 int) is not storing the args
In-Reply-To: 
References: 
Message-ID: 

On Thu, 8 Feb 2024 13:18:41 GMT, Adam Sotona  wrote:

> ClassFile API provides two sets of instructions implementations (bound and unbound).
> Unbound implementation of `IncrementInstruction::constant` returns invalid value. 
> This bug discovered a hole in the ClassFile API test coverage.
> 
> This patch provides very simple fix of `IncrementInstruction`
> and more complex fix of the test framework to cover all unbound instruction with automated tests.
> 
> The test framework fix includes correction of hash calculation of instructions in `ClassRecord` and
> two-pass transformation in `RebuildingTransformation`. Second pass has been added to discover bugs in unbound-to-unbound instruction conversions.
> 
> Please review.
> 
> Thanks,
> Adam

test/jdk/jdk/classfile/helpers/RebuildingTransformation.java line 441:

> 439:                     switch (i.opcode()) {
> 440:                         case MONITORENTER ->  cob.monitorenter();
> 441:                         case MONITOREXIT ->  cob.monitorexit();

Suggestion:

                        case MONITORENTER -> cob.monitorenter();
                        case MONITOREXIT -> cob.monitorexit();

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17770#discussion_r1483992861

From eirbjo at openjdk.org  Fri Feb  9 10:33:30 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Fri, 9 Feb 2024 10:33:30 GMT
Subject: RFR: 8303891: Speed up Zip64SizeTest using a small ZIP64 file [v6]
In-Reply-To: 
References: 
Message-ID: 

> Please review this PR which suggests we speed up the `Zip64SizeTest` using a small-sized ZIP64 ZIP file specifically created to reproduce the issue being tested.
> 
> The disk space requirement of this test is known to cause problems in some builds, see [JDK-8259866](https://bugs.openjdk.org/browse/JDK-8259866)
> 
> By using a sparse file, we reduce consumed disk space from 5GB to 266 bytes and also reduce the runtime from ~35 seconds to ~1 seconds on my Macbook Pro.
> 
> The PR also fixes the `@summary` tag, which seems to have been copied from an unrelated test.

Eirik Bj?rsn?s has updated the pull request incrementally with two additional commits since the last revision:

 - Spell fix for "Contents"
 - Add comments to explain how we temporarily use the 'unknown' tag to prevent ZipEntry.setExtra0 from processing the extra field.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12948/files
  - new: https://git.openjdk.org/jdk/pull/12948/files/41b2ba5e..34333c98

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

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

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

From eirbjo at openjdk.org  Fri Feb  9 10:45:02 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Fri, 9 Feb 2024 10:45:02 GMT
Subject: RFR: 8303891: Speed up Zip64SizeTest using a small ZIP64 file [v5]
In-Reply-To: <2rbbCXHLEpdPrhf6jmXaPJV32_9cYwV8ra7KFEvBYrw=.ef926c3c-4381-42a2-a785-e47755078a69@github.com>
References: 
 
 <2rbbCXHLEpdPrhf6jmXaPJV32_9cYwV8ra7KFEvBYrw=.ef926c3c-4381-42a2-a785-e47755078a69@github.com>
Message-ID: 

On Fri, 9 Feb 2024 06:39:31 GMT, Jaikiran Pai  wrote:

>> Eirik Bj?rsn?s has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 13 additional commits since the last revision:
>> 
>>  - Use a small ZIP64 file to reproduce the issue. Convert test to JUnit
>>  - Update copyright year for 2024
>>  - Use ENTRY instead of FILE when refering to names and sizes of file entries in the ZIP file
>>  - Merge branch 'master' into zip64-size-test-sparse
>>  - Merge branch 'master' into zip64-size-test-sparse
>>  - Sparse files must be created explicitly on NTFS
>>  - Merge branch 'master' into zip64-size-test-sparse
>>  - Merge branch 'master' into zip64-size-test-sparse
>>  - Make test method public
>>  - Add a missing "when" in Javadocs for SparseOutputStream
>>  - ... and 3 more: https://git.openjdk.org/jdk/compare/1bff6cd8...41b2ba5e
>
> test/jdk/java/util/zip/ZipFile/Zip64SizeTest.java line 53:
> 
>> 51:     // ZIP file to create
>> 52:     private static final Path ZIP_FILE = Path.of("Zip64SizeTest.zip");
>> 53:     // ontents to write to ZIP entries
> 
> Typo - should have been "contents"

Thanks, fixed.

> Hello Eirik, I couldn't understand why we first add a opaque extra field first and then update it to be a zip64 extra field. Why do we do this?

`ZipEntry.setExtra` processes the byte array argument, looking for Zip64 extended fields which it can extract the size fields from. To prevent this parsing from happening, we temporarily use the `unknown` tag.

In this particular case, `ZipExtra.setExtra` actually ends up skipping this processing (because `isLOC == true` and it has a guard for the block size being `>= 16`).

However, I prefer the test to not depend too much on the details of `setExtra` Zip64 processing. This trick is used in other tests as well and may be copied over to a test where the conditions are not the same.

I have refactored a bit and added some code comments to help explain the use of the 'unknown' tag.

Do you think this makes sense?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/12948#discussion_r1484148941
PR Review Comment: https://git.openjdk.org/jdk/pull/12948#discussion_r1484148034

From asotona at openjdk.org  Fri Feb  9 10:47:08 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 9 Feb 2024 10:47:08 GMT
Subject: RFR: 8325485: IncrementInstructions.of(int,
 int) is not storing the args [v2]
In-Reply-To: 
References: 
Message-ID: 

> ClassFile API provides two sets of instructions implementations (bound and unbound).
> Unbound implementation of `IncrementInstruction::constant` returns invalid value. 
> This bug discovered a hole in the ClassFile API test coverage.
> 
> This patch provides very simple fix of `IncrementInstruction`
> and more complex fix of the test framework to cover all unbound instruction with automated tests.
> 
> The test framework fix includes correction of hash calculation of instructions in `ClassRecord` and
> two-pass transformation in `RebuildingTransformation`. Second pass has been added to discover bugs in unbound-to-unbound instruction conversions.
> 
> Please review.
> 
> Thanks,
> Adam

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

  Update test/jdk/jdk/classfile/helpers/RebuildingTransformation.java
  
  Co-authored-by: Andrey Turbanov 

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17770/files
  - new: https://git.openjdk.org/jdk/pull/17770/files/92d5af38..8586d628

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

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

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

From alanb at openjdk.org  Fri Feb  9 11:41:06 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 9 Feb 2024 11:41:06 GMT
Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v10]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 8 Feb 2024 07:44:18 GMT, Magnus Ihse Bursie  wrote:

>> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK native libraries.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Once more, remove AIX dirent64 et al defines

I can't comment on AIX but the changes look okay overall. I assume you'll bump the copyright header date on all the updated files before integrating.

src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c line 257:

> 255: static int fstatat_wrapper(int dfd, const char *path,
> 256:                              struct stat *statbuf, int flag)
> 257: {

Minor nit - you can probably fix the align after the edit or collapse it into one line.

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17538#pullrequestreview-1872182776
PR Review Comment: https://git.openjdk.org/jdk/pull/17538#discussion_r1484203284

From lancea at openjdk.org  Fri Feb  9 12:05:55 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 9 Feb 2024 12:05:55 GMT
Subject: RFR: 8303891: Speed up Zip64SizeTest using a small ZIP64 file [v6]
In-Reply-To: 
References: 
 
Message-ID: <9aSa7L7oFJi2APM10qnHx9JO19w6mCKSSilOgYhSt2w=.5a125032-2faf-47a3-9306-00c7c300729b@github.com>

On Fri, 9 Feb 2024 10:33:30 GMT, Eirik Bj?rsn?s  wrote:

>> Please review this PR which suggests we speed up the `Zip64SizeTest` using a small-sized ZIP64 ZIP file specifically created to reproduce the issue being tested.
>> 
>> The disk space requirement of this test is known to cause problems in some builds, see [JDK-8259866](https://bugs.openjdk.org/browse/JDK-8259866)
>> 
>> By using a sparse file, we reduce consumed disk space from 5GB to 266 bytes and also reduce the runtime from ~35 seconds to ~1 seconds on my Macbook Pro.
>> 
>> The PR also fixes the `@summary` tag, which seems to have been copied from an unrelated test.
>
> Eirik Bj?rsn?s has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Spell fix for "Contents"
>  - Add comments to explain how we temporarily use the 'unknown' tag to prevent ZipEntry.setExtra0 from processing the extra field.

thank you for the latest updates Eirik.

Overall it is good a few more comment suggestions for extra clarity.

test/jdk/java/util/zip/ZipFile/Zip64SizeTest.java line 114:

> 112: 
> 113:             // Make an extra field with the correct size for an 8-byte 'uncompressed size'
> 114:             // Zip64 field. Temporarily use the 'unknown' tag 0x9902 to make

I would suggest adding a reference to the following in the APPNOTE.TXT  to make clearer where that value came from

>  4.6.1 Third party mappings commonly used are:

another suggestion would be to show the CEN here with this change I think would make it easier for someone who is not as familiar with APPNOTE.TXT

test/jdk/java/util/zip/ZipFile/Zip64SizeTest.java line 140:

> 138:      * @param zip the ZIP file to update to ZIP64
> 139:      */
> 140:     private static void updateCENHeaderToZip64(byte[] zip) {

Again minor but perhaps articulate that after this call, the extra data will be(obvious to you and I but probably not to others...)

   

>   * 00B4 Extra ID #0001        0001 'ZIP64'
>      * 00B6   Length              0008
>      * 00B8   Uncompressed Size   0000000000000005

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

Marked as reviewed by lancea (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/12948#pullrequestreview-1872219560
PR Review Comment: https://git.openjdk.org/jdk/pull/12948#discussion_r1484225117
PR Review Comment: https://git.openjdk.org/jdk/pull/12948#discussion_r1484229268

From eirbjo at openjdk.org  Fri Feb  9 12:23:19 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Fri, 9 Feb 2024 12:23:19 GMT
Subject: RFR: 8303891: Speed up Zip64SizeTest using a small ZIP64 file [v6]
In-Reply-To: <9aSa7L7oFJi2APM10qnHx9JO19w6mCKSSilOgYhSt2w=.5a125032-2faf-47a3-9306-00c7c300729b@github.com>
References: 
 
 <9aSa7L7oFJi2APM10qnHx9JO19w6mCKSSilOgYhSt2w=.5a125032-2faf-47a3-9306-00c7c300729b@github.com>
Message-ID: 

On Fri, 9 Feb 2024 11:55:16 GMT, Lance Andersen  wrote:

>> Eirik Bj?rsn?s has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Spell fix for "Contents"
>>  - Add comments to explain how we temporarily use the 'unknown' tag to prevent ZipEntry.setExtra0 from processing the extra field.
>
> test/jdk/java/util/zip/ZipFile/Zip64SizeTest.java line 114:
> 
>> 112: 
>> 113:             // Make an extra field with the correct size for an 8-byte 'uncompressed size'
>> 114:             // Zip64 field. Temporarily use the 'unknown' tag 0x9902 to make
> 
> I would suggest adding a reference to the following in the APPNOTE.TXT  to make clearer where that value came from
> 
>>  4.6.1 Third party mappings commonly used are:
> 
> another suggestion would be to show the CEN here with this change I think would make it easier for someone who is not as familiar with APPNOTE.TXT

The CEN structure is already descibed in the method-level documentation. Would you prefer I move it into the code? Not sure I would like to repeat it, and I think perhaps it's better to have the whole structure in once place, instead of splitting it (since the Zip64 extra corresponds to the CEN header fields).

What do you think?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/12948#discussion_r1484246232

From eirbjo at openjdk.org  Fri Feb  9 12:23:19 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Fri, 9 Feb 2024 12:23:19 GMT
Subject: RFR: 8303891: Speed up Zip64SizeTest using a small ZIP64 file [v6]
In-Reply-To: 
References: 
 
 <9aSa7L7oFJi2APM10qnHx9JO19w6mCKSSilOgYhSt2w=.5a125032-2faf-47a3-9306-00c7c300729b@github.com>
 
Message-ID: 

On Fri, 9 Feb 2024 12:17:17 GMT, Eirik Bj?rsn?s  wrote:

>> test/jdk/java/util/zip/ZipFile/Zip64SizeTest.java line 114:
>> 
>>> 112: 
>>> 113:             // Make an extra field with the correct size for an 8-byte 'uncompressed size'
>>> 114:             // Zip64 field. Temporarily use the 'unknown' tag 0x9902 to make
>> 
>> I would suggest adding a reference to the following in the APPNOTE.TXT  to make clearer where that value came from
>> 
>>>  4.6.1 Third party mappings commonly used are:
>> 
>> another suggestion would be to show the CEN here with this change I think would make it easier for someone who is not as familiar with APPNOTE.TXT
>
> The CEN structure is already descibed in the method-level documentation. Would you prefer I move it into the code? Not sure I would like to repeat it, and I think perhaps it's better to have the whole structure in once place, instead of splitting it (since the Zip64 extra corresponds to the CEN header fields).
> 
> What do you think?

> I would suggest adding a reference to the following in the APPNOTE.TXT to make clearer where that value came from

Added a reference to "Third Party Mappings". (It's not super-important that we chose 'unknown' here, it just seemed a reasonable choice for something ZipEntry cannot see into)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/12948#discussion_r1484248708

From eirbjo at openjdk.org  Fri Feb  9 12:23:19 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Fri, 9 Feb 2024 12:23:19 GMT
Subject: RFR: 8303891: Speed up Zip64SizeTest using a small ZIP64 file [v7]
In-Reply-To: 
References: 
Message-ID: 

> Please review this PR which suggests we speed up the `Zip64SizeTest` using a small-sized ZIP64 ZIP file specifically created to reproduce the issue being tested.
> 
> The disk space requirement of this test is known to cause problems in some builds, see [JDK-8259866](https://bugs.openjdk.org/browse/JDK-8259866)
> 
> By using a sparse file, we reduce consumed disk space from 5GB to 266 bytes and also reduce the runtime from ~35 seconds to ~1 seconds on my Macbook Pro.
> 
> The PR also fixes the `@summary` tag, which seems to have been copied from an unrelated test.

Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:

  Add reference to APPNOTE.TXT for the 'unknown tag' (4.6.1 Third Party Mappings)

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12948/files
  - new: https://git.openjdk.org/jdk/pull/12948/files/34333c98..a6cc978f

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

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

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

From eirbjo at openjdk.org  Fri Feb  9 12:31:27 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Fri, 9 Feb 2024 12:31:27 GMT
Subject: RFR: 8303891: Speed up Zip64SizeTest using a small ZIP64 file [v8]
In-Reply-To: 
References: 
Message-ID: 

> Please review this PR which suggests we speed up the `Zip64SizeTest` using a small-sized ZIP64 ZIP file specifically created to reproduce the issue being tested.
> 
> The disk space requirement of this test is known to cause problems in some builds, see [JDK-8259866](https://bugs.openjdk.org/browse/JDK-8259866)
> 
> By using a sparse file, we reduce consumed disk space from 5GB to 266 bytes and also reduce the runtime from ~35 seconds to ~1 seconds on my Macbook Pro.
> 
> The PR also fixes the `@summary` tag, which seems to have been copied from an unrelated test.

Eirik Bj?rsn?s has updated the pull request incrementally with two additional commits since the last revision:

 - Use three dots consistently for representing an ellipsis
 - Add zipdetails of the Zip64 extra field in updateCENHeaderToZip64

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12948/files
  - new: https://git.openjdk.org/jdk/pull/12948/files/a6cc978f..9f843fcd

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

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

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

From eirbjo at openjdk.org  Fri Feb  9 12:31:27 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Fri, 9 Feb 2024 12:31:27 GMT
Subject: RFR: 8303891: Speed up Zip64SizeTest using a small ZIP64 file [v6]
In-Reply-To: <9aSa7L7oFJi2APM10qnHx9JO19w6mCKSSilOgYhSt2w=.5a125032-2faf-47a3-9306-00c7c300729b@github.com>
References: 
 
 <9aSa7L7oFJi2APM10qnHx9JO19w6mCKSSilOgYhSt2w=.5a125032-2faf-47a3-9306-00c7c300729b@github.com>
Message-ID: <-XKREFrm8NZDOQ56-MvgKRRQ2ytQvFVF0IXyaKj6EEY=.b9b9cba2-3bd1-4763-bb5d-bbc818bfd260@github.com>

On Fri, 9 Feb 2024 11:59:13 GMT, Lance Andersen  wrote:

> Again minor but perhaps articulate that after this call, the extra data will be(obvious to you and I but probably not to others...)

Added `zipdetails` describing the resulting ZIP64 structure to the `updateCENHeaderToZip64` method documentation.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/12948#discussion_r1484254390

From ihse at openjdk.org  Fri Feb  9 13:41:39 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 9 Feb 2024 13:41:39 GMT
Subject: RFR: 8325558: Add jcheck whitespace checking for properties files
Message-ID: 

This is an attempt to finally implement the idea brought forward in JDK-8295729:  Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes or leading tabs instead of spaces. 

With Skara jcheck, it is possible to increase the coverage of the whitespace checks.

However, this turned out to be problematic, since trailing whitespace is significant in properties files. That issue has mostly been sorted out in a series of PRs, and this patch will finish the job with the few remaining files, and actually enable the check in jcheck.

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

Commit messages:
 - 8325558: Add jcheck whitespace checking for properties files

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

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

From ihse at openjdk.org  Fri Feb  9 13:41:39 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 9 Feb 2024 13:41:39 GMT
Subject: RFR: 8325558: Add jcheck whitespace checking for properties files
In-Reply-To: 
References: 
Message-ID: 

On Fri, 9 Feb 2024 13:35:55 GMT, Magnus Ihse Bursie  wrote:

> This is an attempt to finally implement the idea brought forward in JDK-8295729:  Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes or leading tabs instead of spaces. 
> 
> With Skara jcheck, it is possible to increase the coverage of the whitespace checks.
> 
> However, this turned out to be problematic, since trailing whitespace is significant in properties files. That issue has mostly been sorted out in a series of PRs, and this patch will finish the job with the few remaining files, and actually enable the check in jcheck.

I'll add some specific comments/reasoning to individual files, where I think a remark might be needed.

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

PR Comment: https://git.openjdk.org/jdk/pull/17789#issuecomment-1935947566

From ihse at openjdk.org  Fri Feb  9 13:55:09 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 9 Feb 2024 13:55:09 GMT
Subject: RFR: 8325558: Add jcheck whitespace checking for properties files
In-Reply-To: 
References: 
Message-ID: 

On Fri, 9 Feb 2024 13:35:55 GMT, Magnus Ihse Bursie  wrote:

> This is an attempt to finally implement the idea brought forward in JDK-8295729:  Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes or leading tabs instead of spaces. 
> 
> With Skara jcheck, it is possible to increase the coverage of the whitespace checks.
> 
> However, this turned out to be problematic, since trailing whitespace is significant in properties files. That issue has mostly been sorted out in a series of PRs, and this patch will finish the job with the few remaining files, and actually enable the check in jcheck.

src/java.base/unix/classes/sun/net/www/content-types.properties line 1:

> 1: #sun.net.www MIME content-types table

I have converted all leading tabs to 8 spaces.

src/java.base/windows/classes/sun/net/www/content-types.properties line 1:

> 1: #sun.net.www MIME content-types table

I have converted all leading tabs to 8 spaces.

src/java.desktop/share/classes/com/sun/imageio/plugins/common/iio-plugin.properties line 11:

> 9: ImageUtil0=The supplied Raster does not represent a binary data set.
> 10: ImageUtil1=The provided sample model is null.
> 11: ImageUtil2=The provided image cannot be encoded using: 

While it seems like this could have been significant, the code that uses it looks like this:

 throw new IIOException(I18N.getString("ImageUtil2")+" "+
                                   writer.getClass().getName());

so it will end up with a double space right now.

src/java.scripting/share/classes/com/sun/tools/script/shell/messages.properties line 1:

> 1: #

I have converted all leading tabs to 8 spaces.

src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle.properties line 73:

> 71: cachedrowsetimpl.numrows = Number of rows is less than zero or less than fetch size
> 72: cachedrowsetimpl.startpos = Start position cannot be negative
> 73: cachedrowsetimpl.nextpage = Populate data before calling 

This sounded like it could potentially be followed by a name, but this is not the case.

src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle.properties line 128:

> 126: crswriter.params1 = Value of params1 : {0} 
> 127: crswriter.params2 = Value of params2 : {0} 
> 128: crswriter.conflictsno =  conflicts while synchronizing 

This sounded like it could potentially be followed by a string, but this is not the case.

src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_de.properties line 1:

> 1: #

The changes in this and the following files are just to align the file with the English master copy.

src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages.properties line 24:

> 22: 
> 23:         BadMessageKey = The error message corresponding to the message key can not be found.
> 24:         FormatFailed = An internal error occurred while formatting the following message:\n  

At first glance, it might look like something should follow the `:`, but note that there is a `\n` so if anything this will only make the next line improperly indented.

src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_de.properties line 1:

> 1: #

The changes in this and the following files are just to align the file with the English master copy.

src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_de.properties line 1:

> 1: #

The changes in this and the following files are just to align the file with the English master copy.

src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages.properties line 20:

> 18: # Messages for message reporting
> 19: BadMessageKey = The error message corresponding to the message key can not be found.
> 20: FormatFailed = An internal error occurred while formatting the following message:\n

At first glance, it might look like something should follow the :, but note that there is a \n so if anything this will only make the next line improperly indented.

src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_de.properties line 1:

> 1: #

The changes in this and the following files are just to align the file with the English master copy.

src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages.properties line 27:

> 25: 
> 26:         BadMessageKey = The error message corresponding to the message key can not be found.
> 27:         FormatFailed = An internal error occurred while formatting the following message:\n

Same here with `:\n`...

src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages.properties line 24:

> 22: # Messages for message reporting
> 23: BadMessageKey = The error message corresponding to the message key can not be found.
> 24: FormatFailed = An internal error occurred while formatting the following message:\n

Same here with `:\n`...

src/jdk.compiler/share/classes/sun/tools/serialver/resources/serialver.properties line 1:

> 1: #

I have converted all leading tabs to 8 spaces.

src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties line 49:

> 47:         'u' flag requires manifest, 'e' flag or input files to be specified!
> 48: error.bad.eflag=\
> 49: 	'e' flag and manifest with the 'Main-Class' attribute cannot be specified \n\

Here were two lines that used tab instead of space; I converted them to 8 spaces.

test/jaxp/javax/xml/jaxp/unittest/common/config/files/catalog2.properties line 4:

> 2: #       XML Library (java.xml) Configuration File
> 3: #
> 4: # This file is in java.util.Properties format and typically located in the conf 

These spaces at the end of comment lines has crept in since I cleaned all such out in [JDK-8298047](https://bugs.openjdk.org/browse/JDK-8298047). It's a good example of why we need the jcheck verification to keep this from regressing once more.

test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/table/resources/TableDemo.properties line 12:

> 10: 
> 11: TableDemo.noDataStatusLabel=No data loaded
> 12: TableDemo.loadingStatusLabel=Loading data:\u0020

According to https://github.com/openjdk/jdk/pull/11488/files#r1038605801 the latter two are actually needed as spaces, and the first might be; so keeping it as well seems to be the safe choice.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17789#discussion_r1484326435
PR Review Comment: https://git.openjdk.org/jdk/pull/17789#discussion_r1484326568
PR Review Comment: https://git.openjdk.org/jdk/pull/17789#discussion_r1484327614
PR Review Comment: https://git.openjdk.org/jdk/pull/17789#discussion_r1484327859
PR Review Comment: https://git.openjdk.org/jdk/pull/17789#discussion_r1484329632
PR Review Comment: https://git.openjdk.org/jdk/pull/17789#discussion_r1484329770
PR Review Comment: https://git.openjdk.org/jdk/pull/17789#discussion_r1484330650
PR Review Comment: https://git.openjdk.org/jdk/pull/17789#discussion_r1484332081
PR Review Comment: https://git.openjdk.org/jdk/pull/17789#discussion_r1484332649
PR Review Comment: https://git.openjdk.org/jdk/pull/17789#discussion_r1484334629
PR Review Comment: https://git.openjdk.org/jdk/pull/17789#discussion_r1484334259
PR Review Comment: https://git.openjdk.org/jdk/pull/17789#discussion_r1484335061
PR Review Comment: https://git.openjdk.org/jdk/pull/17789#discussion_r1484335669
PR Review Comment: https://git.openjdk.org/jdk/pull/17789#discussion_r1484337306
PR Review Comment: https://git.openjdk.org/jdk/pull/17789#discussion_r1484338418
PR Review Comment: https://git.openjdk.org/jdk/pull/17789#discussion_r1484339114
PR Review Comment: https://git.openjdk.org/jdk/pull/17789#discussion_r1484341847
PR Review Comment: https://git.openjdk.org/jdk/pull/17789#discussion_r1484345466

From simonis at openjdk.org  Fri Feb  9 14:08:57 2024
From: simonis at openjdk.org (Volker Simonis)
Date: Fri, 9 Feb 2024 14:08:57 GMT
Subject: RFR: 8324573: HashMap::putAll should resize to sum of both map
 sizes [v4]
In-Reply-To: <-eVaZ9AgZ_GzfN2yeTK8VdE3efeSyx1NqjPyOOkPZAI=.e1007274-1943-46eb-bfab-f796d461da31@github.com>
References: 
 <-eVaZ9AgZ_GzfN2yeTK8VdE3efeSyx1NqjPyOOkPZAI=.e1007274-1943-46eb-bfab-f796d461da31@github.com>
Message-ID: <5_NlZ_BIRHaToTQyjCxCBqW1Ua_EWaZt8p17trx5e_g=.afc2a52f-129d-4be5-99b2-8cfa0ea2868f@github.com>

On Fri, 2 Feb 2024 17:38:13 GMT, Joshua Cao  wrote:

>> This change mirrors what we did for ConcurrentHashMap in https://github.com/openjdk/jdk/pull/17116. When we add all entries from one map to anther, we should resize that map to the size of the sum of both maps.
>> 
>> I used the command below to run the benchmarks. I set a high heap to reduce garbage collection noise.
>> 
>> java -Xms25G -jar benchmarks.jar -p size=100000 -p addSize=100000 -gc true org.openjdk.bench.java.util.HashMapBench
>> 
>> 
>> Before change
>> 
>> 
>> Benchmark            (addSize)        (mapType)  (size)  Mode  Cnt   Score   Error  Units
>> HashMapBench.putAll     100000         HASH_MAP  100000  avgt    4  22.927 ? 3.170  ms/op
>> HashMapBench.putAll     100000  LINKED_HASH_MAP  100000  avgt    4  25.198 ? 2.189  ms/op
>> 
>> 
>> After change
>> 
>> 
>> Benchmark            (addSize)        (mapType)  (size)  Mode  Cnt   Score   Error  Units
>> HashMapBench.putAll     100000         HASH_MAP  100000  avgt    4  16.780 ? 0.526  ms/op
>> HashMapBench.putAll     100000  LINKED_HASH_MAP  100000  avgt    4  19.721 ? 0.349  ms/op
>> 
>> 
>> We see about average time improvements of 26% in HashMap and 20% in LinkedHashMap.
>> 
>> ---
>> 
>> In the worse case, we may have two maps with identical keys. In this case, we would aggressively resize when we do not need to. I'm also adding an additional `putAllSameKeys` benchmark.
>> 
>> Before change:
>> 
>> 
>> Benchmark                                       (addSize)        (mapType)  (size)  Mode  Cnt        Score   Error   Units
>> HashMapBench.putAllSameKeys                        100000         HASH_MAP  100000  avgt             6.956           ms/op
>> HashMapBench.putAllSameKeys:gc.alloc.rate          100000         HASH_MAP  100000  avgt          1091.383          MB/sec
>> HashMapBench.putAllSameKeys:gc.alloc.rate.norm     100000         HASH_MAP  100000  avgt       7968871.917            B/op
>> HashMapBench.putAllSameKeys:gc.count               100000         HASH_MAP  100000  avgt               ? 0          counts
>> HashMapBench.putAllSameKeys                        100000  LINKED_HASH_MAP  100000  avgt             8.417           ms/op
>> HashMapBench.putAllSameKeys:gc.alloc.rate          100000  LINKED_HASH_MAP  100000  avgt           992.543          MB/sec
>> HashMapBench.putAllSameKeys:gc.alloc.rate.norm     100000  LINKED_HASH_MAP  100000  avgt       8768892.941            B/op
>> HashMapBench.putAllSameKeys:gc.count               100000  LINKED_HASH_MAP  100000  avgt               ? 0          counts
>> 
>> 
>> Af...
>
> Joshua Cao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   extract msize variable

I agree that a comment would be helpful but I'm afraid that it will not be of much help if its buried in the code. So instead maybe better add an `@implNote` to the `putAll()` method which describes the current, conservative resizing heuristic and give the advice that users can presize the destination map accordingly if they want to avoid resizing when merging in other maps.

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

PR Comment: https://git.openjdk.org/jdk/pull/17544#issuecomment-1935992895

From dfuchs at openjdk.org  Fri Feb  9 14:10:57 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 9 Feb 2024 14:10:57 GMT
Subject: RFR: 8325558: Add jcheck whitespace checking for properties files
In-Reply-To: 
References: 
Message-ID: 

On Fri, 9 Feb 2024 13:35:55 GMT, Magnus Ihse Bursie  wrote:

> This is an attempt to finally implement the idea brought forward in JDK-8295729:  Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes or leading tabs instead of spaces. 
> 
> With Skara jcheck, it is possible to increase the coverage of the whitespace checks.
> 
> However, this turned out to be problematic, since trailing whitespace is significant in properties files. That issue has mostly been sorted out in a series of PRs, and this patch will finish the job with the few remaining files, and actually enable the check in jcheck.

changes to sun/net content-types.properties look OK

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

PR Comment: https://git.openjdk.org/jdk/pull/17789#issuecomment-1935996382

From erikj at openjdk.org  Fri Feb  9 14:56:57 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 9 Feb 2024 14:56:57 GMT
Subject: RFR: 8325558: Add jcheck whitespace checking for properties files
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 9 Feb 2024 13:42:02 GMT, Magnus Ihse Bursie  wrote:

>> This is an attempt to finally implement the idea brought forward in JDK-8295729:  Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes or leading tabs instead of spaces. 
>> 
>> With Skara jcheck, it is possible to increase the coverage of the whitespace checks.
>> 
>> However, this turned out to be problematic, since trailing whitespace is significant in properties files. That issue has mostly been sorted out in a series of PRs, and this patch will finish the job with the few remaining files, and actually enable the check in jcheck.
>
> src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages.properties line 24:
> 
>> 22: 
>> 23:         BadMessageKey = The error message corresponding to the message key can not be found.
>> 24:         FormatFailed = An internal error occurred while formatting the following message:\n  
> 
> At first glance, it might look like something should follow the `:`, but note that there is a `\n` so if anything this will only make the next line improperly indented.

That could have been intentional though. Not sure if it was a good idea, but indenting something is a way of making something stand out as a quote. But looking at every use site, there is an extra space added anyway, so this seems fine. If we wanted to preserve the exact same behavior, all use sites should be updated to add 3 spaces.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17789#discussion_r1484416962

From asemenyuk at openjdk.org  Fri Feb  9 17:08:06 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 9 Feb 2024 17:08:06 GMT
Subject: Integrated: 8325203: System.exit(0) kills the launched 3rd party
 application
In-Reply-To: 
References: 
Message-ID: <-ZKK3IngtoURhMGVUAWI_ePAp7fHuoVi8A3Nl7_Pjyg=.64ce60d8-ce11-41ee-89d6-3eec79a8cafa@github.com>

On Thu, 8 Feb 2024 20:57:51 GMT, Alexey Semenyuk  wrote:

> Tested with the use case from the CR.
> 
> The idea of the fix is to prevent grandchildren processes from being automatically attached to the job killing all processes attached to it when the job object is destroyed.
> 
> Filed a follow-up https://bugs.openjdk.org/browse/JDK-8325525 CR to track adding a jtreg test for the issue.

This pull request has now been integrated.

Changeset: 6944537c
Author:    Alexey Semenyuk 
URL:       https://git.openjdk.org/jdk/commit/6944537c3ebbbb638479e4c2b90a71ad5869023c
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8325203: System.exit(0) kills the launched 3rd party application

Reviewed-by: almatvee

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

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

From lancea at openjdk.org  Fri Feb  9 17:11:04 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 9 Feb 2024 17:11:04 GMT
Subject: RFR: 8303891: Speed up Zip64SizeTest using a small ZIP64 file [v8]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 9 Feb 2024 12:31:27 GMT, Eirik Bj?rsn?s  wrote:

>> Please review this PR which suggests we speed up the `Zip64SizeTest` using a small-sized ZIP64 ZIP file specifically created to reproduce the issue being tested.
>> 
>> The disk space requirement of this test is known to cause problems in some builds, see [JDK-8259866](https://bugs.openjdk.org/browse/JDK-8259866)
>> 
>> By using a sparse file, we reduce consumed disk space from 5GB to 266 bytes and also reduce the runtime from ~35 seconds to ~1 seconds on my Macbook Pro.
>> 
>> The PR also fixes the `@summary` tag, which seems to have been copied from an unrelated test.
>
> Eirik Bj?rsn?s has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Use three dots consistently for representing an ellipsis
>  - Add zipdetails of the Zip64 extra field in updateCENHeaderToZip64

Marked as reviewed by lancea (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/12948#pullrequestreview-1872850714

From naoto at openjdk.org  Fri Feb  9 18:12:06 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 9 Feb 2024 18:12:06 GMT
Subject: RFR: 8325558: Add jcheck whitespace checking for properties files
In-Reply-To: 
References: 
Message-ID: 

On Fri, 9 Feb 2024 13:35:55 GMT, Magnus Ihse Bursie  wrote:

> This is an attempt to finally implement the idea brought forward in JDK-8295729:  Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes or leading tabs instead of spaces. 
> 
> With Skara jcheck, it is possible to increase the coverage of the whitespace checks.
> 
> However, this turned out to be problematic, since trailing whitespace is significant in properties files. That issue has mostly been sorted out in a series of PRs, and this patch will finish the job with the few remaining files, and actually enable the check in jcheck.

Skimmed through the changes and all look good to me. Good to have `jcheck` detect those unneeded trailing spaces.

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

PR Review: https://git.openjdk.org/jdk/pull/17789#pullrequestreview-1872951198

From rriggs at openjdk.org  Fri Feb  9 19:43:04 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 9 Feb 2024 19:43:04 GMT
Subject: RFR: JDK-8318761: MessageFormat pattern support for
 CompactNumberFormat, ListFormat, and DateTimeFormatter [v7]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 8 Feb 2024 21:29:19 GMT, Justin Lu  wrote:

>> Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8319344) which adds MessageFormat pattern support for the following subformats: ListFormat, CompactNumberFormat, and DateTimeFormatter. This change is intended to provide pattern support for the more recently added JDK Format subclasses, as well as improving java.time formatting within i18n. The draft javadoc can be viewed here: https://cr.openjdk.org/~jlu/docs/api/java.base/java/text/MessageFormat.html. Please see the CSR for more in-depth behavioral changes, as well as limitations.
>> 
>> The `FormatTypes`:  dtf_date, dtf_time, dtf_datetime, pre-defined DateTimeFormatter(s), and list are added.
>> The `FormatStyles`: compact_short, compact_long, or, and unit are added.
>> 
>> For example, previously,
>> 
>> 
>> Object[] args = {LocalDate.of(2023, 11, 16), LocalDate.of(2023, 11, 27)};
>> MessageFormat.format("It was {0,date,full}, now it is {1,date,full}", args);
>> 
>> 
>> would throw `Exception java.lang.IllegalArgumentException: Cannot format given Object as a Date`
>> 
>> Now, a user can call
>> 
>> 
>> MessageFormat.format("It was {0,dtf_date,full}, now it is {1,dtf_date,full}", args);
>> 
>> 
>> which returns "It was Thursday, November 16, 2023, now it is Friday, November 17, 2023"
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   implement Naoto's review

Good cleanup and filling some gaps in the pattern cases.

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

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17663#pullrequestreview-1873083702

From clanger at openjdk.org  Fri Feb  9 21:34:15 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Fri, 9 Feb 2024 21:34:15 GMT
Subject: RFR: 8325579: Inconsistent behavior in
 com.sun.jndi.ldap.Connection::createSocket
Message-ID: 

During analysing a customer case I figured out that we have an inconsistency between documentation and actual behavior in class com.sun.jndi.ldap.Connection. The [method documentation of com.sun.jndi.ldap.Connection::createSocket](https://github.com/openjdk/jdk/blob/3ebe6c192a5dd5cc46ae2d263713c9ff38cd46bb/src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java#L281) states: "If a timeout is supplied but unconnected sockets are not supported then the timeout is ignored and a connected socket is created."

This, however does not happen. If a SocketFactory would not support unconnected sockets, it would likely throw a SocketException in [SocketFactory::createSocket()](https://github.com/openjdk/jdk/blob/6303c0e7136436a2d3cb6043b88edf788c0067cc/src/java.base/share/classes/javax/net/SocketFactory.java#L123). And since [the code](https://github.com/openjdk/jdk/blob/3ebe6c192a5dd5cc46ae2d263713c9ff38cd46bb/src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java#L336) does not check for this behavior, a connection with timeout value through a SocketFactory that does not support unconnected sockets would simply fail with an IOException.

So we should either make the code adhere to what is documented or adapt the documentation to the actual behavior.

I hereby try to fix the connect coding. Alternatively, we could also adapt the description - I have no strong opinion. What do the experts suggest?

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

Commit messages:
 - JDK-8325579

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

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

From jlu at openjdk.org  Fri Feb  9 23:20:30 2024
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 9 Feb 2024 23:20:30 GMT
Subject: RFR: JDK-8318761: MessageFormat pattern support for
 CompactNumberFormat, ListFormat, and DateTimeFormatter [v8]
In-Reply-To: 
References: 
Message-ID: 

> Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8319344) which adds MessageFormat pattern support for the following subformats: ListFormat, CompactNumberFormat, and DateTimeFormatter. This change is intended to provide pattern support for the more recently added JDK Format subclasses, as well as improving java.time formatting within i18n. The draft javadoc can be viewed here: https://cr.openjdk.org/~jlu/docs/api/java.base/java/text/MessageFormat.html. Please see the CSR for more in-depth behavioral changes, as well as limitations.
> 
> The `FormatTypes`:  dtf_date, dtf_time, dtf_datetime, pre-defined DateTimeFormatter(s), and list are added.
> The `FormatStyles`: compact_short, compact_long, or, and unit are added.
> 
> For example, previously,
> 
> 
> Object[] args = {LocalDate.of(2023, 11, 16), LocalDate.of(2023, 11, 27)};
> MessageFormat.format("It was {0,date,full}, now it is {1,date,full}", args);
> 
> 
> would throw `Exception java.lang.IllegalArgumentException: Cannot format given Object as a Date`
> 
> Now, a user can call
> 
> 
> MessageFormat.format("It was {0,dtf_date,full}, now it is {1,dtf_date,full}", args);
> 
> 
> which returns "It was Thursday, November 16, 2023, now it is Friday, November 17, 2023"

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

 - white space tweak for spec
 - Merge branch 'master' into JDK-8318761-j.text.MessageFormat-pattern-enh
 - implement Naoto's review
 - Move the if-else nFmt checking to a package-private method in NumberFormat
 - Merge remote-tracking branch 'origin/JDK-8318761-j.text.MessageFormat-pattern-enh' into JDK-8318761-j.text.MessageFormat-pattern-enh
 - Apply spacing suggestions
   
   Co-authored-by: Andrey Turbanov 
 - implement some feedback from Roger's comments
 - merge master and resolve conflicts stemming from 8323699
 - add expected message to exception checking
 - Use Naoto's recommended example
 - ... and 2 more: https://git.openjdk.org/jdk/compare/3ebe6c19...ee36eebb

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

Changes: https://git.openjdk.org/jdk/pull/17663/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17663&range=07
  Stats: 1258 lines in 7 files changed: 929 ins; 197 del; 132 mod
  Patch: https://git.openjdk.org/jdk/pull/17663.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17663/head:pull/17663

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

From lbourges at openjdk.org  Sat Feb 10 13:14:05 2024
From: lbourges at openjdk.org (Laurent =?UTF-8?B?Qm91cmfDqHM=?=)
Date: Sat, 10 Feb 2024 13:14:05 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>
 
 
 
 
 
 <-bYhysKjQVb_ZS0I0YutJZ7umfYwbs74rtK6-d2qL9U=.f9981e59-f0c4-48f3-ad7e-5627aad00919@github.com>
 <91Zv361kqKOjCSJPu20-yhKOb4lBIZVyVTm9f79dkcQ=.745c271d-3cb1-4ff3-9d71-5cad85ff4f14@github.com>
 
 <9q8Gg6DQnrf0HLW3oxwfpoUP9639drr1BIQMc1rxDFo=.eb4ea73c-b632-446a-8d50-b51838f67f69@github.com>
 
 
 
Message-ID: 

On Thu, 8 Feb 2024 01:54:45 GMT, Srinivas Vamsi Parasa  wrote:

>> Hello Vamsi (@vamsi-parasa),
>> 
>> Many thanks for the results! Now we can see that intrinsics are applied in all cases,
>> but there are big differences between the same code.
>> 
>> For example,
>> parallelSort REPEATED 20000:  58.265(Stock JDK) and 42.189(a15) with speedup x1.38
>> parallelSort STAGGER 3000000:  3687.198(Stock JDK) 4363.242(a15) with speedup  x0.85
>> 
>> Case a15 is the current source code from JDK, but in one benchmarking it is faster,
>> in other benchmarking it is slower (~15-30%).
>> 
>> Other strange behaviour with new sorting: r20p and r20s have the same code for
>> sequential sorting (no radix sort at all), but we can see that on case works much slower
>>  
>> sort STAGGER 3000000: 34406.74(r20p) and 10467.03(r20s) - 3.3 times slower,
>> whereas other sizes show more or less equal values.
>> 
>> Vamsi (@vamsi-parasa),
>> Could you please run benchmarking of 5 cases with **updated** test class **ArraysSortNew**?
>> https://github.com/iaroslavski/sorting/blob/master/radixsort/ArraysSortNew.java
>> 
>> Put the DPQS code in java.util package and recompiling the JDK for each case as you
>> did before, but run new **ArraysSortNew**.
>> 
>> Find the sources there:
>> 
>> https://github.com/iaroslavski/sorting/blob/master/radixsort/ArraysSortNew.java
>> https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_jdk.java
>> https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_r20p.java
>> https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_r20s.java
>> https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_r25p.java
>> https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_r25s.java
>> 
>> Thank you,
>> Vladimir
>
> Hi Vladimir (@iaroslavski),
> 
> The new ArraysSortNew.Java has compilation issues:
> 
> 
> error: DualPivotQuicksort is not public in java.util; cannot be accessed from outside package
>              java.util.DualPivotQuicksort.sort(b, PARALLELISM, 0, b.length);
> 
> Have you run into this issue? 
> 
> Thanks,
> Vamsi

Hi Vamsi (@vamsi-parasa), few questions on your test environment:
- what are the hardware specs of your server ?
- bare-metal or virtual ?
- are other services or big processes running ?
- os tuning ? CPU HT: off? Fixed CPU governor or frequency ?
- isolation using taskset ?

Maybe C2 JIT (+ CDS archive) are given more performance on stock jdk sort than same code running outside jdk...

Thanks,
Laurent

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

PR Comment: https://git.openjdk.org/jdk/pull/13568#issuecomment-1937004457

From davidalayachew at gmail.com  Sun Feb 11 05:16:29 2024
From: davidalayachew at gmail.com (David Alayachew)
Date: Sun, 11 Feb 2024 00:16:29 -0500
Subject: Thoughts on a new method for equality on java.util.Objects?
Message-ID: 

Hello Core Libs Dev Team,

I jumped the gun a bit and made a PR for this first. Alan Bateman kindly
informed me of my faux pas, and now I'm trying to redo things correctly.

I am looking to add a new method to java.util.Objects to facilitate
equality checks, something that I hope fits well in place with the other
methods in this class.

Here is my basic idea. (Special thanks to @liach for guidance in creating
this!)

```java
import java.util.*;
import java.util.function.*;

import static java.util.Objects.*;

public class Objects2
{

   public static  BiPredicate equalsBy(final List>
functions)
   {

      requireNonNull(functions, "Objects.equalsBy cannot execute because
the parameter is null!");

      return
         (final T o1, final T o2) ->
         {

            requireNonNull(o1, "Cannot check for equality because the first
object is null!");
            requireNonNull(o2, "Cannot check for equality because the
second object is null!");

            for (final var function : functions)
            {

               requireNonNull(function, "Cannot check for equality because
the function is null!");

               final var r1 = function.apply(o1);
               final var r2 = function.apply(o2);

               final boolean theyAreEqual = Objects.equals(r1, r2);

               if (!theyAreEqual)
               {

                  return false;

               }

            }

            return true;

         }
         ;

   }

   public static void main(final String[] args)
   {

      record Point3D(int x, String y, int z) {}

      final Point3D a = new Point3D(1, "2", 3);
      final Point3D b = new Point3D(1, "2", 4);

      final BiPredicate equalsByXY  =
equalsBy(List.of(Point3D::x, Point3D::y));
      final BiPredicate equalsByXYZ =
equalsBy(List.of(Point3D::x, Point3D::y, Point3D::z));

      System.out.println(equalsByXY.test(a, b));  //true
      System.out.println(equalsByXYZ.test(a, b)); //false

   }

}
```

The concept is simple -- I want to make it easy to create ad-hoc equals
methods.

Object equality is domain-specific -- in some domains, 2 objects are equal,
but in another, they are not. The object's equals method is not always a
good spot to put this logic into, largely because we don't always know what
domain we are in. The object's equals method is where a good default should
be placed, not logic for every domain. And even if we tried, it's
difficult, if not impossible, to apply equality for the correct domain if
both objects are of the same type.

So, for domain-specific contexts, I would like to introduce this method.
This method (which should be constant-foldable, thanks again for the help
@liach!) lets you clearly say that you are taking 2 objects and comparing
them by the following methods that apply to both. And due to the nature of
lambdas, developers are not constrained to just the getters of the object
in question -- any function that takes in T is fair game. This allows
flexibility, and lets developers keep their objects simple, thus
facilitating things like DOP.

Now, perhaps this makes more sense on the BiPredicate interface instead.
However, since this was more equality focused, I figured Objects was a
better fit.

Any thoughts?

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

From holo3146 at gmail.com  Sun Feb 11 08:25:57 2024
From: holo3146 at gmail.com (Holo The Sage Wolf)
Date: Sun, 11 Feb 2024 10:25:57 +0200
Subject: Thoughts on a new method for equality on java.util.Objects?
In-Reply-To: 
References: 
Message-ID: 

How beneficial is it to extend equality method without appropriate hashing?

Specifically, given you are working in a domain specific world, e.g.
projection of Point3D into XY with equality semantics of equalsByXY, Java
does not know how to treat semantically equal objects as equal:

var foo = new Point3D(0,0,0);
var bar = new Point3D(0,0,1);
var set = new HashSet<>(Arrays.asList(foo, bar));
assert set.size() == 1 \\ assertion failure :(

The idea is fine, but you need to wrap a lot of Java's Standard Library to
respect the new semantics.

I think that the idea can work nicely as a library, but not inside java.*


On Sun, 11 Feb 2024, 07:41 David Alayachew, 
wrote:

> Hello Core Libs Dev Team,
>
> I jumped the gun a bit and made a PR for this first. Alan Bateman kindly
> informed me of my faux pas, and now I'm trying to redo things correctly.
>
> I am looking to add a new method to java.util.Objects to facilitate
> equality checks, something that I hope fits well in place with the other
> methods in this class.
>
> Here is my basic idea. (Special thanks to @liach for guidance in creating
> this!)
>
> ```java
> import java.util.*;
> import java.util.function.*;
>
> import static java.util.Objects.*;
>
> public class Objects2
> {
>
>    public static  BiPredicate equalsBy(final List>
> functions)
>    {
>
>       requireNonNull(functions, "Objects.equalsBy cannot execute because
> the parameter is null!");
>
>       return
>          (final T o1, final T o2) ->
>          {
>
>             requireNonNull(o1, "Cannot check for equality because the
> first object is null!");
>             requireNonNull(o2, "Cannot check for equality because the
> second object is null!");
>
>             for (final var function : functions)
>             {
>
>                requireNonNull(function, "Cannot check for equality because
> the function is null!");
>
>                final var r1 = function.apply(o1);
>                final var r2 = function.apply(o2);
>
>                final boolean theyAreEqual = Objects.equals(r1, r2);
>
>                if (!theyAreEqual)
>                {
>
>                   return false;
>
>                }
>
>             }
>
>             return true;
>
>          }
>          ;
>
>    }
>
>    public static void main(final String[] args)
>    {
>
>       record Point3D(int x, String y, int z) {}
>
>       final Point3D a = new Point3D(1, "2", 3);
>       final Point3D b = new Point3D(1, "2", 4);
>
>       final BiPredicate equalsByXY  =
> equalsBy(List.of(Point3D::x, Point3D::y));
>       final BiPredicate equalsByXYZ =
> equalsBy(List.of(Point3D::x, Point3D::y, Point3D::z));
>
>       System.out.println(equalsByXY.test(a, b));  //true
>       System.out.println(equalsByXYZ.test(a, b)); //false
>
>    }
>
> }
> ```
>
> The concept is simple -- I want to make it easy to create ad-hoc equals
> methods.
>
> Object equality is domain-specific -- in some domains, 2 objects are
> equal, but in another, they are not. The object's equals method is not
> always a good spot to put this logic into, largely because we don't always
> know what domain we are in. The object's equals method is where a good
> default should be placed, not logic for every domain. And even if we tried,
> it's difficult, if not impossible, to apply equality for the correct domain
> if both objects are of the same type.
>
> So, for domain-specific contexts, I would like to introduce this method.
> This method (which should be constant-foldable, thanks again for the help
> @liach!) lets you clearly say that you are taking 2 objects and comparing
> them by the following methods that apply to both. And due to the nature of
> lambdas, developers are not constrained to just the getters of the object
> in question -- any function that takes in T is fair game. This allows
> flexibility, and lets developers keep their objects simple, thus
> facilitating things like DOP.
>
> Now, perhaps this makes more sense on the BiPredicate interface instead.
> However, since this was more equality focused, I figured Objects was a
> better fit.
>
> Any thoughts?
>
> Thank you all for your time and help!
> David Alayachew
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From davidalayachew at gmail.com  Sun Feb 11 10:10:13 2024
From: davidalayachew at gmail.com (David Alayachew)
Date: Sun, 11 Feb 2024 05:10:13 -0500
Subject: Thoughts on a new method for equality on java.util.Objects?
In-Reply-To: 
References: 
 
Message-ID: 

Hello,

Thank you for your response!

So, I had thought of that before posting this email, and mentally, I had
hand-waved away the concern by saying that there were plenty of situations
where equality would still be useful without hashing. And while I still
very much feel the same, the way you phrased your question is making me
realize that my proposal could double nicely as a foot gun.

Like you said -- Java's concept of equality is often attached to the
concept of hashing. And while the 2 are permitted to exist out of alignment
with each other, handling the asymmetric relationship is a dangerous
balancing act that is error-prone.

I fear that this method would be handing developer a foot gun. There
already exists a large number of bugs caused by misalignment between equals
and hashCode, and I see how this method would contribute to exactly that
problem. Understanding that, I myself don't feel comfortable pushing this
method forward.

That said, I do appreciate you , @Philip Race  , @Alan
Bateman  , and @-  for
being helpful as I go through the process. If nothing else, this was
educational, and I now know exactly what concerns my next proposal should
keep in mind when I try again.

And I see the value of "socializing", as @Alan Bateman
 put it. I had thought this idea through plenty,
but I can only see from my perspective.

Thank you all for your time and help!
David Alayachew

On Sun, Feb 11, 2024 at 3:26?AM Holo The Sage Wolf 
wrote:

> How beneficial is it to extend equality method without appropriate hashing?
>
> Specifically, given you are working in a domain specific world, e.g.
> projection of Point3D into XY with equality semantics of equalsByXY, Java
> does not know how to treat semantically equal objects as equal:
>
> var foo = new Point3D(0,0,0);
> var bar = new Point3D(0,0,1);
> var set = new HashSet<>(Arrays.asList(foo, bar));
> assert set.size() == 1 \\ assertion failure :(
>
> The idea is fine, but you need to wrap a lot of Java's Standard Library to
> respect the new semantics.
>
> I think that the idea can work nicely as a library, but not inside java.*
>
>
> On Sun, 11 Feb 2024, 07:41 David Alayachew, 
> wrote:
>
>> Hello Core Libs Dev Team,
>>
>> I jumped the gun a bit and made a PR for this first. Alan Bateman kindly
>> informed me of my faux pas, and now I'm trying to redo things correctly.
>>
>> I am looking to add a new method to java.util.Objects to facilitate
>> equality checks, something that I hope fits well in place with the other
>> methods in this class.
>>
>> Here is my basic idea. (Special thanks to @liach for guidance in creating
>> this!)
>>
>> ```java
>> import java.util.*;
>> import java.util.function.*;
>>
>> import static java.util.Objects.*;
>>
>> public class Objects2
>> {
>>
>>    public static  BiPredicate equalsBy(final List> ?>> functions)
>>    {
>>
>>       requireNonNull(functions, "Objects.equalsBy cannot execute because
>> the parameter is null!");
>>
>>       return
>>          (final T o1, final T o2) ->
>>          {
>>
>>             requireNonNull(o1, "Cannot check for equality because the
>> first object is null!");
>>             requireNonNull(o2, "Cannot check for equality because the
>> second object is null!");
>>
>>             for (final var function : functions)
>>             {
>>
>>                requireNonNull(function, "Cannot check for equality
>> because the function is null!");
>>
>>                final var r1 = function.apply(o1);
>>                final var r2 = function.apply(o2);
>>
>>                final boolean theyAreEqual = Objects.equals(r1, r2);
>>
>>                if (!theyAreEqual)
>>                {
>>
>>                   return false;
>>
>>                }
>>
>>             }
>>
>>             return true;
>>
>>          }
>>          ;
>>
>>    }
>>
>>    public static void main(final String[] args)
>>    {
>>
>>       record Point3D(int x, String y, int z) {}
>>
>>       final Point3D a = new Point3D(1, "2", 3);
>>       final Point3D b = new Point3D(1, "2", 4);
>>
>>       final BiPredicate equalsByXY  =
>> equalsBy(List.of(Point3D::x, Point3D::y));
>>       final BiPredicate equalsByXYZ =
>> equalsBy(List.of(Point3D::x, Point3D::y, Point3D::z));
>>
>>       System.out.println(equalsByXY.test(a, b));  //true
>>       System.out.println(equalsByXYZ.test(a, b)); //false
>>
>>    }
>>
>> }
>> ```
>>
>> The concept is simple -- I want to make it easy to create ad-hoc equals
>> methods.
>>
>> Object equality is domain-specific -- in some domains, 2 objects are
>> equal, but in another, they are not. The object's equals method is not
>> always a good spot to put this logic into, largely because we don't always
>> know what domain we are in. The object's equals method is where a good
>> default should be placed, not logic for every domain. And even if we tried,
>> it's difficult, if not impossible, to apply equality for the correct domain
>> if both objects are of the same type.
>>
>> So, for domain-specific contexts, I would like to introduce this method.
>> This method (which should be constant-foldable, thanks again for the help
>> @liach!) lets you clearly say that you are taking 2 objects and comparing
>> them by the following methods that apply to both. And due to the nature of
>> lambdas, developers are not constrained to just the getters of the object
>> in question -- any function that takes in T is fair game. This allows
>> flexibility, and lets developers keep their objects simple, thus
>> facilitating things like DOP.
>>
>> Now, perhaps this makes more sense on the BiPredicate interface instead.
>> However, since this was more equality focused, I figured Objects was a
>> better fit.
>>
>> Any thoughts?
>>
>> Thank you all for your time and help!
>> David Alayachew
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From davidalayachew at gmail.com  Sun Feb 11 10:13:20 2024
From: davidalayachew at gmail.com (David Alayachew)
Date: Sun, 11 Feb 2024 05:13:20 -0500
Subject: Thoughts on a new method for equality on java.util.Objects?
In-Reply-To: 
References: 
 
 
Message-ID: 

Since I am abandoning this idea, could someone close my JBS ticket?

And please link this message in the core-libs-dev archives as the close
reason -- I fear the potential for misuse, as mentioned in previous emails
on this thread.

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


On Sun, Feb 11, 2024 at 5:10?AM David Alayachew 
wrote:

> Hello,
>
> Thank you for your response!
>
> So, I had thought of that before posting this email, and mentally, I had
> hand-waved away the concern by saying that there were plenty of situations
> where equality would still be useful without hashing. And while I still
> very much feel the same, the way you phrased your question is making me
> realize that my proposal could double nicely as a foot gun.
>
> Like you said -- Java's concept of equality is often attached to the
> concept of hashing. And while the 2 are permitted to exist out of alignment
> with each other, handling the asymmetric relationship is a dangerous
> balancing act that is error-prone.
>
> I fear that this method would be handing developer a foot gun. There
> already exists a large number of bugs caused by misalignment between equals
> and hashCode, and I see how this method would contribute to exactly that
> problem. Understanding that, I myself don't feel comfortable pushing this
> method forward.
>
> That said, I do appreciate you , @Philip Race  , @Alan
> Bateman  , and @-  for
> being helpful as I go through the process. If nothing else, this was
> educational, and I now know exactly what concerns my next proposal should
> keep in mind when I try again.
>
> And I see the value of "socializing", as @Alan Bateman
>  put it. I had thought this idea through plenty,
> but I can only see from my perspective.
>
> Thank you all for your time and help!
> David Alayachew
>
> On Sun, Feb 11, 2024 at 3:26?AM Holo The Sage Wolf 
> wrote:
>
>> How beneficial is it to extend equality method without appropriate
>> hashing?
>>
>> Specifically, given you are working in a domain specific world, e.g.
>> projection of Point3D into XY with equality semantics of equalsByXY, Java
>> does not know how to treat semantically equal objects as equal:
>>
>> var foo = new Point3D(0,0,0);
>> var bar = new Point3D(0,0,1);
>> var set = new HashSet<>(Arrays.asList(foo, bar));
>> assert set.size() == 1 \\ assertion failure :(
>>
>> The idea is fine, but you need to wrap a lot of Java's Standard Library
>> to respect the new semantics.
>>
>> I think that the idea can work nicely as a library, but not inside java.*
>>
>>
>> On Sun, 11 Feb 2024, 07:41 David Alayachew, 
>> wrote:
>>
>>> Hello Core Libs Dev Team,
>>>
>>> I jumped the gun a bit and made a PR for this first. Alan Bateman kindly
>>> informed me of my faux pas, and now I'm trying to redo things correctly.
>>>
>>> I am looking to add a new method to java.util.Objects to facilitate
>>> equality checks, something that I hope fits well in place with the other
>>> methods in this class.
>>>
>>> Here is my basic idea. (Special thanks to @liach for guidance in
>>> creating this!)
>>>
>>> ```java
>>> import java.util.*;
>>> import java.util.function.*;
>>>
>>> import static java.util.Objects.*;
>>>
>>> public class Objects2
>>> {
>>>
>>>    public static  BiPredicate equalsBy(final List>> ?>> functions)
>>>    {
>>>
>>>       requireNonNull(functions, "Objects.equalsBy cannot execute because
>>> the parameter is null!");
>>>
>>>       return
>>>          (final T o1, final T o2) ->
>>>          {
>>>
>>>             requireNonNull(o1, "Cannot check for equality because the
>>> first object is null!");
>>>             requireNonNull(o2, "Cannot check for equality because the
>>> second object is null!");
>>>
>>>             for (final var function : functions)
>>>             {
>>>
>>>                requireNonNull(function, "Cannot check for equality
>>> because the function is null!");
>>>
>>>                final var r1 = function.apply(o1);
>>>                final var r2 = function.apply(o2);
>>>
>>>                final boolean theyAreEqual = Objects.equals(r1, r2);
>>>
>>>                if (!theyAreEqual)
>>>                {
>>>
>>>                   return false;
>>>
>>>                }
>>>
>>>             }
>>>
>>>             return true;
>>>
>>>          }
>>>          ;
>>>
>>>    }
>>>
>>>    public static void main(final String[] args)
>>>    {
>>>
>>>       record Point3D(int x, String y, int z) {}
>>>
>>>       final Point3D a = new Point3D(1, "2", 3);
>>>       final Point3D b = new Point3D(1, "2", 4);
>>>
>>>       final BiPredicate equalsByXY  =
>>> equalsBy(List.of(Point3D::x, Point3D::y));
>>>       final BiPredicate equalsByXYZ =
>>> equalsBy(List.of(Point3D::x, Point3D::y, Point3D::z));
>>>
>>>       System.out.println(equalsByXY.test(a, b));  //true
>>>       System.out.println(equalsByXYZ.test(a, b)); //false
>>>
>>>    }
>>>
>>> }
>>> ```
>>>
>>> The concept is simple -- I want to make it easy to create ad-hoc equals
>>> methods.
>>>
>>> Object equality is domain-specific -- in some domains, 2 objects are
>>> equal, but in another, they are not. The object's equals method is not
>>> always a good spot to put this logic into, largely because we don't always
>>> know what domain we are in. The object's equals method is where a good
>>> default should be placed, not logic for every domain. And even if we tried,
>>> it's difficult, if not impossible, to apply equality for the correct domain
>>> if both objects are of the same type.
>>>
>>> So, for domain-specific contexts, I would like to introduce this method.
>>> This method (which should be constant-foldable, thanks again for the help
>>> @liach!) lets you clearly say that you are taking 2 objects and comparing
>>> them by the following methods that apply to both. And due to the nature of
>>> lambdas, developers are not constrained to just the getters of the object
>>> in question -- any function that takes in T is fair game. This allows
>>> flexibility, and lets developers keep their objects simple, thus
>>> facilitating things like DOP.
>>>
>>> Now, perhaps this makes more sense on the BiPredicate interface instead.
>>> However, since this was more equality focused, I figured Objects was a
>>> better fit.
>>>
>>> Any thoughts?
>>>
>>> Thank you all for your time and help!
>>> David Alayachew
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From duke at openjdk.org  Sun Feb 11 10:18:58 2024
From: duke at openjdk.org (David Alayachew)
Date: Sun, 11 Feb 2024 10:18:58 GMT
Subject: Withdrawn: 8324718: Add a static function to java.util.Objects to
 simplify object equality checks
In-Reply-To: <1kfn5xsxLfmMtcCO8BxdreJEg6pBEwIss-f_ckH3qQ0=.fd5a77a6-d1a4-4f77-ab6e-c0e9ca989328@github.com>
References: <1kfn5xsxLfmMtcCO8BxdreJEg6pBEwIss-f_ckH3qQ0=.fd5a77a6-d1a4-4f77-ab6e-c0e9ca989328@github.com>
Message-ID: 

On Sat, 27 Jan 2024 03:57:58 GMT, David Alayachew  wrote:

> Adding a function to Objects in order to facilitate equality checking and enhance readability. You simply specify the 2 objects that you want to check for equality, and then provide the functions which will be used to provide the values that we will check for equality.

This pull request has been closed without being integrated.

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

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

From frank.kretschmer at gmx.net  Sun Feb 11 13:57:26 2024
From: frank.kretschmer at gmx.net (Frank Kretschmer)
Date: Sun, 11 Feb 2024 14:57:26 +0100
Subject: OpenJDK 17: Loitering AbstractQueuedSynchronizer$ConditionNode
 instances (also on latest master branch)
In-Reply-To: <64bc8cbd-78f4-44f4-90ae-80466c563281@gmx.net>
References: <591b0e9c-1d7a-405d-ace1-bd94f8dbbe22@gmx.net>
 
 
 <64bc8cbd-78f4-44f4-90ae-80466c563281@gmx.net>
Message-ID: <6d3b62cb-15f4-471c-97b6-b72977223f91@gmx.net>

Hello Core-Libs-Dev team,

may I ask you about your opinion about a tiny one-liner change in
AbstractQueuedSynchronizer, just as a suggestion how to make
ConditionObjects / Nodes even more garbage collector friendly?

Checked out
https://github.com/openjdk/jdk/blob/jdk-17%2B35/src/java.base/share/classes/java/util/concurrent/locks/AbstractQueuedSynchronizer.java
(the same on master branch with different line numbers near to line 1506):

@@ -1431,40 +1431,41 @@ public abstract class AbstractQueuedSynchronizer
 ???? public class ConditionObject implements Condition,
java.io.Serializable {
 ???????? // ...
 ???????? private void doSignal(ConditionNode first, boolean all) {
 ???????????? while (first != null) {
 ???????????????? ConditionNode next = first.nextWaiter;
+??????????????? first.nextWaiter = null;? // GC-friendly: avoid chains
of dead ConditionNodes
 ???????????????? if ((firstWaiter = next) == null)
 ???????????????????? lastWaiter = null;
 ???????????????? if ((first.getAndUnsetStatus(COND) & COND) != 0) {
 ???????????????????? enqueue(first);
 ???????????????? // ...

By setting the nextWaiter to null of the first condition node, which is
transferred from the condition queue to the sync queue in this method,
long chains of ConditionNode instances can be avoided. Though a single
ConditionNode is small, these chains of ConditionNodes become very huge
on the heap (I've seen more than 1GB on an application server over time)
if at least one node was promoted to the old generation for any reason.
They survive minor collections and are cleaned up only on mixed / full
collections, and thus put unnecessary pressure on G1 garbage collector.

The same change could also be applied to 'AbstractQueuedLongSynchronizer'.

I know premature optimization is the root of all evil, on the other hand
I could image that many applications benefit from GC-friendly
ConditionObjects, since they are frequently used in various classes like
PriorityBlockingQueue / LinkedBlockingDeque / LinkedBlockingQueue, the
latter one as default work queue for executor services like fixed thread
pools for processing asynchronous tasks.

Thank you all for your time and help!

Best regards
Frank

Am 08.02.2024 um 12:15 schrieb Frank Kretschmer:
> Hello Thomas, hello Core-Libs-Dev,
>
> thank you for cc'ing my email. In deed my idea/suggestion is to modify
> the AbstractQueuedSynchronizer$ConditionNode handling in such a way that
> it gets unlinked from the chain of condition nodes if it is not needed
> any more (it might be the "nextWaiter" node), in order to be more
> GC-friendly.
>
> @core-libs-dev: I've just attached the ?G1LoiteringConditionNodes? demo
> class and "gc.log" again so that you can have a look if you like.
>
> Best regards
>
> Frank
>
>
> Am 08.02.2024 um 11:04 schrieb Thomas Schatzl:
>> Hi,
>>
>> ? since this looks like a suggestion for a change to the libraries
>> similar to the mentioned JDK-6805775, and not actually GC, cc'ing the
>> core-libs-dev mailing list.
>>
>> Hth,
>> ? Thomas
>>
>> On 07.02.24 15:20, Frank Kretschmer wrote:
>>> Hi Java GC-experts,
>>>
>>> I'm facing an interesting G1 garbage collector observation in OpenJDK
>>> 17.0.9+9, which I would like to share with you.
>>>
>>> My application runs many asynchronous tasks in a fixed thread pool,
>>> utilizing its standard LinkedBlockingQueue. Usually, it generates
>>> just a
>>> little garbage, but from time to time, I observed that the survivor
>>> spaces grow unexpectedly, and minor collection times increase.
>>>
>>> This being the case, many
>>> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionNode
>>> instances can be found on the heap. In fact, the whole heap (rank 1 as
>>> shown in jmap) was filled up with ConditionNode instances after a
>>> while.
>>>
>>> After some tests, I figured out that G1 seems to be able to collect
>>> ?dead? ConditionNode instances during minor collections only if no
>>> formerly alive ConditionNode instances were promoted to the old
>>> generation and died there.
>>>
>>> To illustrate that, I've attached a ?G1LoiteringConditionNodes? class
>>> that can be run for demo purposes, e.g. under Linux with OpenJDK
>>> 17.0.9+9 (VM options see comments within the class), and its gc-log
>>> output. It shows that during the first two minutes, everything is fine,
>>> but after a promotion to the old generation, survivors grow and minor
>>> pause time increase from 3 to 10ms.
>>>
>>> For me, it looks like an issue similar to
>>> https://bugs.openjdk.org/browse/JDK-6805775 ?LinkedBlockingQueue Nodes
>>> should unlink themselves before becoming garbage?, which was fixed in
>>> OpenJDK 7.
>>>
>>> What?s your opinion about that? Wouldn?t it be worth to enable G1 to
>>> collect those AbstractQueuedSynchronizer$ConditionNode instances during
>>> minor collections, as it is done for LinkedBlockingQueue Nodes?
>>>
>>> Best regards
>>>
>>> Frank
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From duke at openjdk.org  Sun Feb 11 17:43:13 2024
From: duke at openjdk.org (ExE Boss)
Date: Sun, 11 Feb 2024 17:43:13 GMT
Subject: RFR: JDK-8310913 Move ReferencedKeyMap to jdk.internal so it may
 be shared [v10]
In-Reply-To: 
References: 
 
 
 
 <4h2Z1vQnTnCmFGv0K0Ji7nbgBR_FerkVP11U9ZnzDy4=.9c361fd3-8780-4a7e-a0bc-91e82ce1eb28@github.com>
 
Message-ID: 

On Mon, 5 Feb 2024 16:59:51 GMT, Jim Laskey  wrote:

>> ok, `intern(e) == e` is sufficient.
>
> Created https://bugs.openjdk.org/browse/JDK-8325255

While `intern(e)?==?e` is?(mostly)?sufficient, it?will?return a?false?positive when?`add(e)` is?called and?`e` is?already?present in?the?map, the?correctest?implementation would?be some?internal?API in?`ReferencedKeyMap` for?implementing?`ReferencedKeySet::add`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14684#discussion_r1485634936

From duke at openjdk.org  Sun Feb 11 17:44:03 2024
From: duke at openjdk.org (ExE Boss)
Date: Sun, 11 Feb 2024 17:44:03 GMT
Subject: RFR: JDK-8325255 jdk.internal.util.ReferencedKeySet::add using
 wrong test [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 6 Feb 2024 18:43:09 GMT, Jim Laskey  wrote:

>> Currently, add is returning intern(e) == null which will always be false. The correct test is intern(e) == e , that is, true when element is newly added.
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update ReferencedKeyTest.java

src/java.base/share/classes/jdk/internal/util/ReferencedKeySet.java line 151:

> 149:     @Override
> 150:     public boolean add(T e) {
> 151:         return intern(e) == e;

https://github.com/openjdk/jdk/pull/14684#discussion_r1485634936
> While `intern(e)?==?e` is?(mostly)?sufficient, it?will?return a?false?positive when?`add(e)` is?called and?`e` is?already?present in?the?map, the?correctest?implementation would?be some?internal?API in?`ReferencedKeyMap` for?implementing?`ReferencedKeySet::add`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17732#discussion_r1485635132

From ihse at openjdk.org  Mon Feb 12 08:01:23 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 12 Feb 2024 08:01:23 GMT
Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v11]
In-Reply-To: 
References: 
Message-ID: 

> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK native libraries.

Magnus Ihse Bursie 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 branch 'master' into jdk-FOB64
 - Fix indentation
 - Once more, remove AIX dirent64 et al defines
 - Also fix fstatvfs on AIX
 - Redefine statvfs as statvfs64 on AIX
 - Add kludge to BufferedRenderPipe.c for AIX
 - Merge branch 'master' into jdk-FOB64
 - Remove all system includes from debug_util.h
 - Merge branch 'master' into jdk-FOB64
 - Move #include  out of debug_util.h
 - ... and 5 more: https://git.openjdk.org/jdk/compare/efa071dd...caccbf9b

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

Changes: https://git.openjdk.org/jdk/pull/17538/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17538&range=10
  Stats: 284 lines in 29 files changed: 23 ins; 144 del; 117 mod
  Patch: https://git.openjdk.org/jdk/pull/17538.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17538/head:pull/17538

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

From ihse at openjdk.org  Mon Feb 12 08:09:34 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 12 Feb 2024 08:09:34 GMT
Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v12]
In-Reply-To: 
References: 
Message-ID: 

> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK native libraries.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Update copyright year

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17538/files
  - new: https://git.openjdk.org/jdk/pull/17538/files/caccbf9b..7f673ef6

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

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

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

From ihse at openjdk.org  Mon Feb 12 08:09:34 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 12 Feb 2024 08:09:34 GMT
Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v10]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Thu, 8 Feb 2024 14:47:26 GMT, Joachim Kern  wrote:

>> And also `#define statvfs statvfs64` is not necessary with the same explanation as  for the `opendir` defines above -- sorry again.
>> The very only difference between statvfs and statvfs64 is that the filesystem ID field in statvfs has a width of 8 Bytes, while in statvfs64 it has a width of 16 Bytes.
>
>> @JoKern65 So what about `#define fstatvfs fstatvfs64`? Is that still needed? If so, I could not be bothered to make another change. Otherwise, we can get rid of _all_ AIX 64-bit redefines, and then I'll (probably) do it.
> 
> Same as `statvfs`. Only the file system ID field is smaller.

@JoKern65 @MBaesken I did not receive any reply about what to do with `fstatvfs`, so I decided to keep the last verified change for AIX. If you want to clean this up, then please do so, but at that time it will be an AIX-only patch.

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

PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1938201250

From duke at openjdk.org  Mon Feb 12 08:09:36 2024
From: duke at openjdk.org (Sam James)
Date: Mon, 12 Feb 2024 08:09:36 GMT
Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v11]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 12 Feb 2024 08:01:23 GMT, Magnus Ihse Bursie  wrote:

>> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK native libraries.
>
> Magnus Ihse Bursie 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 branch 'master' into jdk-FOB64
>  - Fix indentation
>  - Once more, remove AIX dirent64 et al defines
>  - Also fix fstatvfs on AIX
>  - Redefine statvfs as statvfs64 on AIX
>  - Add kludge to BufferedRenderPipe.c for AIX
>  - Merge branch 'master' into jdk-FOB64
>  - Remove all system includes from debug_util.h
>  - Merge branch 'master' into jdk-FOB64
>  - Move #include  out of debug_util.h
>  - ... and 5 more: https://git.openjdk.org/jdk/compare/efa071dd...caccbf9b

Thank you again for this!

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

PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1938202537

From ihse at openjdk.org  Mon Feb 12 08:09:36 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 12 Feb 2024 08:09:36 GMT
Subject: Integrated: 8324539: Do not use LFS64 symbols in JDK libs
In-Reply-To: 
References: 
Message-ID: 

On Tue, 23 Jan 2024 15:42:55 GMT, Magnus Ihse Bursie  wrote:

> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK native libraries.

This pull request has now been integrated.

Changeset: e5cb78cc
Author:    Magnus Ihse Bursie 
URL:       https://git.openjdk.org/jdk/commit/e5cb78cc88761cd27964e9fe77fc9c6f9073e888
Stats:     310 lines in 29 files changed: 23 ins; 144 del; 143 mod

8324539: Do not use LFS64 symbols in JDK libs

Reviewed-by: jwaters, erikj, mbaesken, alanb

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

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

From ihse at openjdk.org  Mon Feb 12 08:11:03 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 12 Feb 2024 08:11:03 GMT
Subject: RFR: 8325558: Add jcheck whitespace checking for properties files
In-Reply-To: 
References: 
 
Message-ID: <8BLLuuu7gTj4P8bDZ40PWRJDT7668CSSqMiywzlPrIs=.1f188e66-2327-43e3-b30e-16798937eefe@github.com>

On Fri, 9 Feb 2024 18:09:11 GMT, Naoto Sato  wrote:

>> This is an attempt to finally implement the idea brought forward in JDK-8295729:  Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes or leading tabs instead of spaces. 
>> 
>> With Skara jcheck, it is possible to increase the coverage of the whitespace checks.
>> 
>> However, this turned out to be problematic, since trailing whitespace is significant in properties files. That issue has mostly been sorted out in a series of PRs, and this patch will finish the job with the few remaining files, and actually enable the check in jcheck.
>
> Skimmed through the changes and all look good to me. Good to have `jcheck` detect those unneeded trailing spaces.

@naotoj Thanks! Would you care to also submit a review?

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

PR Comment: https://git.openjdk.org/jdk/pull/17789#issuecomment-1938204446

From jkern at openjdk.org  Mon Feb 12 09:26:14 2024
From: jkern at openjdk.org (Joachim Kern)
Date: Mon, 12 Feb 2024 09:26:14 GMT
Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v10]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Thu, 8 Feb 2024 14:47:26 GMT, Joachim Kern  wrote:

>> And also `#define statvfs statvfs64` is not necessary with the same explanation as  for the `opendir` defines above -- sorry again.
>> The very only difference between statvfs and statvfs64 is that the filesystem ID field in statvfs has a width of 8 Bytes, while in statvfs64 it has a width of 16 Bytes.
>
>> @JoKern65 So what about `#define fstatvfs fstatvfs64`? Is that still needed? If so, I could not be bothered to make another change. Otherwise, we can get rid of _all_ AIX 64-bit redefines, and then I'll (probably) do it.
> 
> Same as `statvfs`. Only the file system ID field is smaller.

> @JoKern65 @MBaesken I did not receive any reply about what to do with `fstatvfs`, so I decided to keep the last verified change for AIX. If you want to clean this up, then please do so, but at that time it will be an AIX-only patch.

@magicus I have to reach out to IBM asking if the different size of the 'filesystem ID' field in statvfs makes an important difference. If not, I will remove the defines in an AIX-only patch.
Thanks a lot for your effort.

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

PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1938300228

From jpai at openjdk.org  Mon Feb 12 10:34:03 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 12 Feb 2024 10:34:03 GMT
Subject: RFR: 8303891: Speed up Zip64SizeTest using a small ZIP64 file [v8]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 9 Feb 2024 12:31:27 GMT, Eirik Bj?rsn?s  wrote:

>> Please review this PR which suggests we speed up the `Zip64SizeTest` using a small-sized ZIP64 ZIP file specifically created to reproduce the issue being tested.
>> 
>> The disk space requirement of this test is known to cause problems in some builds, see [JDK-8259866](https://bugs.openjdk.org/browse/JDK-8259866)
>> 
>> By using a sparse file, we reduce consumed disk space from 5GB to 266 bytes and also reduce the runtime from ~35 seconds to ~1 seconds on my Macbook Pro.
>> 
>> The PR also fixes the `@summary` tag, which seems to have been copied from an unrelated test.
>
> Eirik Bj?rsn?s has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Use three dots consistently for representing an ellipsis
>  - Add zipdetails of the Zip64 extra field in updateCENHeaderToZip64

These test-only changes look good to me.

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/12948#pullrequestreview-1874939320

From jpai at openjdk.org  Mon Feb 12 10:34:04 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 12 Feb 2024 10:34:04 GMT
Subject: RFR: 8303891: Speed up Zip64SizeTest using a small ZIP64 file [v5]
In-Reply-To: 
References: 
 
 <2rbbCXHLEpdPrhf6jmXaPJV32_9cYwV8ra7KFEvBYrw=.ef926c3c-4381-42a2-a785-e47755078a69@github.com>
 
Message-ID: 

On Fri, 9 Feb 2024 10:41:18 GMT, Eirik Bj?rsn?s  wrote:

>> test/jdk/java/util/zip/ZipFile/Zip64SizeTest.java line 112:
>> 
>>> 110:             ZipEntry e1 = new ZipEntry("first");
>>> 111:             // Make room for an 8-byte ZIP64 extra field
>>> 112:             e1.setExtra(createOpaqueExtra((short) Long.BYTES));
>> 
>> Hello Eirik, I couldn't understand why we first add a opaque extra field first and then update it to be a zip64 extra field. Why do we do this?
>
>> Hello Eirik, I couldn't understand why we first add a opaque extra field first and then update it to be a zip64 extra field. Why do we do this?
> 
> `ZipEntry.setExtra` processes the byte array argument, looking for Zip64 extended fields which it can extract the size fields from. To prevent this parsing from happening, we temporarily use the `unknown` tag.
> 
> In this particular case, `ZipExtra.setExtra` actually ends up skipping this processing (because `isLOC == true` and it has a guard for the block size being `>= 16`).
> 
> However, I prefer the test to not depend too much on the details of `setExtra` Zip64 processing. This trick is used in other tests as well and may be copied over to a test where the conditions are not the same.
> 
> I have refactored a bit and added some code comments to help explain the use of the 'unknown' tag.
> 
> Do you think this makes sense?

Hello Eirik, thank you for that detail. Yes, what you note and the updated comment, looks good to me.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/12948#discussion_r1485992196

From jpai at openjdk.org  Mon Feb 12 10:50:54 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 12 Feb 2024 10:50:54 GMT
Subject: RFR: JDK-8324930: java/lang/StringBuilder problem with concurrent
 jtreg runs
In-Reply-To: 
References: 
Message-ID: 

On Tue, 30 Jan 2024 09:08:28 GMT, Matthias Baesken  wrote:

> On some Windows machines we see sometimes OOM errors because of high resource (memory/swap) consumption. This is especially seen when the jtreg runs have higher concurrency. A solution is to put the java/lang/StringBuilder tests in the exclusiveAccess.dirs group so that they are not executed concurrently, which helps to mitigate the resource shortages.
> Of course this has the downside that on very large machines the concurrent execution is not done any more.

Hello Matthias, looking at the crash log you pasted, it's clear that the test itself isn't a culprit here. Specifically, the failure appears to be when a JVM launch is being attempted for the `test/jdk/java/lang/StringBuilder/Insert.java` test (which looking at the code doesn't use too much memory once launched).

What seems to be happening is that the system where this run appears to be launching too many tests concurrently. The exact command used to launch these tests on that setup would be helpful in understanding the configurations. 

The JDK build by default "computes" the `TEST_JOBS` value which controls this concurrency (the number of jtreg concurrent tests to run) and that's done here https://github.com/openjdk/jdk/blob/master/make/RunTests.gmk#L151 and as noted in testing.md, it is configurable (and has a per system default) https://github.com/openjdk/jdk/blob/master/doc/testing.md#jobs-1. This configuration ultimately translates to the `-concurrency` option of jtreg which is explained in section `3.8 How do I specify whether to run tests concurrently?` and `3.25 My system is unusable while I run tests. How do I fix that?` of the jtreg FAQ https://openjdk.org/jtreg/faq.html.

Based on the available details so far, it appears that you might have to reduce the value for this concurrency option, through the right build/test option.

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

PR Comment: https://git.openjdk.org/jdk/pull/17625#issuecomment-1938437285

From viktor.klang at oracle.com  Mon Feb 12 15:13:08 2024
From: viktor.klang at oracle.com (Viktor Klang)
Date: Mon, 12 Feb 2024 15:13:08 +0000
Subject: The common ForkJoinPool does not have any ForkJoinWorkerThread
 while tasks are submitted to the queue
In-Reply-To: 
References: 
 
 
Message-ID: 

Hi,

Could the problem have occurred because the ForkJoinPool got an OOME when it tried to allocate a ForkJoinWorkerThread?

To check for that, if you're using the commonPool(), you might be able to add a custom ForkJoinWorkerThreadFactory via passing in -Djava.util.concurrent.ForkJoinPool.common.threadFactory= and implement newThread() such that you try-catch OOME and log it from there.

Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: core-libs-dev  on behalf of Xiao Yu 
Sent: Saturday, 3 February 2024 19:54
To: Jaikiran Pai 
Cc: core-libs-dev at openjdk.org 
Subject: Re: The common ForkJoinPool does not have any ForkJoinWorkerThread while tasks are submitted to the queue

Hi Jaikiran,

Thanks a lot for replying.

Our application is a client that communicates to the server for
request/response. The client creates a secure (TLS) connection to the server,
that is, on top of the SocketChannel, we implement a Wrapper class called
SSLDataChannel for reading and writing. The SSLDataChannel uses the
javax.net.ssl.SSLEngine. Before any read and write can happen, we need to do
SSL handshakes by calling methods in SSLEngine. One of the methods is
SSLEngine#getDelegatedTask(). The returned task needs to be executed before the
handshake can proceed. After the task is done, we need to continue processing
read and write events on the connection. The connection read and write events
are all handled by a class called NioEndpointHandler. One requirement for our
client is that it supports an asynchronous API and therefore the whole stack
must all implement non-blocking methods. The tasks from the SSLEngine could
take a long time and we do not want them to block our other connection events,
and this is when the ForkJoinPool is used. We run the SSL tasks in the
ForkJoinPool and after the task is done we arrange to run the
NioEndpointHandler callbacks to proceed with the read and write events. The
much simplified code looks somewhat like the following.

```
class NioEndpointHandler {

    /** The ssl channel */
    private final SSLDataChannel sslDataChannel;
    /** The runnable to execute to handle read after ssl tasks is done. */
    private final Runnable handleReadAfterSSLTask = () -> onRead();
    /** The handler state. */
    State state;

    /** Executes the SSL tasks until no task to run, then run the callback. */
    private void executeSSLTask(ExecutorService executor, Runnable callback) {
        executor.submit(() -> {
            Runnable task;
            while ((task = sslDataChannel.getSSLEngine().getDelegatedTask()) != null) {
                task.run();
            }
            try {
                callback.run();
            } catch (Throwable t) {
                /* logging the exception. */
            }
        });
    }

    /** Handle a read event. */
    private void onRead() {
        if (sslDataChannel.needsHandshake()) {
            /* do handshake */

            /* One of the handshake step is to check if there is any SSL task to run. */
            if (sslDataChannel.needExecuteTask()) {
                executeSSLTask(ForkJoinPool.commonPool(), handleReadAfterSSLTask);
            }
        }
    }

    private void terminate() {
        state = TERMINATED;

        /* Other clean up tasks, however, tasks submitted to the ForkJoinPool are not cancelled. */
    }
}
```

> What are these handlers? Are they classes which implement Runnable or
> are they something else? What does termination of handler mean in this
> context? Do you use any java.util.concurrent.* APIs to "cancel" such
> terminated handlers?

The much simplified handler code please see above.

The tasks submitted to the ForkJoinPool queue are Runnables that are fields to
the NioEndpointHandler. What we have observed is that there are a lot of tasks
in the fork join pool that have a reference to the lambda inside
NioEndpointHandler#executeSSLTask which eventually have a reference to the
NioEndpointHandler. Those NioEndpointHandler are in the TERMINATED state. The
only reference to those NioEndpointHandler are these tasks or otherwise they
can be garbage collected after the termination cleans up all the other
references.

Termination of the handler means those connections are at the end of their life
cycle. We clean up things such as signal end of life cycle for all the
associated request/response pairs and closing the SSLDataChannel, etc.

No, we have not use the cancel method to cancel the submitted tasks. I agree
that this is an oversight and it would be cleaner to cancel them. However, my
current theory is that this is not the root cause. From my understanding of the
code, the cancel method only changes the state of the task. It does not remove
the task from the queue of the ForkJoinPool. Therefore, those tasks, even if
got cancelled, would still stay in the queue preventing the terminated
NioEndpointHandler from being garbage collected. Currently, I am strongly
biased to my own theory that somehow there is no ForkJoinPool thread that
polling tasks out of the queue and I am trying to use the ctl field in the
ForkJoinPool as the evidence to backup my theory. I am wondering if I am making
some mistake with my theory.

> Finally, what does the OutOfMemoryError exception stacktrace look like
> and what is the JVM parameters (heap size for example) used to launch
> this application?

Our clients creates about 155 threads and quite a lot of them have OOME on
their stack. I am not quite sure how to reply to this question. Going through
the stack traces, I do not find anything very suspicious. They are just
exercising their most frequent code path: some I/O threads waiting for I/O
events and some execution threads waiting for more work to do, etc.

It is worth mentioning that there is no ForkJoinPoolWorkerThread stacks in the
thread dump from the heap dump. From my understanding, the only time when there
is no such thread is when there is no tasks to run. But there are quite a lot
of tasks in the queue.

Here are our JVM arguments:

```
-Xms1G
-Xmx1G
-Djava.util.logging.config.file=/var/lib/andc/config/params/sender.logging.properties
-Djavax.net.ssl.trustStore=/var/lib/andc/wallet/client.trust
-Doracle.kv.security=/var/lib/andc/config/security/login.properties
-Doci.javasdk.extra.stream.logs.enabled=false
-XX:G1HeapRegionSize=32m
-XX:+DisableExplicitGC
-Xlog:all=warning,gc*=info,safepoint=info:file=/var/lib/andc/log/sender/sender.gc:utctime:filecount=10,filesize=10000000
-XX:+HeapDumpOnOutOfMemoryError
-XX:HeapDumpPath=/var/lib/andc/log/sender/
```

We have creation and termination timestamps in the NioEndpointHandler object.
From what I can see in the heap dump, the SSL tasks in the ForkJoinPool are
associated with NioEndpointHandler that are created at an interval on the
magnitude of seconds (retry attempt with second-magnitude backoff). Each
NioEndpointHandler are terminated after a fixed 5-second timeout due to unable
to connect. The time span for those NioEndpointHandler is about 2 hours. This
creates
```
2 hours * 3600 seconds / hour * 1 NioEndpointHandler / second  * 1 SSLDataChannel / NioEndpointHandler * 65K bytes / SSLDataChannel ~= 468M bytes.
```
With 1G heap size, this eventually caused OOME.

We are adding fixes so that the SSL tasks would not preventing the
NioEndpointHandler from being garbage collected. However, the root cause is
still a mystery and I am wondering if I am on the right tracker to figure it
out.

Thanks a lot for your time and patience.



Xiao Yu


On Fri, Feb 2, 2024 at 5:35?AM Jaikiran Pai > wrote:
Hello Xiao,

I don't have enough knowledge of this area to provide any insight into
the issue. However, just to try and get the discussion started, do you
have any sample code of your application which shows how the application
uses the ForkJoinPool? More specifically what APIs do you use in the
application?

Few other questions inline below.

On 12/01/24 11:30 am, Xiao Yu wrote:
> ....
> Here is the full background. One of our process experienced an OOME
> and a heap
> dump was obtained. We know there was a concurrent issue of our system
> happening
> on some other machines such that network failure and retries occurred
> in this
> process at the same time. Upon analyzing the heap dump, we observed a
> lot of
> our network connection handlers being frequently created and
> terminated which
> is expected due to the network failure and retry attempts mentioned above.
> However, those terminated handlers are not being GC'ed because of
> there were
> references to tasks submitted to the ForkJoinPool during the connection
> attempts. The tasks stayed in the queue until OOME happened as there is no
> threads to execute them.

What are these handlers? Are they classes which implement Runnable or
are they something else? What does termination of handler mean in this
context? Do you use any java.util.concurrent.* APIs to "cancel" such
terminated handlers?

Finally, what does the OutOfMemoryError exception stacktrace look like
and what is the JVM parameters (heap size for example) used to launch
this application?

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

From dlutker at openjdk.org  Mon Feb 12 16:44:25 2024
From: dlutker at openjdk.org (Dan Lutker)
Date: Mon, 12 Feb 2024 16:44:25 GMT
Subject: RFR: 8325576: TEST_BUG: java/lang/ProcessHandle/InfoTest.java#test3
 fails on systems with coreutils with --enable-single-binary
Message-ID: 

Ran the test on AmazonLinux 2 which has multiple binaries from coreutils package and no coreutils executable as well as AmazonLinux 2023 that uses `--enable-single-binary`

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

Commit messages:
 - TEST_BUG: java/lang/ProcessHandle/InfoTest.java#test3 fails on systems with coreutils with --enable-single-binary

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

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

From aefimov at openjdk.org  Mon Feb 12 17:12:01 2024
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Mon, 12 Feb 2024 17:12:01 GMT
Subject: RFR: 8325579: Inconsistent behavior in
 com.sun.jndi.ldap.Connection::createSocket
In-Reply-To: 
References: 
Message-ID: 

On Fri, 9 Feb 2024 21:29:28 GMT, Christoph Langer  wrote:

> During analysing a customer case I figured out that we have an inconsistency between documentation and actual behavior in class com.sun.jndi.ldap.Connection. The [method documentation of com.sun.jndi.ldap.Connection::createSocket](https://github.com/openjdk/jdk/blob/3ebe6c192a5dd5cc46ae2d263713c9ff38cd46bb/src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java#L281) states: "If a timeout is supplied but unconnected sockets are not supported then the timeout is ignored and a connected socket is created."
> 
> This, however does not happen. If a SocketFactory would not support unconnected sockets, it would likely throw a SocketException in [SocketFactory::createSocket()](https://github.com/openjdk/jdk/blob/6303c0e7136436a2d3cb6043b88edf788c0067cc/src/java.base/share/classes/javax/net/SocketFactory.java#L123). And since [the code](https://github.com/openjdk/jdk/blob/3ebe6c192a5dd5cc46ae2d263713c9ff38cd46bb/src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java#L336) does not check for this behavior, a connection with timeout value through a SocketFactory that does not support unconnected sockets would simply fail with an IOException.
> 
> So we should either make the code adhere to what is documented or adapt the documentation to the actual behavior.
> 
> I hereby try to fix the connect coding. Alternatively, we could also adapt the description - I have no strong opinion. What do the experts suggest?

Hi Christoph,

I think the proposed change is good, and it solves the problem we've also seen before with custom socket factories specified in the `"java.naming.ldap.factory.socket"` JNDI environment property not implementing  `javax.net.SocketFactory::createSocket()` method - custom implementations are not required to implement this method, hence `SocketException` can be thrown by the default implementation.
The change proposed by you should help to address such scenarios. 

It would also be great to update the `com.sun.jndi.ldap.connect.timeout` env property documentation in the `java.naming` module-info with the code comment mentioned above.
To fully clarify the `"unconnected sockets are not supported"` statement the `"java.naming.ldap.factory.socket"` environment property might need to have documentation added.

I've launched JNDI/LDAP regression tests with your patch and no failures were observed.
As a good addition to the proposed fix, it would be great to have a test for scenarios when a custom socket factory does/doesn't override the `createSocket` method. There are a few test examples that can be used as a bootstrap - for example, `test/jdk/com/sun/jndi/ldap/DeadSSLLdapTimeoutTest.java`.

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

PR Comment: https://git.openjdk.org/jdk/pull/17797#issuecomment-1939169699

From prappo at openjdk.org  Mon Feb 12 17:21:06 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Mon, 12 Feb 2024 17:21:06 GMT
Subject: RFR: 8311864: Add ArraysSupport.hashCode(int[] a, fromIndex,
 length, initialValue) [v4]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 2 Jan 2024 14:37:16 GMT, Pavel Rappo  wrote:

>> This PR adds an internal method to calculate hash code from the provided integer array, offset and length into that array, and the initial hash code value.
>> 
>> Current options for calculating a hash code for int[] are inflexible. It's either ArraysSupport.vectorizedHashCode with an offset, length and initial value, or Arrays.hashCode with just an array.
>> 
>> For an arbitrary int[], unconditional vectorization might be unwarranted or puzzling. Unfortunately, it's the only hash code method that operates on an array subrange or accepts the initial hash code value.
>> 
>> A more convenient method could be added and then used, for example, here:
>> 
>> * https://github.com/openjdk/jdk/blob/0ef03f122866f010ebf50683097e9b92e41cdaad/src/java.base/share/classes/java/util/concurrent/CopyOnWriteArrayList.java#L1076-L1083
>> 
>> * https://github.com/openjdk/jdk/blob/0ef03f122866f010ebf50683097e9b92e41cdaad/src/java.base/share/classes/java/util/ArrayList.java#L669-L680
>> 
>> * https://github.com/openjdk/jdk/blob/0ef03f122866f010ebf50683097e9b92e41cdaad/src/java.base/share/classes/sun/security/pkcs10/PKCS10.java#L356-L362
>> 
>> This PR adds such a method and provides tests for it. Additionally, this PR adds tests for `null` passed to `java.util.Arrays.hashCode` overloads, behaviour which was specified but untested.
>
> 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 four additional commits since the last revision:
> 
>  - Merge branch 'master' into 8311864
>  - Merge remote-tracking branch 'jdk/master' into 8311864
>  - Merge branch 'master' into 8311864
>  - Initial commit

To Skara bots: keep this PR alive.

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

PR Comment: https://git.openjdk.org/jdk/pull/14831#issuecomment-1939184314

From naoto at openjdk.org  Mon Feb 12 17:37:56 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 12 Feb 2024 17:37:56 GMT
Subject: RFR: 8325558: Add jcheck whitespace checking for properties files
In-Reply-To: 
References: 
Message-ID: 

On Fri, 9 Feb 2024 13:35:55 GMT, Magnus Ihse Bursie  wrote:

> This is an attempt to finally implement the idea brought forward in JDK-8295729:  Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes or leading tabs instead of spaces. 
> 
> With Skara jcheck, it is possible to increase the coverage of the whitespace checks.
> 
> However, this turned out to be problematic, since trailing whitespace is significant in properties files. That issue has mostly been sorted out in a series of PRs, and this patch will finish the job with the few remaining files, and actually enable the check in jcheck.

> @naotoj Thanks! Would you care to also submit a review?

My bad. I thought I approved this PR.

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17789#pullrequestreview-1875811619

From dfuchs at openjdk.org  Mon Feb 12 17:42:06 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 12 Feb 2024 17:42:06 GMT
Subject: RFR: 8325558: Add jcheck whitespace checking for properties files
In-Reply-To: 
References: 
Message-ID: 

On Fri, 9 Feb 2024 13:35:55 GMT, Magnus Ihse Bursie  wrote:

> This is an attempt to finally implement the idea brought forward in JDK-8295729:  Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes or leading tabs instead of spaces. 
> 
> With Skara jcheck, it is possible to increase the coverage of the whitespace checks.
> 
> However, this turned out to be problematic, since trailing whitespace is significant in properties files. That issue has mostly been sorted out in a series of PRs, and this patch will finish the job with the few remaining files, and actually enable the check in jcheck.

Approving the sun.net changes.

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

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17789#pullrequestreview-1875818676

From joehw at openjdk.org  Mon Feb 12 20:25:59 2024
From: joehw at openjdk.org (Joe Wang)
Date: Mon, 12 Feb 2024 20:25:59 GMT
Subject: RFR: 8325558: Add jcheck whitespace checking for properties files
In-Reply-To: 
References: 
Message-ID: 

On Fri, 9 Feb 2024 13:35:55 GMT, Magnus Ihse Bursie  wrote:

> This is an attempt to finally implement the idea brought forward in JDK-8295729:  Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes or leading tabs instead of spaces. 
> 
> With Skara jcheck, it is possible to increase the coverage of the whitespace checks.
> 
> However, this turned out to be problematic, since trailing whitespace is significant in properties files. That issue has mostly been sorted out in a series of PRs, and this patch will finish the job with the few remaining files, and actually enable the check in jcheck.

java.xml changes look fine to me.

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

Marked as reviewed by joehw (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17789#pullrequestreview-1876181019

From joehw at openjdk.org  Mon Feb 12 20:26:00 2024
From: joehw at openjdk.org (Joe Wang)
Date: Mon, 12 Feb 2024 20:26:00 GMT
Subject: RFR: 8325558: Add jcheck whitespace checking for properties files
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 9 Feb 2024 13:46:06 GMT, Magnus Ihse Bursie  wrote:

>> This is an attempt to finally implement the idea brought forward in JDK-8295729:  Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes or leading tabs instead of spaces. 
>> 
>> With Skara jcheck, it is possible to increase the coverage of the whitespace checks.
>> 
>> However, this turned out to be problematic, since trailing whitespace is significant in properties files. That issue has mostly been sorted out in a series of PRs, and this patch will finish the job with the few remaining files, and actually enable the check in jcheck.
>
> src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages.properties line 24:
> 
>> 22: # Messages for message reporting
>> 23: BadMessageKey = The error message corresponding to the message key can not be found.
>> 24: FormatFailed = An internal error occurred while formatting the following message:\n
> 
> Same here with `:\n`...

It's done with the code (that is, a key is appended with the code). In fact, the whole Xerces stack was implemented this way. I'd leave it as is.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17789#discussion_r1486731927

From rriggs at openjdk.org  Mon Feb 12 21:33:12 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 12 Feb 2024 21:33:12 GMT
Subject: RFR: 8325590: Regression in round-tripping UTF-16 strings after
 JDK-8311906
Message-ID: 

Correct the result string coder of a string encoded using a CharsetDecoder with multi-byte encoded input.
Added tests for UTF16 strings and a regression test.

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

Commit messages:
 - 8325590: Regression in round-tripping UTF-16 strings after JDK-8311906

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

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

From lancea at openjdk.org  Mon Feb 12 22:41:05 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 12 Feb 2024 22:41:05 GMT
Subject: RFR: 8303866: Allow ZipInputStream.readEnd to parse small Zip64
 ZIP files [v16]
In-Reply-To: 
References: 
 
Message-ID: <9yrL4eVJ3oFkXjcaWaZKAX-jFEN1cxR9AqaRiAEHfdM=.357cd076-916f-42e3-bacb-8522a1390968@github.com>

On Mon, 5 Feb 2024 13:14:39 GMT, Eirik Bj?rsn?s  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 AND at least one of the 'compressed size' and 'uncompressed size' have the expected Zip64 "magic" value 0xFFFFFFFF. 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 Bj?rsn?s has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 230 commits:
> 
>  - Update readZipInputStream to verify that the ZipInputStream finds a single zip entry with the expected contents
>  - Merge branch 'master' into data-descriptor
>  - Merge branch 'master' into data-descriptor
>  - Update comment of expect64BitDataDescriptor to reflect relaxed validation
>  - Dial down validation of the Zip64 extra field
>  - 8321712: C2: "failed: Multiple uses of register" in C2_MacroAssembler::vminmax_fp
>    
>    Co-authored-by: Volodymyr Paprotski 
>    Reviewed-by: kvn, thartmann, epeter, jbhateja
>  - 8319128: sun/security/pkcs11 tests fail on OL 7.9 aarch64
>    
>    Reviewed-by: mbaesken
>  - 8322971: KEM.getInstance() should check if a 3rd-party security provider is signed
>    
>    Reviewed-by: mullan, valeriep
>  - 8320890: [AIX] Find a better way to mimic dl handle equality
>    
>    Reviewed-by: stuefe, mdoerr
>  - 8323276: StressDirListings.java fails on AIX
>    
>    Reviewed-by: jpai, dfuchs
>  - ... and 220 more: https://git.openjdk.org/jdk/compare/692c9f88...e8d3b904

The latest updates seem OK.

Thank you Eirik

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

Marked as reviewed by lancea (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/12524#pullrequestreview-1876488622

From attila at openjdk.org  Mon Feb 12 22:58:22 2024
From: attila at openjdk.org (Attila Szegedi)
Date: Mon, 12 Feb 2024 22:58:22 GMT
Subject: RFR: 8325679: Optimize ArrayList subList sort
Message-ID: 

Somewhat surprisingly, `ArrayList$Sublist.sort()` is not specialized and will thus fall back to slower default method of `List.sort()` instead of sorting a range of the array in-place in its backing root `ArrayList`. 

This doesn't change observable behavior, so haven't added tests, and `tier1` tests still all pass except for `test/jdk/java/util/Locale/LocaleProvidersFormat.java` which also currently fails on master too on the machine I tested on.

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

Commit messages:
 - Add sort specialization for ArrayList

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

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

From jlaskey at openjdk.org  Mon Feb 12 23:41:02 2024
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 12 Feb 2024 23:41:02 GMT
Subject: RFR: 8325679: Optimize ArrayList subList sort
In-Reply-To: 
References: 
Message-ID: 

On Mon, 12 Feb 2024 22:52:51 GMT, Attila Szegedi  wrote:

> Somewhat surprisingly, `ArrayList$Sublist.sort()` is not specialized and will thus fall back to slower default method of `List.sort()` instead of sorting a range of the array in-place in its backing root `ArrayList`. 
> 
> This doesn't change observable behavior, so haven't added tests, and `tier1` tests still all pass except for `test/jdk/java/util/Locale/LocaleProvidersFormat.java` which also currently fails on master too on the machine I tested on.

Been there since day one?

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

PR Comment: https://git.openjdk.org/jdk/pull/17818#issuecomment-1939788165

From smarks at openjdk.org  Tue Feb 13 03:58:07 2024
From: smarks at openjdk.org (Stuart Marks)
Date: Tue, 13 Feb 2024 03:58:07 GMT
Subject: RFR: 8325679: Optimize ArrayList subList sort
In-Reply-To: 
References: 
Message-ID: 

On Mon, 12 Feb 2024 22:52:51 GMT, Attila Szegedi  wrote:

> Somewhat surprisingly, `ArrayList$Sublist.sort()` is not specialized and will thus fall back to slower default method of `List.sort()` instead of sorting a range of the array in-place in its backing root `ArrayList`. 
> 
> This doesn't change observable behavior, so haven't added tests, and `tier1` tests still all pass except for `test/jdk/java/util/Locale/LocaleProvidersFormat.java` which also currently fails on master too on the machine I tested on.

@szegedi Oh interesting catch. Looks like a reasonable optimization. Is this covered by a test, or should a new test be added?

@JimLaskey The `List.sort` method was added in JDK 8, so not really day one. Prior to that one had to call `Collections.sort` which copied to a temp array, sorted, then copied back; this applied equally to full lists and sublists. Since JDK 8, `ArrayList.sort` on the full list did sorting in place but sorting a subList just inherited the default method (which uses the old copy-to-temp-and-sort technique). My guess is that nobody noticed this because sublists aren't used that much, and sorting of subarrays, while arguably necessary for completeness, probably aren't used all that much either.

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

PR Comment: https://git.openjdk.org/jdk/pull/17818#issuecomment-1940384762

From alanb at openjdk.org  Tue Feb 13 07:24:03 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 13 Feb 2024 07:24:03 GMT
Subject: RFR: 8325590: Regression in round-tripping UTF-16 strings after
 JDK-8311906
In-Reply-To: 
References: 
Message-ID: 

On Mon, 12 Feb 2024 21:29:02 GMT, Roger Riggs  wrote:

> Correct the result string coder of a string encoded using a CharsetDecoder with multi-byte encoded input.
> Added tests for UTF16 strings and a regression test.

test/jdk/java/nio/file/Files/ReadWriteString.java line 322:

> 320:         }
> 321:         assertEquals(actual, original, "Round trip string mismatch with multi-byte encoding");
> 322:     }

The update to newStringNoRepl1 looks fine.

The added test is very different to the tests in this source file. We really need to expand the test to exercise a lot more charsets and input cases.  It's okay to have a targeted test for now but needs to be renamed to be consistent with the other tests. Also the other tests use testFiles as the file paths rather than putting files in /tmp.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17817#discussion_r1487326652

From mbaesken at openjdk.org  Tue Feb 13 08:35:02 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 13 Feb 2024 08:35:02 GMT
Subject: RFR: JDK-8324930: java/lang/StringBuilder problem with concurrent
 jtreg runs
In-Reply-To: 
References: 
 
Message-ID: <6HjwfY4ALEPqkjqHRc0nEn_Fzj4fhmzHUo5ORj0fBrQ=.fa8cfdea-95db-4906-997a-2bdc9ceb2ccb@github.com>

On Mon, 12 Feb 2024 10:47:56 GMT, Jaikiran Pai  wrote:

> What seems to be happening is that the system where this run appears to be launching too many tests concurrently. 

Sure, that's why I want to limit the concurrency *for certain tests/ test groups* . Limiting it for the whole tier1 would slow down tests that are absolutely fine with the concurrency we set.

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

PR Comment: https://git.openjdk.org/jdk/pull/17625#issuecomment-1940741219

From ihse at openjdk.org  Tue Feb 13 10:03:08 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 13 Feb 2024 10:03:08 GMT
Subject: Integrated: 8325558: Add jcheck whitespace checking for properties
 files
In-Reply-To: 
References: 
Message-ID: <1_5f_JhU7k2LuEKn7w-rn3FkkBpaBDiz3o_uBy-uKiw=.7ed5bef7-6484-435f-8d87-12dadc4d9e9d@github.com>

On Fri, 9 Feb 2024 13:35:55 GMT, Magnus Ihse Bursie  wrote:

> This is an attempt to finally implement the idea brought forward in JDK-8295729:  Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes or leading tabs instead of spaces. 
> 
> With Skara jcheck, it is possible to increase the coverage of the whitespace checks.
> 
> However, this turned out to be problematic, since trailing whitespace is significant in properties files. That issue has mostly been sorted out in a series of PRs, and this patch will finish the job with the few remaining files, and actually enable the check in jcheck.

This pull request has now been integrated.

Changeset: c266800a
Author:    Magnus Ihse Bursie 
URL:       https://git.openjdk.org/jdk/commit/c266800a3a7dd44416b0b4df3bdd78410241d74b
Stats:     761 lines in 95 files changed: 0 ins; 5 del; 756 mod

8325558: Add jcheck whitespace checking for properties files

Reviewed-by: naoto, dfuchs, joehw

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

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

From shade at openjdk.org  Tue Feb 13 10:15:10 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 13 Feb 2024 10:15:10 GMT
Subject: RFR: 8325576: java/lang/ProcessHandle/InfoTest.java fails on
 systems with coreutils with --enable-single-binary
In-Reply-To: 
References: 
Message-ID: 

On Fri, 9 Feb 2024 23:40:00 GMT, Dan Lutker  wrote:

> Ran the test on AmazonLinux 2 which has multiple binaries from coreutils package and no coreutils executable as well as AmazonLinux 2023 that uses `--enable-single-binary`

test/jdk/java/lang/ProcessHandle/InfoTest.java line 321:

> 319:                     String[] args = info.arguments().get();
> 320:                     if (args.length > 0) {
> 321:                         if (timeIsLastParam) {

I gotta ask: is it true that time argument is the last param in _all_ testing modes? If so, we don't need `timeIsLastParam` at all?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17798#discussion_r1487540871

From attila at openjdk.org  Tue Feb 13 12:37:53 2024
From: attila at openjdk.org (Attila Szegedi)
Date: Tue, 13 Feb 2024 12:37:53 GMT
Subject: RFR: 8325679: Optimize ArrayList subList sort
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 13 Feb 2024 03:55:37 GMT, Stuart Marks  wrote:

>> Somewhat surprisingly, `ArrayList$Sublist.sort()` is not specialized and will thus fall back to slower default method of `List.sort()` instead of sorting a range of the array in-place in its backing root `ArrayList`. 
>> 
>> This doesn't change observable behavior, so haven't added tests, and `tier1` tests still all pass except for `test/jdk/java/util/Locale/LocaleProvidersFormat.java` which also currently fails on master too on the machine I tested on.
>
> @szegedi Oh interesting catch. Looks like a reasonable optimization. Is this covered by a test, or should a new test be added?
> 
> @JimLaskey The `List.sort` method was added in JDK 8, so not really day one. Prior to that one had to call `Collections.sort` which copied to a temp array, sorted, then copied back; this applied equally to full lists and sublists. Since JDK 8, `ArrayList.sort` on the full list did sorting in place but sorting a subList just inherited the default method (which uses the old copy-to-temp-and-sort technique). My guess is that nobody noticed this because sublists aren't used that much, and sorting of subarrays, while arguably necessary for completeness, probably aren't used all that much either.

@stuart-marks you're right that sorting of sublists is rare. I did run into a need for it a few months ago in my day job though, that's how I stumbled upon this. Granted, it was a performance optimization and not a correctness necessity. See, I have a large list of data I read from an external location. Some elements ? in at most one identifiable but arbitrarily large stride in the large list ? need some extra processing. The algorithm for this processing can be written to be more efficient if it can presume those elements are sorted.

I could still sort the entire list (as the ordering doesn't matter to the final receiver), using a sort that just compares irrelevant elements as equal, so they'd remain as large "already sorted" strides, and only apply the real sort on only the relevant elements:

static int fullListCompare(Data d1, Data d2) {
  if (isRelevant(d1)) {
    if (isRelevant(d2)) {
      return sublistCompare(d1, d2);
    } else {
      return -1;
    }
  } else if (isRelevant(d2)) {
    return 1;
  }
  return 0;    
}

This'd also have the side effect of moving all the relevant entries to the beginning of the list, but while that's not a problem, it's not necessary either. For this reason, I prefer to scan the list for the stride, reify it as a sublist, and only run a sort with `sublistCompare` on it, and then also do the extra processing of the elements on the sublist too.

So yeah, it is rare this pops up, but it does happen :-)

I'm not sure if there's a test that already exercises sublist sorts. I did find what seems like a setup for a [TCK test for ArrayList](https://github.com/openjdk/jdk/blob/master/test/jdk/java/util/concurrent/tck/ArrayListTest.java) that seems like it is specifically creating a test suite for sublists too, but I haven't looked more closely into how is that supposed to work. I'm happy to write some tests specifically for ArrayList sublist sort if this TCK one doesn't exercise it.

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

PR Comment: https://git.openjdk.org/jdk/pull/17818#issuecomment-1941426905

From rriggs at openjdk.org  Tue Feb 13 12:47:26 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 13 Feb 2024 12:47:26 GMT
Subject: RFR: 8325590: Regression in round-tripping UTF-16 strings after
 JDK-8311906 [v2]
In-Reply-To: 
References: 
Message-ID: 

> Correct the result string coder of a string encoded using a CharsetDecoder with multi-byte encoded input.
> Added tests for UTF16 strings and a regression test.

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

  Test Files.readString with multiple charsets
  Cleanup regression test to match style of other tests

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17817/files
  - new: https://git.openjdk.org/jdk/pull/17817/files/45ed4e19..39403b00

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

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

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

From rriggs at openjdk.org  Tue Feb 13 12:47:27 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 13 Feb 2024 12:47:27 GMT
Subject: RFR: 8325590: Regression in round-tripping UTF-16 strings after
 JDK-8311906 [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 13 Feb 2024 07:21:01 GMT, Alan Bateman  wrote:

>> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Test Files.readString with multiple charsets
>>   Cleanup regression test to match style of other tests
>
> test/jdk/java/nio/file/Files/ReadWriteString.java line 322:
> 
>> 320:         }
>> 321:         assertEquals(actual, original, "Round trip string mismatch with multi-byte encoding");
>> 322:     }
> 
> The update to newStringNoRepl1 looks fine.
> 
> The added test is very different to the tests in this source file. We really need to expand the test to exercise a lot more charsets and input cases.  It's okay to have a targeted test for now but needs to be renamed to be consistent with the other tests. Also the other tests use testFiles as the file paths rather than putting files in /tmp.

The UTF-16 charset is added to the existing `readString` test.
Additional charsets can be added, most will exercise the same code path in newStringNoRepl1 that uses a CharsetDecoder for all charsets other than UTF-8, ASCII, or ISO-8859-1.

The additional individual test is taken from the bug report and is not strictly necessary.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17817#discussion_r1487787125

From jvernee at openjdk.org  Tue Feb 13 14:18:23 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 13 Feb 2024 14:18:23 GMT
Subject: RFR: 8318966: Some methods make promises about Java array element
 alignment that are too strong [v3]
In-Reply-To: 
References: 
Message-ID: 

> 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...

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

 - Merge branch 'master' into AlignedOffset
 - Merge branch 'master' into AlignedOffset
 - Add api note pointing to alternatives for client that require non-plain access
 - simplify spec for alignmentOffset and alignedSlice
 - Merge note about misaligned access in byteBufferViewVarHandle
 - updated alignedSlice implNote as well
 - updated alignedOffset implNote
 - Use ISE for bbvvh instead of UOE
 - restore some tests for direct buffers
 - fix BAVV and BBVV impl and tests
 - ... and 2 more: https://git.openjdk.org/jdk/compare/a2273ed0...281deaa5

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16681/files
  - new: https://git.openjdk.org/jdk/pull/16681/files/eccf4f41..281deaa5

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

  Stats: 14804 lines in 723 files changed: 8780 ins; 2698 del; 3326 mod
  Patch: https://git.openjdk.org/jdk/pull/16681.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16681/head:pull/16681

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

From jvernee at openjdk.org  Tue Feb 13 14:18:27 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 13 Feb 2024 14:18:27 GMT
Subject: RFR: 8318966: Some methods make promises about Java array element
 alignment that are too strong [v2]
In-Reply-To: <7BH7MA_XWtqbGekVB83r9KMCYIq2P1QXeMX25QmqvTU=.edb35293-fa11-4d7f-945d-9ec0ce0e2a31@github.com>
References: 
 <7BH7MA_XWtqbGekVB83r9KMCYIq2P1QXeMX25QmqvTU=.edb35293-fa11-4d7f-945d-9ec0ce0e2a31@github.com>
Message-ID: 

On Thu, 1 Feb 2024 20:10:29 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...
>
> Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision:
> 
>  - Merge branch 'master' into AlignedOffset
>  - Add api note pointing to alternatives for client that require non-plain access
>  - simplify spec for alignmentOffset and alignedSlice
>  - Merge note about misaligned access in byteBufferViewVarHandle
>  - updated alignedSlice implNote as well
>  - updated alignedOffset implNote
>  - Use ISE for bbvvh instead of UOE
>  - restore some tests for direct buffers
>  - fix BAVV and BBVV impl and tests
>  - regen test files
>  - ... and 1 more: https://git.openjdk.org/jdk/compare/1d01cf48...eccf4f41

I'll do one more batch of testing (after merging with the latest master) and then integrate

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

PR Comment: https://git.openjdk.org/jdk/pull/16681#issuecomment-1941613924

From alanb at openjdk.org  Tue Feb 13 14:47:12 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 13 Feb 2024 14:47:12 GMT
Subject: RFR: 8325590: Regression in round-tripping UTF-16 strings after
 JDK-8311906 [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 13 Feb 2024 12:47:26 GMT, Roger Riggs  wrote:

>> Correct the result string coder of a string encoded using a CharsetDecoder with multi-byte encoded input.
>> Added tests for UTF16 strings and a regression test.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test Files.readString with multiple charsets
>   Cleanup regression test to match style of other tests

Thanks for update, looks good.

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17817#pullrequestreview-1878145643

From redestad at openjdk.org  Tue Feb 13 14:53:53 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 13 Feb 2024 14:53:53 GMT
Subject: RFR: 8325590: Regression in round-tripping UTF-16 strings after
 JDK-8311906 [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 13 Feb 2024 12:47:26 GMT, Roger Riggs  wrote:

>> Correct the result string coder of a string encoded using a CharsetDecoder with multi-byte encoded input.
>> Added tests for UTF16 strings and a regression test.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test Files.readString with multiple charsets
>   Cleanup regression test to match style of other tests

Marked as reviewed by redestad (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17817#pullrequestreview-1878164294

From rriggs at openjdk.org  Tue Feb 13 15:20:08 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 13 Feb 2024 15:20:08 GMT
Subject: Integrated: 8325590: Regression in round-tripping UTF-16 strings after
 JDK-8311906
In-Reply-To: 
References: 
Message-ID: <12jt0yObhaZkFCwcAcXE-BiCrfwseiVubjAq2BynSd8=.8b6267fe-6bd8-41da-b643-e5b5159c10fd@github.com>

On Mon, 12 Feb 2024 21:29:02 GMT, Roger Riggs  wrote:

> Correct the result string coder of a string encoded using a CharsetDecoder with multi-byte encoded input.
> Added tests for UTF16 strings and a regression test.

This pull request has now been integrated.

Changeset: 13d9e8ff
Author:    Roger Riggs 
URL:       https://git.openjdk.org/jdk/commit/13d9e8ff38536287b82c54bb63bd2d20f65615dc
Stats:     39 lines in 2 files changed: 32 ins; 2 del; 5 mod

8325590: Regression in round-tripping UTF-16 strings after JDK-8311906

Reviewed-by: alanb, redestad

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

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

From rriggs at openjdk.org  Tue Feb 13 16:02:27 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 13 Feb 2024 16:02:27 GMT
Subject: [jdk22] RFR: 8325590: Regression in round-tripping UTF-16 strings
 after JDK-8311906
Message-ID: 

8325590: Regression in round-tripping UTF-16 strings after JDK-8311906

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

Commit messages:
 - Backport 13d9e8ff38536287b82c54bb63bd2d20f65615dc

Changes: https://git.openjdk.org/jdk22/pull/110/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk22&pr=110&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8325590
  Stats: 39 lines in 2 files changed: 32 ins; 2 del; 5 mod
  Patch: https://git.openjdk.org/jdk22/pull/110.diff
  Fetch: git fetch https://git.openjdk.org/jdk22.git pull/110/head:pull/110

PR: https://git.openjdk.org/jdk22/pull/110

From redestad at openjdk.org  Tue Feb 13 16:13:12 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 13 Feb 2024 16:13:12 GMT
Subject: RFR: 8325340: Add ASCII fast-path to Data-/ObjectInputStream.readUTF
Message-ID: 

Adding a fast-path for ASCII-only modified UTF-8 strings deserialied via Data- and ObjectInputStream

Testing: tier1-3

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

Commit messages:
 - Merge branch 'master' into io_utf8_fastpath
 - Reduce cost for small Strings in DataInputStream
 - Optimize away StringBuilder for strings smaller than CHAR_BUF_SIZE chars, add more micros, minor improvements
 - Sync up DataInputStreamTest to make results comparable with ObjectInputStreamTest, fix a buffer overrun issue in ObjectInputStream
 - Remove stray code
 - Clean up DataInputStream.readUTF/readUTFChars
 - Use ISO-8859-1 to avoid back-to-back countPositives scans
 - Rearrange JLA
 - Add ASCII fast-path to Data-/ObjectInputStream.readUTF

Changes: https://git.openjdk.org/jdk/pull/17734/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17734&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8325340
  Stats: 413 lines in 4 files changed: 375 ins; 15 del; 23 mod
  Patch: https://git.openjdk.org/jdk/pull/17734.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17734/head:pull/17734

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

From liach at openjdk.org  Tue Feb 13 16:13:12 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 13 Feb 2024 16:13:12 GMT
Subject: RFR: 8325340: Add ASCII fast-path to
 Data-/ObjectInputStream.readUTF
In-Reply-To: 
References: 
Message-ID: 

On Tue, 6 Feb 2024 16:17:21 GMT, Claes Redestad  wrote:

> Adding a fast-path for ASCII-only modified UTF-8 strings deserialied via Data- and ObjectInputStream
> 
> Testing: tier1-3

src/java.base/share/classes/java/io/ObjectInputStream.java line 3688:

> 3686:                         // avoid a redundant scan
> 3687:                         String utf = new String(buf, pos, (int)utflen, StandardCharsets.ISO_8859_1);
> 3688:                         pos += (int)utflen;

Suggestion:

                        String utf = new String(buf, pos, ascii, StandardCharsets.ISO_8859_1);
                        pos += ascii;

Redundant casts

src/java.base/share/classes/java/io/ObjectInputStream.java line 3746:

> 3744:             int avail = Math.min(end - pos, CHAR_BUF_SIZE);
> 3745:             // stop short of last char unless all of utf bytes in buffer
> 3746:             int stop = start + ((utflen > avail) ? avail - 2 : (int) utflen);

Though reading LV instead of getfield is an improvement, we probably prefer to keep this patch cleaner.

src/java.base/share/classes/java/nio/charset/Charset.java line 682:

> 680:                 else
> 681:                     defaultCharset = sun.nio.cs.UTF_8.INSTANCE;
> 682:                 Charset.forName("UTF-8");

Redundant debug code?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17734#discussion_r1480387150
PR Review Comment: https://git.openjdk.org/jdk/pull/17734#discussion_r1480389129
PR Review Comment: https://git.openjdk.org/jdk/pull/17734#discussion_r1480391246

From redestad at openjdk.org  Tue Feb 13 16:13:12 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 13 Feb 2024 16:13:12 GMT
Subject: RFR: 8325340: Add ASCII fast-path to
 Data-/ObjectInputStream.readUTF
In-Reply-To: 
References: 
Message-ID: 

On Tue, 6 Feb 2024 16:17:21 GMT, Claes Redestad  wrote:

> Adding a fast-path for ASCII-only modified UTF-8 strings deserialied via Data- and ObjectInputStream
> 
> Testing: tier1-3

Benchmark numbers

M1 MacBook:

Name                                        Cnt  Base   Error   Test   Error  Unit  Change
DataInputStreamTest.readUTFAsciiLarge        20 1,517 ? 0,018  1,052 ? 0,014 us/op   1,44x (p = 0,000*)
DataInputStreamTest.readUTFAsciiMixed        20 1,391 ? 0,012  1,034 ? 0,021 us/op   1,34x (p = 0,000*)
DataInputStreamTest.readUTFAsciiSmall        20 1,017 ? 0,019  1,007 ? 0,010 us/op   1,01x (p = 0,085 )
DataInputStreamTest.readUTFLarge             20 2,109 ? 0,032  2,025 ? 0,028 us/op   1,04x (p = 0,000*)
DataInputStreamTest.readUTFMixed             20 1,651 ? 0,085  1,615 ? 0,025 us/op   1,02x (p = 0,124 )
DataInputStreamTest.readUTFSmall             20 1,020 ? 0,015  1,021 ? 0,014 us/op   1,00x (p = 0,773 )
ObjectInputStreamTest.readUTFAsciiLarge      15 3,094 ? 0,064  1,070 ? 0,018 us/op   2,89x (p = 0,000*)
ObjectInputStreamTest.readUTFAsciiMixed      15 2,670 ? 0,062  0,779 ? 0,024 us/op   3,43x (p = 0,000*)
ObjectInputStreamTest.readUTFAsciiSmall      15 1,138 ? 0,037  0,594 ? 0,026 us/op   1,92x (p = 0,000*)
ObjectInputStreamTest.readUTFLarge           15 4,714 ? 0,049  3,040 ? 0,023 us/op   1,55x (p = 0,000*)
ObjectInputStreamTest.readUTFMixed           15 2,952 ? 0,032  2,358 ? 0,024 us/op   1,25x (p = 0,000*)
ObjectInputStreamTest.readUTFSmall           15 1,544 ? 0,169  1,259 ? 0,055 us/op   1,23x (p = 0,000*)
  * = significant
 ```
 
 Intel(R) Xeon(R) Platinum 8358 CPU @ 2.60GHz, Linux:
 ```
Name                                        Cnt   Base   Error    Test   Error  Unit  Change
DataInputStreamTest.readUTFAsciiLarge        20  2.827 ? 0.006   2.098 ? 0.016 us/op   1.35x (p = 0.000*)
DataInputStreamTest.readUTFAsciiMixed        20  2.453 ? 0.009   2.071 ? 0.010 us/op   1.18x (p = 0.000*)
DataInputStreamTest.readUTFAsciiSmall        20  1.957 ? 0.005   2.052 ? 0.015 us/op   0.95x (p = 0.000*)
DataInputStreamTest.readUTFLarge             20  4.339 ? 0.038   4.057 ? 0.017 us/op   1.07x (p = 0.000*)
DataInputStreamTest.readUTFMixed             20  3.494 ? 0.007   3.387 ? 0.042 us/op   1.03x (p = 0.000*)
DataInputStreamTest.readUTFSmall             20  2.257 ? 0.009   2.309 ? 0.016 us/op   0.98x (p = 0.000*)
ObjectInputStreamTest.readUTFAsciiLarge      15  5.056 ? 0.028   1.827 ? 0.021 us/op   2.77x (p = 0.000*)
ObjectInputStreamTest.readUTFAsciiMixed      15  3.492 ? 0.107   1.221 ? 0.011 us/op   2.86x (p = 0.000*)
ObjectInputStreamTest.readUTFAsciiSmall      15  1.651 ? 0.014   0.976 ? 0.018 us/op   1.69x (p = 0.000*)
ObjectInputStreamTest.readUTFLarge           15  9.741 ? 0.034   6.049 ? 0.039 us/op   1.61x (p = 0.000*)
ObjectInputStreamTest.readUTFMixed           15  5.786 ? 0.082   4.220 ? 0.008 us/op   1.37x (p = 0.000*)
ObjectInputStreamTest.readUTFSmall           15  2.219 ? 0.075   1.405 ? 0.013 us/op   1.58x (p = 0.000*)
  * = significant


For the `Small` variants of the `DataInputStream` the optimization doesn't pay off inputs less than 8 bytes. The added cost seen here is due the increased code complexity and an added branch, without the `utflen > 7` checks the `readUTFSmall` (slow-path test) would score 0.6-0.7x which was unacceptable.

For the `ObjectInputStream` case the fast-path additionally helps avoid the need for a `StringBuilder` if the byte length of the UTF record fits in the shared `char[]`.

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

PR Comment: https://git.openjdk.org/jdk/pull/17734#issuecomment-1930221329

From redestad at openjdk.org  Tue Feb 13 16:13:12 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 13 Feb 2024 16:13:12 GMT
Subject: RFR: 8325340: Add ASCII fast-path to
 Data-/ObjectInputStream.readUTF
In-Reply-To: 
References: 
 
Message-ID: <7YF7_pI-7BKuDGWGHOJMANhn7Avv3Kvnxr55dm4XZAc=.6937ce45-2d81-4dec-860c-992ec288386c@github.com>

On Tue, 6 Feb 2024 18:40:20 GMT, Chen Liang  wrote:

>> Adding a fast-path for ASCII-only modified UTF-8 strings deserialied via Data- and ObjectInputStream
>> 
>> Testing: tier1-3
>
> src/java.base/share/classes/java/io/ObjectInputStream.java line 3688:
> 
>> 3686:                         // avoid a redundant scan
>> 3687:                         String utf = new String(buf, pos, (int)utflen, StandardCharsets.ISO_8859_1);
>> 3688:                         pos += (int)utflen;
> 
> Suggestion:
> 
>                         String utf = new String(buf, pos, ascii, StandardCharsets.ISO_8859_1);
>                         pos += ascii;
> 
> Redundant casts

I get warnings and build failures if I leave out those casts (`utflen` is a `long`)

> src/java.base/share/classes/java/nio/charset/Charset.java line 682:
> 
>> 680:                 else
>> 681:                     defaultCharset = sun.nio.cs.UTF_8.INSTANCE;
>> 682:                 Charset.forName("UTF-8");
> 
> Redundant debug code?

Yes, accidentally included here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17734#discussion_r1480406485
PR Review Comment: https://git.openjdk.org/jdk/pull/17734#discussion_r1480404260

From liach at openjdk.org  Tue Feb 13 16:13:12 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 13 Feb 2024 16:13:12 GMT
Subject: RFR: 8325340: Add ASCII fast-path to
 Data-/ObjectInputStream.readUTF
In-Reply-To: <7YF7_pI-7BKuDGWGHOJMANhn7Avv3Kvnxr55dm4XZAc=.6937ce45-2d81-4dec-860c-992ec288386c@github.com>
References: 
 
 <7YF7_pI-7BKuDGWGHOJMANhn7Avv3Kvnxr55dm4XZAc=.6937ce45-2d81-4dec-860c-992ec288386c@github.com>
Message-ID: <7EY1lQA_fbDNsmt-JxKxElo9BvWxh9IlUDSE_h_qlT0=.cdd57ff6-9900-40ef-baa9-0f6392f7b54d@github.com>

On Tue, 6 Feb 2024 18:58:01 GMT, Claes Redestad  wrote:

>> src/java.base/share/classes/java/io/ObjectInputStream.java line 3688:
>> 
>>> 3686:                         // avoid a redundant scan
>>> 3687:                         String utf = new String(buf, pos, (int)utflen, StandardCharsets.ISO_8859_1);
>>> 3688:                         pos += (int)utflen;
>> 
>> Suggestion:
>> 
>>                         String utf = new String(buf, pos, ascii, StandardCharsets.ISO_8859_1);
>>                         pos += ascii;
>> 
>> Redundant casts
>
> I get warnings and build failures if I leave out those casts (`utflen` is a `long`)

Ah, I meant to use the equivalent local variable int ascii, the return value of countPositives, to avoid these casts.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17734#discussion_r1480639568

From alanb at openjdk.org  Tue Feb 13 16:14:04 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 13 Feb 2024 16:14:04 GMT
Subject: [jdk22] RFR: 8325590: Regression in round-tripping UTF-16 strings
 after JDK-8311906
In-Reply-To: 
References: 
Message-ID: 

On Tue, 13 Feb 2024 15:57:31 GMT, Roger Riggs  wrote:

> 8325590: Regression in round-tripping UTF-16 strings after JDK-8311906

Marked as reviewed by alanb (Reviewer).

This is for jdk22u, not jdk22

This is for jdk22u, not jdk22

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

PR Review: https://git.openjdk.org/jdk22/pull/110#pullrequestreview-1878383225
PR Review: https://git.openjdk.org/jdk22/pull/110#pullrequestreview-1878385355
Changes requested by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk22/pull/110#pullrequestreview-1878386430

From kcr at openjdk.org  Tue Feb 13 16:14:05 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 13 Feb 2024 16:14:05 GMT
Subject: [jdk22] RFR: 8325590: Regression in round-tripping UTF-16 strings
 after JDK-8311906
In-Reply-To: 
References: 
Message-ID: 

On Tue, 13 Feb 2024 15:57:31 GMT, Roger Riggs  wrote:

> 8325590: Regression in round-tripping UTF-16 strings after JDK-8311906

@RogerRiggs Since this is deferred out of JDK 22, you need to close this PR and open a new one against jdk22u.

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

PR Comment: https://git.openjdk.org/jdk22/pull/110#issuecomment-1941908401

From kcr at openjdk.org  Tue Feb 13 16:14:05 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 13 Feb 2024 16:14:05 GMT
Subject: [jdk22] RFR: 8325590: Regression in round-tripping UTF-16 strings
 after JDK-8311906
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 13 Feb 2024 16:09:04 GMT, Alan Bateman  wrote:

>> 8325590: Regression in round-tripping UTF-16 strings after JDK-8311906
>
> This is for jdk22u, not jdk22

@AlanBateman You might want to unapprove this PR (go to "Files" and submit a review with "Request Changes")

UPDATE: I see you already did.

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

PR Comment: https://git.openjdk.org/jdk22/pull/110#issuecomment-1941917372

From rriggs at openjdk.org  Tue Feb 13 16:18:08 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 13 Feb 2024 16:18:08 GMT
Subject: [jdk22] RFR: 8325590: Regression in round-tripping UTF-16 strings
 after JDK-8311906
In-Reply-To: 
References: 
Message-ID: 

On Tue, 13 Feb 2024 15:57:31 GMT, Roger Riggs  wrote:

> 8325590: Regression in round-tripping UTF-16 strings after JDK-8311906

The backport was intended to be for jdk22u

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

PR Comment: https://git.openjdk.org/jdk22/pull/110#issuecomment-1941927141

From rriggs at openjdk.org  Tue Feb 13 16:18:08 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 13 Feb 2024 16:18:08 GMT
Subject: [jdk22] Withdrawn: 8325590: Regression in round-tripping UTF-16
 strings after JDK-8311906
In-Reply-To: 
References: 
Message-ID: 

On Tue, 13 Feb 2024 15:57:31 GMT, Roger Riggs  wrote:

> 8325590: Regression in round-tripping UTF-16 strings after JDK-8311906

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.org/jdk22/pull/110

From eirbjo at openjdk.org  Tue Feb 13 16:21:59 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Tue, 13 Feb 2024 16:21:59 GMT
Subject: Integrated: 8303891: Speed up Zip64SizeTest using a small ZIP64 file
In-Reply-To: 
References: 
Message-ID: 

On Thu, 9 Mar 2023 12:06:52 GMT, Eirik Bj?rsn?s  wrote:

> Please review this PR which suggests we speed up the `Zip64SizeTest` using a small-sized ZIP64 ZIP file specifically created to reproduce the issue being tested.
> 
> The disk space requirement of this test is known to cause problems in some builds, see [JDK-8259866](https://bugs.openjdk.org/browse/JDK-8259866)
> 
> By using a sparse file, we reduce consumed disk space from 5GB to 266 bytes and also reduce the runtime from ~35 seconds to ~1 seconds on my Macbook Pro.
> 
> The PR also fixes the `@summary` tag, which seems to have been copied from an unrelated test.

This pull request has now been integrated.

Changeset: 842b895f
Author:    Eirik Bj?rsn?s 
URL:       https://git.openjdk.org/jdk/commit/842b895f093e15ecd8aa0153d712f5f81cf1cf67
Stats:     147 lines in 1 file changed: 75 ins; 10 del; 62 mod

8303891: Speed up Zip64SizeTest using a small ZIP64 file
8259866: two java.util tests failed with "IOException: There is not enough space on the disk"

Reviewed-by: lancea, jpai

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

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

From eirbjo at openjdk.org  Tue Feb 13 16:30:19 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Tue, 13 Feb 2024 16:30:19 GMT
Subject: RFR: 8303866: Allow ZipInputStream.readEnd to parse small Zip64
 ZIP files [v15]
In-Reply-To: <5B5-e-8xUHT4BW8Fl_uVwY7QYeuHblLj1Y1j48HokjI=.02468581-c036-4a97-88e1-f24a536a3962@github.com>
References: 
 
 
 <5B5-e-8xUHT4BW8Fl_uVwY7QYeuHblLj1Y1j48HokjI=.02468581-c036-4a97-88e1-f24a536a3962@github.com>
Message-ID: 

On Fri, 26 Jan 2024 20:49:57 GMT, Lance Andersen  wrote:

>> To help make progress here, I have relaxed the validation such that we now check:
>> 
>> - That the "streaming mode" bit 3 flag is set
>> - That at least one of the LOC's size fields are marked 0xFFFFFFFF.
>> - That the LOC extra field has a field with header ID 0x1 (Zip64)
>> 
>> Any reading/validation of the contents of the Zip64 extra field has been removed.
>> 
>> @jaikiran Is this closer to what you'd like to see?
>
>> To help make progress here, I have relaxed the validation such that we now check:
>> 
>> * That the "streaming mode" bit 3 flag is set
>> * That at least one of the LOC's size fields are marked 0xFFFFFFFF.
>> * That the LOC extra field has a field with header ID 0x1 (Zip64)
>> 
>> Any reading/validation of the contents of the Zip64 extra field has been removed.
>> 
>> @jaikiran Is this closer to what you'd like to see?
> 
> Have not forgotten this, hope to get to it next week

Thanks @LanceAndersen, @jaikiran and @AlanBateman for your helpful and patient guidance.

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

PR Comment: https://git.openjdk.org/jdk/pull/12524#issuecomment-1941945147

From eirbjo at openjdk.org  Tue Feb 13 16:30:19 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Tue, 13 Feb 2024 16:30:19 GMT
Subject: Integrated: 8303866: Allow ZipInputStream.readEnd to parse small Zip64
 ZIP files
In-Reply-To: 
References: 
Message-ID: 

On Sun, 12 Feb 2023 15:41:55 GMT, Eirik Bj?rsn?s  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 AND at least one of the 'compressed size' and 'uncompressed size' have the expected Zip64 "magic" value 0xFFFFFFFF. 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.

This pull request has now been integrated.

Changeset: 628cd8a4
Author:    Eirik Bj?rsn?s 
URL:       https://git.openjdk.org/jdk/commit/628cd8a489fd54db18204c3bbaf4339d7ab5e9d6
Stats:     341 lines in 2 files changed: 338 ins; 0 del; 3 mod

8303866: Allow ZipInputStream.readEnd to parse small Zip64 ZIP files

Reviewed-by: lancea, jpai

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

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

From prappo at openjdk.org  Tue Feb 13 16:39:05 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 13 Feb 2024 16:39:05 GMT
Subject: RFR: JDK-8323760 putIfAbsent documentation conflicts with itself
In-Reply-To: 
References: 
Message-ID: 

On Tue, 16 Jan 2024 07:40:44 GMT, John Hendrikx  wrote:

> Update the documentation for `@return` tag of `putIfAbsent` to match the main description. `putIfAbsent` uses the same wording as `put` for its `@return` tag, but that is incorrect.  `putIfAbsent` never returns the **previous** value, as the whole point of the method is not the replace the value if it was present.  As such, if it returns a value, it is the **current** value, and in all other cases it will return `null`.

@hjohn, I think this PR is worth pursuing. I again pinged those who might help you see this through.

I generally note that the phrase "current value", which is used in some Map methods that take a value argument, sounds a bit ambiguous to my non-native English speaker's ear. "Current value" might be confused with the passed value. "Associated", "currently mapped",  might be better.

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

PR Comment: https://git.openjdk.org/jdk/pull/17438#issuecomment-1941964756

From dlutker at openjdk.org  Tue Feb 13 17:03:55 2024
From: dlutker at openjdk.org (Dan Lutker)
Date: Tue, 13 Feb 2024 17:03:55 GMT
Subject: RFR: 8325576: java/lang/ProcessHandle/InfoTest.java fails on
 systems with coreutils with --enable-single-binary
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 13 Feb 2024 10:11:36 GMT, Aleksey Shipilev  wrote:

>> Ran the test on AmazonLinux 2 which has multiple binaries from coreutils package and no coreutils executable as well as AmazonLinux 2023 that uses `--enable-single-binary`
>
> test/jdk/java/lang/ProcessHandle/InfoTest.java line 321:
> 
>> 319:                     String[] args = info.arguments().get();
>> 320:                     if (args.length > 0) {
>> 321:                         if (timeIsLastParam) {
> 
> I gotta ask: is it true that time argument is the last param in _all_ testing modes? If so, we don't need `timeIsLastParam` at all?

Hah, yes. I was trying too hard to not change the default behavior.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17798#discussion_r1488259691

From jhendrikx at openjdk.org  Tue Feb 13 17:11:05 2024
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Tue, 13 Feb 2024 17:11:05 GMT
Subject: RFR: JDK-8323760 putIfAbsent documentation conflicts with itself
 [v2]
In-Reply-To: 
References: 
Message-ID: 

> Update the documentation for `@return` tag of `putIfAbsent` to match the main description. `putIfAbsent` uses the same wording as `put` for its `@return` tag, but that is incorrect.  `putIfAbsent` never returns the **previous** value, as the whole point of the method is not the replace the value if it was present.  As such, if it returns a value, it is the **current** value, and in all other cases it will return `null`.

John Hendrikx has updated the pull request incrementally with four additional commits since the last revision:

 - Add code block around argument
 - Reword
 - Reword to use put's previous value wording
 - Reword more clearly

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17438/files
  - new: https://git.openjdk.org/jdk/pull/17438/files/81276376..3621be54

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

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

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

From jhendrikx at openjdk.org  Tue Feb 13 17:11:05 2024
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Tue, 13 Feb 2024 17:11:05 GMT
Subject: RFR: JDK-8323760 putIfAbsent documentation conflicts with itself
 [v2]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Tue, 16 Jan 2024 13:27:31 GMT, Chen Liang  wrote:

>> Yeah, I wasn't sure about that, I can make it more specific, I used `considered` here because both unmapped keys and keys mapped to `null` are considered to be absent.
>
> I think `absent or {@code null}` is no less concise yet it is way more accurate than `considered absent`. So something like `@return {@code null} if the mapping for the specified key is absent or has a {@code null} value`?

I used your wording @liach but changed the sentence to past tense.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17438#discussion_r1488255726

From rriggs at openjdk.org  Tue Feb 13 17:56:53 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 13 Feb 2024 17:56:53 GMT
Subject: RFR: 8325576: java/lang/ProcessHandle/InfoTest.java fails on
 systems with coreutils with --enable-single-binary
In-Reply-To: 
References: 
Message-ID: 

On Fri, 9 Feb 2024 23:40:00 GMT, Dan Lutker  wrote:

> Ran the test on AmazonLinux 2 which has multiple binaries from coreutils package and no coreutils executable as well as AmazonLinux 2023 that uses `--enable-single-binary`

test/lib/jdk/test/lib/Platform.java line 145:

> 143:     }
> 144: 
> 145:     public static boolean isOSX() {

This seems like a real hack. Is there really no better way to identity how sleep is implemented.
I'd probably favor an alternative that accepts multiple values for the expected value.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17798#discussion_r1488338803

From dlutker at openjdk.org  Tue Feb 13 18:03:14 2024
From: dlutker at openjdk.org (Dan Lutker)
Date: Tue, 13 Feb 2024 18:03:14 GMT
Subject: RFR: 8325576: java/lang/ProcessHandle/InfoTest.java fails on
 systems with coreutils with --enable-single-binary [v2]
In-Reply-To: 
References: 
Message-ID: 

> Ran the test on AmazonLinux 2 which has multiple binaries from coreutils package and no coreutils executable as well as AmazonLinux 2023 that uses `--enable-single-binary`

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

  Remove unnecessary var.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17798/files
  - new: https://git.openjdk.org/jdk/pull/17798/files/986d35f5..3f42d85e

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

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

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

From duke at openjdk.org  Tue Feb 13 18:11:04 2024
From: duke at openjdk.org (Bernd)
Date: Tue, 13 Feb 2024 18:11:04 GMT
Subject: RFR: 8325576: java/lang/ProcessHandle/InfoTest.java fails on
 systems with coreutils with --enable-single-binary [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 13 Feb 2024 17:54:43 GMT, Roger Riggs  wrote:

>> Dan Lutker has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove unnecessary var.
>
> test/lib/jdk/test/lib/Platform.java line 145:
> 
>> 143:     }
>> 144: 
>> 145:     public static boolean isOSX() {
> 
> This seems like a real hack. Is there really no better way to identity how sleep is implemented.
> I'd probably favor an alternative that accepts multiple values for the expected value.

Just ignore the binary name and only check for argv1 is imho enough.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17798#discussion_r1488357647

From dlutker at openjdk.org  Tue Feb 13 18:18:53 2024
From: dlutker at openjdk.org (Dan Lutker)
Date: Tue, 13 Feb 2024 18:18:53 GMT
Subject: RFR: 8325576: java/lang/ProcessHandle/InfoTest.java fails on
 systems with coreutils with --enable-single-binary [v2]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Tue, 13 Feb 2024 18:08:03 GMT, Bernd  wrote:

>> test/lib/jdk/test/lib/Platform.java line 145:
>> 
>>> 143:     }
>>> 144: 
>>> 145:     public static boolean isOSX() {
>> 
>> This seems like a real hack. Is there really no better way to identity how sleep is implemented.
>> I'd probably favor an alternative that accepts multiple values for the expected value.
>
> Just ignore the binary name and only check for argv1 is imho enough.

I couldn't think if a better way to detect what the host system had and adding this seemed inline with the busybox check. 

The choice of running `sleep` seems like it was arbitrary and the test should use something that is under JDK control rather than a platform specific tool that can change from distro to distro. Is there any reason we don't use the `java`, something else in the image, or even something built as part of the test-image.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17798#discussion_r1488368949

From shade at openjdk.org  Tue Feb 13 18:22:53 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 13 Feb 2024 18:22:53 GMT
Subject: RFR: 8325576: java/lang/ProcessHandle/InfoTest.java fails on
 systems with coreutils with --enable-single-binary [v2]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Tue, 13 Feb 2024 18:15:59 GMT, Dan Lutker  wrote:

>> Just ignore the binary name and only check for argv1 is imho enough.
>
> I couldn't think if a better way to detect what the host system had and adding this seemed inline with the busybox check. 
> 
> The choice of running `sleep` seems like it was arbitrary and the test should use something that is under JDK control rather than a platform specific tool that can change from distro to distro. Is there any reason we don't use the `java`, something else in the image, or even something built as part of the test-image.

To be fair, this looks similar to what `isMusl()` does: searching for strings in outputs. But I do wonder if `--help` would include "sleep" for some innocuous description somewhere, and this code would accidentally match. @lutkerd, what's the output for `coreutils --help` for a single executable binary?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17798#discussion_r1488374538

From dlutker at openjdk.org  Tue Feb 13 18:26:54 2024
From: dlutker at openjdk.org (Dan Lutker)
Date: Tue, 13 Feb 2024 18:26:54 GMT
Subject: RFR: 8325576: java/lang/ProcessHandle/InfoTest.java fails on
 systems with coreutils with --enable-single-binary [v2]
In-Reply-To: 
References: 
 
 
 
 
Message-ID: <8bH-nWhM3TbK68Pt5wOjoPzc5bc81VQ-rY3dMBeYE3o=.ee389cb7-46d5-48e6-a547-3cf9fa07b0ff@github.com>

On Tue, 13 Feb 2024 18:19:48 GMT, Aleksey Shipilev  wrote:

> what's the output for `coreutils --help` for a single executable binary?


# coreutils --help
Usage: coreutils --coreutils-prog=PROGRAM_NAME [PARAMETERS]... 
Execute the PROGRAM_NAME built-in program with the given PARAMETERS.

      --help     display this help and exit
      --version  output version information and exit

Built-in programs:
 [ arch b2sum base32 base64 basename basenc cat chcon chgrp chmod chown chroot cksum comm cp csplit cut date dd df dir dircolors dirname du echo env expand expr factor false fmt fold ginstall groups head hostid id join link ln logname ls md5sum mkdir mkfifo mknod mktemp mv nice nl nohup nproc numfmt od paste pathchk pinky pr printenv printf ptx pwd readlink realpath rm rmdir runcon seq sha1sum sha224sum sha256sum sha384sum sha512sum shred shuf sleep sort split stat stdbuf stty sum sync tac tail tee test timeout touch tr true truncate tsort tty uname unexpand uniq unlink users vdir wc who whoami yes

Use: 'coreutils --coreutils-prog=PROGRAM_NAME --help' for individual program help.

GNU coreutils online help: 
Report any translation bugs to 
Full documentation 
or available locally via: info '(coreutils) Multi-call invocation'


This test is about parameter checking, so I am inclined to agree with @ecki and not check the process name or change the exe.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17798#discussion_r1488380807

From rriggs at openjdk.org  Tue Feb 13 19:26:52 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 13 Feb 2024 19:26:52 GMT
Subject: RFR: 8325576: java/lang/ProcessHandle/InfoTest.java fails on
 systems with coreutils with --enable-single-binary [v2]
In-Reply-To: <8bH-nWhM3TbK68Pt5wOjoPzc5bc81VQ-rY3dMBeYE3o=.ee389cb7-46d5-48e6-a547-3cf9fa07b0ff@github.com>
References: 
 
 
 
 
 <8bH-nWhM3TbK68Pt5wOjoPzc5bc81VQ-rY3dMBeYE3o=.ee389cb7-46d5-48e6-a547-3cf9fa07b0ff@github.com>
Message-ID: 

On Tue, 13 Feb 2024 18:24:10 GMT, Dan Lutker  wrote:

>> To be fair, this looks similar to what `isMusl()` does: searching for strings in outputs. But I do wonder if `--help` would include "sleep" for some innocuous description somewhere, and this code would accidentally match. @lutkerd, what's the output for `coreutils --help` for a single executable binary?
>
>> what's the output for `coreutils --help` for a single executable binary?
> 
> 
> # coreutils --help
> Usage: coreutils --coreutils-prog=PROGRAM_NAME [PARAMETERS]... 
> Execute the PROGRAM_NAME built-in program with the given PARAMETERS.
> 
>       --help     display this help and exit
>       --version  output version information and exit
> 
> Built-in programs:
>  [ arch b2sum base32 base64 basename basenc cat chcon chgrp chmod chown chroot cksum comm cp csplit cut date dd df dir dircolors dirname du echo env expand expr factor false fmt fold ginstall groups head hostid id join link ln logname ls md5sum mkdir mkfifo mknod mktemp mv nice nl nohup nproc numfmt od paste pathchk pinky pr printenv printf ptx pwd readlink realpath rm rmdir runcon seq sha1sum sha224sum sha256sum sha384sum sha512sum shred shuf sleep sort split stat stdbuf stty sum sync tac tail tee test timeout touch tr true truncate tsort tty uname unexpand uniq unlink users vdir wc who whoami yes
> 
> Use: 'coreutils --coreutils-prog=PROGRAM_NAME --help' for individual program help.
> 
> GNU coreutils online help: 
> Report any translation bugs to 
> Full documentation 
> or available locally via: info '(coreutils) Multi-call invocation'
> 
> 
> This test is about parameter checking, so I am inclined to agree with @ecki and not check the process name or change the exe.

At the time `sleep` seemed ubiquitous and was native so it ran quickly. (Much quicker than running java).
Running another program would be fine.  For example ,selecting an executable based on the OS type and giving the expected string in the output would be preferred.
The isBusyBox check is also a bad hack, but lighter weight since its not executing a program.
As the number of minor variations of platforms appear a more general approach would be useful.

I'd code it all in the test itself, doing a lookup based on the operating system name with the respective executable and expected string in the info arguments[0].
(With a fallback to sleep, so the table does not have to list every os).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17798#discussion_r1488468243

From brian.burkhalter at oracle.com  Tue Feb 13 20:25:11 2024
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Tue, 13 Feb 2024 20:25:11 +0000
Subject: CFV: New Core Libraries Group Member: Raffaello Giulietti
Message-ID: <14851B34-A785-4389-9C23-056B8C7E0D7C@oracle.com>

I hereby nominate Raffaello Giulietti to Membership in the Core Libraries Group.

Raffaello has been working in the Core Library team at Oracle since April, 2022. He has authored more than 50 contributions to OpenJDK in a number of areas including numerics, formatting, regular expressions, and random number generation. 

Votes are due by Wednesday, February 28, 2023.

Only current Members of the Core Libraries Group [1] are eligible
to vote on this nomination.  Votes must be cast in the open by
replying to this mailing list

For Lazy Consensus voting instructions, see [2].

Brian Burkhalter

[1] https://openjdk.org/census#core-libs
[2] https://openjdk.org/groups/#member-vote

From lance.andersen at oracle.com  Tue Feb 13 20:33:22 2024
From: lance.andersen at oracle.com (Lance Andersen)
Date: Tue, 13 Feb 2024 20:33:22 +0000
Subject: CFV: New Core Libraries Group Member: Raffaello Giulietti
In-Reply-To: <14851B34-A785-4389-9C23-056B8C7E0D7C@oracle.com>
References: <14851B34-A785-4389-9C23-056B8C7E0D7C@oracle.com>
Message-ID: 

Vote: yes

On Feb 13, 2024, at 3:25?PM, Brian Burkhalter  wrote:

I hereby nominate Raffaello Giulietti to Membership in the Core Libraries Group.

Raffaello has been working in the Core Library team at Oracle since April, 2022. He has authored more than 50 contributions to OpenJDK in a number of areas including numerics, formatting, regular expressions, and random number generation.

Votes are due by Wednesday, February 28, 2023.

Only current Members of the Core Libraries Group [1] are eligible
to vote on this nomination.  Votes must be cast in the open by
replying to this mailing list

For Lazy Consensus voting instructions, see [2].

Brian Burkhalter

[1] https://openjdk.org/census#core-libs
[2] https://openjdk.org/groups/#member-vote

[oracle_sig_logo.gif]






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 naoto.sato at oracle.com  Tue Feb 13 20:35:13 2024
From: naoto.sato at oracle.com (Naoto Sato)
Date: Tue, 13 Feb 2024 12:35:13 -0800
Subject: CFV: New Core Libraries Group Member: Raffaello Giulietti
In-Reply-To: <14851B34-A785-4389-9C23-056B8C7E0D7C@oracle.com>
References: <14851B34-A785-4389-9C23-056B8C7E0D7C@oracle.com>
Message-ID: 

Vote: yes

Naoto

On 2/13/24 12:25 PM, Brian Burkhalter wrote:
> I hereby nominate Raffaello Giulietti to Membership in the Core Libraries Group.
> 
> Raffaello has been working in the Core Library team at Oracle since April, 2022. He has authored more than 50 contributions to OpenJDK in a number of areas including numerics, formatting, regular expressions, and random number generation.
> 
> Votes are due by Wednesday, February 28, 2023.
> 
> Only current Members of the Core Libraries Group [1] are eligible
> to vote on this nomination.  Votes must be cast in the open by
> replying to this mailing list
> 
> For Lazy Consensus voting instructions, see [2].
> 
> Brian Burkhalter
> 
> [1] https://openjdk.org/census#core-libs
> [2] https://openjdk.org/groups/#member-vote

From roger.riggs at oracle.com  Tue Feb 13 20:36:02 2024
From: roger.riggs at oracle.com (Roger Riggs)
Date: Tue, 13 Feb 2024 15:36:02 -0500
Subject: CFV: New Core Libraries Group Member: Raffaello Giulietti
In-Reply-To: <14851B34-A785-4389-9C23-056B8C7E0D7C@oracle.com>
References: <14851B34-A785-4389-9C23-056B8C7E0D7C@oracle.com>
Message-ID: <717c789d-2092-4102-8a4b-041e101efff5@oracle.com>

Vote: Yes

On 2/13/24 3:25 PM, Brian Burkhalter wrote:
> I hereby nominate Raffaello Giulietti to Membership in the Core 
> Libraries Group.


From huizhe.wang at oracle.com  Tue Feb 13 20:52:30 2024
From: huizhe.wang at oracle.com (Joe Wang)
Date: Tue, 13 Feb 2024 12:52:30 -0800
Subject: CFV: New Core Libraries Group Member: Raffaello Giulietti
In-Reply-To: <14851B34-A785-4389-9C23-056B8C7E0D7C@oracle.com>
References: <14851B34-A785-4389-9C23-056B8C7E0D7C@oracle.com>
Message-ID: <31f9d2df-b8b1-45c1-97fd-3c743433911f@oracle.com>

Vote: yes

Joe (joehw)

On 2/13/24 12:25 PM, Brian Burkhalter wrote:
> I hereby nominate Raffaello Giulietti to Membership in the Core Libraries Group.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From joe.darcy at oracle.com  Tue Feb 13 21:17:08 2024
From: joe.darcy at oracle.com (Joseph D. Darcy)
Date: Tue, 13 Feb 2024 13:17:08 -0800
Subject: CFV: New Core Libraries Group Member: Raffaello Giulietti
In-Reply-To: <14851B34-A785-4389-9C23-056B8C7E0D7C@oracle.com>
References: <14851B34-A785-4389-9C23-056B8C7E0D7C@oracle.com>
Message-ID: <2323fdf3-e49f-4ca1-82ae-e016bb45efb2@oracle.com>

Vote: yes

-Joe

On 2/13/2024 12:25 PM, Brian Burkhalter wrote:
> I hereby nominate Raffaello Giulietti to Membership in the Core Libraries Group.
>
> Raffaello has been working in the Core Library team at Oracle since April, 2022. He has authored more than 50 contributions to OpenJDK in a number of areas including numerics, formatting, regular expressions, and random number generation.
>
> Votes are due by Wednesday, February 28, 2023.
>
> Only current Members of the Core Libraries Group [1] are eligible
> to vote on this nomination.  Votes must be cast in the open by
> replying to this mailing list
>
> For Lazy Consensus voting instructions, see [2].
>
> Brian Burkhalter
>
> [1] https://openjdk.org/census#core-libs
> [2] https://openjdk.org/groups/#member-vote

From iris.clark at oracle.com  Tue Feb 13 21:23:36 2024
From: iris.clark at oracle.com (Iris Clark)
Date: Tue, 13 Feb 2024 21:23:36 +0000
Subject: CFV: New Core Libraries Group Member: Raffaello Giulietti
In-Reply-To: <14851B34-A785-4389-9C23-056B8C7E0D7C@oracle.com>
References: <14851B34-A785-4389-9C23-056B8C7E0D7C@oracle.com>
Message-ID: 

Vote: yes

Iris

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

From dlutker at openjdk.org  Tue Feb 13 21:26:07 2024
From: dlutker at openjdk.org (Dan Lutker)
Date: Tue, 13 Feb 2024 21:26:07 GMT
Subject: RFR: 8325576: java/lang/ProcessHandle/InfoTest.java fails on
 systems with coreutils with --enable-single-binary [v2]
In-Reply-To: 
References: 
 
 
 
 
 <8bH-nWhM3TbK68Pt5wOjoPzc5bc81VQ-rY3dMBeYE3o=.ee389cb7-46d5-48e6-a547-3cf9fa07b0ff@github.com>
 
Message-ID: <46wD8xd0OIGGfHW5aexaJ7fzHSlUIxF6RkQnaCrrRn8=.6f968e71-4bf2-4d47-8d10-6acec20596bd@github.com>

On Tue, 13 Feb 2024 19:23:50 GMT, Roger Riggs  wrote:

>>> what's the output for `coreutils --help` for a single executable binary?
>> 
>> 
>> # coreutils --help
>> Usage: coreutils --coreutils-prog=PROGRAM_NAME [PARAMETERS]... 
>> Execute the PROGRAM_NAME built-in program with the given PARAMETERS.
>> 
>>       --help     display this help and exit
>>       --version  output version information and exit
>> 
>> Built-in programs:
>>  [ arch b2sum base32 base64 basename basenc cat chcon chgrp chmod chown chroot cksum comm cp csplit cut date dd df dir dircolors dirname du echo env expand expr factor false fmt fold ginstall groups head hostid id join link ln logname ls md5sum mkdir mkfifo mknod mktemp mv nice nl nohup nproc numfmt od paste pathchk pinky pr printenv printf ptx pwd readlink realpath rm rmdir runcon seq sha1sum sha224sum sha256sum sha384sum sha512sum shred shuf sleep sort split stat stdbuf stty sum sync tac tail tee test timeout touch tr true truncate tsort tty uname unexpand uniq unlink users vdir wc who whoami yes
>> 
>> Use: 'coreutils --coreutils-prog=PROGRAM_NAME --help' for individual program help.
>> 
>> GNU coreutils online help: 
>> Report any translation bugs to 
>> Full documentation 
>> or available locally via: info '(coreutils) Multi-call invocation'
>> 
>> 
>> This test is about parameter checking, so I am inclined to agree with @ecki and not check the process name or change the exe.
>
> At the time `sleep` seemed ubiquitous and was native so it ran quickly. (Much quicker than running java).
> Running another program would be fine.  For example ,selecting an executable based on the OS type and giving the expected string in the output would be preferred.
> The isBusyBox check is also a bad hack, but lighter weight since its not executing a program.
> As the number of minor variations of platforms appear a more general approach would be useful.
> 
> I'd code it all in the test itself, doing a lookup based on the operating system name with the respective executable and expected string in the info arguments[0].
> (With a fallback to sleep, so the table does not have to list every os).

Any reason not to use [exesanity_SimpleNativeLauncher](https://github.com/openjdk/jdk/blob/628cd8a489fd54db18204c3bbaf4339d7ab5e9d6/test/jdk/native_sanity/simplenativelauncher/exesanity_SimpleNativeLauncher.c) or [exeBasicSleep](https://github.com/openjdk/jdk/blob/628cd8a489fd54db18204c3bbaf4339d7ab5e9d6/test/jdk/java/lang/ProcessBuilder/exeBasicSleep.c) in all cases?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17798#discussion_r1488594104

From james.laskey at oracle.com  Tue Feb 13 21:27:28 2024
From: james.laskey at oracle.com (Jim Laskey)
Date: Tue, 13 Feb 2024 21:27:28 +0000
Subject: CFV: New Core Libraries Group Member: Raffaello Giulietti
In-Reply-To: <14851B34-A785-4389-9C23-056B8C7E0D7C@oracle.com>
References: <14851B34-A785-4389-9C23-056B8C7E0D7C@oracle.com>
Message-ID: 

Vote: yes
?

> On Feb 13, 2024, at 4:25?PM, Brian Burkhalter  wrote:
> 
> ?I hereby nominate Raffaello Giulietti to Membership in the Core Libraries Group.
> 
> Raffaello has been working in the Core Library team at Oracle since April, 2022. He has authored more than 50 contributions to OpenJDK in a number of areas including numerics, formatting, regular expressions, and random number generation.
> 
> Votes are due by Wednesday, February 28, 2023.
> 
> Only current Members of the Core Libraries Group [1] are eligible
> to vote on this nomination.  Votes must be cast in the open by
> replying to this mailing list
> 
> For Lazy Consensus voting instructions, see [2].
> 
> Brian Burkhalter
> 
> [1] https://openjdk.org/census#core-libs
> [2] https://openjdk.org/groups/#member-vote

From redestad at openjdk.org  Tue Feb 13 21:36:03 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 13 Feb 2024 21:36:03 GMT
Subject: RFR: 8325340: Add ASCII fast-path to
 Data-/ObjectInputStream.readUTF
In-Reply-To: <7EY1lQA_fbDNsmt-JxKxElo9BvWxh9IlUDSE_h_qlT0=.cdd57ff6-9900-40ef-baa9-0f6392f7b54d@github.com>
References: 
 
 <7YF7_pI-7BKuDGWGHOJMANhn7Avv3Kvnxr55dm4XZAc=.6937ce45-2d81-4dec-860c-992ec288386c@github.com>
 <7EY1lQA_fbDNsmt-JxKxElo9BvWxh9IlUDSE_h_qlT0=.cdd57ff6-9900-40ef-baa9-0f6392f7b54d@github.com>
Message-ID: 

On Tue, 6 Feb 2024 23:01:07 GMT, Chen Liang  wrote:

>> I get warnings and build failures if I leave out those casts (`utflen` is a `long`)
>
> Ah, I meant to use the equivalent local variable int ascii, the return value of countPositives, to avoid these casts.

Missed this comment, but ended up doing like you suggested.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17734#discussion_r1488613636

From mandy.chung at oracle.com  Tue Feb 13 21:48:53 2024
From: mandy.chung at oracle.com (mandy.chung at oracle.com)
Date: Tue, 13 Feb 2024 13:48:53 -0800
Subject: CFV: New Core Libraries Group Member: Raffaello Giulietti
In-Reply-To: <14851B34-A785-4389-9C23-056B8C7E0D7C@oracle.com>
References: <14851B34-A785-4389-9C23-056B8C7E0D7C@oracle.com>
Message-ID: 

Vote: yes

Mandy

On 2/13/24 12:25 PM, Brian Burkhalter wrote:
> I hereby nominate Raffaello Giulietti to Membership in the Core Libraries Group.
>


From rriggs at openjdk.org  Tue Feb 13 22:04:54 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 13 Feb 2024 22:04:54 GMT
Subject: RFR: 8325576: java/lang/ProcessHandle/InfoTest.java fails on
 systems with coreutils with --enable-single-binary [v2]
In-Reply-To: <46wD8xd0OIGGfHW5aexaJ7fzHSlUIxF6RkQnaCrrRn8=.6f968e71-4bf2-4d47-8d10-6acec20596bd@github.com>
References: 
 
 
 
 
 <8bH-nWhM3TbK68Pt5wOjoPzc5bc81VQ-rY3dMBeYE3o=.ee389cb7-46d5-48e6-a547-3cf9fa07b0ff@github.com>
 
 <46wD8xd0OIGGfHW5aexaJ7fzHSlUIxF6RkQnaCrrRn8=.6f968e71-4bf2-4d47-8d10-6acec20596bd@github.com>
Message-ID: 

On Tue, 13 Feb 2024 21:23:29 GMT, Dan Lutker  wrote:

>> At the time `sleep` seemed ubiquitous and was native so it ran quickly. (Much quicker than running java).
>> Running another program would be fine.  For example ,selecting an executable based on the OS type and giving the expected string in the output would be preferred.
>> The isBusyBox check is also a bad hack, but lighter weight since its not executing a program.
>> As the number of minor variations of platforms appear a more general approach would be useful.
>> 
>> I'd code it all in the test itself, doing a lookup based on the operating system name with the respective executable and expected string in the info arguments[0].
>> (With a fallback to sleep, so the table does not have to list every os).
>
> Any reason not to use [exesanity_SimpleNativeLauncher](https://github.com/openjdk/jdk/blob/628cd8a489fd54db18204c3bbaf4339d7ab5e9d6/test/jdk/native_sanity/simplenativelauncher/exesanity_SimpleNativeLauncher.c) or [exeBasicSleep](https://github.com/openjdk/jdk/blob/628cd8a489fd54db18204c3bbaf4339d7ab5e9d6/test/jdk/java/lang/ProcessBuilder/exeBasicSleep.c) in all cases?

I'd be ok with exeBasicSleep; (currently only used on Windows and if its been built by the make files).
Note the discovery mechanism used in Basic.java `initSleepPath()` to locate and identify the path where its built or to fallback to the OS sleep.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17798#discussion_r1488640847

From weijun at openjdk.org  Tue Feb 13 22:30:28 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 13 Feb 2024 22:30:28 GMT
Subject: RFR: 8325506: Ensure randomness is only read from provided
 SecureRandom object [v3]
In-Reply-To: 
References: 
Message-ID: 

> Many crypto service classes require a `SecureRandom` object at initialization. This test goes through each of them and calculates (generate, encrypt, sign,...) twice with the same `SecureRandom` object and ensures the output is the same.

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

  assertNotEqualsByteArray

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17776/files
  - new: https://git.openjdk.org/jdk/pull/17776/files/a1715f04..96e09a5d

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

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

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

From sgibbons at openjdk.org  Wed Feb 14 00:48:18 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Wed, 14 Feb 2024 00:48:18 GMT
Subject: RFR: JDK-8320448 Accelerate IndexOf using AVX2 [v8]
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:

  Remove gcc lib fn; reduce spacial cases to 10 from 32

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16753/files
  - new: https://git.openjdk.org/jdk/pull/16753/files/3e58d0c2..827ca245

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

  Stats: 2624 lines in 4 files changed: 320 ins; 1981 del; 323 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 liach at openjdk.org  Wed Feb 14 03:03:55 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 14 Feb 2024 03:03:55 GMT
Subject: RFR: JDK-8323760 putIfAbsent documentation conflicts with itself
 [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 13 Feb 2024 17:11:05 GMT, John Hendrikx  wrote:

>> Update the documentation for `@return` tag of `putIfAbsent` to match the main description. `putIfAbsent` uses the same wording as `put` for its `@return` tag, but that is incorrect.  `putIfAbsent` never returns the **previous** value, as the whole point of the method is not the replace the value if it was present.  As such, if it returns a value, it is the **current** value, and in all other cases it will return `null`.
>
> John Hendrikx has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - Add code block around argument
>  - Reword
>  - Reword to use put's previous value wording
>  - Reword more clearly

Looks good to me. Since this changes API specification, you need a CSR before integration.

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

PR Comment: https://git.openjdk.org/jdk/pull/17438#issuecomment-1943013175

From jhendrikx at openjdk.org  Wed Feb 14 03:50:02 2024
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Wed, 14 Feb 2024 03:50:02 GMT
Subject: RFR: JDK-8323760 putIfAbsent documentation conflicts with itself
 [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 13 Feb 2024 17:11:05 GMT, John Hendrikx  wrote:

>> Update the documentation for `@return` tag of `putIfAbsent` to match the main description. `putIfAbsent` uses the same wording as `put` for its `@return` tag, but that is incorrect.  `putIfAbsent` never returns the **previous** value, as the whole point of the method is not the replace the value if it was present.  As such, if it returns a value, it is the **current** value, and in all other cases it will return `null`.
>
> John Hendrikx has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - Add code block around argument
>  - Reword
>  - Reword to use put's previous value wording
>  - Reword more clearly

CSR is available now.

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

PR Comment: https://git.openjdk.org/jdk/pull/17438#issuecomment-1943040199

From jai.forums2013 at gmail.com  Wed Feb 14 06:43:46 2024
From: jai.forums2013 at gmail.com (Jaikiran Pai)
Date: Wed, 14 Feb 2024 12:13:46 +0530
Subject: OpenJDK 17: Loitering AbstractQueuedSynchronizer$ConditionNode
 instances (also on latest master branch)
In-Reply-To: <6d3b62cb-15f4-471c-97b6-b72977223f91@gmx.net>
References: <591b0e9c-1d7a-405d-ace1-bd94f8dbbe22@gmx.net>
 
 
 <64bc8cbd-78f4-44f4-90ae-80466c563281@gmx.net>
 <6d3b62cb-15f4-471c-97b6-b72977223f91@gmx.net>
Message-ID: <59c3b1bc-fd60-4215-b8f7-96421f1881e2@gmail.com>

Hello Frank,

I see that a JBS issue has been created for this same issue 
https://bugs.openjdk.org/browse/JDK-8325754.

I don't have enough knowledge of this area and haven't reviewed this 
part of the code in detail to see if there are any obvious issues with 
what you are proposing as a solution. Since there's now a JBS issue 
created for this and you seem to have done enough investigation and work 
on this one already, would you be interested in creating a pull request 
against the https://github.com/openjdk/jdk repo with this proposed 
change? (you'll have to sign a OCA). This guide 
https://openjdk.org/guide/ should help you get started. It can then go 
through the usual reviews that a bug fix/enhancement goes through.

-Jaikiran

On 11/02/24 7:27 pm, Frank Kretschmer wrote:
>
> Hello Core-Libs-Dev team,
>
> may I ask you about your opinion about a tiny one-liner change in 
> AbstractQueuedSynchronizer, just as a suggestion how to make 
> ConditionObjects / Nodes even more garbage collector friendly?
>
> Checked out 
> https://github.com/openjdk/jdk/blob/jdk-17%2B35/src/java.base/share/classes/java/util/concurrent/locks/AbstractQueuedSynchronizer.java 
> (the same on master branch with different line numbers near to line 1506):
>
> @@ -1431,40 +1431,41 @@ public abstract class AbstractQueuedSynchronizer
> ???? public class ConditionObject implements Condition, 
> java.io.Serializable {
> ???????? // ...
> ???????? private void doSignal(ConditionNode first, boolean all) {
> ???????????? while (first != null) {
> ???????????????? ConditionNode next = first.nextWaiter;
> +??????????????? first.nextWaiter = null;? // GC-friendly: avoid 
> chains of dead ConditionNodes
> ???????????????? if ((firstWaiter = next) == null)
> ???????????????????? lastWaiter = null;
> ???????????????? if ((first.getAndUnsetStatus(COND) & COND) != 0) {
> ???????????????????? enqueue(first);
> ???????????????? // ...
>
> By setting the nextWaiter to null of the first condition node, which 
> is transferred from the condition queue to the sync queue in this 
> method, long chains of ConditionNode instances can be avoided. Though 
> a single ConditionNode is small, these chains of ConditionNodes become 
> very huge on the heap (I've seen more than 1GB on an application 
> server over time) if at least one node was promoted to the old 
> generation for any reason. They survive minor collections and are 
> cleaned up only on mixed / full collections, and thus put unnecessary 
> pressure on G1 garbage collector.
>
> The same change could also be applied to 'AbstractQueuedLongSynchronizer'.
>
> I know premature optimization is the root of all evil, on the other 
> hand I could image that many applications benefit from GC-friendly 
> ConditionObjects, since they are frequently used in various classes 
> like PriorityBlockingQueue / LinkedBlockingDeque / 
> LinkedBlockingQueue, the latter one as default work queue for executor 
> services like fixed thread pools for processing asynchronous tasks.
>
> Thank you all for your time and help!
>
> Best regards
> Frank
>
> Am 08.02.2024 um 12:15 schrieb Frank Kretschmer:
>> Hello Thomas, hello Core-Libs-Dev,
>>
>> thank you for cc'ing my email. In deed my idea/suggestion is to modify
>> the AbstractQueuedSynchronizer$ConditionNode handling in such a way that
>> it gets unlinked from the chain of condition nodes if it is not needed
>> any more (it might be the "nextWaiter" node), in order to be more
>> GC-friendly.
>>
>> @core-libs-dev: I've just attached the ?G1LoiteringConditionNodes? demo
>> class and "gc.log" again so that you can have a look if you like.
>>
>> Best regards
>>
>> Frank
>>
>>
>> Am 08.02.2024 um 11:04 schrieb Thomas Schatzl:
>>> Hi,
>>>
>>> ? since this looks like a suggestion for a change to the libraries
>>> similar to the mentioned JDK-6805775, and not actually GC, cc'ing the
>>> core-libs-dev mailing list.
>>>
>>> Hth,
>>> ? Thomas
>>>
>>> On 07.02.24 15:20, Frank Kretschmer wrote:
>>>> Hi Java GC-experts,
>>>>
>>>> I'm facing an interesting G1 garbage collector observation in OpenJDK
>>>> 17.0.9+9, which I would like to share with you.
>>>>
>>>> My application runs many asynchronous tasks in a fixed thread pool,
>>>> utilizing its standard LinkedBlockingQueue. Usually, it generates 
>>>> just a
>>>> little garbage, but from time to time, I observed that the survivor
>>>> spaces grow unexpectedly, and minor collection times increase.
>>>>
>>>> This being the case, many
>>>> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionNode
>>>> instances can be found on the heap. In fact, the whole heap (rank 1 as
>>>> shown in jmap) was filled up with ConditionNode instances after a 
>>>> while.
>>>>
>>>> After some tests, I figured out that G1 seems to be able to collect
>>>> ?dead? ConditionNode instances during minor collections only if no
>>>> formerly alive ConditionNode instances were promoted to the old
>>>> generation and died there.
>>>>
>>>> To illustrate that, I've attached a ?G1LoiteringConditionNodes? class
>>>> that can be run for demo purposes, e.g. under Linux with OpenJDK
>>>> 17.0.9+9 (VM options see comments within the class), and its gc-log
>>>> output. It shows that during the first two minutes, everything is 
>>>> fine,
>>>> but after a promotion to the old generation, survivors grow and minor
>>>> pause time increase from 3 to 10ms.
>>>>
>>>> For me, it looks like an issue similar to
>>>> https://bugs.openjdk.org/browse/JDK-6805775 ?LinkedBlockingQueue Nodes
>>>> should unlink themselves before becoming garbage?, which was fixed in
>>>> OpenJDK 7.
>>>>
>>>> What?s your opinion about that? Wouldn?t it be worth to enable G1 to
>>>> collect those AbstractQueuedSynchronizer$ConditionNode instances 
>>>> during
>>>> minor collections, as it is done for LinkedBlockingQueue Nodes?
>>>>
>>>> Best regards
>>>>
>>>> Frank
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From Alan.Bateman at oracle.com  Wed Feb 14 07:22:47 2024
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 14 Feb 2024 07:22:47 +0000
Subject: CFV: New Core Libraries Group Member: Raffaello Giulietti
In-Reply-To: <14851B34-A785-4389-9C23-056B8C7E0D7C@oracle.com>
References: <14851B34-A785-4389-9C23-056B8C7E0D7C@oracle.com>
Message-ID: <5800f50f-2a76-4557-ada9-cdce7b008d89@oracle.com>

Vote: yes

From aturbanov at openjdk.org  Wed Feb 14 09:07:06 2024
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Wed, 14 Feb 2024 09:07:06 GMT
Subject: RFR: 8325576: java/lang/ProcessHandle/InfoTest.java fails on
 systems with coreutils with --enable-single-binary [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 13 Feb 2024 18:03:14 GMT, Dan Lutker  wrote:

>> Ran the test on AmazonLinux 2 which has multiple binaries from coreutils package and no coreutils executable as well as AmazonLinux 2023 that uses `--enable-single-binary`
>
> Dan Lutker has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unnecessary var.

test/lib/jdk/test/lib/Platform.java line 140:

> 138:                 }
> 139:             }
> 140:         } catch(Exception e) {

Suggestion:

        } catch (Exception e) {

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17798#discussion_r1489133848

From pavel.rappo at oracle.com  Wed Feb 14 09:55:28 2024
From: pavel.rappo at oracle.com (Pavel Rappo)
Date: Wed, 14 Feb 2024 09:55:28 +0000
Subject: CFV: New Core Libraries Group Member: Raffaello Giulietti
In-Reply-To: <14851B34-A785-4389-9C23-056B8C7E0D7C@oracle.com>
References: <14851B34-A785-4389-9C23-056B8C7E0D7C@oracle.com>
Message-ID: <85B64AFC-AC52-40B6-B1D7-E3CF89972BE8@oracle.com>

Vote: yes

> On 13 Feb 2024, at 20:25, Brian Burkhalter  wrote:
> 
> I hereby nominate Raffaello Giulietti to Membership in the Core Libraries Group.
> 
> Raffaello has been working in the Core Library team at Oracle since April, 2022. He has authored more than 50 contributions to OpenJDK in a number of areas including numerics, formatting, regular expressions, and random number generation. 
> 
> Votes are due by Wednesday, February 28, 2023.
> 
> Only current Members of the Core Libraries Group [1] are eligible
> to vote on this nomination.  Votes must be cast in the open by
> replying to this mailing list
> 
> For Lazy Consensus voting instructions, see [2].
> 
> Brian Burkhalter
> 
> [1] https://openjdk.org/census#core-libs
> [2] https://openjdk.org/groups/#member-vote



From rgiulietti at openjdk.org  Wed Feb 14 10:44:03 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 14 Feb 2024 10:44:03 GMT
Subject: RFR: 8325340: Add ASCII fast-path to
 Data-/ObjectInputStream.readUTF
In-Reply-To: 
References: 
Message-ID: 

On Tue, 6 Feb 2024 16:17:21 GMT, Claes Redestad  wrote:

> Adding a fast-path for ASCII-only modified UTF-8 strings deserialied via Data- and ObjectInputStream
> 
> Testing: tier1-3

src/java.base/share/classes/java/io/DataInputStream.java line 585:

> 583:         DataInputStream dis = null;
> 584:         if (in instanceof DataInputStream) {
> 585:             dis = (DataInputStream)in;

I guess that not making use of `instanceof` pattern matching is to enable backporting before JDK 16?

src/java.base/share/classes/java/io/DataInputStream.java line 604:

> 602:                 // For ASCII ISO-8859-1 is equivalent to UTF-8, while avoiding a redundant
> 603:                 // scan
> 604:                 return new String(bytearr, 0, utflen, StandardCharsets.ISO_8859_1);

Not sure this is correct.
If `bytearr` contains some `(byte)0`, that is, if `in` is malformed, this doesn't throw `UTFDataFormatException`, but it should: modified UTF-8 cannot contain zeros.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17734#discussion_r1489261534
PR Review Comment: https://git.openjdk.org/jdk/pull/17734#discussion_r1489261783

From cstein at openjdk.org  Wed Feb 14 11:08:14 2024
From: cstein at openjdk.org (Christian Stein)
Date: Wed, 14 Feb 2024 11:08:14 GMT
Subject: RFR: 8318812: LauncherHelper.checkAndLoadMain closes jar file that's
 about to be re-opened
Message-ID: 

Please review this PR that makes the launcher helper keep a reference to the executable JAR file active after extracting the name of the main class and returning it as Class instance. Now, when loading classes from the JAR file, it hasn't to be re-opened.

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

Commit messages:
 - Fail fast
 - Simplify implementation
 - 8318812: LauncherHelper.checkAndLoadMain closes jar file that's about to be re-opened

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

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

From redestad at openjdk.org  Wed Feb 14 11:32:03 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 14 Feb 2024 11:32:03 GMT
Subject: RFR: 8325340: Add ASCII fast-path to
 Data-/ObjectInputStream.readUTF
In-Reply-To: 
References: 
 
Message-ID: <0ql4FUUK2bFwDWVXGrZwHic4nN5iyUIE4pZAMEQncIo=.b2b69c82-1bfb-4542-977b-32a582755f64@github.com>

On Wed, 14 Feb 2024 10:41:17 GMT, Raffaello Giulietti  wrote:

>> Adding a fast-path for ASCII-only modified UTF-8 strings deserialied via Data- and ObjectInputStream
>> 
>> Testing: tier1-3
>
> src/java.base/share/classes/java/io/DataInputStream.java line 604:
> 
>> 602:                 // For ASCII ISO-8859-1 is equivalent to UTF-8, while avoiding a redundant
>> 603:                 // scan
>> 604:                 return new String(bytearr, 0, utflen, StandardCharsets.ISO_8859_1);
> 
> Not sure this is correct.
> If `bytearr` contains some `(byte)0`, that is, if `in` is malformed, this doesn't throw `UTFDataFormatException`, but it should: modified UTF-8 cannot contain zeros.

While properly encoded modified UTF-8 strings won't have embedded zeros (`\u0000` will be encoded as `0xC0, 0x80`) the decoding routines in `DataInputStream` and `ObjectInputStream` allows them and does not throw an exception if an embedded zero is encountered. This PR does not change semantics here AFAICT. If you think we need to be stricter in these decoders that could be done as a separate RFE and I'll put this on hold.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17734#discussion_r1489325376

From rgiulietti at openjdk.org  Wed Feb 14 11:37:54 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 14 Feb 2024 11:37:54 GMT
Subject: RFR: 8325340: Add ASCII fast-path to
 Data-/ObjectInputStream.readUTF
In-Reply-To: <0ql4FUUK2bFwDWVXGrZwHic4nN5iyUIE4pZAMEQncIo=.b2b69c82-1bfb-4542-977b-32a582755f64@github.com>
References: 
 
 <0ql4FUUK2bFwDWVXGrZwHic4nN5iyUIE4pZAMEQncIo=.b2b69c82-1bfb-4542-977b-32a582755f64@github.com>
Message-ID: 

On Wed, 14 Feb 2024 11:29:43 GMT, Claes Redestad  wrote:

>> src/java.base/share/classes/java/io/DataInputStream.java line 604:
>> 
>>> 602:                 // For ASCII ISO-8859-1 is equivalent to UTF-8, while avoiding a redundant
>>> 603:                 // scan
>>> 604:                 return new String(bytearr, 0, utflen, StandardCharsets.ISO_8859_1);
>> 
>> Not sure this is correct.
>> If `bytearr` contains some `(byte)0`, that is, if `in` is malformed, this doesn't throw `UTFDataFormatException`, but it should: modified UTF-8 cannot contain zeros.
>
> While properly encoded modified UTF-8 strings won't have embedded zeros (`\u0000` will be encoded as `0xC0, 0x80`) the decoding routines in `DataInputStream` and `ObjectInputStream` allows them and does not throw an exception if an embedded zero is encountered. This PR does not change semantics here AFAICT. If you think we need to be stricter in these decoders that could be done as a separate RFE and I'll put this on hold.

Ah OK.

I didn't check the current code, only the proposed one.
Although the specification clearly states that the method should throw, if the current code does not throw on zeros, then it makes sense that the proposed one shouldn't either.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17734#discussion_r1489331002

From alanb at openjdk.org  Wed Feb 14 11:55:05 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 14 Feb 2024 11:55:05 GMT
Subject: RFR: 8318812: LauncherHelper.checkAndLoadMain closes jar file
 that's about to be re-opened
In-Reply-To: 
References: 
Message-ID: 

On Wed, 14 Feb 2024 11:03:07 GMT, Christian Stein  wrote:

> Please review this PR that makes the launcher helper keep a reference to the executable JAR file active after extracting the name of the main class and returning it as Class instance. Now, when loading classes from the JAR file, it hasn't to be re-opened.

So if we run today with `java -jar app.jar` then the JAR file will be opened, and its manifest parsed, by LauncherHelper.loadMainClass, then again by URLClassPath$JarLoader when it is lazily opened on the class path. That seems reasonable. It would of course be useful to see any performance/startup data but it might be hard to gather.

src/java.base/share/classes/sun/launcher/LauncherHelper.java line 593:

> 591:     }
> 592: 
> 593:     private static String getMainClassFromJar(String jarname, JarFile jarFile) {

Can you check if the "jarname" parameter can be dropped, the error handling in this method should be able to use jarFile.getName().

src/java.base/share/classes/sun/launcher/LauncherHelper.java line 596:

> 594:         String mainValue;
> 595:         try {
> 596:             Manifest manifest = jarFile.getManifest();

I think the try-catch around the block can be dropped and you can put a more targeted try-catch around getManifest, at least I think that is the only case remaining in getMainClassFromJar that needs error handling now.

src/java.base/share/classes/sun/launcher/LauncherHelper.java line 823:

> 821:         // get the class name
> 822:         String cn;
> 823:         // store the jar file

"store the jar file" is a confusing comment to add. I think what you want to say is that the JarFile will put the underlying file in the JarFile/ZipFile cache and this will avoid needing to re-parse the manifest when the JAR file is opened on the class path, triggered by Class.forName.

src/java.base/share/classes/sun/launcher/LauncherHelper.java line 876:

> 874:                     jarFile.close();
> 875:                 } catch (IOException ioe) {
> 876:                     abort(ioe, "java.launcher.jar.error1", what);

java.launcher.jar.error1 is "Error: An unexpected error occurred while trying to open file". I can't think of any cases where it might fail but the error message would be confusing if it did.

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

PR Review: https://git.openjdk.org/jdk/pull/17843#pullrequestreview-1880069738
PR Review Comment: https://git.openjdk.org/jdk/pull/17843#discussion_r1489338851
PR Review Comment: https://git.openjdk.org/jdk/pull/17843#discussion_r1489340464
PR Review Comment: https://git.openjdk.org/jdk/pull/17843#discussion_r1489339435
PR Review Comment: https://git.openjdk.org/jdk/pull/17843#discussion_r1489342147

From duke at openjdk.org  Wed Feb 14 12:03:56 2024
From: duke at openjdk.org (tsypanovs)
Date: Wed, 14 Feb 2024 12:03:56 GMT
Subject: RFR: 8325679: Optimize ArrayList subList sort
In-Reply-To: 
References: 
Message-ID: <5_1LNJHQNi7aDGuTcM6sIzC9gbIrQhvq7ilr7xAiHKU=.9d817e1a-f302-44d0-b4ba-d77c12d2cf2c@github.com>

On Mon, 12 Feb 2024 22:52:51 GMT, Attila Szegedi  wrote:

> Somewhat surprisingly, `ArrayList$Sublist.sort()` is not specialized and will thus fall back to slower default method of `List.sort()` instead of sorting a range of the array in-place in its backing root `ArrayList`. 
> 
> This doesn't change observable behavior, so haven't added tests, and `tier1` tests still all pass except for `test/jdk/java/util/Locale/LocaleProvidersFormat.java` which also currently fails on master too on the machine I tested on.

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

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

PR Review: https://git.openjdk.org/jdk/pull/17818#pullrequestreview-1880107173

From daniel.fuchs at oracle.com  Wed Feb 14 12:07:01 2024
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Wed, 14 Feb 2024 12:07:01 +0000
Subject: CFV: New Core Libraries Group Member: Raffaello Giulietti
In-Reply-To: <14851B34-A785-4389-9C23-056B8C7E0D7C@oracle.com>
References: <14851B34-A785-4389-9C23-056B8C7E0D7C@oracle.com>
Message-ID: 

Vote: yes

best regards,

-- daniel

On 13/02/2024 20:25, Brian Burkhalter wrote:
> I hereby nominate Raffaello Giulietti to Membership in the Core Libraries Group.


From michael.x.mcmahon at oracle.com  Wed Feb 14 12:19:53 2024
From: michael.x.mcmahon at oracle.com (Michael McMahon)
Date: Wed, 14 Feb 2024 12:19:53 +0000
Subject: CFV: New Core Libraries Group Member: Raffaello Giulietti
In-Reply-To: <14851B34-A785-4389-9C23-056B8C7E0D7C@oracle.com>
References: <14851B34-A785-4389-9C23-056B8C7E0D7C@oracle.com>
Message-ID: <0455de2d-f18b-4f2f-9b5c-5b883940780b@oracle.com>

Vote: Yes

On 13/02/2024 20:25, Brian Burkhalter wrote:
> I hereby nominate Raffaello Giulietti to Membership in the Core Libraries Group.
>
> Raffaello has been working in the Core Library team at Oracle since April, 2022. He has authored more than 50 contributions to OpenJDK in a number of areas including numerics, formatting, regular expressions, and random number generation.
>
> Votes are due by Wednesday, February 28, 2023.
>
> Only current Members of the Core Libraries Group [1] are eligible
> to vote on this nomination.  Votes must be cast in the open by
> replying to this mailing list
>
> For Lazy Consensus voting instructions, see [2].
>
> Brian Burkhalter
>
> [1]https://openjdk.org/census#core-libs
> [2]https://openjdk.org/groups/#member-vote
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From mbaesken at openjdk.org  Wed Feb 14 13:15:03 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 14 Feb 2024 13:15:03 GMT
Subject: RFR: JDK-8324930: java/lang/StringBuilder problem with concurrent
 jtreg runs
In-Reply-To: 
References: 
Message-ID: 

On Tue, 30 Jan 2024 09:08:28 GMT, Matthias Baesken  wrote:

> On some Windows machines we see sometimes OOM errors because of high resource (memory/swap) consumption. This is especially seen when the jtreg runs have higher concurrency. A solution is to put the java/lang/StringBuilder tests in the exclusiveAccess.dirs group so that they are not executed concurrently, which helps to mitigate the resource shortages.
> Of course this has the downside that on very large machines the concurrent execution is not done any more.

I started a discussion on jtreg-dev  https://mail.openjdk.org/pipermail/jtreg-dev/2024-February/001926.html 
but not much response so far.  Adding a jtreg test key for tests with higher memory requirement  (like HugeCapacity) would probably help to solve these resource issues .

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

PR Comment: https://git.openjdk.org/jdk/pull/17625#issuecomment-1943742596

From redestad at openjdk.org  Wed Feb 14 14:32:55 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 14 Feb 2024 14:32:55 GMT
Subject: RFR: 8325340: Add ASCII fast-path to
 Data-/ObjectInputStream.readUTF
In-Reply-To: 
References: 
 
 <0ql4FUUK2bFwDWVXGrZwHic4nN5iyUIE4pZAMEQncIo=.b2b69c82-1bfb-4542-977b-32a582755f64@github.com>
 
Message-ID: 

On Wed, 14 Feb 2024 11:35:10 GMT, Raffaello Giulietti  wrote:

>> While properly encoded modified UTF-8 strings won't have embedded zeros (`\u0000` will be encoded as `0xC0, 0x80`) the decoding routines in `DataInputStream` and `ObjectInputStream` allows them and does not throw an exception if an embedded zero is encountered. This PR does not change semantics here AFAICT. If you think we need to be stricter in these decoders that could be done as a separate RFE and I'll put this on hold.
>
> Ah OK.
> 
> I didn't check the current code, only the proposed one.
> Although the specification clearly states that the method should throw, if the current code does not throw on zeros, then it makes sense that the proposed one shouldn't either.

The specification is somewhat ambiguous:
https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/io/DataInput.html#readUTF()

There's a sweeping `Throws UTFDataFormatException - if the bytes do not represent a valid modified UTF-8 encoding of a string` but also: `If the first byte of a group matches the bit pattern 0xxxxxxx (where x means "may be 0 or 1"), then the group consists of just that byte. The byte is zero-extended to form a character.` I think the latter gives some leeway on being lenient on embedded zeros, even if it's made clear elsewhere that valid encoders need to replace zeros with the `0xC0, 0x80` sequence.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17734#discussion_r1489564324

From sgibbons at openjdk.org  Wed Feb 14 14:34:07 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Wed, 14 Feb 2024 14:34:07 GMT
Subject: RFR: JDK-8320448 Accelerate IndexOf using AVX2 [v8]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 14 Feb 2024 00:48:18 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:
> 
>   Remove gcc lib fn; reduce spacial cases to 10 from 32

Thank you all for the reviews.  I have been asked to simplify this code to facilitate easier review, and to remove the gcc library code I used for memcmp.  We also discovered that special-casing up to 31 bytes of needle was not necessary to get the performance gain.  I will be commenting the code and fixing the single build failure soon.

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

PR Comment: https://git.openjdk.org/jdk/pull/16753#issuecomment-1943904829

From jvernee at openjdk.org  Wed Feb 14 14:34:12 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 14 Feb 2024 14:34:12 GMT
Subject: Integrated: 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...

This pull request has now been integrated.

Changeset: 9c852df6
Author:    Jorn Vernee 
URL:       https://git.openjdk.org/jdk/commit/9c852df6aa019f63d6fae733d7a73521b7151dd0
Stats:     5133 lines in 19 files changed: 612 ins; 3440 del; 1081 mod

8318966: Some methods make promises about Java array element alignment that are too strong

Reviewed-by: psandoz, mcimadamore

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

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

From prappo at openjdk.org  Wed Feb 14 14:55:02 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 14 Feb 2024 14:55:02 GMT
Subject: RFR: 8325679: Optimize ArrayList subList sort
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 13 Feb 2024 03:55:37 GMT, Stuart Marks  wrote:

> My guess is that nobody noticed this because sublists aren't used that much, and sorting of subarrays, while arguably necessary for completeness, probably aren't used all that much either.

FWIW, `CopyOnWriteArrayList.COWSubList` overrides `sort`.

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

PR Comment: https://git.openjdk.org/jdk/pull/17818#issuecomment-1943965071

From clanger at openjdk.org  Wed Feb 14 15:08:02 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Wed, 14 Feb 2024 15:08:02 GMT
Subject: RFR: 8325579: Inconsistent behavior in
 com.sun.jndi.ldap.Connection::createSocket
In-Reply-To: 
References: 
Message-ID: 

On Fri, 9 Feb 2024 21:29:28 GMT, Christoph Langer  wrote:

> During analysing a customer case I figured out that we have an inconsistency between documentation and actual behavior in class com.sun.jndi.ldap.Connection. The [method documentation of com.sun.jndi.ldap.Connection::createSocket](https://github.com/openjdk/jdk/blob/3ebe6c192a5dd5cc46ae2d263713c9ff38cd46bb/src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java#L281) states: "If a timeout is supplied but unconnected sockets are not supported then the timeout is ignored and a connected socket is created."
> 
> This, however does not happen. If a SocketFactory would not support unconnected sockets, it would likely throw a SocketException in [SocketFactory::createSocket()](https://github.com/openjdk/jdk/blob/6303c0e7136436a2d3cb6043b88edf788c0067cc/src/java.base/share/classes/javax/net/SocketFactory.java#L123). And since [the code](https://github.com/openjdk/jdk/blob/3ebe6c192a5dd5cc46ae2d263713c9ff38cd46bb/src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java#L336) does not check for this behavior, a connection with timeout value through a SocketFactory that does not support unconnected sockets would simply fail with an IOException.
> 
> So we should either make the code adhere to what is documented or adapt the documentation to the actual behavior.
> 
> I hereby try to fix the connect coding. Alternatively, we could also adapt the description - I have no strong opinion. What do the experts suggest?

Hi Aleksei,

thanks for taking a look. Yes, I'm working on extending the test. Stay tuned. ? 

Cheers
Christoph

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

PR Comment: https://git.openjdk.org/jdk/pull/17797#issuecomment-1944018942

From prappo at openjdk.org  Wed Feb 14 15:13:04 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 14 Feb 2024 15:13:04 GMT
Subject: RFR: JDK-8323760 putIfAbsent documentation conflicts with itself
 [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 13 Feb 2024 17:11:05 GMT, John Hendrikx  wrote:

>> Update the documentation for `@return` tag of `putIfAbsent` to match the main description. `putIfAbsent` uses the same wording as `put` for its `@return` tag, but that is incorrect.  `putIfAbsent` never returns the **previous** value, as the whole point of the method is not the replace the value if it was present.  As such, if it returns a value, it is the **current** value, and in all other cases it will return `null`.
>
> John Hendrikx has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - Add code block around argument
>  - Reword
>  - Reword to use put's previous value wording
>  - Reword more clearly

Firstly, while it does not hurt to file CSR, in this case it feels like overkill: here you are fixing a glorified typo. It's a good and helpful fix, but it's also a typo fix. A good indication that CSR is not needed is that "Compatibility Kind" for this change is none of the available "source", "binary", or "behavioral".

Secondly, the current wording feels redundant and at the same time disjointed (bold font is mine):

> Returns null if the specified key was absent **or had a null value**, else returns the value currently associated with key. **(A null return can also indicate that the map previously associated null with the key, if the implementation supports null values.)**

Those parts I empathised are related, but they are also far apart and duplicate each other in a sense. We can get rid of the first part, retain the common wording in parentheses used in other `Map` methods, and swap clauses of the first sentence around:

> Returns the value currently associated with key, or null if the specified key was absent. (A null return can also indicate that the map previously associated null with the key, if the implementation supports null values.)

Don't rush to changing your PR, even if you like that proposal. Let's hear from others first.

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

PR Comment: https://git.openjdk.org/jdk/pull/17438#issuecomment-1944028388

From jjg at openjdk.org  Wed Feb 14 15:20:05 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 14 Feb 2024 15:20:05 GMT
Subject: RFR: JDK-8323760 putIfAbsent documentation conflicts with itself
 [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 13 Feb 2024 17:11:05 GMT, John Hendrikx  wrote:

>> Update the documentation for `@return` tag of `putIfAbsent` to match the main description. `putIfAbsent` uses the same wording as `put` for its `@return` tag, but that is incorrect.  `putIfAbsent` never returns the **previous** value, as the whole point of the method is not the replace the value if it was present.  As such, if it returns a value, it is the **current** value, and in all other cases it will return `null`.
>
> John Hendrikx has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - Add code block around argument
>  - Reword
>  - Reword to use put's previous value wording
>  - Reword more clearly

src/java.base/share/classes/java/util/Map.java line 824:

> 822:      *         {@code null} return can also indicate that the map previously
> 823:      *         associated {@code null} with the key, if the implementation supports
> 824:      *         null values.)

inconsistent typography for `null`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17438#discussion_r1489648755

From cstein at openjdk.org  Wed Feb 14 15:46:05 2024
From: cstein at openjdk.org (Christian Stein)
Date: Wed, 14 Feb 2024 15:46:05 GMT
Subject: RFR: 8318812: LauncherHelper.checkAndLoadMain closes jar file
 that's about to be re-opened
In-Reply-To: 
References: 
 
Message-ID: <3GZWKZF6hJQw6Q5iQR40bVocP8qGj2dNLLwDhK9RrLM=.3a3aa6cb-e91e-4d4a-b8f8-e771772ca48b@github.com>

On Wed, 14 Feb 2024 11:40:16 GMT, Alan Bateman  wrote:

>> Please review this PR that makes the launcher helper keep a reference to the executable JAR file active after extracting the name of the main class and returning it as Class instance. Now, when loading classes from the JAR file, it hasn't to be re-opened.
>
> src/java.base/share/classes/sun/launcher/LauncherHelper.java line 593:
> 
>> 591:     }
>> 592: 
>> 593:     private static String getMainClassFromJar(String jarname, JarFile jarFile) {
> 
> Can you check if the "jarname" parameter can be dropped, the error handling in this method should be able to use jarFile.getName().

`String jarname` is filled by the caller with the value of `String what`, and therefore contains the entire path to the executable JAR file. Using only `jarFile.getName()` will prevent any parent directories from being noted in error messages; which might affect some tests

> src/java.base/share/classes/sun/launcher/LauncherHelper.java line 823:
> 
>> 821:         // get the class name
>> 822:         String cn;
>> 823:         // store the jar file
> 
> "store the jar file" is a confusing comment to add. I think what you want to say is that the JarFile will put the underlying file in the JarFile/ZipFile cache and this will avoid needing to re-parse the manifest when the JAR file is opened on the class path, triggered by Class.forName.

Updating to use the precise description.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17843#discussion_r1489688919
PR Review Comment: https://git.openjdk.org/jdk/pull/17843#discussion_r1489689891

From cstein at openjdk.org  Wed Feb 14 15:52:54 2024
From: cstein at openjdk.org (Christian Stein)
Date: Wed, 14 Feb 2024 15:52:54 GMT
Subject: RFR: 8318812: LauncherHelper.checkAndLoadMain closes jar file
 that's about to be re-opened
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 14 Feb 2024 11:41:43 GMT, Alan Bateman  wrote:

>> Please review this PR that makes the launcher helper keep a reference to the executable JAR file active after extracting the name of the main class and returning it as Class instance. Now, when loading classes from the JAR file, it hasn't to be re-opened.
>
> src/java.base/share/classes/sun/launcher/LauncherHelper.java line 596:
> 
>> 594:         String mainValue;
>> 595:         try {
>> 596:             Manifest manifest = jarFile.getManifest();
> 
> I think the try-catch around the block can be dropped and you can put a more targeted try-catch around getManifest, at least I think that is the only case remaining in getMainClassFromJar that needs error handling now.

Dropping that outer try-catch will lead to many whitespace-only changes due to un-indenting lines of the former block. Proceed or keep the indentation stable by making that internal method throw IOE and insert a comment-only block like:


/* keep indentation stable */ {
    Manifest manifest = jarFile.getManifest();
// ...
}

> src/java.base/share/classes/sun/launcher/LauncherHelper.java line 876:
> 
>> 874:                     jarFile.close();
>> 875:                 } catch (IOException ioe) {
>> 876:                     abort(ioe, "java.launcher.jar.error1", what);
> 
> java.launcher.jar.error1 is "Error: An unexpected error occurred while trying to open file". I can't think of any cases where it might fail but the error message would be confusing if it did.

Good catch! Introducing and using:

java.launcher.jar.error5=\
    Error: An unexpected error occurred while trying to close file {0}

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17843#discussion_r1489697776
PR Review Comment: https://git.openjdk.org/jdk/pull/17843#discussion_r1489699548

From alanb at openjdk.org  Wed Feb 14 16:19:03 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 14 Feb 2024 16:19:03 GMT
Subject: RFR: 8318812: LauncherHelper.checkAndLoadMain closes jar file
 that's about to be re-opened
In-Reply-To: 
References: 
 
 
Message-ID: 

On Wed, 14 Feb 2024 15:49:01 GMT, Christian Stein  wrote:

>> src/java.base/share/classes/sun/launcher/LauncherHelper.java line 596:
>> 
>>> 594:         String mainValue;
>>> 595:         try {
>>> 596:             Manifest manifest = jarFile.getManifest();
>> 
>> I think the try-catch around the block can be dropped and you can put a more targeted try-catch around getManifest, at least I think that is the only case remaining in getMainClassFromJar that needs error handling now.
>
> Dropping that outer try-catch will lead to many whitespace-only changes due to un-indenting lines of the former block. Proceed or keep the indentation stable by making that internal method throw IOE and insert a comment-only block like:
> 
> 
> /* keep indentation stable */ {
>     Manifest manifest = jarFile.getManifest();
> // ...
> }

> Dropping that outer try-catch will lead to many whitespace-only changes due to un-indenting lines of the former block. Proceed or keep the indentation stable by making that internal method throw IOE and insert a comment-only block like:
> 
> ```java
> /* keep indentation stable */ {
>     Manifest manifest = jarFile.getManifest();
> // ...
> }    
> ```

I think it's okay to shift-tab to re-align it after you remove the try-catch. It's a small patch and the changes are easy to see.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17843#discussion_r1489736759

From clanger at openjdk.org  Wed Feb 14 17:15:15 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Wed, 14 Feb 2024 17:15:15 GMT
Subject: RFR: 8325579: Inconsistent behavior in
 com.sun.jndi.ldap.Connection::createSocket [v2]
In-Reply-To: 
References: 
Message-ID: 

> During analysing a customer case I figured out that we have an inconsistency between documentation and actual behavior in class com.sun.jndi.ldap.Connection. The [method documentation of com.sun.jndi.ldap.Connection::createSocket](https://github.com/openjdk/jdk/blob/3ebe6c192a5dd5cc46ae2d263713c9ff38cd46bb/src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java#L281) states: "If a timeout is supplied but unconnected sockets are not supported then the timeout is ignored and a connected socket is created."
> 
> This, however does not happen. If a SocketFactory would not support unconnected sockets, it would likely throw a SocketException in [SocketFactory::createSocket()](https://github.com/openjdk/jdk/blob/6303c0e7136436a2d3cb6043b88edf788c0067cc/src/java.base/share/classes/javax/net/SocketFactory.java#L123). And since [the code](https://github.com/openjdk/jdk/blob/3ebe6c192a5dd5cc46ae2d263713c9ff38cd46bb/src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java#L336) does not check for this behavior, a connection with timeout value through a SocketFactory that does not support unconnected sockets would simply fail with an IOException.
> 
> So we should either make the code adhere to what is documented or adapt the documentation to the actual behavior.
> 
> I hereby try to fix the connect coding. Alternatively, we could also adapt the description - I have no strong opinion. What do the experts suggest?

Christoph Langer 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:

  JDK-8325579

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17797/files
  - new: https://git.openjdk.org/jdk/pull/17797/files/419f96f5..48318eb2

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

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

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

From sgibbons at openjdk.org  Wed Feb 14 17:41:30 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Wed, 14 Feb 2024 17:41:30 GMT
Subject: RFR: JDK-8320448 Accelerate IndexOf using AVX2 [v9]
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:

  Move arrays_equals to MacroAssembler_x86.cpp

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16753/files
  - new: https://git.openjdk.org/jdk/pull/16753/files/827ca245..e3e91953

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

  Stats: 736 lines in 8 files changed: 269 ins; 243 del; 224 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 Feb 14 17:55:20 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Wed, 14 Feb 2024 17:55:20 GMT
Subject: RFR: JDK-8320448 Accelerate IndexOf using AVX2 [v10]
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:

  Move arrays_equals out of LP_64 block

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16753/files
  - new: https://git.openjdk.org/jdk/pull/16753/files/e3e91953..8638a5f4

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

  Stats: 7 lines in 2 files changed: 4 ins; 3 del; 0 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 smarks at openjdk.org  Wed Feb 14 19:26:56 2024
From: smarks at openjdk.org (Stuart Marks)
Date: Wed, 14 Feb 2024 19:26:56 GMT
Subject: RFR: JDK-8323760 putIfAbsent documentation conflicts with itself
 [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 13 Feb 2024 17:11:05 GMT, John Hendrikx  wrote:

>> Update the documentation for `@return` tag of `putIfAbsent` to match the main description. `putIfAbsent` uses the same wording as `put` for its `@return` tag, but that is incorrect.  `putIfAbsent` never returns the **previous** value, as the whole point of the method is not the replace the value if it was present.  As such, if it returns a value, it is the **current** value, and in all other cases it will return `null`.
>
> John Hendrikx has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - Add code block around argument
>  - Reword
>  - Reword to use put's previous value wording
>  - Reword more clearly

In the original wording, the parenthesized sentence was, I think, an attempt to clarify the first sentence of the `@return` clause, since its use of "previous" is indeed confusing. Since we're rewording the main part of the clause to cover both the absent and was-mapped-to-null case, I don't think we need the parenthesized statement at all. How about:

> @return {@code null} if the specified key was absent or was associated with {@code null}, otherwise the value currently associated with the key

This largely mirrors the initial sentence of the method specification, but that's no bad thing; indeed, it's preferable to apparently contradicting it.

The "associated with null" wording is rather clumsy compared with "mapped to null" but most of the rest of the text here uses some form of "association" so I stuck with that.

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

PR Comment: https://git.openjdk.org/jdk/pull/17438#issuecomment-1944451781

From bpb at openjdk.org  Wed Feb 14 20:07:04 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 14 Feb 2024 20:07:04 GMT
Subject: RFR: 8325340: Add ASCII fast-path to
 Data-/ObjectInputStream.readUTF
In-Reply-To: 
References: 
Message-ID: 

On Tue, 6 Feb 2024 16:17:21 GMT, Claes Redestad  wrote:

> Adding a fast-path for ASCII-only modified UTF-8 strings deserialied via Data- and ObjectInputStream
> 
> Testing: tier1-3

As there are no regression tests added by this request, I assume that existing tests must sufficiently cover this area. If so, however, the issue has no `noreg-` label.

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

PR Comment: https://git.openjdk.org/jdk/pull/17734#issuecomment-1944507481

From bpb at openjdk.org  Wed Feb 14 20:07:05 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 14 Feb 2024 20:07:05 GMT
Subject: RFR: 8325340: Add ASCII fast-path to
 Data-/ObjectInputStream.readUTF
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 14 Feb 2024 10:41:08 GMT, Raffaello Giulietti  wrote:

>> Adding a fast-path for ASCII-only modified UTF-8 strings deserialied via Data- and ObjectInputStream
>> 
>> Testing: tier1-3
>
> src/java.base/share/classes/java/io/DataInputStream.java line 585:
> 
>> 583:         DataInputStream dis = null;
>> 584:         if (in instanceof DataInputStream) {
>> 585:             dis = (DataInputStream)in;
> 
> I guess that not making use of `instanceof` pattern matching is to enable backporting before JDK 16?

I have the same question here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17734#discussion_r1489994945

From jhendrikx at openjdk.org  Wed Feb 14 20:46:17 2024
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Wed, 14 Feb 2024 20:46:17 GMT
Subject: RFR: JDK-8323760 putIfAbsent documentation conflicts with itself
 [v3]
In-Reply-To: 
References: 
Message-ID: <2MuoCDS5QNXFwMb8hrVZ7IS2Vomgm8Z8SQVyOWN2us4=.ac233527-0bba-41ea-929a-36955f05861b@github.com>

> Update the documentation for `@return` tag of `putIfAbsent` to match the main description. `putIfAbsent` uses the same wording as `put` for its `@return` tag, but that is incorrect.  `putIfAbsent` never returns the **previous** value, as the whole point of the method is not the replace the value if it was present.  As such, if it returns a value, it is the **current** value, and in all other cases it will return `null`.

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

  Use new suggestion and remove original clarification

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17438/files
  - new: https://git.openjdk.org/jdk/pull/17438/files/3621be54..8c91f058

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

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

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

From dholmes at openjdk.org  Wed Feb 14 20:57:56 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 14 Feb 2024 20:57:56 GMT
Subject: RFR: 8323782: Race: Thread::interrupt vs.
 AbstractInterruptibleChannel.begin [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 5 Feb 2024 09:06:24 GMT, Richard Reingruber  wrote:

>> Set `interrupted` in `Thread::interrupt` before reading `nioBlocker` for correct (Dekker scheme) synchronization with concurrent execution of [`AbstractInterruptibleChannel::begin`](https://github.com/openjdk/jdk/blob/59062402b9c5ed5612a13c1c40eb22cf1b97c41a/src/java.base/share/classes/java/nio/channels/spi/AbstractInterruptibleChannel.java#L176).
>> 
>> The change passed our CI functional testing: JTReg tests: tier1-4 of hotspot and jdk. All of Langtools and jaxp. SPECjvm2008, SPECjbb2015, Renaissance Suite, and SAP specific tests.
>> Testing was done with fastdebug and release builds on the main platforms and also on Linux/PPC64le and AIX.
>
> Richard Reingruber has updated the pull request with a new target base 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 8323782__Race__Thread__interrupt_vs__AbstractInterruptibleChannel_begin
>  - Review Alan
>  - New version of LotsOfInterrupts.java supporting virtual threads
>  - Add Alan's LotsOfInterrupts.java test
>  - Must checkAccess before changing interrupt state of other thread
>  - 8323782: Race: Thread::interrupt vs. AbstractInterruptibleChannel.begin

Sorry for leaving this hanging. Change looks good.

Thanks

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17444#pullrequestreview-1881293498

From smarks at openjdk.org  Wed Feb 14 21:25:01 2024
From: smarks at openjdk.org (Stuart Marks)
Date: Wed, 14 Feb 2024 21:25:01 GMT
Subject: RFR: 8325679: Optimize ArrayList subList sort
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 12 Feb 2024 23:37:59 GMT, Jim Laskey  wrote:

>> Somewhat surprisingly, `ArrayList$Sublist.sort()` is not specialized and will thus fall back to slower default method of `List.sort()` instead of sorting a range of the array in-place in its backing root `ArrayList`. 
>> 
>> This doesn't change observable behavior, so haven't added tests, and `tier1` tests still all pass except for `test/jdk/java/util/Locale/LocaleProvidersFormat.java` which also currently fails on master too on the machine I tested on.
>
> Been there since day one?

Just to clarify, my comments about "sorting sublists is rare" is a response to "has this been there since day one?" from @JimLaskey, and it's not an argument against adding this. Maybe it's a bit surprising that it hasn't been done, but maybe not, as the case is somewhat rare. (There are a lot of cases in the collections where various collection views inherit slow implementations from default methods or from the Abstract implementations, because nobody has really cared enough to provide optimized implementations, and it would add bulk to the code.)

CopyOnWriteArrayList needs to override subList.sort since it potentially modifies the array, and COWAL needs to make a copy before making any modifications.

Regarding testing: the tests in `test/jdk/java/util/concurrent/tck` are supposed to be the conformance tests for the java.util.concurrent package, so it'd be somewhat odd to have functional tests for non-juc classes added there. (I did find it surprising that there are ArrayList tests there, but a lot of work in the core collections was done in the context of JSR166, so maybe I shouldn't be too surprised.)

There appears to be some coverage of the List.sort() default method in `test/jdk/java/util/List/ListDefault.java'. It does seem to cover sublists. I guess the question is whether this test is focused on the _default implementation_ of List.sort(), or whether it's intended to cover all implementations -- whether the default or overridden -- of the default methods that were added in JDK 8. I think this area is worth a closer look. If the new ArrayList.subList().sort() override is covered already, we might be able to get away without adding a new test. Or possibly some adjustment could be made to this test if necessary.

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

PR Comment: https://git.openjdk.org/jdk/pull/17818#issuecomment-1944635901

From redestad at openjdk.org  Wed Feb 14 22:12:15 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 14 Feb 2024 22:12:15 GMT
Subject: RFR: 8325340: Add ASCII fast-path to
 Data-/ObjectInputStream.readUTF [v2]
In-Reply-To: 
References: 
Message-ID: 

> Adding a fast-path for ASCII-only modified UTF-8 strings deserialied via Data- and ObjectInputStream
> 
> Testing: tier1-3

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

  Refactor to use a shared impl for slow-path mod-UTF8 decoding

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17734/files
  - new: https://git.openjdk.org/jdk/pull/17734/files/90a805bf..e6a8c312

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

  Stats: 94 lines in 2 files changed: 13 ins; 46 del; 35 mod
  Patch: https://git.openjdk.org/jdk/pull/17734.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17734/head:pull/17734

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

From jlu at openjdk.org  Wed Feb 14 22:34:13 2024
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 14 Feb 2024 22:34:13 GMT
Subject: RFR: JDK-6801704: ChoiceFormat::applyPattern inconsistency for invalid
 patterns
Message-ID: 

Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8317756) which defines the behavior for creating ChoiceFormats with incorrect patterns. The wording is added to both the ChoiceFormat constructor and ChoiceFormat::applyPattern method.

While ideally the inconsistent behavior itself could be fixed, this behavior has been long-standing for 20+ years and the benefit of consistent error handling does not outweigh the risk of breaking applications that may be relying on the "expected" incorrect behavior.

Examples of the range of behavior, (all examples violate the pattern syntax defined in the class description)


// no limit -> throws an expected IllegalArgumentException
var a = new ChoiceFormat("#foo");
// no limit or relation in the last subPattern -> discards the incorrect portion, 'baz' and continues
var b = new ChoiceFormat("0#foo|1#bar|baz"); 
b.format(2); // returns 'bar'
// no relation or limit -> discards the incorrect portion, 'foo' and continues
var c = new ChoiceFormat("foo");
c.format(1); // throws AIOOBE

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

Commit messages:
 - more conservative wording
 - init

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

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

From jlu at openjdk.org  Wed Feb 14 23:10:12 2024
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 14 Feb 2024 23:10:12 GMT
Subject: RFR: JDK-8325908: Finish removal of IntlTest and CollatorTest
Message-ID: 

Please review this PR which fixes / finishes the rest of the IntlTest test framework removal in java.text and java.util.i18n tests.

For context, the IntlTest class only ran methods prefixed by _test_ or _Test_ with public visibility and was originally removed due to some tests spuriously passing that were not aware of the specific running requirements.

This PR includes the following changes,
- There were some tests with package-private visibility that were never ran by IntlTest. Those tests do appear to be valid tests, and thus have been updated with `@Test` annotation.
- The test method DFSExponenTest() in DFSExponential.java was not prefixed by test and thus never ran by IntlTest. It is a valid test and should be ran as well.
- DateFormatRoundTripTest.java was supposed to remain a non JUnit test, however the run invocation was converted to `@run junit ...` this has been switched back to `@run main ...`
- There were two instances of the script missing some tests that should have had their methods updated with the `@Test` annotation: APITest.java and DFSSerialization.java. These tests have been updated accordingly.

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

Commit messages:
 - init

Changes: https://git.openjdk.org/jdk/pull/17858/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17858&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8325908
  Stats: 77 lines in 7 files changed: 46 ins; 11 del; 20 mod
  Patch: https://git.openjdk.org/jdk/pull/17858.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17858/head:pull/17858

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

From prappo at openjdk.org  Wed Feb 14 23:11:04 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 14 Feb 2024 23:11:04 GMT
Subject: RFR: 8325679: Optimize ArrayList subList sort
In-Reply-To: 
References: 
 
 
Message-ID: 

On Wed, 14 Feb 2024 21:22:14 GMT, Stuart Marks  wrote:

> CopyOnWriteArrayList needs to override subList.sort since it potentially modifies the array, and COWAL needs to make a copy before making any modifications.

I admit, I didn't look into that much; I just skimmed through some overrides of `List.sort`. That said, does it mean that before `List.sort`, `Collections.sort`, which had the same implementation that the default `List.sort` now has, would not be able to be properly sort `CopyOnWriteArrayList`?

(Sorry, if I digress.)

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

PR Comment: https://git.openjdk.org/jdk/pull/17818#issuecomment-1944950931

From brent.christian at oracle.com  Wed Feb 14 23:13:07 2024
From: brent.christian at oracle.com (Brent Christian)
Date: Wed, 14 Feb 2024 15:13:07 -0800
Subject: CFV: New Core Libraries Group Member: Raffaello Giulietti
In-Reply-To: <14851B34-A785-4389-9C23-056B8C7E0D7C@oracle.com>
References: <14851B34-A785-4389-9C23-056B8C7E0D7C@oracle.com>
Message-ID: <858616f5-f82e-41a0-992c-033fc4765b7e@oracle.com>

Vote: Yes

On 2/13/2024 12:25 PM, Brian Burkhalter wrote:
> I hereby nominate Raffaello Giulietti to Membership in the Core Libraries Group.
> 
> Raffaello has been working in the Core Library team at Oracle since April, 2022. He has authored more than 50 contributions to OpenJDK in a number of areas including numerics, formatting, regular expressions, and random number generation.
> 
> Votes are due by Wednesday, February 28, 2023.
> 
> Only current Members of the Core Libraries Group [1] are eligible
> to vote on this nomination.  Votes must be cast in the open by
> replying to this mailing list
> 
> For Lazy Consensus voting instructions, see [2].
> 
> Brian Burkhalter
> 
> [1] https://openjdk.org/census#core-libs
> [2] https://openjdk.org/groups/#member-vote

From redestad at openjdk.org  Wed Feb 14 23:32:17 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 14 Feb 2024 23:32:17 GMT
Subject: RFR: 8325340: Add ASCII fast-path to
 Data-/ObjectInputStream.readUTF [v3]
In-Reply-To: 
References: 
Message-ID: <2_qXqLlAdhLofohkeDtG8DiInZG8tCiISprn6YtI5Cc=.768ae3b0-70df-481d-aab6-08d7651f4df6@github.com>

> Adding a fast-path for ASCII-only modified UTF-8 strings deserialied via Data- and ObjectInputStream
> 
> Testing: tier1-3

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

  Revert "Refactor to use a shared impl for slow-path mod-UTF8 decoding"
  
  This reverts commit e6a8c3120b7f9c96a66ba40c27f8352735cdb588.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17734/files
  - new: https://git.openjdk.org/jdk/pull/17734/files/e6a8c312..5655826b

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

  Stats: 94 lines in 2 files changed: 46 ins; 13 del; 35 mod
  Patch: https://git.openjdk.org/jdk/pull/17734.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17734/head:pull/17734

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

From davidalayachew at gmail.com  Wed Feb 14 23:36:32 2024
From: davidalayachew at gmail.com (David Alayachew)
Date: Wed, 14 Feb 2024 18:36:32 -0500
Subject: Thoughts on a new method for equality on java.util.Objects?
In-Reply-To: 
References: 
 
 
 
Message-ID: 

Thank you to Stuart, Michel, and Joe for taking care of closing my
enhancement and adding helpful comments, I appreciate it!

On Sun, Feb 11, 2024, 5:13?AM David Alayachew 
wrote:

> Since I am abandoning this idea, could someone close my JBS ticket?
>
> And please link this message in the core-libs-dev archives as the close
> reason -- I fear the potential for misuse, as mentioned in previous emails
> on this thread.
>
> https://bugs.openjdk.org/browse/JDK-8324718
>
>
> On Sun, Feb 11, 2024 at 5:10?AM David Alayachew 
> wrote:
>
>> Hello,
>>
>> Thank you for your response!
>>
>> So, I had thought of that before posting this email, and mentally, I had
>> hand-waved away the concern by saying that there were plenty of situations
>> where equality would still be useful without hashing. And while I still
>> very much feel the same, the way you phrased your question is making me
>> realize that my proposal could double nicely as a foot gun.
>>
>> Like you said -- Java's concept of equality is often attached to the
>> concept of hashing. And while the 2 are permitted to exist out of alignment
>> with each other, handling the asymmetric relationship is a dangerous
>> balancing act that is error-prone.
>>
>> I fear that this method would be handing developer a foot gun. There
>> already exists a large number of bugs caused by misalignment between equals
>> and hashCode, and I see how this method would contribute to exactly that
>> problem. Understanding that, I myself don't feel comfortable pushing this
>> method forward.
>>
>> That said, I do appreciate you , @Philip Race  , @Alan
>> Bateman  , and @-  for
>> being helpful as I go through the process. If nothing else, this was
>> educational, and I now know exactly what concerns my next proposal should
>> keep in mind when I try again.
>>
>> And I see the value of "socializing", as @Alan Bateman
>>  put it. I had thought this idea through
>> plenty, but I can only see from my perspective.
>>
>> Thank you all for your time and help!
>> David Alayachew
>>
>> On Sun, Feb 11, 2024 at 3:26?AM Holo The Sage Wolf 
>> wrote:
>>
>>> How beneficial is it to extend equality method without appropriate
>>> hashing?
>>>
>>> Specifically, given you are working in a domain specific world, e.g.
>>> projection of Point3D into XY with equality semantics of equalsByXY, Java
>>> does not know how to treat semantically equal objects as equal:
>>>
>>> var foo = new Point3D(0,0,0);
>>> var bar = new Point3D(0,0,1);
>>> var set = new HashSet<>(Arrays.asList(foo, bar));
>>> assert set.size() == 1 \\ assertion failure :(
>>>
>>> The idea is fine, but you need to wrap a lot of Java's Standard Library
>>> to respect the new semantics.
>>>
>>> I think that the idea can work nicely as a library, but not inside java.*
>>>
>>>
>>> On Sun, 11 Feb 2024, 07:41 David Alayachew, 
>>> wrote:
>>>
>>>> Hello Core Libs Dev Team,
>>>>
>>>> I jumped the gun a bit and made a PR for this first. Alan Bateman
>>>> kindly informed me of my faux pas, and now I'm trying to redo things
>>>> correctly.
>>>>
>>>> I am looking to add a new method to java.util.Objects to facilitate
>>>> equality checks, something that I hope fits well in place with the other
>>>> methods in this class.
>>>>
>>>> Here is my basic idea. (Special thanks to @liach for guidance in
>>>> creating this!)
>>>>
>>>> ```java
>>>> import java.util.*;
>>>> import java.util.function.*;
>>>>
>>>> import static java.util.Objects.*;
>>>>
>>>> public class Objects2
>>>> {
>>>>
>>>>    public static  BiPredicate equalsBy(final List>>> ?>> functions)
>>>>    {
>>>>
>>>>       requireNonNull(functions, "Objects.equalsBy cannot execute
>>>> because the parameter is null!");
>>>>
>>>>       return
>>>>          (final T o1, final T o2) ->
>>>>          {
>>>>
>>>>             requireNonNull(o1, "Cannot check for equality because the
>>>> first object is null!");
>>>>             requireNonNull(o2, "Cannot check for equality because the
>>>> second object is null!");
>>>>
>>>>             for (final var function : functions)
>>>>             {
>>>>
>>>>                requireNonNull(function, "Cannot check for equality
>>>> because the function is null!");
>>>>
>>>>                final var r1 = function.apply(o1);
>>>>                final var r2 = function.apply(o2);
>>>>
>>>>                final boolean theyAreEqual = Objects.equals(r1, r2);
>>>>
>>>>                if (!theyAreEqual)
>>>>                {
>>>>
>>>>                   return false;
>>>>
>>>>                }
>>>>
>>>>             }
>>>>
>>>>             return true;
>>>>
>>>>          }
>>>>          ;
>>>>
>>>>    }
>>>>
>>>>    public static void main(final String[] args)
>>>>    {
>>>>
>>>>       record Point3D(int x, String y, int z) {}
>>>>
>>>>       final Point3D a = new Point3D(1, "2", 3);
>>>>       final Point3D b = new Point3D(1, "2", 4);
>>>>
>>>>       final BiPredicate equalsByXY  =
>>>> equalsBy(List.of(Point3D::x, Point3D::y));
>>>>       final BiPredicate equalsByXYZ =
>>>> equalsBy(List.of(Point3D::x, Point3D::y, Point3D::z));
>>>>
>>>>       System.out.println(equalsByXY.test(a, b));  //true
>>>>       System.out.println(equalsByXYZ.test(a, b)); //false
>>>>
>>>>    }
>>>>
>>>> }
>>>> ```
>>>>
>>>> The concept is simple -- I want to make it easy to create ad-hoc equals
>>>> methods.
>>>>
>>>> Object equality is domain-specific -- in some domains, 2 objects are
>>>> equal, but in another, they are not. The object's equals method is not
>>>> always a good spot to put this logic into, largely because we don't always
>>>> know what domain we are in. The object's equals method is where a good
>>>> default should be placed, not logic for every domain. And even if we tried,
>>>> it's difficult, if not impossible, to apply equality for the correct domain
>>>> if both objects are of the same type.
>>>>
>>>> So, for domain-specific contexts, I would like to introduce this
>>>> method. This method (which should be constant-foldable, thanks again for
>>>> the help @liach!) lets you clearly say that you are taking 2 objects and
>>>> comparing them by the following methods that apply to both. And due to the
>>>> nature of lambdas, developers are not constrained to just the getters of
>>>> the object in question -- any function that takes in T is fair game. This
>>>> allows flexibility, and lets developers keep their objects simple, thus
>>>> facilitating things like DOP.
>>>>
>>>> Now, perhaps this makes more sense on the BiPredicate interface
>>>> instead. However, since this was more equality focused, I figured Objects
>>>> was a better fit.
>>>>
>>>> Any thoughts?
>>>>
>>>> Thank you all for your time and help!
>>>> David Alayachew
>>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From smarks at openjdk.org  Wed Feb 14 23:40:04 2024
From: smarks at openjdk.org (Stuart Marks)
Date: Wed, 14 Feb 2024 23:40:04 GMT
Subject: RFR: 8325679: Optimize ArrayList subList sort
In-Reply-To: 
References: 
Message-ID: 

On Mon, 12 Feb 2024 22:52:51 GMT, Attila Szegedi  wrote:

> Somewhat surprisingly, `ArrayList$Sublist.sort()` is not specialized and will thus fall back to slower default method of `List.sort()` instead of sorting a range of the array in-place in its backing root `ArrayList`. 
> 
> This doesn't change observable behavior, so haven't added tests, and `tier1` tests still all pass except for `test/jdk/java/util/Locale/LocaleProvidersFormat.java` which also currently fails on master too on the machine I tested on.

(Discussion mainly of historical interest.)

@pavelrappo Correct, historically, `Collections.sort` would fail to sort `CopyOnWriteArrayList`. You have to go back to JDK 7 to see this. The sorting approach used by `Collections.sort` (still present in the default implementation of `List.sort`) gets an array using `toArray()`, sorts it, and then copies the sorted elements back using `ListIterator.set`. Since `CopyOnWriteArrayList` doesn't support modifications using `ListIterator`, it fails with `UnsupportedOperationException`. The overrides of `List.sort` have fixed this problem.

COWAL still has some problems with other things that use similar techniques, such as `Collections.shuffle`. That uses get/set to swap elements, which COWAL does support, but it copies the array on each set() operation. This results in N copies of the array being made for an N-element list.

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

PR Comment: https://git.openjdk.org/jdk/pull/17818#issuecomment-1945025984

From naoto at openjdk.org  Thu Feb 15 00:18:03 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 15 Feb 2024 00:18:03 GMT
Subject: RFR: JDK-8325908: Finish removal of IntlTest and CollatorTest
In-Reply-To: 
References: 
Message-ID: <7w7zIBaA8EhH2zWzH2wSjcPt368AID8DJPIElzEc4yc=.b58f185c-0ab2-4e7e-9f03-5eb13e7d6091@github.com>

On Wed, 14 Feb 2024 23:05:25 GMT, Justin Lu  wrote:

> Please review this PR which fixes / finishes the rest of the IntlTest test framework removal in java.text and java.util.i18n tests.
> 
> For context, the IntlTest class only ran methods prefixed by _test_ or _Test_ with public visibility and was originally removed due to some tests spuriously passing that were not aware of the specific running requirements.
> 
> This PR includes the following changes,
> - There were some tests with package-private visibility that were never ran by IntlTest. Those tests do appear to be valid tests, and thus have been updated with `@Test` annotation.
> - The test method DFSExponenTest() in DFSExponential.java was not prefixed by test and thus never ran by IntlTest. It is a valid test and should be ran as well.
> - DateFormatRoundTripTest.java was supposed to remain a non JUnit test, however the run invocation was converted to `@run junit ...` this has been switched back to `@run main ...`
> - There were two instances of the script missing some tests that should have had their methods updated with the `@Test` annotation: APITest.java and DFSSerialization.java. These tests have been updated accordingly.

LGTM

test/jdk/java/text/Format/NumberFormat/DFSExponential.java line 44:

> 42: 
> 43:     @Test
> 44:     public void DFSExponenTest() throws Exception {

Not your change, but the method name reads odd to me. `TestDFSExponential` may be better alined with the other test for serialization.

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17858#pullrequestreview-1881533695
PR Review Comment: https://git.openjdk.org/jdk/pull/17858#discussion_r1490216492

From jlu at openjdk.org  Thu Feb 15 00:31:15 2024
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 15 Feb 2024 00:31:15 GMT
Subject: RFR: JDK-8325908: Finish removal of IntlTest and CollatorTest [v2]
In-Reply-To: 
References: 
Message-ID: 

> Please review this PR which fixes / finishes the rest of the IntlTest test framework removal in java.text and java.util.i18n tests.
> 
> For context, the IntlTest class only ran methods prefixed by _test_ or _Test_ with public visibility and was originally removed due to some tests spuriously passing that were not aware of the specific running requirements.
> 
> This PR includes the following changes,
> - There were some tests with package-private visibility that were never ran by IntlTest. Those tests do appear to be valid tests, and thus have been updated with `@Test` annotation.
> - The test method DFSExponenTest() in DFSExponential.java was not prefixed by test and thus never ran by IntlTest. It is a valid test and should be ran as well.
> - DateFormatRoundTripTest.java was supposed to remain a non JUnit test, however the run invocation was converted to `@run junit ...` this has been switched back to `@run main ...`
> - There were two instances of the script missing some tests that should have had their methods updated with the `@Test` annotation: APITest.java and DFSSerialization.java. These tests have been updated accordingly.

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

  improve method name as suggested, remove unusued clutter

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17858/files
  - new: https://git.openjdk.org/jdk/pull/17858/files/c04309a7..35f06d62

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

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

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

From jlu at openjdk.org  Thu Feb 15 00:31:15 2024
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 15 Feb 2024 00:31:15 GMT
Subject: RFR: JDK-8325908: Finish removal of IntlTest and CollatorTest [v2]
In-Reply-To: <7w7zIBaA8EhH2zWzH2wSjcPt368AID8DJPIElzEc4yc=.b58f185c-0ab2-4e7e-9f03-5eb13e7d6091@github.com>
References: 
 <7w7zIBaA8EhH2zWzH2wSjcPt368AID8DJPIElzEc4yc=.b58f185c-0ab2-4e7e-9f03-5eb13e7d6091@github.com>
Message-ID: 

On Thu, 15 Feb 2024 00:13:28 GMT, Naoto Sato  wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   improve method name as suggested, remove unusued clutter
>
> test/jdk/java/text/Format/NumberFormat/DFSExponential.java line 44:
> 
>> 42: 
>> 43:     @Test
>> 44:     public void DFSExponenTest() throws Exception {
> 
> Not your change, but the method name reads odd to me. `TestDFSExponential` may be better alined with the other test for serialization.

Done, thanks for the review.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17858#discussion_r1490224498

From sgibbons at openjdk.org  Thu Feb 15 01:27:21 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Thu, 15 Feb 2024 01:27:21 GMT
Subject: RFR: JDK-8320448 Accelerate IndexOf using AVX2 [v11]
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:

  Change copy to stack to be only if hs size - needle size > 10

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16753/files
  - new: https://git.openjdk.org/jdk/pull/16753/files/8638a5f4..71ebf9e7

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

  Stats: 20 lines in 1 file changed: 7 ins; 6 del; 7 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 duke at openjdk.org  Thu Feb 15 05:11:06 2024
From: duke at openjdk.org (duke)
Date: Thu, 15 Feb 2024 05:11:06 GMT
Subject: Withdrawn: 8294960: Convert java.base/java.lang.invoke package to use
 the Classfile API to generate lambdas and method handles
In-Reply-To: 
References: 
Message-ID: 

On Thu, 14 Dec 2023 12:39:52 GMT, Adam Sotona  wrote:

> java.base java.lang.invoke package heavily uses ASM to generate lambdas and method handles.
> 
> This patch converts ASM calls to Classfile API.
> 
> This PR is continuation of https://github.com/openjdk/jdk/pull/12945
> 
> Any comments and suggestions are welcome.
> 
> Please review.
> 
> Thank you,
> Adam

This pull request has been closed without being integrated.

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

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

From cstein at openjdk.org  Thu Feb 15 06:29:24 2024
From: cstein at openjdk.org (Christian Stein)
Date: Thu, 15 Feb 2024 06:29:24 GMT
Subject: RFR: 8318812: LauncherHelper.checkAndLoadMain closes jar file
 that's about to be re-opened [v2]
In-Reply-To: 
References: 
Message-ID: <5p6LlYPi8V2bxmBvggJJqfrEeOEr9r-foY9yZOQMFbg=.616900a0-6652-4fde-aa74-1e9745d0fe07@github.com>

> Please review this PR that makes the launcher helper keep a reference to the executable JAR file active after extracting the name of the main class and returning it as Class instance. Now, when loading classes from the JAR file, it hasn't to be re-opened.

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

 - Remove `String jarname` from `getMainClassFromJar`'s signature
 - Introduce and use dedicated on-close error message

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17843/files
  - new: https://git.openjdk.org/jdk/pull/17843/files/bd0927d3..202a4ef4

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

  Stats: 81 lines in 2 files changed: 18 ins; 18 del; 45 mod
  Patch: https://git.openjdk.org/jdk/pull/17843.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17843/head:pull/17843

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

From alanb at openjdk.org  Thu Feb 15 08:55:53 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 15 Feb 2024 08:55:53 GMT
Subject: RFR: 8318812: LauncherHelper.checkAndLoadMain closes jar file
 that's about to be re-opened [v2]
In-Reply-To: <5p6LlYPi8V2bxmBvggJJqfrEeOEr9r-foY9yZOQMFbg=.616900a0-6652-4fde-aa74-1e9745d0fe07@github.com>
References: 
 <5p6LlYPi8V2bxmBvggJJqfrEeOEr9r-foY9yZOQMFbg=.616900a0-6652-4fde-aa74-1e9745d0fe07@github.com>
Message-ID: 

On Thu, 15 Feb 2024 06:29:24 GMT, Christian Stein  wrote:

>> Please review this PR that makes the launcher helper keep a reference to the executable JAR file active after extracting the name of the main class and returning it as Class instance. Now, when loading classes from the JAR file, it hasn't to be re-opened.
>
> Christian Stein has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove `String jarname` from `getMainClassFromJar`'s signature
>  - Introduce and use dedicated on-close error message

Updated version looks good to me.

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17843#pullrequestreview-1882142536

From alanb at openjdk.org  Thu Feb 15 08:55:54 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 15 Feb 2024 08:55:54 GMT
Subject: RFR: 8318812: LauncherHelper.checkAndLoadMain closes jar file
 that's about to be re-opened [v2]
In-Reply-To: <3GZWKZF6hJQw6Q5iQR40bVocP8qGj2dNLLwDhK9RrLM=.3a3aa6cb-e91e-4d4a-b8f8-e771772ca48b@github.com>
References: 
 
 <3GZWKZF6hJQw6Q5iQR40bVocP8qGj2dNLLwDhK9RrLM=.3a3aa6cb-e91e-4d4a-b8f8-e771772ca48b@github.com>
Message-ID: 

On Wed, 14 Feb 2024 15:42:48 GMT, Christian Stein  wrote:

> `String jarname` is filled by the caller with the value of `String what`, and therefore contains the entire path to the executable JAR file. Using only `jarFile.getName()` will prevent any parent directories from being noted in error messages; which might affect some tests

It returns the path name so I think it does what we want. Do you observe a behavior difference?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17843#discussion_r1490650825

From redestad at openjdk.org  Thu Feb 15 10:30:20 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Thu, 15 Feb 2024 10:30:20 GMT
Subject: RFR: 8325340: Add ASCII fast-path to
 Data-/ObjectInputStream.readUTF [v4]
In-Reply-To: 
References: 
Message-ID: 

> Adding a fast-path for ASCII-only modified UTF-8 strings deserialied via Data- and ObjectInputStream
> 
> Testing: tier1-3

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

  Revert changes to DataInputStream

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17734/files
  - new: https://git.openjdk.org/jdk/pull/17734/files/5655826b..3e712648

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

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

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

From redestad at openjdk.org  Thu Feb 15 10:33:07 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Thu, 15 Feb 2024 10:33:07 GMT
Subject: RFR: 8325340: Add ASCII fast-path to
 Data-/ObjectInputStream.readUTF [v5]
In-Reply-To: 
References: 
Message-ID: <8-ZU83v8i-p_Md_Qrx2qgqTJvwPq0sY691aD6dPSYJ8=.00c58942-6eab-4aef-8fbf-1d8b2702bf05@github.com>

> Adding a fast-path for ASCII-only modified UTF-8 strings deserialied via Data- and ObjectInputStream
> 
> Testing: tier1-3

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

  Revert spurious formatting changes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17734/files
  - new: https://git.openjdk.org/jdk/pull/17734/files/3e712648..ca2b09c6

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

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

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

From redestad at openjdk.org  Thu Feb 15 10:38:06 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Thu, 15 Feb 2024 10:38:06 GMT
Subject: RFR: 8325340: Add ASCII fast-path to
 Data-/ObjectInputStream.readUTF [v5]
In-Reply-To: <8-ZU83v8i-p_Md_Qrx2qgqTJvwPq0sY691aD6dPSYJ8=.00c58942-6eab-4aef-8fbf-1d8b2702bf05@github.com>
References: 
 <8-ZU83v8i-p_Md_Qrx2qgqTJvwPq0sY691aD6dPSYJ8=.00c58942-6eab-4aef-8fbf-1d8b2702bf05@github.com>
Message-ID: <4Yh-5DOHMZMWJVC21CZ5Ui9Pk9LYOO0vjs4c_0bFjoA=.ecb569ef-f2ee-47c9-8cc5-31940b2b2cd7@github.com>

On Thu, 15 Feb 2024 10:33:07 GMT, Claes Redestad  wrote:

>> Adding a fast-path for ASCII-only modified UTF-8 strings deserialied via Data- and ObjectInputStream
>> 
>> Testing: tier1-3
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert spurious formatting changes

After some deliberation I decided to back out the proposed changes to `DataInputStream`. It sees less of a speed-up in my tests thanks to an existing simple fast-path - and there are paths through the code that are not covered by these microbenchmarks.

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

PR Comment: https://git.openjdk.org/jdk/pull/17734#issuecomment-1945796077

From redestad at openjdk.org  Thu Feb 15 10:47:04 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Thu, 15 Feb 2024 10:47:04 GMT
Subject: RFR: 8325340: Add ASCII fast-path to
 Data-/ObjectInputStream.readUTF
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 14 Feb 2024 20:04:42 GMT, Brian Burkhalter  wrote:

> As there are no regression tests added by this request, I assume that existing tests must sufficiently cover this area. If so, however, the issue has no `noreg-` label.

At least for `ObjectInputStream` there's a large and seemingly very thorough selection of often randomized tests that explicitly and implicitly exercises `readUTF`, including most of the tests in `java/io/Serializable`. `DataInputStream` tests seem less thorough, though that doesn't matter for this since I'm pulling out those changes. I added `noreg-perf` to the bug.

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

PR Comment: https://git.openjdk.org/jdk/pull/17734#issuecomment-1945820085

From rgiulietti at openjdk.org  Thu Feb 15 10:57:54 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 15 Feb 2024 10:57:54 GMT
Subject: RFR: 8325340: Add ASCII fast-path to
 Data-/ObjectInputStream.readUTF [v5]
In-Reply-To: 
References: 
 
 <0ql4FUUK2bFwDWVXGrZwHic4nN5iyUIE4pZAMEQncIo=.b2b69c82-1bfb-4542-977b-32a582755f64@github.com>
 
 
Message-ID: 

On Wed, 14 Feb 2024 14:30:02 GMT, Claes Redestad  wrote:

>> Ah OK.
>> 
>> I didn't check the current code, only the proposed one.
>> Although the specification clearly states that the method should throw, if the current code does not throw on zeros, then it makes sense that the proposed one shouldn't either.
>
> The specification is somewhat ambiguous:
> https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/io/DataInput.html#readUTF()
> 
> There's a sweeping `Throws UTFDataFormatException - if the bytes do not represent a valid modified UTF-8 encoding of a string` but also: `If the first byte of a group matches the bit pattern 0xxxxxxx (where x means "may be 0 or 1"), then the group consists of just that byte. The byte is zero-extended to form a character.` I think the latter gives some leeway on being lenient on embedded zeros, even if it's made clear elsewhere that valid encoders need to replace zeros with the `0xC0, 0x80` sequence.

In fact, the implementations of `readUTF*()` in `DataInputStream` and `ObjectInputStream` are much more lenient than that. They also accept ASCII characters that are encoded with 2 bytes instead of 1. There's no check that the encoding is "minimal length".

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17734#discussion_r1490820923

From rgiulietti at openjdk.org  Thu Feb 15 11:03:02 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 15 Feb 2024 11:03:02 GMT
Subject: RFR: 8325340: Add ASCII fast-path to
 Data-/ObjectInputStream.readUTF [v5]
In-Reply-To: 
References: 
 
 <0ql4FUUK2bFwDWVXGrZwHic4nN5iyUIE4pZAMEQncIo=.b2b69c82-1bfb-4542-977b-32a582755f64@github.com>
 
 
 
Message-ID: 

On Thu, 15 Feb 2024 10:55:38 GMT, Raffaello Giulietti  wrote:

>> The specification is somewhat ambiguous:
>> https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/io/DataInput.html#readUTF()
>> 
>> There's a sweeping `Throws UTFDataFormatException - if the bytes do not represent a valid modified UTF-8 encoding of a string` but also: `If the first byte of a group matches the bit pattern 0xxxxxxx (where x means "may be 0 or 1"), then the group consists of just that byte. The byte is zero-extended to form a character.` I think the latter gives some leeway on being lenient on embedded zeros, even if it's made clear elsewhere that valid encoders need to replace zeros with the `0xC0, 0x80` sequence.
>
> In fact, the implementations of `readUTF*()` in `DataInputStream` and `ObjectInputStream` are much more lenient than that. They also accept ASCII characters that are encoded with 2 bytes instead of 1. There's no check that the encoding is "minimal length".

This is according to `DataInput` specification.
So what `UTFDataFormatException` means is kind of ambiguous.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17734#discussion_r1490826777

From rgiulietti at openjdk.org  Thu Feb 15 12:03:54 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 15 Feb 2024 12:03:54 GMT
Subject: RFR: 8325340: Add ASCII fast-path to
 Data-/ObjectInputStream.readUTF [v5]
In-Reply-To: <8-ZU83v8i-p_Md_Qrx2qgqTJvwPq0sY691aD6dPSYJ8=.00c58942-6eab-4aef-8fbf-1d8b2702bf05@github.com>
References: 
 <8-ZU83v8i-p_Md_Qrx2qgqTJvwPq0sY691aD6dPSYJ8=.00c58942-6eab-4aef-8fbf-1d8b2702bf05@github.com>
Message-ID: 

On Thu, 15 Feb 2024 10:33:07 GMT, Claes Redestad  wrote:

>> Adding a fast-path for ASCII-only modified UTF-8 strings deserialied via Data- and ObjectInputStream
>> 
>> Testing: tier1-3
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert spurious formatting changes

src/java.base/share/classes/java/io/DataInputStream.java line 574:

> 572:      * @see        java.io.DataInputStream#readUnsignedShort()
> 573:      */
> 574:     public static final String readUTF(DataInput in) throws IOException {

Suggestion:

    public static String readUTF(DataInput in) throws IOException {

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17734#discussion_r1490827814

From ihse at openjdk.org  Thu Feb 15 12:29:23 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 15 Feb 2024 12:29:23 GMT
Subject: RFR: 8325950: Make sure all files in the JDK pass jcheck
Message-ID: <8OFfLzjcABtbqaxklrESgILudN93NzwtNzEJxoOBMoM=.50f8e451-2ef4-467c-9c6b-7ae795428748@github.com>

Since jcheck only checks file in a commit, there is a possibility of us getting files in the repository that would not be accepted by jcheck. This can happen when extending the set of files checked by jcheck, or if jcheck changes how it checks files (perhaps due to bug fixes).

I have now run jcheck over the entire code base, and fixed a handful of issues. With these changes, jcheck accept the entire code base.

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

Commit messages:
 - 8325950: Make sure all files in the JDK pass jcheck

Changes: https://git.openjdk.org/jdk/pull/17871/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17871&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8325950
  Stats: 113 lines in 38 files changed: 0 ins; 10 del; 103 mod
  Patch: https://git.openjdk.org/jdk/pull/17871.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17871/head:pull/17871

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

From ihse at openjdk.org  Thu Feb 15 12:29:24 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 15 Feb 2024 12:29:24 GMT
Subject: RFR: 8325950: Make sure all files in the JDK pass jcheck
In-Reply-To: <8OFfLzjcABtbqaxklrESgILudN93NzwtNzEJxoOBMoM=.50f8e451-2ef4-467c-9c6b-7ae795428748@github.com>
References: <8OFfLzjcABtbqaxklrESgILudN93NzwtNzEJxoOBMoM=.50f8e451-2ef4-467c-9c6b-7ae795428748@github.com>
Message-ID: 

On Thu, 15 Feb 2024 12:19:31 GMT, Magnus Ihse Bursie  wrote:

> Since jcheck only checks file in a commit, there is a possibility of us getting files in the repository that would not be accepted by jcheck. This can happen when extending the set of files checked by jcheck, or if jcheck changes how it checks files (perhaps due to bug fixes).
> 
> I have now run jcheck over the entire code base, and fixed a handful of issues. With these changes, jcheck accept the entire code base.

Some general remarks: The problems in .m4 files where not properly detected and fixed when I added .m4 to the list of checked files. The properties files were recently checked by me, so these suprrised me. It turned out I had misunderstood the jcheck criteria: I thought only leading tabs were disallowed, but it is actually tabs anywhere in the file that are banned.

In general, I have replaced tab characters with spaces aligning to tab stops at 8 characters distance. 

I'll leave some remarks for individual files.

src/java.naming/share/classes/com/sun/jndi/ldap/jndiprovider.properties line 10:

> 8: java.naming.factory.object=com.sun.jndi.ldap.obj.AttrsToCorba:com.sun.jndi.ldap.obj.MarshalledToObject
> 9: 
> 10: # RemoteToAttrs: Turn RMI/JRMP and RMI/IIOP object into javaMarshalledObject or

I adjusted this tab stop (with one space) so it aligned properly with the line above; I think that was the intention.

src/jdk.jdeps/share/classes/com/sun/tools/jdeps/resources/jdkinternals.properties line 41:

> 39: jdk.internal.ref.Cleaner=Use java.lang.ref.PhantomReference @since 1.2 or java.lang.ref.Cleaner @since 9
> 40: sun.awt.CausedFocusEvent=Use java.awt.event.FocusEvent::getCause @since 9
> 41: sun.font.FontUtilities=See java.awt.Font.textRequiresLayout	@since 9

This tab just looked out of place, so I replaced it with a space. (Rhyming not intentional...)

test/hotspot/jtreg/containers/docker/JfrReporter.java line 52:

> 50:             }
> 51:         }
> 52:     }

I'm not sure how a Java file ever got into the code base with trailing spaces, but a guess is that there have been a bug in jcheck that did not properly check for trailing whitespace at the end of the file, or something like that.

test/jdk/java/util/Currency/currency.properties line 18:

> 16: SB=EUR,111,2, 2099-01-01T00:00:00
> 17: US=euR,978,2,2001-01-01T00:00:00
> 18: ZZ	=	ZZZ	,	999	,	3

This looks weird, but so did the original code. I assume this is to clearly indicate this as a end of list marker.

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

PR Comment: https://git.openjdk.org/jdk/pull/17871#issuecomment-1945992837
PR Review Comment: https://git.openjdk.org/jdk/pull/17871#discussion_r1490931378
PR Review Comment: https://git.openjdk.org/jdk/pull/17871#discussion_r1490931979
PR Review Comment: https://git.openjdk.org/jdk/pull/17871#discussion_r1490933432
PR Review Comment: https://git.openjdk.org/jdk/pull/17871#discussion_r1490934063

From redestad at openjdk.org  Thu Feb 15 13:07:20 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Thu, 15 Feb 2024 13:07:20 GMT
Subject: RFR: 8325340: Add ASCII fast-path to
 Data-/ObjectInputStream.readUTF [v6]
In-Reply-To: 
References: 
Message-ID: 

> Adding a fast-path for ASCII-only modified UTF-8 strings deserialied via Data- and ObjectInputStream
> 
> Testing: tier1-3

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

  Update src/java.base/share/classes/java/io/DataInputStream.java
  
  Co-authored-by: Raffaello Giulietti 

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17734/files
  - new: https://git.openjdk.org/jdk/pull/17734/files/ca2b09c6..48902ad2

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

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

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

From rrich at openjdk.org  Thu Feb 15 13:35:24 2024
From: rrich at openjdk.org (Richard Reingruber)
Date: Thu, 15 Feb 2024 13:35:24 GMT
Subject: RFR: 8323782: Race: Thread::interrupt vs.
 AbstractInterruptibleChannel.begin [v4]
In-Reply-To: 
References: 
Message-ID: 

> Set `interrupted` in `Thread::interrupt` before reading `nioBlocker` for correct (Dekker scheme) synchronization with concurrent execution of [`AbstractInterruptibleChannel::begin`](https://github.com/openjdk/jdk/blob/59062402b9c5ed5612a13c1c40eb22cf1b97c41a/src/java.base/share/classes/java/nio/channels/spi/AbstractInterruptibleChannel.java#L176).
> 
> The change passed our CI functional testing: JTReg tests: tier1-4 of hotspot and jdk. All of Langtools and jaxp. SPECjvm2008, SPECjbb2015, Renaissance Suite, and SAP specific tests.
> Testing was done with fastdebug and release builds on the main platforms and also on Linux/PPC64le and AIX.

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

 - Merge branch 'master' into 8323782__Race__Thread__interrupt_vs__AbstractInterruptibleChannel_begin
 - Merge branch 'master' into 8323782__Race__Thread__interrupt_vs__AbstractInterruptibleChannel_begin
 - Review Alan
 - New version of LotsOfInterrupts.java supporting virtual threads
 - Add Alan's LotsOfInterrupts.java test
 - Must checkAccess before changing interrupt state of other thread
 - 8323782: Race: Thread::interrupt vs. AbstractInterruptibleChannel.begin

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17444/files
  - new: https://git.openjdk.org/jdk/pull/17444/files/81a9f812..d9a71c2e

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

  Stats: 25934 lines in 915 files changed: 11079 ins; 9566 del; 5289 mod
  Patch: https://git.openjdk.org/jdk/pull/17444.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17444/head:pull/17444

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

From erikj at openjdk.org  Thu Feb 15 14:05:12 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 15 Feb 2024 14:05:12 GMT
Subject: RFR: 8325950: Make sure all files in the JDK pass jcheck
In-Reply-To: 
References: <8OFfLzjcABtbqaxklrESgILudN93NzwtNzEJxoOBMoM=.50f8e451-2ef4-467c-9c6b-7ae795428748@github.com>
 
Message-ID: 

On Thu, 15 Feb 2024 12:26:11 GMT, Magnus Ihse Bursie  wrote:

>> Since jcheck only checks file in a commit, there is a possibility of us getting files in the repository that would not be accepted by jcheck. This can happen when extending the set of files checked by jcheck, or if jcheck changes how it checks files (perhaps due to bug fixes).
>> 
>> I have now run jcheck over the entire code base, and fixed a handful of issues. With these changes, jcheck accept the entire code base.
>
> test/jdk/java/util/Currency/currency.properties line 18:
> 
>> 16: SB=EUR,111,2, 2099-01-01T00:00:00
>> 17: US=euR,978,2,2001-01-01T00:00:00
>> 18: ZZ	=	ZZZ	,	999	,	3
> 
> This looks weird, but so did the original code. I assume this is to clearly indicate this as a end of list marker.

This looks weird indeed. Luckily it's just test code. Did you run the test after this change?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17871#discussion_r1491056108

From clanger at openjdk.org  Thu Feb 15 15:11:15 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Thu, 15 Feb 2024 15:11:15 GMT
Subject: RFR: 8325579: Inconsistent behavior in
 com.sun.jndi.ldap.Connection::createSocket [v3]
In-Reply-To: 
References: 
Message-ID: 

> During analysing a customer case I figured out that we have an inconsistency between documentation and actual behavior in class com.sun.jndi.ldap.Connection. The [method documentation of com.sun.jndi.ldap.Connection::createSocket](https://github.com/openjdk/jdk/blob/3ebe6c192a5dd5cc46ae2d263713c9ff38cd46bb/src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java#L281) states: "If a timeout is supplied but unconnected sockets are not supported then the timeout is ignored and a connected socket is created."
> 
> This, however does not happen. If a SocketFactory would not support unconnected sockets, it would likely throw a SocketException in [SocketFactory::createSocket()](https://github.com/openjdk/jdk/blob/6303c0e7136436a2d3cb6043b88edf788c0067cc/src/java.base/share/classes/javax/net/SocketFactory.java#L123). And since [the code](https://github.com/openjdk/jdk/blob/3ebe6c192a5dd5cc46ae2d263713c9ff38cd46bb/src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java#L336) does not check for this behavior, a connection with timeout value through a SocketFactory that does not support unconnected sockets would simply fail with an IOException.
> 
> So we should either make the code adhere to what is documented or adapt the documentation to the actual behavior.
> 
> I hereby try to fix the connect coding. Alternatively, we could also adapt the description - I have no strong opinion. What do the experts suggest?

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

 - Enhance test
 - JDK-8325579

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

Changes: https://git.openjdk.org/jdk/pull/17797/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17797&range=02
  Stats: 235 lines in 3 files changed: 128 ins; 29 del; 78 mod
  Patch: https://git.openjdk.org/jdk/pull/17797.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17797/head:pull/17797

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

From clanger at openjdk.org  Thu Feb 15 15:25:53 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Thu, 15 Feb 2024 15:25:53 GMT
Subject: RFR: 8325579: Inconsistent behavior in
 com.sun.jndi.ldap.Connection::createSocket [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 15 Feb 2024 15:11:15 GMT, Christoph Langer  wrote:

>> During analysing a customer case I figured out that we have an inconsistency between documentation and actual behavior in class com.sun.jndi.ldap.Connection. The [method documentation of com.sun.jndi.ldap.Connection::createSocket](https://github.com/openjdk/jdk/blob/3ebe6c192a5dd5cc46ae2d263713c9ff38cd46bb/src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java#L281) states: "If a timeout is supplied but unconnected sockets are not supported then the timeout is ignored and a connected socket is created."
>> 
>> This, however does not happen. If a SocketFactory would not support unconnected sockets, it would likely throw a SocketException in [SocketFactory::createSocket()](https://github.com/openjdk/jdk/blob/6303c0e7136436a2d3cb6043b88edf788c0067cc/src/java.base/share/classes/javax/net/SocketFactory.java#L123). And since [the code](https://github.com/openjdk/jdk/blob/3ebe6c192a5dd5cc46ae2d263713c9ff38cd46bb/src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java#L336) does not check for this behavior, a connection with timeout value through a SocketFactory that does not support unconnected sockets would simply fail with an IOException.
>> 
>> So we should either make the code adhere to what is documented or adapt the documentation to the actual behavior.
>> 
>> I hereby try to fix the connect coding. Alternatively, we could also adapt the description - I have no strong opinion. What do the experts suggest?
>
> Christoph Langer has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - Enhance test
>  - JDK-8325579

So, I've updated the PR. Sorry for force-pushing, hope you didn't review the code in detail yet.

The new version updates module-info as requested. I also enhanced the test `LdapSSLHandshakeFailureTest.java` and added variants that exercise a Socket Factory which does not support unconnected sockets. Two of the test variants would fail with the current JDK.

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

PR Comment: https://git.openjdk.org/jdk/pull/17797#issuecomment-1946315957

From ihse at openjdk.org  Thu Feb 15 15:50:57 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 15 Feb 2024 15:50:57 GMT
Subject: RFR: 8325950: Make sure all files in the JDK pass jcheck
In-Reply-To: 
References: <8OFfLzjcABtbqaxklrESgILudN93NzwtNzEJxoOBMoM=.50f8e451-2ef4-467c-9c6b-7ae795428748@github.com>
 
 
Message-ID: 

On Thu, 15 Feb 2024 14:01:46 GMT, Erik Joelsson  wrote:

>> test/jdk/java/util/Currency/currency.properties line 18:
>> 
>>> 16: SB=EUR,111,2, 2099-01-01T00:00:00
>>> 17: US=euR,978,2,2001-01-01T00:00:00
>>> 18: ZZ	=	ZZZ	,	999	,	3
>> 
>> This looks weird, but so did the original code. I assume this is to clearly indicate this as a end of list marker.
>
> This looks weird indeed. Luckily it's just test code. Did you run the test after this change?

All the java/util/Currency tests pass. I also searched the code for "ZZ" but could not find any references in the test.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17871#discussion_r1491227492

From mdonovan at openjdk.org  Thu Feb 15 17:12:18 2024
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Thu, 15 Feb 2024 17:12:18 GMT
Subject: RFR: 8319648: java/lang/SecurityManager tests ignore vm flags
Message-ID: <8QF-ychCHq3eRcsTlZqFqP68z2NApgazCTWyaDaP2iY=.e261430a-7cff-425a-ba7d-26b7f44fd0bc@github.com>

In this PR I updated the tests to use the newer ProcessTools.createTestJavaProcessBuilder methods to pass VM options to child processes.

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

Commit messages:
 - 8319648: java/lang/SecurityManager tests ignore vm flags

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

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

From naoto at openjdk.org  Thu Feb 15 17:12:55 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 15 Feb 2024 17:12:55 GMT
Subject: RFR: 8325950: Make sure all files in the JDK pass jcheck
In-Reply-To: 
References: <8OFfLzjcABtbqaxklrESgILudN93NzwtNzEJxoOBMoM=.50f8e451-2ef4-467c-9c6b-7ae795428748@github.com>
 
 
 
Message-ID: 

On Thu, 15 Feb 2024 15:48:38 GMT, Magnus Ihse Bursie  wrote:

>> This looks weird indeed. Luckily it's just test code. Did you run the test after this change?
>
> All the java/util/Currency tests pass. I also searched the code for "ZZ" but could not find any references in the test.

Please do not replace those tabs with spaces as they are intentional for testing the runtime to safely ignore them. I suggest replacing them with Unicode escapes (`\u000b`)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17871#discussion_r1491352359

From angorya at openjdk.org  Thu Feb 15 17:31:56 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 15 Feb 2024 17:31:56 GMT
Subject: RFR: 8325950: Make sure all files in the JDK pass jcheck
In-Reply-To: 
References: <8OFfLzjcABtbqaxklrESgILudN93NzwtNzEJxoOBMoM=.50f8e451-2ef4-467c-9c6b-7ae795428748@github.com>
 
 
 
 
Message-ID: 

On Thu, 15 Feb 2024 17:09:17 GMT, Naoto Sato  wrote:

>> All the java/util/Currency tests pass. I also searched the code for "ZZ" but could not find any references in the test.
>
> Please do not replace those tabs with spaces as they are intentional for testing the runtime to safely ignore them. I suggest replacing them with Unicode escapes (`\u000b`)

`\u000b` is VT   (vertical tab)  
`\u0009` or `\t` perhaps?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17871#discussion_r1491375928

From naoto at openjdk.org  Thu Feb 15 17:55:58 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 15 Feb 2024 17:55:58 GMT
Subject: RFR: 8325950: Make sure all files in the JDK pass jcheck
In-Reply-To: 
References: <8OFfLzjcABtbqaxklrESgILudN93NzwtNzEJxoOBMoM=.50f8e451-2ef4-467c-9c6b-7ae795428748@github.com>
 
 
 
 
 
Message-ID: 

On Thu, 15 Feb 2024 17:28:52 GMT, Andy Goryachev  wrote:

>> Please do not replace those tabs with spaces as they are intentional for testing the runtime to safely ignore them. I suggest replacing them with Unicode escapes (`\u000b`)
>
> `\u000b` is VT   (vertical tab)  
> `\u0009` or `\t` perhaps?

Right. `\t` is better to avoid such a mistake.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17871#discussion_r1491403426

From bpb at openjdk.org  Thu Feb 15 19:00:06 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 15 Feb 2024 19:00:06 GMT
Subject: RFR: 8325990: Remove use of snippet @replace annotation in java.base
Message-ID: 

Revert `@replace` snippet annotation construct to value of `replacement` attribute.

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

Commit messages:
 - 8325990: Remove use of snippet @replace annotation in java.base

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

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

From jlu at openjdk.org  Thu Feb 15 19:26:53 2024
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 15 Feb 2024 19:26:53 GMT
Subject: RFR: 8325990: Remove use of snippet @replace annotation in
 java.base
In-Reply-To: 
References: 
Message-ID: 

On Thu, 15 Feb 2024 18:54:46 GMT, Brian Burkhalter  wrote:

> Revert `@replace` snippet annotation construct to value of `replacement` attribute.

LGTM

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

Marked as reviewed by jlu (Committer).

PR Review: https://git.openjdk.org/jdk/pull/17882#pullrequestreview-1883649981

From naoto at openjdk.org  Thu Feb 15 19:29:55 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 15 Feb 2024 19:29:55 GMT
Subject: RFR: 8325990: Remove use of snippet @replace annotation in
 java.base
In-Reply-To: 
References: 
Message-ID: 

On Thu, 15 Feb 2024 18:54:46 GMT, Brian Burkhalter  wrote:

> Revert `@replace` snippet annotation construct to value of `replacement` attribute.

I saw the internal discussion and agree with the changes.

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17882#pullrequestreview-1883655274

From jlu at openjdk.org  Thu Feb 15 19:49:17 2024
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 15 Feb 2024 19:49:17 GMT
Subject: RFR: JDK-8325898: ChoiceFormat returns erroneous result when
 formatting bad pattern
Message-ID: 

Please review this PR which handles an edge case pattern bug with ChoiceFormat.


var d = new ChoiceFormat("0#foo|1#bar|baz|") // creates cFmt equivalent to "0.0#foo|1.0#bar|1.0#"
d.format(1) // unexpectedly returns ""


Not only does this lead to faulty formatting results, but breaks the ChoiceFormat class invariant of duplicate limits.

It would have been preferable if either an exception was thrown when the ChoiceFormat was initially created, or the ChoiceFormat formatting 1 returned a value of "bar".

For comparison,

var d = new ChoiceFormat("0#foo|1#bar|baz") // creates cFmt equivalent to "0.0#foo|1.0#bar"
d.format(1) // returns "bar"


After this change, the first code snippet now returns "bar" when formatting 1 and discards the "baz" as the second code snippet does.


This PR includes a lot of cleanup to the applyPattern implementation, the specific fix for this bug is addressed with the following, on line 305,

if (seg != Segment.FORMAT) {
    // Discard incorrect portion and finish building cFmt
    break;
}

This prevents a limit/format entry from being built when the current parsing mode has not yet processed the limit and relation. The previous implementation would build an additional limit/format of 1 with an empty string. The `break` allows for the discarding of the incorrect portion and continuing. Alternatively an exception could have been thrown. For consistency with the second code snippet, the former was picked.

https://github.com/openjdk/jdk/pull/17856 may be of interest, which is a semi-related specification fix.

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

Commit messages:
 - add additional longer test case
 - shorten relational symbol in format comment
 - preserve final modifier for next/previousDouble
 - reduce visibility of Segment enum
 - init

Changes: https://git.openjdk.org/jdk/pull/17883/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17883&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8325898
  Stats: 187 lines in 2 files changed: 74 ins; 55 del; 58 mod
  Patch: https://git.openjdk.org/jdk/pull/17883.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17883/head:pull/17883

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

From mark.reinhold at oracle.com  Thu Feb 15 21:08:15 2024
From: mark.reinhold at oracle.com (Mark Reinhold)
Date: Thu, 15 Feb 2024 21:08:15 +0000
Subject: New candidate JEP: 466: Class-File API (Second Preview)
Message-ID: <20240215210814.15B926C1C26@eggemoggin.niobe.net>

https://openjdk.org/jeps/466

  Summary: Provide a standard API for parsing, generating, and
  transforming Java class files. This is a preview API.

- Mark

From stuart.marks at oracle.com  Thu Feb 15 22:11:11 2024
From: stuart.marks at oracle.com (Stuart Marks)
Date: Thu, 15 Feb 2024 14:11:11 -0800
Subject: CFV: New Core Libraries Group Member: Raffaello Giulietti
In-Reply-To: <14851B34-A785-4389-9C23-056B8C7E0D7C@oracle.com>
References: <14851B34-A785-4389-9C23-056B8C7E0D7C@oracle.com>
Message-ID: 

Vote: yes

On 2/13/24 12:25 PM, Brian Burkhalter wrote:
> I hereby nominate Raffaello Giulietti to Membership in the Core Libraries Group.
> 
> Raffaello has been working in the Core Library team at Oracle since April, 2022. He has authored more than 50 contributions to OpenJDK in a number of areas including numerics, formatting, regular expressions, and random number generation.
> 
> Votes are due by Wednesday, February 28, 2023.
> 
> Only current Members of the Core Libraries Group [1] are eligible
> to vote on this nomination.  Votes must be cast in the open by
> replying to this mailing list
> 
> For Lazy Consensus voting instructions, see [2].
> 
> Brian Burkhalter
> 
> [1] https://openjdk.org/census#core-libs
> [2] https://openjdk.org/groups/#member-vote

From clanger at openjdk.org  Thu Feb 15 22:13:25 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Thu, 15 Feb 2024 22:13:25 GMT
Subject: RFR: 8325579: Inconsistent behavior in
 com.sun.jndi.ldap.Connection::createSocket [v4]
In-Reply-To: 
References: 
Message-ID: <7FFT-stfO4_X3r9XHcjBGImQxpk92oelDAIyV50V6_Y=.d86749c1-1de8-4807-8f65-068fb64f6776@github.com>

> During analysing a customer case I figured out that we have an inconsistency between documentation and actual behavior in class com.sun.jndi.ldap.Connection. The [method documentation of com.sun.jndi.ldap.Connection::createSocket](https://github.com/openjdk/jdk/blob/3ebe6c192a5dd5cc46ae2d263713c9ff38cd46bb/src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java#L281) states: "If a timeout is supplied but unconnected sockets are not supported then the timeout is ignored and a connected socket is created."
> 
> This, however does not happen. If a SocketFactory would not support unconnected sockets, it would likely throw a SocketException in [SocketFactory::createSocket()](https://github.com/openjdk/jdk/blob/6303c0e7136436a2d3cb6043b88edf788c0067cc/src/java.base/share/classes/javax/net/SocketFactory.java#L123). And since [the code](https://github.com/openjdk/jdk/blob/3ebe6c192a5dd5cc46ae2d263713c9ff38cd46bb/src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java#L336) does not check for this behavior, a connection with timeout value through a SocketFactory that does not support unconnected sockets would simply fail with an IOException.
> 
> So we should either make the code adhere to what is documented or adapt the documentation to the actual behavior.
> 
> I hereby try to fix the connect coding. Alternatively, we could also adapt the description - I have no strong opinion. What do the experts suggest?

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

  Rename test and refine comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17797/files
  - new: https://git.openjdk.org/jdk/pull/17797/files/c0dee34c..88ae0b27

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

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

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

From prr at openjdk.org  Thu Feb 15 22:40:56 2024
From: prr at openjdk.org (Phil Race)
Date: Thu, 15 Feb 2024 22:40:56 GMT
Subject: RFR: 8325950: Make sure all files in the JDK pass jcheck
In-Reply-To: <8OFfLzjcABtbqaxklrESgILudN93NzwtNzEJxoOBMoM=.50f8e451-2ef4-467c-9c6b-7ae795428748@github.com>
References: <8OFfLzjcABtbqaxklrESgILudN93NzwtNzEJxoOBMoM=.50f8e451-2ef4-467c-9c6b-7ae795428748@github.com>
Message-ID: 

On Thu, 15 Feb 2024 12:19:31 GMT, Magnus Ihse Bursie  wrote:

> Since jcheck only checks file in a commit, there is a possibility of us getting files in the repository that would not be accepted by jcheck. This can happen when extending the set of files checked by jcheck, or if jcheck changes how it checks files (perhaps due to bug fixes).
> 
> I have now run jcheck over the entire code base, and fixed a handful of issues. With these changes, jcheck accept the entire code base.

desktop changes look fine to me.

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

Marked as reviewed by prr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17871#pullrequestreview-1884009342

From wetmore at openjdk.org  Fri Feb 16 01:44:57 2024
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Fri, 16 Feb 2024 01:44:57 GMT
Subject: RFR: 8325950: Make sure all files in the JDK pass jcheck
In-Reply-To: <8OFfLzjcABtbqaxklrESgILudN93NzwtNzEJxoOBMoM=.50f8e451-2ef4-467c-9c6b-7ae795428748@github.com>
References: <8OFfLzjcABtbqaxklrESgILudN93NzwtNzEJxoOBMoM=.50f8e451-2ef4-467c-9c6b-7ae795428748@github.com>
Message-ID: 

On Thu, 15 Feb 2024 12:19:31 GMT, Magnus Ihse Bursie  wrote:

> Since jcheck only checks file in a commit, there is a possibility of us getting files in the repository that would not be accepted by jcheck. This can happen when extending the set of files checked by jcheck, or if jcheck changes how it checks files (perhaps due to bug fixes).
> 
> I have now run jcheck over the entire code base, and fixed a handful of issues. With these changes, jcheck accept the entire code base.

security properties looks ok.

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

Marked as reviewed by wetmore (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17871#pullrequestreview-1884183930

From rrich at openjdk.org  Fri Feb 16 08:43:00 2024
From: rrich at openjdk.org (Richard Reingruber)
Date: Fri, 16 Feb 2024 08:43:00 GMT
Subject: RFR: 8323782: Race: Thread::interrupt vs.
 AbstractInterruptibleChannel.begin [v4]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 15 Feb 2024 13:35:24 GMT, Richard Reingruber  wrote:

>> Set `interrupted` in `Thread::interrupt` before reading `nioBlocker` for correct (Dekker scheme) synchronization with concurrent execution of [`AbstractInterruptibleChannel::begin`](https://github.com/openjdk/jdk/blob/59062402b9c5ed5612a13c1c40eb22cf1b97c41a/src/java.base/share/classes/java/nio/channels/spi/AbstractInterruptibleChannel.java#L176).
>> 
>> The change passed our CI functional testing: JTReg tests: tier1-4 of hotspot and jdk. All of Langtools and jaxp. SPECjvm2008, SPECjbb2015, Renaissance Suite, and SAP specific tests.
>> Testing was done with fastdebug and release builds on the main platforms and also on Linux/PPC64le and AIX.
>
> Richard Reingruber has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:
> 
>  - Merge branch 'master' into 8323782__Race__Thread__interrupt_vs__AbstractInterruptibleChannel_begin
>  - Merge branch 'master' into 8323782__Race__Thread__interrupt_vs__AbstractInterruptibleChannel_begin
>  - Review Alan
>  - New version of LotsOfInterrupts.java supporting virtual threads
>  - Add Alan's LotsOfInterrupts.java test
>  - Must checkAccess before changing interrupt state of other thread
>  - 8323782: Race: Thread::interrupt vs. AbstractInterruptibleChannel.begin

Thanks for helping and reviewing.
Richard.

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

PR Comment: https://git.openjdk.org/jdk/pull/17444#issuecomment-1947964958

From rrich at openjdk.org  Fri Feb 16 08:43:01 2024
From: rrich at openjdk.org (Richard Reingruber)
Date: Fri, 16 Feb 2024 08:43:01 GMT
Subject: Integrated: 8323782: Race: Thread::interrupt vs.
 AbstractInterruptibleChannel.begin
In-Reply-To: 
References: 
Message-ID: 

On Tue, 16 Jan 2024 10:57:46 GMT, Richard Reingruber  wrote:

> Set `interrupted` in `Thread::interrupt` before reading `nioBlocker` for correct (Dekker scheme) synchronization with concurrent execution of [`AbstractInterruptibleChannel::begin`](https://github.com/openjdk/jdk/blob/59062402b9c5ed5612a13c1c40eb22cf1b97c41a/src/java.base/share/classes/java/nio/channels/spi/AbstractInterruptibleChannel.java#L176).
> 
> The change passed our CI functional testing: JTReg tests: tier1-4 of hotspot and jdk. All of Langtools and jaxp. SPECjvm2008, SPECjbb2015, Renaissance Suite, and SAP specific tests.
> Testing was done with fastdebug and release builds on the main platforms and also on Linux/PPC64le and AIX.

This pull request has now been integrated.

Changeset: 4018b2b1
Author:    Richard Reingruber 
URL:       https://git.openjdk.org/jdk/commit/4018b2b19629ddb8cd7a56e064dfef371f23e5fa
Stats:     103 lines in 2 files changed: 97 ins; 5 del; 1 mod

8323782: Race: Thread::interrupt vs. AbstractInterruptibleChannel.begin

Co-authored-by: Alan Bateman 
Reviewed-by: alanb, dholmes

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

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

From clanger at openjdk.org  Fri Feb 16 10:27:11 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Fri, 16 Feb 2024 10:27:11 GMT
Subject: RFR: 8325579: Inconsistent behavior in
 com.sun.jndi.ldap.Connection::createSocket [v5]
In-Reply-To: 
References: 
Message-ID: 

> During analysing a customer case I figured out that we have an inconsistency between documentation and actual behavior in class com.sun.jndi.ldap.Connection. The [method documentation of com.sun.jndi.ldap.Connection::createSocket](https://github.com/openjdk/jdk/blob/3ebe6c192a5dd5cc46ae2d263713c9ff38cd46bb/src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java#L281) states: "If a timeout is supplied but unconnected sockets are not supported then the timeout is ignored and a connected socket is created."
> 
> This, however does not happen. If a SocketFactory would not support unconnected sockets, it would likely throw a SocketException in [SocketFactory::createSocket()](https://github.com/openjdk/jdk/blob/6303c0e7136436a2d3cb6043b88edf788c0067cc/src/java.base/share/classes/javax/net/SocketFactory.java#L123). And since [the code](https://github.com/openjdk/jdk/blob/3ebe6c192a5dd5cc46ae2d263713c9ff38cd46bb/src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java#L336) does not check for this behavior, a connection with timeout value through a SocketFactory that does not support unconnected sockets would simply fail with an IOException.
> 
> So we should either make the code adhere to what is documented or adapt the documentation to the actual behavior.
> 
> I hereby try to fix the connect coding. Alternatively, we could also adapt the description - I have no strong opinion. What do the experts suggest?

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

 - Typo
 - Merge branch 'master' into JDK-8325579
 - Rename test and refine comment
 - Enhance test
 - JDK-8325579

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17797/files
  - new: https://git.openjdk.org/jdk/pull/17797/files/88ae0b27..d8d1d6db

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

  Stats: 1085 lines in 40 files changed: 842 ins; 125 del; 118 mod
  Patch: https://git.openjdk.org/jdk/pull/17797.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17797/head:pull/17797

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

From ihse at openjdk.org  Fri Feb 16 12:43:25 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 16 Feb 2024 12:43:25 GMT
Subject: RFR: 8325950: Make sure all files in the JDK pass jcheck [v2]
In-Reply-To: <8OFfLzjcABtbqaxklrESgILudN93NzwtNzEJxoOBMoM=.50f8e451-2ef4-467c-9c6b-7ae795428748@github.com>
References: <8OFfLzjcABtbqaxklrESgILudN93NzwtNzEJxoOBMoM=.50f8e451-2ef4-467c-9c6b-7ae795428748@github.com>
Message-ID: 

> Since jcheck only checks file in a commit, there is a possibility of us getting files in the repository that would not be accepted by jcheck. This can happen when extending the set of files checked by jcheck, or if jcheck changes how it checks files (perhaps due to bug fixes).
> 
> I have now run jcheck over the entire code base, and fixed a handful of issues. With these changes, jcheck accept the entire code base.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Replace spaces with \t in test properties file

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17871/files
  - new: https://git.openjdk.org/jdk/pull/17871/files/3faa912e..e1c9c0f0

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

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

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

From ihse at openjdk.org  Fri Feb 16 12:43:25 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 16 Feb 2024 12:43:25 GMT
Subject: RFR: 8325950: Make sure all files in the JDK pass jcheck [v2]
In-Reply-To: 
References: <8OFfLzjcABtbqaxklrESgILudN93NzwtNzEJxoOBMoM=.50f8e451-2ef4-467c-9c6b-7ae795428748@github.com>
 
 
 
 
 
 
Message-ID: 

On Thu, 15 Feb 2024 17:53:41 GMT, Naoto Sato  wrote:

>> `\u000b` is VT   (vertical tab)  
>> `\u0009` or `\t` perhaps?
>
> Right. `\t` is better to avoid such a mistake.

Ok, fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17871#discussion_r1492403403

From erikj at openjdk.org  Fri Feb 16 13:39:56 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 16 Feb 2024 13:39:56 GMT
Subject: RFR: 8325950: Make sure all files in the JDK pass jcheck [v2]
In-Reply-To: 
References: <8OFfLzjcABtbqaxklrESgILudN93NzwtNzEJxoOBMoM=.50f8e451-2ef4-467c-9c6b-7ae795428748@github.com>
 
Message-ID: 

On Fri, 16 Feb 2024 12:43:25 GMT, Magnus Ihse Bursie  wrote:

>> Since jcheck only checks file in a commit, there is a possibility of us getting files in the repository that would not be accepted by jcheck. This can happen when extending the set of files checked by jcheck, or if jcheck changes how it checks files (perhaps due to bug fixes).
>> 
>> I have now run jcheck over the entire code base, and fixed a handful of issues. With these changes, jcheck accept the entire code base.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Replace spaces with \t in test properties file

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17871#pullrequestreview-1885177994

From rgiulietti at openjdk.org  Fri Feb 16 14:18:55 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 16 Feb 2024 14:18:55 GMT
Subject: RFR: 8325340: Add ASCII fast-path to
 Data-/ObjectInputStream.readUTF [v6]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 15 Feb 2024 13:07:20 GMT, Claes Redestad  wrote:

>> Adding a fast-path for ASCII-only modified UTF-8 strings deserialied via Data- and ObjectInputStream
>> 
>> Testing: tier1-3
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/java.base/share/classes/java/io/DataInputStream.java
>   
>   Co-authored-by: Raffaello Giulietti 

Looks fine.

test/micro/org/openjdk/bench/java/io/DataInputStreamTest.java line 2:

> 1: /*
> 2:  * Copyright (c) 2020, 2024, Red Hat Inc. All rights reserved.

Suggestion:

 * Copyright (c) 2020, Red Hat Inc. All rights reserved.
 * Copyright (c) 2024, Oracle and/or its affiliates. All rights reserved.

AFAIU, we don't update 3rd party copyright notices.

test/micro/org/openjdk/bench/java/io/ObjectInputStreamTest.java line 2:

> 1: /*
> 2:  * Copyright (c) 2020, 2024, Red Hat Inc. All rights reserved.

Probably the result of a copy&paste...
Suggestion:

 * Copyright (c) 2024, Oracle and/or its affiliates. All rights reserved.

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

PR Review: https://git.openjdk.org/jdk/pull/17734#pullrequestreview-1885257935
PR Review Comment: https://git.openjdk.org/jdk/pull/17734#discussion_r1492524358
PR Review Comment: https://git.openjdk.org/jdk/pull/17734#discussion_r1492525025

From redestad at openjdk.org  Fri Feb 16 15:31:07 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Fri, 16 Feb 2024 15:31:07 GMT
Subject: RFR: 8325340: Add ASCII fast-path to
 Data-/ObjectInputStream.readUTF [v7]
In-Reply-To: 
References: 
Message-ID: <5W9u4RJXEclgcBrZt6uWlGDcVYFRGJhkqa79PNJjxo8=.46b06cde-865f-447c-b8d6-bf4d80162686@github.com>

> Adding a fast-path for ASCII-only modified UTF-8 strings deserialied via Data- and ObjectInputStream
> 
> Testing: tier1-3

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

 - Update test/micro/org/openjdk/bench/java/io/DataInputStreamTest.java
   
   Co-authored-by: Raffaello Giulietti 
 - Update test/micro/org/openjdk/bench/java/io/ObjectInputStreamTest.java
   
   Co-authored-by: Raffaello Giulietti 

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17734/files
  - new: https://git.openjdk.org/jdk/pull/17734/files/48902ad2..586635e8

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

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

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

From redestad at openjdk.org  Fri Feb 16 15:31:08 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Fri, 16 Feb 2024 15:31:08 GMT
Subject: RFR: 8325340: Add ASCII fast-path to
 Data-/ObjectInputStream.readUTF [v6]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 15 Feb 2024 13:07:20 GMT, Claes Redestad  wrote:

>> Adding a fast-path for ASCII-only modified UTF-8 strings deserialied via Data- and ObjectInputStream
>> 
>> Testing: tier1-3
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/java.base/share/classes/java/io/DataInputStream.java
>   
>   Co-authored-by: Raffaello Giulietti 

Thanks! I know Roger is out this week, and this can wait until he's had a chance to take a look.

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

PR Comment: https://git.openjdk.org/jdk/pull/17734#issuecomment-1948619951

From rgiulietti at openjdk.org  Fri Feb 16 15:37:55 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 16 Feb 2024 15:37:55 GMT
Subject: RFR: 8325340: Add ASCII fast-path to
 Data-/ObjectInputStream.readUTF [v7]
In-Reply-To: <5W9u4RJXEclgcBrZt6uWlGDcVYFRGJhkqa79PNJjxo8=.46b06cde-865f-447c-b8d6-bf4d80162686@github.com>
References: 
 <5W9u4RJXEclgcBrZt6uWlGDcVYFRGJhkqa79PNJjxo8=.46b06cde-865f-447c-b8d6-bf4d80162686@github.com>
Message-ID: 

On Fri, 16 Feb 2024 15:31:07 GMT, Claes Redestad  wrote:

>> Adding a fast-path for ASCII-only modified UTF-8 strings deserialied via Data- and ObjectInputStream
>> 
>> Testing: tier1-3
>
> Claes Redestad has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update test/micro/org/openjdk/bench/java/io/DataInputStreamTest.java
>    
>    Co-authored-by: Raffaello Giulietti 
>  - Update test/micro/org/openjdk/bench/java/io/ObjectInputStreamTest.java
>    
>    Co-authored-by: Raffaello Giulietti 

Marked as reviewed by rgiulietti (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17734#pullrequestreview-1885434083

From dcubed at openjdk.org  Fri Feb 16 16:00:00 2024
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Fri, 16 Feb 2024 16:00:00 GMT
Subject: RFR: 8326062: ProblemList jcstress tests that are failing due to
 JDK-8325984
Message-ID: <7egaeMIqqUPRLYzdbKMhtqu2Pr4Uqnt3bmtsF9Eqzrs=.fa5b8f83-326d-4944-a3d0-f1fbf84a6392@github.com>

A trivial fix to ProblemList jcstress tests that are failing due to JDK-8325984.

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

Commit messages:
 - 8326062: ProblemList jcstress tests that are failing due to JDK-8325984

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

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

From azvegint at openjdk.org  Fri Feb 16 16:00:01 2024
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Fri, 16 Feb 2024 16:00:01 GMT
Subject: RFR: 8326062: ProblemList jcstress tests that are failing due to
 JDK-8325984
In-Reply-To: <7egaeMIqqUPRLYzdbKMhtqu2Pr4Uqnt3bmtsF9Eqzrs=.fa5b8f83-326d-4944-a3d0-f1fbf84a6392@github.com>
References: <7egaeMIqqUPRLYzdbKMhtqu2Pr4Uqnt3bmtsF9Eqzrs=.fa5b8f83-326d-4944-a3d0-f1fbf84a6392@github.com>
Message-ID: 

On Fri, 16 Feb 2024 15:54:27 GMT, Daniel D. Daugherty  wrote:

> A trivial fix to ProblemList jcstress tests that are failing due to JDK-8325984.

Marked as reviewed by azvegint (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17890#pullrequestreview-1885479796

From jvernee at openjdk.org  Fri Feb 16 16:05:57 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 16 Feb 2024 16:05:57 GMT
Subject: RFR: 8326062: ProblemList jcstress tests that are failing due to
 JDK-8325984
In-Reply-To: <7egaeMIqqUPRLYzdbKMhtqu2Pr4Uqnt3bmtsF9Eqzrs=.fa5b8f83-326d-4944-a3d0-f1fbf84a6392@github.com>
References: <7egaeMIqqUPRLYzdbKMhtqu2Pr4Uqnt3bmtsF9Eqzrs=.fa5b8f83-326d-4944-a3d0-f1fbf84a6392@github.com>
Message-ID: 

On Fri, 16 Feb 2024 15:54:27 GMT, Daniel D. Daugherty  wrote:

> A trivial fix to ProblemList jcstress tests that are failing due to JDK-8325984.

Thanks!

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

Marked as reviewed by jvernee (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17890#pullrequestreview-1885494458

From dcubed at openjdk.org  Fri Feb 16 16:05:58 2024
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Fri, 16 Feb 2024 16:05:58 GMT
Subject: RFR: 8326062: ProblemList jcstress tests that are failing due to
 JDK-8325984
In-Reply-To: 
References: <7egaeMIqqUPRLYzdbKMhtqu2Pr4Uqnt3bmtsF9Eqzrs=.fa5b8f83-326d-4944-a3d0-f1fbf84a6392@github.com>
 
Message-ID: 

On Fri, 16 Feb 2024 15:56:41 GMT, Alexander Zvegintsev  wrote:

>> A trivial fix to ProblemList jcstress tests that are failing due to JDK-8325984.
>
> Marked as reviewed by azvegint (Reviewer).

@azvegint - Thanks for the fast review!

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

PR Comment: https://git.openjdk.org/jdk/pull/17890#issuecomment-1948735042

From dcubed at openjdk.org  Fri Feb 16 16:05:58 2024
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Fri, 16 Feb 2024 16:05:58 GMT
Subject: Integrated: 8326062: ProblemList jcstress tests that are failing due
 to JDK-8325984
In-Reply-To: <7egaeMIqqUPRLYzdbKMhtqu2Pr4Uqnt3bmtsF9Eqzrs=.fa5b8f83-326d-4944-a3d0-f1fbf84a6392@github.com>
References: <7egaeMIqqUPRLYzdbKMhtqu2Pr4Uqnt3bmtsF9Eqzrs=.fa5b8f83-326d-4944-a3d0-f1fbf84a6392@github.com>
Message-ID: 

On Fri, 16 Feb 2024 15:54:27 GMT, Daniel D. Daugherty  wrote:

> A trivial fix to ProblemList jcstress tests that are failing due to JDK-8325984.

This pull request has now been integrated.

Changeset: 00b5c707
Author:    Daniel D. Daugherty 
URL:       https://git.openjdk.org/jdk/commit/00b5c70750737855b29b125de6a0c806677c118c
Stats:     5 lines in 1 file changed: 5 ins; 0 del; 0 mod

8326062: ProblemList jcstress tests that are failing due to JDK-8325984

Reviewed-by: azvegint, jvernee

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

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

From bpb at openjdk.org  Fri Feb 16 16:09:57 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 16 Feb 2024 16:09:57 GMT
Subject: Integrated: 8325990: Remove use of snippet @replace annotation in
 java.base
In-Reply-To: 
References: 
Message-ID: 

On Thu, 15 Feb 2024 18:54:46 GMT, Brian Burkhalter  wrote:

> Revert `@replace` snippet annotation construct to value of `replacement` attribute.

This pull request has now been integrated.

Changeset: 7a762520
Author:    Brian Burkhalter 
URL:       https://git.openjdk.org/jdk/commit/7a76252007b603b4346fad61818d488999644f80
Stats:     5 lines in 2 files changed: 0 ins; 0 del; 5 mod

8325990: Remove use of snippet @replace annotation in java.base

Reviewed-by: jlu, naoto

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

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

From dfuchs at openjdk.org  Fri Feb 16 16:42:57 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 16 Feb 2024 16:42:57 GMT
Subject: RFR: 8325579: Inconsistent behavior in
 com.sun.jndi.ldap.Connection::createSocket [v5]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 16 Feb 2024 10:27:11 GMT, Christoph Langer  wrote:

>> During analysing a customer case I figured out that we have an inconsistency between documentation and actual behavior in class com.sun.jndi.ldap.Connection. The [method documentation of com.sun.jndi.ldap.Connection::createSocket](https://github.com/openjdk/jdk/blob/3ebe6c192a5dd5cc46ae2d263713c9ff38cd46bb/src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java#L281) states: "If a timeout is supplied but unconnected sockets are not supported then the timeout is ignored and a connected socket is created."
>> 
>> This, however does not happen. If a SocketFactory would not support unconnected sockets, it would likely throw a SocketException in [SocketFactory::createSocket()](https://github.com/openjdk/jdk/blob/6303c0e7136436a2d3cb6043b88edf788c0067cc/src/java.base/share/classes/javax/net/SocketFactory.java#L123). And since [the code](https://github.com/openjdk/jdk/blob/3ebe6c192a5dd5cc46ae2d263713c9ff38cd46bb/src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java#L336) does not check for this behavior, a connection with timeout value through a SocketFactory that does not support unconnected sockets would simply fail with an IOException.
>> 
>> So we should either make the code adhere to what is documented or adapt the documentation to the actual behavior.
>> 
>> I hereby try to fix the connect coding. Alternatively, we could also adapt the description - I have no strong opinion. What do the experts suggest?
>
> Christoph Langer has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Typo
>  - Merge branch 'master' into JDK-8325579
>  - Rename test and refine comment
>  - Enhance test
>  - JDK-8325579

test/jdk/com/sun/jndi/ldap/LdapSSLHandshakeTest.java line 62:

> 60:  * whether the socket is closed after closing the Context.
> 61:  *
> 62:  * @run main/othervm --add-opens java.naming/javax.naming=ALL-UNNAMED --add-opens java.naming/com.sun.jndi.ldap=ALL-UNNAMED

sigh... git handles the renaming of this test file as a deleted file + a new file which makes it hard to review the changes.

The --add-opens directive are very strange here. I suggest removing them and replacing them with a single `@modules` directive:


@modules java.naming/javax.naming:+open
                  java.naming/com.sun.jndi.ldap:+open

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17797#discussion_r1492725787

From naoto at openjdk.org  Fri Feb 16 16:55:57 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 16 Feb 2024 16:55:57 GMT
Subject: RFR: 8325950: Make sure all files in the JDK pass jcheck [v2]
In-Reply-To: 
References: <8OFfLzjcABtbqaxklrESgILudN93NzwtNzEJxoOBMoM=.50f8e451-2ef4-467c-9c6b-7ae795428748@github.com>
 
Message-ID: 

On Fri, 16 Feb 2024 12:43:25 GMT, Magnus Ihse Bursie  wrote:

>> Since jcheck only checks file in a commit, there is a possibility of us getting files in the repository that would not be accepted by jcheck. This can happen when extending the set of files checked by jcheck, or if jcheck changes how it checks files (perhaps due to bug fixes).
>> 
>> I have now run jcheck over the entire code base, and fixed a handful of issues. With these changes, jcheck accept the entire code base.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Replace spaces with \t in test properties file

LGTM

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17871#pullrequestreview-1885586969

From kbarrett at openjdk.org  Fri Feb 16 17:01:01 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 16 Feb 2024 17:01:01 GMT
Subject: RFR: 8325163: Enable -Wpedantic on clang [v2]
In-Reply-To: <56uYGhLCcDFBfuEV2TpDDYcOzLjBtKKerH03q-L_wlk=.37ca1c75-45e9-42ad-af40-7cfb34c77725@github.com>
References: 
 
 <56uYGhLCcDFBfuEV2TpDDYcOzLjBtKKerH03q-L_wlk=.37ca1c75-45e9-42ad-af40-7cfb34c77725@github.com>
Message-ID: 

On Mon, 5 Feb 2024 21:39:06 GMT, Magnus Ihse Bursie  wrote:

> Here is the full list: https://clang.llvm.org/docs/DiagnosticsReference.html#wpedantic

I know about that list, and that's not what I was asking for. I want to
understand the impact on *our* code. What warnings are arising from *our*
code, how difficult are the fixes, and how beneficial are the fixes.

Looking through the list of warnings it can generate, I don't see much that
looks useful. I'm inclined to agree with Andrew Haley's comment in (draft)
https://github.com/openjdk/jdk/pull/17727#issuecomment-1929178213. It might be
that there are some specific warning options that are part of it that might be
worth turning on (or working toward), but it's mostly uncompelling.

The two that had bazillions of occurrences when I tried with gcc were (1) a
gcc bug (incorrect warning about extra semis), and (2) a completely non-useful
requirement that "%p" format spec only accepts exactly void*, with no implicit
conversions from other pointer types. Clang presumably doesn't have the
former, and I don't know about the latter.

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

PR Comment: https://git.openjdk.org/jdk/pull/17687#issuecomment-1948881656

From jlu at openjdk.org  Fri Feb 16 17:19:59 2024
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 16 Feb 2024 17:19:59 GMT
Subject: Integrated: JDK-8325908: Finish removal of IntlTest and CollatorTest
In-Reply-To: 
References: 
Message-ID: 

On Wed, 14 Feb 2024 23:05:25 GMT, Justin Lu  wrote:

> Please review this PR which fixes / finishes the rest of the IntlTest test framework removal in java.text and java.util.i18n tests.
> 
> For context, the IntlTest class only ran methods prefixed by _test_ or _Test_ with public visibility and was originally removed due to some tests spuriously passing that were not aware of the specific running requirements.
> 
> This PR includes the following changes,
> - There were some tests with package-private visibility that were never ran by IntlTest. Those tests do appear to be valid tests, and thus have been updated with `@Test` annotation.
> - The test method DFSExponenTest() in DFSExponential.java was not prefixed by test and thus never ran by IntlTest. It is a valid test and should be ran as well.
> - DateFormatRoundTripTest.java was supposed to remain a non JUnit test, however the run invocation was converted to `@run junit ...` this has been switched back to `@run main ...`
> - There were two instances of the script missing some tests that should have had their methods updated with the `@Test` annotation: APITest.java and DFSSerialization.java. These tests have been updated accordingly.

This pull request has now been integrated.

Changeset: 4c7b313e
Author:    Justin Lu 
URL:       https://git.openjdk.org/jdk/commit/4c7b313e0dc917cdaffbb2ecc86d1347683acad0
Stats:     93 lines in 7 files changed: 46 ins; 20 del; 27 mod

8325908: Finish removal of IntlTest and CollatorTest

Reviewed-by: naoto

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

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

From bpb at openjdk.org  Fri Feb 16 17:19:59 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 16 Feb 2024 17:19:59 GMT
Subject: RFR: 8325340: Add ASCII fast-path to
 Data-/ObjectInputStream.readUTF [v7]
In-Reply-To: <5W9u4RJXEclgcBrZt6uWlGDcVYFRGJhkqa79PNJjxo8=.46b06cde-865f-447c-b8d6-bf4d80162686@github.com>
References: 
 <5W9u4RJXEclgcBrZt6uWlGDcVYFRGJhkqa79PNJjxo8=.46b06cde-865f-447c-b8d6-bf4d80162686@github.com>
Message-ID: 

On Fri, 16 Feb 2024 15:31:07 GMT, Claes Redestad  wrote:

>> Adding a fast-path for ASCII-only modified UTF-8 strings deserialied via Data- and ObjectInputStream
>> 
>> Testing: tier1-3
>
> Claes Redestad has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update test/micro/org/openjdk/bench/java/io/DataInputStreamTest.java
>    
>    Co-authored-by: Raffaello Giulietti 
>  - Update test/micro/org/openjdk/bench/java/io/ObjectInputStreamTest.java
>    
>    Co-authored-by: Raffaello Giulietti 

Marked as reviewed by bpb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17734#pullrequestreview-1885630906

From eirbjo at gmail.com  Fri Feb 16 19:20:31 2024
From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=)
Date: Fri, 16 Feb 2024 20:20:31 +0100
Subject: RFD: Should java.util.zip.[In|De]flater.getTotal[In|Out] be
 deprecated?
Message-ID: 

Hi,

Initially, the Deflater and Inflater classes in java.util.zip only
supported up to 2GB of inflated or deflated data, the reason being that
their getTotalIn and getTotalOut methods returns an int.

Around 2004, this limitation was remedied by introducing the new methods
getBytesRead and getBytesWritten returning long. The legacy methods
getTotalIn and getTotalOut were updated to simply delegate to the new
method with an added cast to int.

The legacy methods include notes in their Javadoc similar to this:

     * 
Since the number of bytes may be greater than
>      * Integer.MAX_VALUE, the {@link #getBytesRead()} method is now
>      * the preferred means of obtaining this information.



but these methods are not marked as @Deprecated in Javadoc or with
annotations.

Is there any good reason why these four methods have not been officially
deprecated in the past? If not, would it be worthwhile doing so now?

Cheers,
Eirik.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jlu at openjdk.org  Fri Feb 16 21:53:26 2024
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 16 Feb 2024 21:53:26 GMT
Subject: RFR: JDK-6801704: ChoiceFormat::applyPattern inconsistency for
 invalid patterns [v2]
In-Reply-To: 
References: 
Message-ID: 

> Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8317756) which defines the behavior for creating ChoiceFormats with incorrect patterns. The wording is added to both the ChoiceFormat constructor and ChoiceFormat::applyPattern method.
> 
> While ideally the inconsistent behavior itself could be fixed, this behavior has been long-standing for 20+ years and the benefit of consistent error handling does not outweigh the risk of breaking applications that may be relying on the "expected" incorrect behavior.
> 
> Examples of the range of behavior, (all examples violate the pattern syntax defined in the class description)
> 
> 
> // no limit -> throws an expected IllegalArgumentException
> var a = new ChoiceFormat("#foo");
> // no limit or relation in the last subPattern -> discards the incorrect portion, 'baz' and continues
> var b = new ChoiceFormat("0#foo|1#bar|baz"); 
> b.format(2); // returns 'bar'
> // no relation or limit -> discards the incorrect portion, 'foo' and continues
> var c = new ChoiceFormat("foo");
> c.format(1); // throws AIOOBE

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

  replace spec tag with note

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17856/files
  - new: https://git.openjdk.org/jdk/pull/17856/files/af8622c0..e4b602c4

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

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

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

From duke at openjdk.org  Fri Feb 16 22:01:05 2024
From: duke at openjdk.org (duke)
Date: Fri, 16 Feb 2024 22:01:05 GMT
Subject: Withdrawn: 8316662: Remove one allocation per conversion in
 Double.toString(double) and Float.toString(float)
In-Reply-To: 
References: 
Message-ID: <8lbhWVAqV225qjsH6oN_VHaxesN1-3PCAZJqJuhTsRw=.0e39d0ba-e9e1-4fe4-9499-29c86773e6eb@github.com>

On Thu, 21 Sep 2023 12:51:56 GMT, Raffaello Giulietti  wrote:

> By correctly sizing an intermediate `byte[]` and making use of the internal `newStringNoRepl()` method, one allocation per conversion can be avoided when the runtime uses compact strings.

This pull request has been closed without being integrated.

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

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

From prr at openjdk.org  Fri Feb 16 22:25:55 2024
From: prr at openjdk.org (Phil Race)
Date: Fri, 16 Feb 2024 22:25:55 GMT
Subject: RFR: 8325163: Enable -Wpedantic on clang [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 5 Feb 2024 10:58:17 GMT, Magnus Ihse Bursie  wrote:

>> Inspired by (the later backed-out) [JDK-8296115](https://bugs.openjdk.org/browse/JDK-8296115), I propose to enable `-Wpedantic` for clang. This has already found some irregularities in the code, like mistakenly using `#import` instead of `#include`. In this patch, I disable warnings for these individual buggy or badly written files, but I intend to post follow-up issues on the respective teams to have them properly fixed.
>> 
>> Unfortunately, it is not possible to enable `-Wpedantic` on gcc, since individual warnings in `-Wpedantic` cannot be disabled. This means that code like this:
>> 
>> 
>> #define DEBUG_ONLY(code) code;
>> 
>> DEBUG_ONLY(foo());
>> 
>> 
>> will result in a `; ;`. This breaks the C standard, but is benign, and we use it all over the place. On clang, we can ignore this by `-Wno-extra-semi`, but this is not available on gcc.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   FIx dtrace build

OK, although it would have been nice if you could have summarised what -pedantic and vla-extension are, so I didn't have to go and do research.

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

Marked as reviewed by prr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17687#pullrequestreview-1886164910

From naoto at openjdk.org  Fri Feb 16 22:44:55 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 16 Feb 2024 22:44:55 GMT
Subject: RFR: JDK-6801704: ChoiceFormat::applyPattern inconsistency for
 invalid patterns [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 16 Feb 2024 21:53:26 GMT, Justin Lu  wrote:

>> Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8317756) which defines the behavior for creating ChoiceFormats with incorrect patterns. The wording is added to both the ChoiceFormat constructor and ChoiceFormat::applyPattern method.
>> 
>> While ideally the inconsistent behavior itself could be fixed, this behavior has been long-standing for 20+ years and the benefit of consistent error handling does not outweigh the risk of breaking applications that may be relying on the "expected" incorrect behavior.
>> 
>> Examples of the range of behavior, (all examples violate the pattern syntax defined in the class description)
>> 
>> 
>> // no limit -> throws an expected IllegalArgumentException
>> var a = new ChoiceFormat("#foo");
>> // no limit or relation in the last subPattern -> discards the incorrect portion, 'baz' and continues
>> var b = new ChoiceFormat("0#foo|1#bar|baz"); 
>> b.format(2); // returns 'bar'
>> // no relation or limit -> discards the incorrect portion, 'foo' and continues
>> var c = new ChoiceFormat("foo");
>> c.format(1); // throws AIOOBE
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   replace spec tag with note

src/java.base/share/classes/java/text/ChoiceFormat.java line 235:

> 233:      *
> 234:      * @implNote Given an incorrect pattern, this implementation may either
> 235:      * throw an exception or succeed and discard the incorrect

An explanation for the exception may be helpful, either enumerating possible exceptions or simply a `RuntimeException`.

src/java.base/share/classes/java/text/ChoiceFormat.java line 237:

> 235:      * throw an exception or succeed and discard the incorrect
> 236:      * portion. Discarding the incorrect portion may result in a ChoiceFormat
> 237:      * with empty {@code limits} and {@code choices}.

`formats` instead of `choices`? A `choice` means a `limit`+`format` to me.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17856#discussion_r1493046166
PR Review Comment: https://git.openjdk.org/jdk/pull/17856#discussion_r1493048629

From duke at openjdk.org  Fri Feb 16 23:30:22 2024
From: duke at openjdk.org (Joshua Cao)
Date: Fri, 16 Feb 2024 23:30:22 GMT
Subject: RFR: 8324573: HashMap::putAll should resize to sum of both map
 sizes [v5]
In-Reply-To: 
References: 
Message-ID: 

> This change mirrors what we did for ConcurrentHashMap in https://github.com/openjdk/jdk/pull/17116. When we add all entries from one map to anther, we should resize that map to the size of the sum of both maps.
> 
> I used the command below to run the benchmarks. I set a high heap to reduce garbage collection noise.
> 
> java -Xms25G -jar benchmarks.jar -p size=100000 -p addSize=100000 -gc true org.openjdk.bench.java.util.HashMapBench
> 
> 
> Before change
> 
> 
> Benchmark            (addSize)        (mapType)  (size)  Mode  Cnt   Score   Error  Units
> HashMapBench.putAll     100000         HASH_MAP  100000  avgt    4  22.927 ? 3.170  ms/op
> HashMapBench.putAll     100000  LINKED_HASH_MAP  100000  avgt    4  25.198 ? 2.189  ms/op
> 
> 
> After change
> 
> 
> Benchmark            (addSize)        (mapType)  (size)  Mode  Cnt   Score   Error  Units
> HashMapBench.putAll     100000         HASH_MAP  100000  avgt    4  16.780 ? 0.526  ms/op
> HashMapBench.putAll     100000  LINKED_HASH_MAP  100000  avgt    4  19.721 ? 0.349  ms/op
> 
> 
> We see about average time improvements of 26% in HashMap and 20% in LinkedHashMap.
> 
> ---
> 
> In the worse case, we may have two maps with identical keys. In this case, we would aggressively resize when we do not need to. I'm also adding an additional `putAllSameKeys` benchmark.
> 
> Before change:
> 
> 
> Benchmark                                       (addSize)        (mapType)  (size)  Mode  Cnt        Score   Error   Units
> HashMapBench.putAllSameKeys                        100000         HASH_MAP  100000  avgt             6.956           ms/op
> HashMapBench.putAllSameKeys:gc.alloc.rate          100000         HASH_MAP  100000  avgt          1091.383          MB/sec
> HashMapBench.putAllSameKeys:gc.alloc.rate.norm     100000         HASH_MAP  100000  avgt       7968871.917            B/op
> HashMapBench.putAllSameKeys:gc.count               100000         HASH_MAP  100000  avgt               ? 0          counts
> HashMapBench.putAllSameKeys                        100000  LINKED_HASH_MAP  100000  avgt             8.417           ms/op
> HashMapBench.putAllSameKeys:gc.alloc.rate          100000  LINKED_HASH_MAP  100000  avgt           992.543          MB/sec
> HashMapBench.putAllSameKeys:gc.alloc.rate.norm     100000  LINKED_HASH_MAP  100000  avgt       8768892.941            B/op
> HashMapBench.putAllSameKeys:gc.count               100000  LINKED_HASH_MAP  100000  avgt               ? 0          counts
> 
> 
> After change:
> 
> 
> Benchmark                                       (addSize)        (mapType)...

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

 - Add note about conservative resizing
 - Merge branch 'master' into hashmap
 - extract msize variable
 - Use max of both sizes and other maps size in case of overflow
 - Add benchmark with all duplicate keys
 - 8324573: HashMap::putAll should resize to sum of both map sizes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17544/files
  - new: https://git.openjdk.org/jdk/pull/17544/files/2a896d0c..0edb86f1

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

  Stats: 54376 lines in 2260 files changed: 23981 ins; 13857 del; 16538 mod
  Patch: https://git.openjdk.org/jdk/pull/17544.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17544/head:pull/17544

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

From duke at openjdk.org  Fri Feb 16 23:32:55 2024
From: duke at openjdk.org (Joshua Cao)
Date: Fri, 16 Feb 2024 23:32:55 GMT
Subject: RFR: 8324573: HashMap::putAll add notes for conservative resizing
 [v4]
In-Reply-To: <-eVaZ9AgZ_GzfN2yeTK8VdE3efeSyx1NqjPyOOkPZAI=.e1007274-1943-46eb-bfab-f796d461da31@github.com>
References: 
 <-eVaZ9AgZ_GzfN2yeTK8VdE3efeSyx1NqjPyOOkPZAI=.e1007274-1943-46eb-bfab-f796d461da31@github.com>
Message-ID: 

On Fri, 2 Feb 2024 17:38:13 GMT, Joshua Cao  wrote:

>> Add notes for `HashMap::putAll()` conservative resizing.
>> 
>> Note: everything below this line is from the original change. After discussion, we decided to keep the conservative resizing, but we should add an `@implNote` for the decision.
>> 
>> ---
>> 
>> This change mirrors what we did for ConcurrentHashMap in https://github.com/openjdk/jdk/pull/17116. When we add all entries from one map to anther, we should resize that map to the size of the sum of both maps.
>> 
>> I used the command below to run the benchmarks. I set a high heap to reduce garbage collection noise.
>> 
>> java -Xms25G -jar benchmarks.jar -p size=100000 -p addSize=100000 -gc true org.openjdk.bench.java.util.HashMapBench
>> 
>> 
>> Before change
>> 
>> 
>> Benchmark            (addSize)        (mapType)  (size)  Mode  Cnt   Score   Error  Units
>> HashMapBench.putAll     100000         HASH_MAP  100000  avgt    4  22.927 ? 3.170  ms/op
>> HashMapBench.putAll     100000  LINKED_HASH_MAP  100000  avgt    4  25.198 ? 2.189  ms/op
>> 
>> 
>> After change
>> 
>> 
>> Benchmark            (addSize)        (mapType)  (size)  Mode  Cnt   Score   Error  Units
>> HashMapBench.putAll     100000         HASH_MAP  100000  avgt    4  16.780 ? 0.526  ms/op
>> HashMapBench.putAll     100000  LINKED_HASH_MAP  100000  avgt    4  19.721 ? 0.349  ms/op
>> 
>> 
>> We see about average time improvements of 26% in HashMap and 20% in LinkedHashMap.
>> 
>> ---
>> 
>> In the worse case, we may have two maps with identical keys. In this case, we would aggressively resize when we do not need to. I'm also adding an additional `putAllSameKeys` benchmark.
>> 
>> Before change:
>> 
>> 
>> Benchmark                                       (addSize)        (mapType)  (size)  Mode  Cnt        Score   Error   Units
>> HashMapBench.putAllSameKeys                        100000         HASH_MAP  100000  avgt             6.956           ms/op
>> HashMapBench.putAllSameKeys:gc.alloc.rate          100000         HASH_MAP  100000  avgt          1091.383          MB/sec
>> HashMapBench.putAllSameKeys:gc.alloc.rate.norm     100000         HASH_MAP  100000  avgt       7968871.917            B/op
>> HashMapBench.putAllSameKeys:gc.count               100000         HASH_MAP  100000  avgt               ? 0          counts
>> HashMapBench.putAllSameKeys                        100000  LINKED_HASH_MAP  100000  avgt             8.417           ms/op
>> HashMapBench.putAllSameKeys:gc.alloc.rate          100000  LINKED_HASH_MAP  100000  avgt           992.543          MB/sec
>> HashM...
>
> Joshua Cao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   extract msize variable

I copy and pasted the text on conservative resizing that was removed in the past as an `@implNote`. I removed the functionality change. Keeping the benchmark in here cause why not.

> give the advice that users can presize the destination map accordingly if they want to avoid resizing when merging in other maps

I don't think there is a public API for this, so omitting from the comments.

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

PR Comment: https://git.openjdk.org/jdk/pull/17544#issuecomment-1949481110

From jlu at openjdk.org  Fri Feb 16 23:35:10 2024
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 16 Feb 2024 23:35:10 GMT
Subject: RFR: JDK-6801704: ChoiceFormat::applyPattern inconsistency for
 invalid patterns [v3]
In-Reply-To: 
References: 
Message-ID: 

> Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8317756) which defines the behavior for creating ChoiceFormats with incorrect patterns. The wording is added to both the ChoiceFormat constructor and ChoiceFormat::applyPattern method.
> 
> While ideally the inconsistent behavior itself could be fixed, this behavior has been long-standing for 20+ years and the benefit of consistent error handling does not outweigh the risk of breaking applications that may be relying on the "expected" incorrect behavior.
> 
> Examples of the range of behavior, (all examples violate the pattern syntax defined in the class description)
> 
> 
> // no limit -> throws an expected IllegalArgumentException
> var a = new ChoiceFormat("#foo");
> // no limit or relation in the last subPattern -> discards the incorrect portion, 'baz' and continues
> var b = new ChoiceFormat("0#foo|1#bar|baz"); 
> b.format(2); // returns 'bar'
> // no relation or limit -> discards the incorrect portion, 'foo' and continues
> var c = new ChoiceFormat("foo");
> c.format(1); // throws AIOOBE

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

  implement suggested changes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17856/files
  - new: https://git.openjdk.org/jdk/pull/17856/files/e4b602c4..00f8179a

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

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

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

From jlu at openjdk.org  Fri Feb 16 23:35:11 2024
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 16 Feb 2024 23:35:11 GMT
Subject: RFR: JDK-6801704: ChoiceFormat::applyPattern inconsistency for
 invalid patterns [v2]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Fri, 16 Feb 2024 22:38:11 GMT, Naoto Sato  wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   replace spec tag with note
>
> src/java.base/share/classes/java/text/ChoiceFormat.java line 235:
> 
>> 233:      *
>> 234:      * @implNote Given an incorrect pattern, this implementation may either
>> 235:      * throw an exception or succeed and discard the incorrect
> 
> An explanation for the exception may be helpful, either enumerating possible exceptions or simply a `RuntimeException`.

I think initially since it was an `implSpec` tag, I didn't want to over-detail the inconsistent behavior as specification. As an `implNote` tag it seems much better to give further explanation. I added details for the two possible exceptions. Let me know if you think I should go into further detail on when a pattern may be discarded if you think that is necessary.

> src/java.base/share/classes/java/text/ChoiceFormat.java line 237:
> 
>> 235:      * throw an exception or succeed and discard the incorrect
>> 236:      * portion. Discarding the incorrect portion may result in a ChoiceFormat
>> 237:      * with empty {@code limits} and {@code choices}.
> 
> `formats` instead of `choices`? A `choice` means a `limit`+`format` to me.

Yes, should definitely be `formats` here, thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17856#discussion_r1493074870
PR Review Comment: https://git.openjdk.org/jdk/pull/17856#discussion_r1493073571

From duke at openjdk.org  Fri Feb 16 23:46:01 2024
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Fri, 16 Feb 2024 23:46:01 GMT
Subject: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort)
 [v11]
In-Reply-To: <0OkFUL1UCNcLRNh4P2ZdKvMENJgFy8Tz2BA5l2QgDXE=.77152fca-3c03-46a0-9855-bcf1c9b8d152@github.com>
References: <918oCEfFu2JweXfV-afD1l_AGDDuc7dJwAxip-Ze6ZI=.8d5e9692-23db-47e4-9586-99e53b9cfbb6@github.com>
 
 
 
 
 
 <-bYhysKjQVb_ZS0I0YutJZ7umfYwbs74rtK6-d2qL9U=.f9981e59-f0c4-48f3-ad7e-5627aad00919@github.com>
 <91Zv361kqKOjCSJPu20-yhKOb4lBIZVyVTm9f79dkcQ=.745c271d-3cb1-4ff3-9d71-5cad85ff4f14@github.com>
 
 <9q8Gg6DQnrf0HLW3oxwfpoUP9639drr1BIQMc1rxDFo=.eb4ea73c-b632-446a-8d50-b51838f67f69@github.com>
 
 
 
 <0OkFUL1UCNcLRNh4P2ZdKvMENJgFy8Tz2BA5l2QgDXE=.77152fca-3c03-46a0-9855-bcf1c9b8d152@github.com>
Message-ID: 

On Thu, 8 Feb 2024 20:04:20 GMT, Vladimir Yaroslavskiy  wrote:

>> Hi Vladimir (@iaroslavski),
>> 
>> The new ArraysSortNew.Java has compilation issues:
>> 
>> 
>> error: DualPivotQuicksort is not public in java.util; cannot be accessed from outside package
>>              java.util.DualPivotQuicksort.sort(b, PARALLELISM, 0, b.length);
>> 
>> Have you run into this issue? 
>> 
>> Thanks,
>> Vamsi
>
> Hi Vamsi (@vamsi-parasa),
> 
> My fault, there was an incorrect version of ArraysSortNew.java. Methods, of course, should be
> 
> @Benchmark
> public void sort() {
>     Arrays.sort(b);
> }
> 
> @Benchmark
> public void p_sort() {
>     Arrays.parallelSort(b);
> }
> 
> I uploaded correct version, see
> https://github.com/iaroslavski/sorting/blob/master/radixsort/ArraysSortNew.java
> 
> I also comment that pom.xml contains additional options (I guess you have the same)
> --add-exports=java.base/jdk.internal.misc=ALL-UNNAMED
> --add-exports=java.base/jdk.internal.vm.annotation=ALL-UNNAMED
> full text is there https://github.com/iaroslavski/sorting/blob/master/radixsort/pom.xml
> 
> and command to run test is
> java --add-exports=java.base/jdk.internal.vm.annotation=ALL-UNNAMED --add-exports=java.base/jdk.internal.misc=ALL-UNNAMED -jar target/benchmarks.jar
> 
> I assume that each variant of DPQS (DualPivotQuicksort_jdk, DualPivotQuicksort_r20p, DualPivotQuicksort_r20s, DualPivotQuicksort_r25p, DualPivotQuicksort_r25s) is renamed to DualPivotQuicksort and put into
> package java.util. Then benchmarking for a given variant with patched JDK is executed.
> 
> Thank you,
> Vladimir

Hello Vladimir (@iaroslavski),

Please see the data below. Each DPQS class was copied to java.util and the JDK was recompiled.

Thanks,
Vamsi

















Benchmark | (builder) | (size) | Stock JDK | r20p | r20s | r25p | r25s
-- | -- | -- | -- | -- | -- | -- | --
ArraysSort.Int.p_sort | RANDOM | 600 | 1.618 | 2.601 | 2.966 | 2.898 | 3.269
ArraysSort.Int.p_sort | RANDOM | 2000 | 7.433 | 8.438 | 8.463 | 8.414 | 8.65
ArraysSort.Int.p_sort | RANDOM | 90000 | 258.853 | 355.261 | 326.378 | 347.65 | 321.894
ArraysSort.Int.p_sort | RANDOM | 400000 | 842.085 | 1225.929 | 899.852 | 1278.681 | 932.627
ArraysSort.Int.p_sort | RANDOM | 3000000 | 5723.659 | 8711.108 | 6086.974 | 8948.101 | 6122.612
ArraysSort.Int.p_sort | REPEATED | 600 | 0.52 | 0.585 | 0.629 | 0.586 | 0.579
ArraysSort.Int.p_sort | REPEATED | 2000 | 1.18 | 1.225 | 1.21 | 1.225 | 1.238
ArraysSort.Int.p_sort | REPEATED | 90000 | 102.142 | 85.79 | 86.131 | 87.954 | 86.036
ArraysSort.Int.p_sort | REPEATED | 400000 | 244.508 | 229.142 | 227.613 | 228.608 | 228.367
ArraysSort.Int.p_sort | REPEATED | 3000000 | 2752.745 | 2584.103 | 2544.192 | 2576.803 | 2609.833
ArraysSort.Int.p_sort | STAGGER | 600 | 1.146 | 0.894 | 0.898 | 0.904 | 0.912
ArraysSort.Int.p_sort | STAGGER | 2000 | 3.712 | 3.096 | 3.121 | 3.03 | 3.049
ArraysSort.Int.p_sort | STAGGER | 90000 | 72.763 | 77.575 | 78.366 | 79.158 | 77.199
ArraysSort.Int.p_sort | STAGGER | 400000 | 212.455 | 228.331 | 225.888 | 224.686 | 225.728
ArraysSort.Int.p_sort | STAGGER | 3000000 | 2290.327 | 2216.741 | 2196.138 | 2236.658 | 2262.472
ArraysSort.Int.p_sort | SHUFFLE | 600 | 2.01 | 2.92 | 2.907 | 2.91 | 2.926
ArraysSort.Int.p_sort | SHUFFLE | 2000 | 7.06 | 7.759 | 7.776 | 7.688 | 8.062
ArraysSort.Int.p_sort | SHUFFLE | 90000 | 157.728 | 151.871 | 151.101 | 154.03 | 151.2
ArraysSort.Int.p_sort | SHUFFLE | 400000 | 441.166 | 715.243 | 449.698 | 699.75 | 447.069
ArraysSort.Int.p_sort | SHUFFLE | 3000000 | 4326.88 | 7133.045 | 4205.47 | 7161.862 | 4337.321
ArraysSort.Int.sort | RANDOM | 600 | 1.671 | 2.707 | 2.741 | 2.698 | 2.779
ArraysSort.Int.sort | RANDOM | 2000 | 7.265 | 8.226 | 8.942 | 8.193 | 8.339
ArraysSort.Int.sort | RANDOM | 90000 | 529.054 | 559.499 | 554.29 | 566.009 | 559.131
ArraysSort.Int.sort | RANDOM | 400000 | 2448.226 | 2654.71 | 2622.964 | 2629.673 | 2619.051
ArraysSort.Int.sort | RANDOM | 3000000 | 21471.133 | 22670.45 | 22654.94 | 22811.7 | 22957.97
ArraysSort.Int.sort | REPEATED | 600 | 0.517 | 0.578 | 0.578 | 0.587 | 0.568
ArraysSort.Int.sort | REPEATED | 2000 | 1.136 | 1.228 | 1.215 | 1.377 | 1.222
ArraysSort.Int.sort | REPEATED | 90000 | 57.575 | 56.406 | 56.542 | 56.068 | 56.77
ArraysSort.Int.sort | REPEATED | 400000 | 178.874 | 173.883 | 176.098 | 171.975 | 172.067
ArraysSort.Int.sort | REPEATED | 3000000 | 1856.71 | 1588.104 | 1489.842 | 1480.34 | 1522.399
ArraysSort.Int.sort | STAGGER | 600 | 1.143 | 0.893 | 0.901 | 0.896 | 0.906
ArraysSort.Int.sort | STAGGER | 2000 | 3.726 | 3.062 | 3.18 | 3.061 | 3.169
ArraysSort.Int.sort | STAGGER | 90000 | 138.503 | 135.008 | 134.023 | 136.328 | 136.026
ArraysSort.Int.sort | STAGGER | 400000 | 615.732 | 608.269 | 609.348 | 606.986 | 603.287
ArraysSort.Int.sort | STAGGER | 3000000 | 4914.443 | 4578.733 | 4584.407 | 4591.832 | 4613.16
ArraysSort.Int.sort | SHUFFLE | 600 | 2.137 | 2.886 | 2.948 | 2.898 | 2.871
ArraysSort.Int.sort | SHUFFLE | 2000 | 7.029 | 7.697 | 8.133 | 7.666 | 8.122
ArraysSort.Int.sort | SHUFFLE | 90000 | 482.23 | 463.796 | 454.744 | 463.55 | 462.538
ArraysSort.Int.sort | SHUFFLE | 400000 | 2195.147 | 2276.979 | 2233.066 | 2234.718 | 2216.289
ArraysSort.Int.sort | SHUFFLE | 3000000 | 18654.727 | 19861.77 | 18980.49 | 19039.88 | 19081.4







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

PR Comment: https://git.openjdk.org/jdk/pull/13568#issuecomment-1949491405

From naoto at openjdk.org  Sat Feb 17 00:05:52 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Sat, 17 Feb 2024 00:05:52 GMT
Subject: RFR: JDK-6801704: ChoiceFormat::applyPattern inconsistency for
 invalid patterns [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 16 Feb 2024 23:35:10 GMT, Justin Lu  wrote:

>> Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8317756) which defines the behavior for creating ChoiceFormats with incorrect patterns. The wording is added to both the ChoiceFormat constructor and ChoiceFormat::applyPattern method.
>> 
>> While ideally the inconsistent behavior itself could be fixed, this behavior has been long-standing for 20+ years and the benefit of consistent error handling does not outweigh the risk of breaking applications that may be relying on the "expected" incorrect behavior.
>> 
>> Examples of the range of behavior, (all examples violate the pattern syntax defined in the class description)
>> 
>> 
>> // no limit -> throws an expected IllegalArgumentException
>> var a = new ChoiceFormat("#foo");
>> // no limit or relation in the last subPattern -> discards the incorrect portion, 'baz' and continues
>> var b = new ChoiceFormat("0#foo|1#bar|baz"); 
>> b.format(2); // returns 'bar'
>> // no relation or limit -> discards the incorrect portion, 'foo' and continues
>> var c = new ChoiceFormat("foo");
>> c.format(1); // throws AIOOBE
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   implement suggested changes

LGTM. Thanks for the changes.

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17856#pullrequestreview-1886241903

From valeriep at openjdk.org  Sat Feb 17 00:47:57 2024
From: valeriep at openjdk.org (Valerie Peng)
Date: Sat, 17 Feb 2024 00:47:57 GMT
Subject: RFR: 8325506: Ensure randomness is only read from provided
 SecureRandom object [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 13 Feb 2024 22:30:28 GMT, Weijun Wang  wrote:

>> Many crypto service classes require a `SecureRandom` object at initialization. This test goes through each of them and calculates (generate, encrypt, sign,...) twice with the same `SecureRandom` object and ensures the output is the same.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   assertNotEqualsByteArray

test/lib/jdk/test/lib/Asserts.java line 290:

> 288:     public static void assertNotEqualsByteArray(byte[] lhs, byte[] rhs, String msg) {
> 289:         if (Arrays.equals(lhs, rhs)) {
> 290:             msg = Objects.toString(msg, "assertEqualsByteArray")

method name in the message not matching the method?

test/lib/jdk/test/lib/Asserts.java line 292:

> 290:             msg = Objects.toString(msg, "assertEqualsByteArray")
> 291:                     + ": expected " + HexFormat.of().formatHex(lhs)
> 292:                     + " to equal " + HexFormat.of().formatHex(rhs);

"to NOT equal"?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17776#discussion_r1493106466
PR Review Comment: https://git.openjdk.org/jdk/pull/17776#discussion_r1493106604

From valeriep at openjdk.org  Sat Feb 17 01:05:56 2024
From: valeriep at openjdk.org (Valerie Peng)
Date: Sat, 17 Feb 2024 01:05:56 GMT
Subject: RFR: 8325506: Ensure randomness is only read from provided
 SecureRandom object [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 13 Feb 2024 22:30:28 GMT, Weijun Wang  wrote:

>> Many crypto service classes require a `SecureRandom` object at initialization. This test goes through each of them and calculates (generate, encrypt, sign,...) twice with the same `SecureRandom` object and ensures the output is the same.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   assertNotEqualsByteArray

test/lib/jdk/test/lib/Asserts.java line 285:

> 283:      * @param lhs The left hand side of the comparison.
> 284:      * @param rhs The right hand side of the comparison.
> 285:      * @param msg A description of the assumption; {@code null} for a default message.

nit: exceeds 80 chars

test/lib/jdk/test/lib/Asserts.java line 288:

> 286:      * @throws RuntimeException if the assertion is not true.
> 287:      */
> 288:     public static void assertNotEqualsByteArray(byte[] lhs, byte[] rhs, String msg) {

nit: exceeds 80 chars

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17776#discussion_r1493111466
PR Review Comment: https://git.openjdk.org/jdk/pull/17776#discussion_r1493111899

From Alan.Bateman at oracle.com  Sat Feb 17 08:09:32 2024
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sat, 17 Feb 2024 08:09:32 +0000
Subject: RFD: Should java.util.zip.[In|De]flater.getTotal[In|Out] be
 deprecated?
In-Reply-To: 
References: 
Message-ID: 

On 16/02/2024 19:20, Eirik Bj?rsn?s wrote:
> Hi,
>
> Initially,?the Deflater and Inflater classes in java.util.zip only 
> supported up to 2GB of inflated or deflated data, the reason being 
> that their getTotalIn and getTotalOut methods returns an int.
>
> Around 2004, this limitation was remedied by introducing the new 
> methods getBytesRead and getBytesWritten returning long. The legacy 
> methods getTotalIn and getTotalOut were updated to simply delegate to 
> the new method with an added cast to int.
>
> The legacy methods include notes in their Javadoc similar to this:
>
>     ? ?* 
Since the number of bytes may be greater than
>     ? ? ?* Integer.MAX_VALUE, the {@link #getBytesRead()} method is now
>     ? ? ?* the preferred means of obtaining this information.

>
>
> but these methods are not marked as @Deprecated in Javadoc or with 
> annotations.
>
> Is there any good reason why these four methods have not been 
> officially deprecated in the past? If not, would it be worthwhile 
> doing so now?
>

Good question. I'm surprised the spec for these methods wasn't clarified 
in Java 5 when the new methods to return long were added. Right not, 
it's not clear from the spec how the older methods behave when the 
number of bytes is greater than Integer.MAX_VALUE. Long standing 
behavior is to cast to int so they will return a negative value once the 
total in/out exceeds Integer.MAX_VALUE.? Methods such as 
URLConnection::getContentLength are clamped so they return 
Integer.MAX_VALUE when the content length is larger than that. Both 
behaviors are a hazard but arguably the Inflater/Delater behavior is 
worse. So I think there is good case for deprecating the old methods.

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

From eirbjo at gmail.com  Sat Feb 17 10:55:30 2024
From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=)
Date: Sat, 17 Feb 2024 11:55:30 +0100
Subject: RFD: Should java.util.zip.[In|De]flater.getTotal[In|Out] be
 deprecated?
In-Reply-To: 
References: 
 
Message-ID: 

On Sat, Feb 17, 2024 at 9:09?AM Alan Bateman 
wrote:

> So I think there is good case for deprecating the old methods.
>

Thanks Alan, I'll take this task on and have filed the following task to
track it: https://bugs.openjdk.org/browse/JDK-8326096

Cheers,
Eirik.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From eirbjo at openjdk.org  Sat Feb 17 12:42:05 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Sat, 17 Feb 2024 12:42:05 GMT
Subject: RFR: 8326099: GZIPOutputStream should use Deflater.getBytesRead()
 instead of Deflater.getTotalIn()
Message-ID: <9TQrYJq04NGGELIp4gx5GP9aVRX5X0Zm-PX-N9czKq4=.72582b38-6636-4d32-a536-a9cbc0d7e1e7@github.com>

Please review this cleanup PR in preparation for deprecating `Deflater.getTotalIn()` in JDK-8326096. 

This PR replaces `GZIPOutputStream.writeTrailer`'s call to `Deflater.getTotalIn()` with a call to `Deflater.getBytesRead()` followed by an explicit conversion to "modulo 2^32" (a cast to int) as described in RFC 1952:


 ISIZE (Input SIZE)
  This contains the size of the original (uncompressed) input
  data modulo 2^32.


Testing and verification: This should be trivially verifiable by code inspection. Nevertheless, I wrote a test which writes Integer.MAX_VALUE +1 bytes of uncompressed data and verified that the last four bytes written to the file was indeed as expected. (This test is not included in this PR because of its runtime and resource requirements).

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

Commit messages:
 - Update copyright year
 - Update GZIPOutputStream.writeTrailer to use Deflater.getBytesRead() instead of Deflater.getTotalIn()

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

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

From eirbjo at openjdk.org  Sat Feb 17 13:06:12 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Sat, 17 Feb 2024 13:06:12 GMT
Subject: RFR: 8326100: DeflaterDictionaryTests should use
 Deflater.getBytesWritten instead of Deflater.getTotalOut
Message-ID: 

Please review this test-only cleanup PR in preparation for deprecating `Deflater.getTotalOut()` in JDK-8326096.

This PR replaces various calls in`test/jdk/java/util/zip/DeflaterDictionaryTests.java` to `Deflater.getTotalOut()` when formatting some debugging output lines. 

Additionally, various debug output lines claim to print the result of calling `Deflater.getAdler`, but instead prints the output of `Deflater.getTotalOut'. This PR fixes this to print the actual Adler value instead.

Testing and verification: This is a test-only fix affecting only debug output. I have added the `noreg-self` label to the issue.

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

Commit messages:
 - Update DeflaterDictionaryTests to use Deflater.getBytesWritten instead of Deflater.getTotalOut

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

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

From weijun at openjdk.org  Sat Feb 17 14:08:12 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Sat, 17 Feb 2024 14:08:12 GMT
Subject: RFR: 8325506: Ensure randomness is only read from provided
 SecureRandom object [v4]
In-Reply-To: 
References: 
Message-ID: 

> Many crypto service classes require a `SecureRandom` object at initialization. This test goes through each of them and calculates (generate, encrypt, sign,...) twice with the same `SecureRandom` object and ensures the output is the same.

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

  not not not

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17776/files
  - new: https://git.openjdk.org/jdk/pull/17776/files/96e09a5d..180d31ca

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

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

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

From weijun at openjdk.org  Sat Feb 17 14:08:12 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Sat, 17 Feb 2024 14:08:12 GMT
Subject: RFR: 8325506: Ensure randomness is only read from provided
 SecureRandom object [v3]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Sat, 17 Feb 2024 01:01:49 GMT, Valerie Peng  wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   assertNotEqualsByteArray
>
> test/lib/jdk/test/lib/Asserts.java line 285:
> 
>> 283:      * @param lhs The left hand side of the comparison.
>> 284:      * @param rhs The right hand side of the comparison.
>> 285:      * @param msg A description of the assumption; {@code null} for a default message.
> 
> nit: exceeds 80 chars

It has 87 chars, but there are many long lines in this file. For example, line 184 has 113 chars.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17776#discussion_r1493341744

From rgiulietti at openjdk.org  Sat Feb 17 16:51:55 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Sat, 17 Feb 2024 16:51:55 GMT
Subject: RFR: 8316662: Remove one allocation per conversion in
 Double.toString(double) and Float.toString(float) [v3]
In-Reply-To: <54uc54dqaE7tut0nQ9_jdWzMjnMdGDGbw0UZNtdzqM8=.50178293-96f5-4115-a7ee-93cbdd3b8e42@github.com>
References: 
 <54uc54dqaE7tut0nQ9_jdWzMjnMdGDGbw0UZNtdzqM8=.50178293-96f5-4115-a7ee-93cbdd3b8e42@github.com>
Message-ID: 

On Fri, 27 Oct 2023 12:10:07 GMT, Raffaello Giulietti  wrote:

>> By correctly sizing an intermediate `byte[]` and making use of the internal `newStringNoRepl()` method, one allocation per conversion can be avoided when the runtime uses compact strings.
>
> Raffaello Giulietti has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Merge branch 'master' into 8316662
>  - Uppercase JLA.
>  - 8316662: Remove one allocation per conversion in Double.toString(double) and Float.toString(float)

Reopen

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

PR Comment: https://git.openjdk.org/jdk/pull/15861#issuecomment-1950254176

From alanb at openjdk.org  Sun Feb 18 08:23:54 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 18 Feb 2024 08:23:54 GMT
Subject: RFR: 8326100: DeflaterDictionaryTests should use
 Deflater.getBytesWritten instead of Deflater.getTotalOut
In-Reply-To: 
References: 
Message-ID: 

On Sat, 17 Feb 2024 13:00:08 GMT, Eirik Bj?rsn?s  wrote:

> Please review this test-only cleanup PR in preparation for deprecating `Deflater.getTotalOut()` in JDK-8326096.
> 
> This PR replaces various calls in`test/jdk/java/util/zip/DeflaterDictionaryTests.java` to `Deflater.getTotalOut()` with calls to `Deflater.getBytesWritten()` when formatting some debugging output lines. 
> 
> Additionally, various debug output lines claim to print the result of calling `Deflater.getAdler`, but instead prints the output of `Deflater.getTotalOut'. This PR fixes this to print the actual Adler value instead.
> 
> Testing and verification: This is a test-only fix affecting only debug output. I have added the `noreg-self` label to the issue.

The hazard when the format specifiers are all %s.

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17901#pullrequestreview-1887122096

From eirbjo at openjdk.org  Sun Feb 18 10:56:03 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Sun, 18 Feb 2024 10:56:03 GMT
Subject: RFR: 8326100: DeflaterDictionaryTests should use
 Deflater.getBytesWritten instead of Deflater.getTotalOut [v2]
In-Reply-To: 
References: 
Message-ID: 

> Please review this test-only cleanup PR in preparation for deprecating `Deflater.getTotalOut()` in JDK-8326096.
> 
> This PR replaces various calls in`test/jdk/java/util/zip/DeflaterDictionaryTests.java` to `Deflater.getTotalOut()` with calls to `Deflater.getBytesWritten()` when formatting some debugging output lines. 
> 
> Additionally, various debug output lines claim to print the result of calling `Deflater.getAdler`, but instead prints the output of `Deflater.getTotalOut'. This PR fixes this to print the actual Adler value instead.
> 
> Testing and verification: This is a test-only fix affecting only debug output. I have added the `noreg-self` label to the issue.

Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:

  Use more specific format specifier %d instead of %s

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17901/files
  - new: https://git.openjdk.org/jdk/pull/17901/files/4f9059a0..aa46ddaf

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

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

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

From eirbjo at openjdk.org  Sun Feb 18 10:58:54 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Sun, 18 Feb 2024 10:58:54 GMT
Subject: RFR: 8326100: DeflaterDictionaryTests should use
 Deflater.getBytesWritten instead of Deflater.getTotalOut [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Sun, 18 Feb 2024 10:56:03 GMT, Eirik Bj?rsn?s  wrote:

>> Please review this test-only cleanup PR in preparation for deprecating `Deflater.getTotalOut()` in JDK-8326096.
>> 
>> This PR replaces various calls in`test/jdk/java/util/zip/DeflaterDictionaryTests.java` to `Deflater.getTotalOut()` with calls to `Deflater.getBytesWritten()` when formatting some debugging output lines. 
>> 
>> Additionally, various debug output lines claim to print the result of calling `Deflater.getAdler`, but instead prints the output of `Deflater.getTotalOut'. This PR fixes this to print the actual Adler value instead.
>> 
>> Testing and verification: This is a test-only fix affecting only debug output. I have added the `noreg-self` label to the issue.
>
> Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use more specific format specifier %d instead of %s

Thanks for your review Alan! 

> The hazard when the format specifiers are all %s.

Not sure I understand your comment since all arguments are of the same type (int) anyhow, I guess they would still be easy to get wrong or in the wrong order. Was that the hazard you refer to?

Anyhow, I went ahead and replaced the %s specifiers with the more specific decimal integer specifier %d.

WDYT?

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

PR Comment: https://git.openjdk.org/jdk/pull/17901#issuecomment-1951145968

From frank.kretschmer at gmx.net  Sun Feb 18 14:36:24 2024
From: frank.kretschmer at gmx.net (Frank Kretschmer)
Date: Sun, 18 Feb 2024 15:36:24 +0100
Subject: OpenJDK 17: Loitering AbstractQueuedSynchronizer$ConditionNode
 instances (also on latest master branch) [JDK-8325754]
In-Reply-To: <59c3b1bc-fd60-4215-b8f7-96421f1881e2@gmail.com>
References: <591b0e9c-1d7a-405d-ace1-bd94f8dbbe22@gmx.net>
 
 
 <64bc8cbd-78f4-44f4-90ae-80466c563281@gmx.net>
 <6d3b62cb-15f4-471c-97b6-b72977223f91@gmx.net>
 <59c3b1bc-fd60-4215-b8f7-96421f1881e2@gmail.com>
Message-ID: <127f2696-5f6d-4bab-b45e-e7597f267add@gmx.net>

Hello Jaikiran, hello Viktor,

in the meantime, I've seen that the JBS issue has been assigned to
Viktor Klang. @Viktor: I totally agree with your comment that the
proposed solution may not be the best possible option, and that further
explorations were required.

My intention to propose unlinking ConditionNodes by null'ing their
?nextWaiter? reference was just to verify that the chain of ?nextWaiter?
references leads to the observed garbage collection behavior, and that
the GC is able to collect the nodes during minor / young collections if
the references are cleaned in time.

I checked also a few other variants (null'ing the ?nextWaiter? reference
at the end of all await...() methods in ConditionObject, or in/just
before enqueue()), but at the end of the day, I felt that null'ing it in
doSignal() explains what I want to show the easiest. On the other hand,
the other options could be better in order to avoid race conditions with
canceled nodes.

For sure there are many other options that I am not aware of, so please
take my proposal just as an example.

Looking forward to your explorations.

Best regards

Frank


Am 14.02.2024 um 07:43 schrieb Jaikiran Pai:
>
> Hello Frank,
>
> I see that a JBS issue has been created for this same issue
> https://bugs.openjdk.org/browse/JDK-8325754.
>
> I don't have enough knowledge of this area and haven't reviewed this
> part of the code in detail to see if there are any obvious issues with
> what you are proposing as a solution. Since there's now a JBS issue
> created for this and you seem to have done enough investigation and
> work on this one already, would you be interested in creating a pull
> request against the https://github.com/openjdk/jdk repo with this
> proposed change? (you'll have to sign a OCA). This guide
> https://openjdk.org/guide/ should help you get started. It can then go
> through the usual reviews that a bug fix/enhancement goes through.
>
> -Jaikiran
>
> On 11/02/24 7:27 pm, Frank Kretschmer wrote:
>>
>> Hello Core-Libs-Dev team,
>>
>> may I ask you about your opinion about a tiny one-liner change in
>> AbstractQueuedSynchronizer, just as a suggestion how to make
>> ConditionObjects / Nodes even more garbage collector friendly?
>>
>> Checked out
>> https://github.com/openjdk/jdk/blob/jdk-17%2B35/src/java.base/share/classes/java/util/concurrent/locks/AbstractQueuedSynchronizer.java
>> (the same on master branch with different line numbers near to line
>> 1506):
>>
>> @@ -1431,40 +1431,41 @@ public abstract class AbstractQueuedSynchronizer
>> ???? public class ConditionObject implements Condition,
>> java.io.Serializable {
>> ???????? // ...
>> ???????? private void doSignal(ConditionNode first, boolean all) {
>> ???????????? while (first != null) {
>> ???????????????? ConditionNode next = first.nextWaiter;
>> +??????????????? first.nextWaiter = null;? // GC-friendly: avoid
>> chains of dead ConditionNodes
>> ???????????????? if ((firstWaiter = next) == null)
>> ???????????????????? lastWaiter = null;
>> ???????????????? if ((first.getAndUnsetStatus(COND) & COND) != 0) {
>> ???????????????????? enqueue(first);
>> ???????????????? // ...
>>
>> By setting the nextWaiter to null of the first condition node, which
>> is transferred from the condition queue to the sync queue in this
>> method, long chains of ConditionNode instances can be avoided. Though
>> a single ConditionNode is small, these chains of ConditionNodes
>> become very huge on the heap (I've seen more than 1GB on an
>> application server over time) if at least one node was promoted to
>> the old generation for any reason. They survive minor collections and
>> are cleaned up only on mixed / full collections, and thus put
>> unnecessary pressure on G1 garbage collector.
>>
>> The same change could also be applied to
>> 'AbstractQueuedLongSynchronizer'.
>>
>> I know premature optimization is the root of all evil, on the other
>> hand I could image that many applications benefit from GC-friendly
>> ConditionObjects, since they are frequently used in various classes
>> like PriorityBlockingQueue / LinkedBlockingDeque /
>> LinkedBlockingQueue, the latter one as default work queue for
>> executor services like fixed thread pools for processing asynchronous
>> tasks.
>>
>> Thank you all for your time and help!
>>
>> Best regards
>> Frank
>>
>> Am 08.02.2024 um 12:15 schrieb Frank Kretschmer:
>>> Hello Thomas, hello Core-Libs-Dev,
>>>
>>> thank you for cc'ing my email. In deed my idea/suggestion is to modify
>>> the AbstractQueuedSynchronizer$ConditionNode handling in such a way
>>> that
>>> it gets unlinked from the chain of condition nodes if it is not needed
>>> any more (it might be the "nextWaiter" node), in order to be more
>>> GC-friendly.
>>>
>>> @core-libs-dev: I've just attached the ?G1LoiteringConditionNodes? demo
>>> class and "gc.log" again so that you can have a look if you like.
>>>
>>> Best regards
>>>
>>> Frank
>>>
>>>
>>> Am 08.02.2024 um 11:04 schrieb Thomas Schatzl:
>>>> Hi,
>>>>
>>>> ? since this looks like a suggestion for a change to the libraries
>>>> similar to the mentioned JDK-6805775, and not actually GC, cc'ing the
>>>> core-libs-dev mailing list.
>>>>
>>>> Hth,
>>>> ? Thomas
>>>>
>>>> On 07.02.24 15:20, Frank Kretschmer wrote:
>>>>> Hi Java GC-experts,
>>>>>
>>>>> I'm facing an interesting G1 garbage collector observation in OpenJDK
>>>>> 17.0.9+9, which I would like to share with you.
>>>>>
>>>>> My application runs many asynchronous tasks in a fixed thread pool,
>>>>> utilizing its standard LinkedBlockingQueue. Usually, it generates
>>>>> just a
>>>>> little garbage, but from time to time, I observed that the survivor
>>>>> spaces grow unexpectedly, and minor collection times increase.
>>>>>
>>>>> This being the case, many
>>>>> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionNode
>>>>> instances can be found on the heap. In fact, the whole heap (rank
>>>>> 1 as
>>>>> shown in jmap) was filled up with ConditionNode instances after a
>>>>> while.
>>>>>
>>>>> After some tests, I figured out that G1 seems to be able to collect
>>>>> ?dead? ConditionNode instances during minor collections only if no
>>>>> formerly alive ConditionNode instances were promoted to the old
>>>>> generation and died there.
>>>>>
>>>>> To illustrate that, I've attached a ?G1LoiteringConditionNodes? class
>>>>> that can be run for demo purposes, e.g. under Linux with OpenJDK
>>>>> 17.0.9+9 (VM options see comments within the class), and its gc-log
>>>>> output. It shows that during the first two minutes, everything is
>>>>> fine,
>>>>> but after a promotion to the old generation, survivors grow and minor
>>>>> pause time increase from 3 to 10ms.
>>>>>
>>>>> For me, it looks like an issue similar to
>>>>> https://bugs.openjdk.org/browse/JDK-6805775 ?LinkedBlockingQueue
>>>>> Nodes
>>>>> should unlink themselves before becoming garbage?, which was fixed in
>>>>> OpenJDK 7.
>>>>>
>>>>> What?s your opinion about that? Wouldn?t it be worth to enable G1 to
>>>>> collect those AbstractQueuedSynchronizer$ConditionNode instances
>>>>> during
>>>>> minor collections, as it is done for LinkedBlockingQueue Nodes?
>>>>>
>>>>> Best regards
>>>>>
>>>>> Frank
>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From liach at openjdk.org  Sun Feb 18 15:29:06 2024
From: liach at openjdk.org (Chen Liang)
Date: Sun, 18 Feb 2024 15:29:06 GMT
Subject: RFR: 8323707: Adjust Classfile API's type arg model to better
 represent the embodied type [v2]
In-Reply-To: 
References: 
Message-ID: <2QT0Vlh_6-kZ2cUtpf2Ezd2AtVn53SVKoKq1THO72-Y=.736a9f4f-a997-430a-a63c-0851f8d37a84@github.com>

> API changes as discussed on the mailing list: https://mail.openjdk.org/pipermail/classfile-api-dev/2023-November/000419.html
> 
> Additional questions:
> 1. Whether to rename `WildcardIndicator.DEFAULT` to `NONE`

Chen Liang 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 fix/typearg-model
 - redundant line
 - Fix a test in langtools, copyright year
 - Merge branch 'master' of https://github.com/openjdk/jdk into fix/typearg-model
 - Implementation cleanup, test update
 - Merge branch 'master' into fix/typearg-model
 - Formatting
 - Nuke signatureString and fix test fialure from bad cast
 - Adjust the type arg model to better represent the embodied type

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

Changes: https://git.openjdk.org/jdk/pull/16517/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16517&range=01
  Stats: 129 lines in 6 files changed: 46 ins; 32 del; 51 mod
  Patch: https://git.openjdk.org/jdk/pull/16517.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16517/head:pull/16517

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

From liach at openjdk.org  Sun Feb 18 16:52:15 2024
From: liach at openjdk.org (Chen Liang)
Date: Sun, 18 Feb 2024 16:52:15 GMT
Subject: RFR: 8180892: Correct handling of annotations on parameters [v3]
In-Reply-To: 
References: 
Message-ID: 

> This patch aims to correct handling of annotations on parameters with the help of `MethodParameters` attribute, which will be always available once #9862 is integrated.
> 
> It utilizes and expands upon the existing parameter matching logic present in `Executable::getAllGenericParameterTypes`, and delegate parameter parameterized types, parameter annotation, and parameter type annotation accesses through the matched results, if matching is available. If matching failed, it falls back to existing heuristics that works without `MethodParameters` attributes for annotations, in `Executable::handleParameterNumberMismatch` and `TypeAnnotationParser::buildAnnotatedTypes` (renamed `buildAnnotatedTypesWithHeuristics` in this patch)
> 
> `ParameterMappingTest` covers these scenarios with class files that have `MethodParameters` or `Signature` attributes stripped or preserved to ensure the new Reflection API implementation works for both class files generated before #9862 and after its integration.
> 
> Also special thanks to Joe Darcy for reviewing 8304918 (#13183); this brings much convenience to this patch.

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

 - Update copyright year, cleanup and fix volatile, fix test
 - Merge branch 'master' into param-implicit-mapping
 - Merge branch 'master' into param-implicit-mapping
 - Fix assuming match without MethodParameters for type annotations, move implementation related to getAnnotatedParameterTypes to around it
 - copyright years
 - Complete ParameterMappingTest to take care of interested scenarios
 - Merge branch 'master' into param-implicit-mapping
 - test wip
 - Introduce base for annotated types if signature is absent but method parameters is present
 - simplify code with further contracts
 - ... and 1 more: https://git.openjdk.org/jdk/compare/c2d9fa26...611deabe

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

Changes: https://git.openjdk.org/jdk/pull/13664/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13664&range=02
  Stats: 628 lines in 7 files changed: 541 ins; 54 del; 33 mod
  Patch: https://git.openjdk.org/jdk/pull/13664.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13664/head:pull/13664

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

From liach at openjdk.org  Sun Feb 18 16:52:15 2024
From: liach at openjdk.org (Chen Liang)
Date: Sun, 18 Feb 2024 16:52:15 GMT
Subject: RFR: 8180892: Correct handling of annotations on parameters [v2]
In-Reply-To: 
References: 
 
Message-ID: <_yH_I4AuCYvlWRxu_o9G3ICnuCPD3GAO9yNScTAxNyk=.7b85a245-efa7-4b5e-9ba8-b6cd9a58a68a@github.com>

On Wed, 26 Apr 2023 14:46:53 GMT, Chen Liang  wrote:

>> This patch aims to correct handling of annotations on parameters with the help of `MethodParameters` attribute, which will be always available once #9862 is integrated.
>> 
>> It utilizes and expands upon the existing parameter matching logic present in `Executable::getAllGenericParameterTypes`, and delegate parameter parameterized types, parameter annotation, and parameter type annotation accesses through the matched results, if matching is available. If matching failed, it falls back to existing heuristics that works without `MethodParameters` attributes for annotations, in `Executable::handleParameterNumberMismatch` and `TypeAnnotationParser::buildAnnotatedTypes` (renamed `buildAnnotatedTypesWithHeuristics` in this patch)
>> 
>> `ParameterMappingTest` covers these scenarios with class files that have `MethodParameters` or `Signature` attributes stripped or preserved to ensure the new Reflection API implementation works for both class files generated before #9862 and after its integration.
>> 
>> Also special thanks to Joe Darcy for reviewing 8304918 (#13183); this brings much convenience to this patch.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix assuming match without MethodParameters for type annotations, move implementation related to getAnnotatedParameterTypes to around it

This patch has been updated to the latest Class-File API. May I request a review again?

Removed unused parameter.

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

PR Comment: https://git.openjdk.org/jdk/pull/13664#issuecomment-1951382844
PR Review Comment: https://git.openjdk.org/jdk/pull/13664#discussion_r1493804544

From attila at openjdk.org  Sun Feb 18 19:04:22 2024
From: attila at openjdk.org (Attila Szegedi)
Date: Sun, 18 Feb 2024 19:04:22 GMT
Subject: RFR: 8325679: Optimize ArrayList subList sort [v2]
In-Reply-To: 
References: 
Message-ID: 

> Somewhat surprisingly, `ArrayList$Sublist.sort()` is not specialized and will thus fall back to slower default method of `List.sort()` instead of sorting a range of the array in-place in its backing root `ArrayList`. 
> 
> This doesn't change observable behavior, so haven't added tests, and `tier1` tests still all pass except for `test/jdk/java/util/Locale/LocaleProvidersFormat.java` which also currently fails on master too on the machine I tested on.

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

  Add a test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17818/files
  - new: https://git.openjdk.org/jdk/pull/17818/files/680cb10f..33770e1e

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

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

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

From attila at openjdk.org  Sun Feb 18 23:25:55 2024
From: attila at openjdk.org (Attila Szegedi)
Date: Sun, 18 Feb 2024 23:25:55 GMT
Subject: RFR: 8325679: Optimize ArrayList subList sort
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 14 Feb 2024 23:37:03 GMT, Stuart Marks  wrote:

>> Somewhat surprisingly, `ArrayList$Sublist.sort()` is not specialized and will thus fall back to slower default method of `List.sort()` instead of sorting a range of the array in-place in its backing root `ArrayList`. 
>> 
>> This doesn't change observable behavior, so haven't added tests, and `tier1` tests still all pass except for `test/jdk/java/util/Locale/LocaleProvidersFormat.java` which also currently fails on master too on the machine I tested on.
>
> (Discussion mainly of historical interest.)
> 
> @pavelrappo Correct, historically, `Collections.sort` would fail to sort `CopyOnWriteArrayList`. You have to go back to JDK 7 to see this. The sorting approach used by `Collections.sort` (still present in the default implementation of `List.sort`) gets an array using `toArray()`, sorts it, and then copies the sorted elements back using `ListIterator.set`. Since `CopyOnWriteArrayList` doesn't support modifications using `ListIterator`, it fails with `UnsupportedOperationException`. The overrides of `List.sort` have fixed this problem.
> 
> COWAL still has some problems with other things that use similar techniques, such as `Collections.shuffle`. That uses get/set to swap elements, which COWAL does support, but it copies the array on each set() operation. This results in N copies of the array being made for an N-element list.

@stuart-marks > Just to clarify, my comments about "sorting sublists is rare" is a response to "has this been there since day one?" from @JimLaskey, and it's not an argument against adding this.

That's absolutely understood :-) I was just trying to add some color by describing the use case I stumbled upon. 

> There appears to be some coverage of the List.sort() default method in `test/jdk/java/util/List/ListDefault.java'. It does seem to cover sublists. I guess the question is whether this test is focused on the default implementation of List.sort(), or whether it's intended to cover all implementations -- whether the default or overridden -- of the default methods that were added in JDK 8. I think this area is worth a closer look. If the new ArrayList.subList().sort() override is covered already, we might be able to get away without adding a new test. Or possibly some adjustment could be made to this test if necessary.

I confirmed that the code in [ListDefaults.java:403](https://github.com/openjdk/jdk/blob/master/test/jdk/java/util/List/ListDefaults.java#L403) exercises `ArrayList$SubList.sort()`. In the meantime, I also added a more exhaustive stochastic test, although it might be an overkill. I'm inclined to remove it.

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

PR Comment: https://git.openjdk.org/jdk/pull/17818#issuecomment-1951481144

From varadam at openjdk.org  Mon Feb 19 05:57:01 2024
From: varadam at openjdk.org (Varada M)
Date: Mon, 19 Feb 2024 05:57:01 GMT
Subject: RFR: JDK-8252802: java launcher should set MALLOCOPTIONS and LDR_CNTRL
 in order to use 64KB pages on AIX
Message-ID: 

DeCapo Benchmark Results (3 runs) :  

Before : 
===== DaCapo 9.12 h2 PASSED in 281402 msec =====
===== DaCapo 9.12 h2 PASSED in 269818 msec =====
===== DaCapo 9.12 h2 PASSED in 279279 msec =====
 
After:
===== DaCapo 9.12 h2 PASSED in 279192 msec =====
===== DaCapo 9.12 h2 PASSED in 269769 msec =====
===== DaCapo 9.12 h2 PASSED in 271577 msec ===== 

Environmental variables LDR_CNTRL and MALLOCOPTIONS has caused test/jdk/java/lang/ProcessBuilder/Basic.java failure.
Additional environmental variables has to removed from removeAixExpectedVars().

JBS Issue : [JDK-8252802](https://bugs.openjdk.org/browse/JDK-8252802)

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

Commit messages:
 - JDK-8252802: java launcher should set MALLOCOPTIONS and LDR_CNTRL in order to use 64KB pages on AIX

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

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

From jpai at openjdk.org  Mon Feb 19 07:09:56 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 19 Feb 2024 07:09:56 GMT
Subject: RFR: 8326100: DeflaterDictionaryTests should use
 Deflater.getBytesWritten instead of Deflater.getTotalOut [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Sun, 18 Feb 2024 10:56:03 GMT, Eirik Bj?rsn?s  wrote:

>> Please review this test-only cleanup PR in preparation for deprecating `Deflater.getTotalOut()` in JDK-8326096.
>> 
>> This PR replaces various calls in`test/jdk/java/util/zip/DeflaterDictionaryTests.java` to `Deflater.getTotalOut()` with calls to `Deflater.getBytesWritten()` when formatting some debugging output lines. 
>> 
>> Additionally, various debug output lines claim to print the result of calling `Deflater.getAdler`, but instead prints the output of `Deflater.getTotalOut'. This PR fixes this to print the actual Adler value instead.
>> 
>> Testing and verification: This is a test-only fix affecting only debug output. I have added the `noreg-self` label to the issue.
>
> Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use more specific format specifier %d instead of %s

The changes look good to me.

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17901#pullrequestreview-1887689931

From jpai at openjdk.org  Mon Feb 19 07:21:54 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 19 Feb 2024 07:21:54 GMT
Subject: RFR: 8326099: GZIPOutputStream should use Deflater.getBytesRead()
 instead of Deflater.getTotalIn()
In-Reply-To: <9TQrYJq04NGGELIp4gx5GP9aVRX5X0Zm-PX-N9czKq4=.72582b38-6636-4d32-a536-a9cbc0d7e1e7@github.com>
References: <9TQrYJq04NGGELIp4gx5GP9aVRX5X0Zm-PX-N9czKq4=.72582b38-6636-4d32-a536-a9cbc0d7e1e7@github.com>
Message-ID: 

On Sat, 17 Feb 2024 12:08:38 GMT, Eirik Bj?rsn?s  wrote:

> Please review this cleanup PR in preparation for deprecating `Deflater.getTotalIn()` in JDK-8326096. 
> 
> This PR replaces `GZIPOutputStream.writeTrailer`'s call to `Deflater.getTotalIn()` with a call to `Deflater.getBytesRead()` followed by an explicit conversion to "modulo 2^32" (a cast to int) as described in RFC 1952:
> 
> 
>  ISIZE (Input SIZE)
>   This contains the size of the original (uncompressed) input
>   data modulo 2^32.
> 
> 
> Testing and verification: This should be trivially verifiable by code inspection. Nevertheless, I wrote a test which writes Integer.MAX_VALUE +1 bytes of uncompressed data and verified that the last four bytes written to the file was indeed as expected. (This test is not included in this PR because of its runtime and resource requirements).

Hello Eirik, the change looks OK to me. 

For context, the `getTotalIn()` and `getTotalOut()` methods are being proposed for deprecation https://mail.openjdk.org/pipermail/core-libs-dev/2024-February/119321.html. `getTotalIn()` was doing the same `(int) getBytesRead()` internally, so this change should be OK.

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17900#pullrequestreview-1887705275

From jpai at openjdk.org  Mon Feb 19 07:34:56 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 19 Feb 2024 07:34:56 GMT
Subject: RFR: 8318812: LauncherHelper.checkAndLoadMain closes jar file
 that's about to be re-opened [v2]
In-Reply-To: <5p6LlYPi8V2bxmBvggJJqfrEeOEr9r-foY9yZOQMFbg=.616900a0-6652-4fde-aa74-1e9745d0fe07@github.com>
References: 
 <5p6LlYPi8V2bxmBvggJJqfrEeOEr9r-foY9yZOQMFbg=.616900a0-6652-4fde-aa74-1e9745d0fe07@github.com>
Message-ID: 

On Thu, 15 Feb 2024 06:29:24 GMT, Christian Stein  wrote:

>> Please review this PR that makes the launcher helper keep a reference to the executable JAR file active after extracting the name of the main class and returning it as Class instance. Now, when loading classes from the JAR file, it hasn't to be re-opened.
>
> Christian Stein has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove `String jarname` from `getMainClassFromJar`'s signature
>  - Introduce and use dedicated on-close error message

Hello Christian, the changes look OK to me. Both the files will need a copyright year update. The JBS issue would need an appropriate noreg label too https://openjdk.org/guide/#noreg

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17843#pullrequestreview-1887725461

From alanb at openjdk.org  Mon Feb 19 07:38:57 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 19 Feb 2024 07:38:57 GMT
Subject: RFR: JDK-8252802: java launcher should set MALLOCOPTIONS and
 LDR_CNTRL in order to use 64KB pages on AIX
In-Reply-To: 
References: 
Message-ID: <5xX3JTuTBB2nGJNOcm7OSziyaX5aUY56xpMda5p1hdg=.9005be28-c0d6-48ec-a912-2fbef4c68afd@github.com>

On Mon, 19 Feb 2024 05:52:22 GMT, Varada M  wrote:

> DeCapo Benchmark Results (3 runs) :  
> 
> Before : 
> ===== DaCapo 9.12 h2 PASSED in 281402 msec =====
> ===== DaCapo 9.12 h2 PASSED in 269818 msec =====
> ===== DaCapo 9.12 h2 PASSED in 279279 msec =====
>  
> After:
> ===== DaCapo 9.12 h2 PASSED in 279192 msec =====
> ===== DaCapo 9.12 h2 PASSED in 269769 msec =====
> ===== DaCapo 9.12 h2 PASSED in 271577 msec ===== 
> 
> Environmental variables LDR_CNTRL and MALLOCOPTIONS has caused test/jdk/java/lang/ProcessBuilder/Basic.java failure.
> Additional environmental variables has to removed from removeAixExpectedVars().
> 
> JBS Issue : [JDK-8252802](https://bugs.openjdk.org/browse/JDK-8252802)

Question: Is the java launcher the right place for this? I'm wondering about other launcher that uses JNI Invocation API to create the VM.

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

PR Comment: https://git.openjdk.org/jdk/pull/17906#issuecomment-1951860259

From jpai at openjdk.org  Mon Feb 19 07:40:57 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 19 Feb 2024 07:40:57 GMT
Subject: RFR: 8294977: Convert test/jdk/java tests from ASM library to
 Classfile API [v11]
In-Reply-To: 
References: 
 
Message-ID: 

On Sun, 17 Dec 2023 23:11:10 GMT, Chen Liang  wrote:

>> Summaries:
>> 1. A few recommendations about updating the constant API is made at https://mail.openjdk.org/pipermail/classfile-api-dev/2023-March/000233.html and I may update this patch shall the API changes be integrated before
>> 2. One ASM library-specific test, `LambdaAsm` is removed. Others have their code generation infrastructure upgraded from ASM to Classfile API.
>> 3. Most tests are included in tier1, but some are not:
>> In `:jdk_io`: (tier2, part 2)
>> 
>> test/jdk/java/io/Serializable/records/SerialPersistentFieldsTest.java
>> test/jdk/java/io/Serializable/records/ProhibitedMethods.java
>> test/jdk/java/io/Serializable/records/BadCanonicalCtrTest.java
>> 
>> In `:jdk_instrument`: (tier 3)
>> 
>> test/jdk/java/lang/instrument/RetransformAgent.java
>> test/jdk/java/lang/instrument/NativeMethodPrefixAgent.java
>> test/jdk/java/lang/instrument/asmlib/Instrumentor.java
>> 
>> 
>> @asotona Would you mind reviewing?
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix the 2 failing tests and add notes

I see that this PR was approved a month back and there haven't been any changes to the PR since this (which is a good thing). I'll run this against our internal CI to make sure this still works as expected and will sponsor this later today, if that run goes fine.

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

PR Comment: https://git.openjdk.org/jdk/pull/13009#issuecomment-1951862915

From dholmes at openjdk.org  Mon Feb 19 07:56:01 2024
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 19 Feb 2024 07:56:01 GMT
Subject: RFR: 8326126: Update the java manpage with the changes from
 JDK-8322478
Message-ID: 

Please reviews these manpage updates in relation to "JEP 458: Launch Multi-File Source-Code Programs".  The manpage sources had previously been updated internally at Oracle under JDK-8322478, but the open troff file was not regenerated at the time in mainline (it was for JDK 22).

The main gist of the change is that with multi-file support now available,  occurrences of "single source-file" should just refer to "source-file".

Thanks

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

Commit messages:
 - 8326126: Update the java manpage with the changes from JDK-8322478

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

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

From alanb at openjdk.org  Mon Feb 19 08:02:55 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 19 Feb 2024 08:02:55 GMT
Subject: RFR: 8326100: DeflaterDictionaryTests should use
 Deflater.getBytesWritten instead of Deflater.getTotalOut [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Sun, 18 Feb 2024 10:56:03 GMT, Eirik Bj?rsn?s  wrote:

>> Please review this test-only cleanup PR in preparation for deprecating `Deflater.getTotalOut()` in JDK-8326096.
>> 
>> This PR replaces various calls in`test/jdk/java/util/zip/DeflaterDictionaryTests.java` to `Deflater.getTotalOut()` with calls to `Deflater.getBytesWritten()` when formatting some debugging output lines. 
>> 
>> Additionally, various debug output lines claim to print the result of calling `Deflater.getAdler`, but instead prints the output of `Deflater.getTotalOut'. This PR fixes this to print the actual Adler value instead.
>> 
>> Testing and verification: This is a test-only fix affecting only debug output. I have added the `noreg-self` label to the issue.
>
> Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use more specific format specifier %d instead of %s

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17901#pullrequestreview-1887769471

From alanb at openjdk.org  Mon Feb 19 08:02:56 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 19 Feb 2024 08:02:56 GMT
Subject: RFR: 8326100: DeflaterDictionaryTests should use
 Deflater.getBytesWritten instead of Deflater.getTotalOut [v2]
In-Reply-To: 
References: 
 
 
Message-ID: <8IIvx_QvfIJ62edheWIDGBUgiPBuCYMvTz9NYc6YWQ0=.fec46a52-a44c-4221-82cd-c4e47796253c@github.com>

On Sun, 18 Feb 2024 10:56:47 GMT, Eirik Bj?rsn?s  wrote:

> Thanks for your review Alan!
> 
> > The hazard when the format specifiers are all %s.
> 
> Not sure I understand your comment since all arguments are of the same type (int) anyhow, I guess they would still be easy to get wrong or in the wrong order. Was that the hazard you refer to?

Yes, it's easy to get a silent mismatch. In this case, the first message printed by testByteArray, the second parameter should have been the Adler but it was actually printing the number of bytes written. You've fixed it, and switched to %d, so all good.

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

PR Comment: https://git.openjdk.org/jdk/pull/17901#issuecomment-1951892484

From alanb at openjdk.org  Mon Feb 19 08:04:53 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 19 Feb 2024 08:04:53 GMT
Subject: RFR: 8326126: Update the java manpage with the changes from
 JDK-8322478
In-Reply-To: 
References: 
Message-ID: 

On Mon, 19 Feb 2024 07:04:07 GMT, David Holmes  wrote:

> Please reviews these manpage updates in relation to "JEP 458: Launch Multi-File Source-Code Programs".  The manpage sources had previously been updated internally at Oracle under JDK-8322478, but the open troff file was not regenerated at the time in mainline (it was for JDK 22).
> 
> The main gist of the change is that with multi-file support now available,  occurrences of "single source-file" should just refer to "source-file".
> 
> Thanks

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17908#pullrequestreview-1887772261

From pminborg at openjdk.org  Mon Feb 19 08:24:03 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 19 Feb 2024 08:24:03 GMT
Subject: RFR: 8326112: Javadoc snippet for Linker.Option.captureCallState is
 wrong
Message-ID: 

This PR proposes to add an offset parameter for a `VarHandle` invocation in the Javadoc snippet for `Linker.Option.captureCallState()`. The offset parameter was added in 22 but it was forgotten to add it in said Javadoc.

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

Commit messages:
 - Add offset parameter to VarHandle invocation

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

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

From mbaesken at openjdk.org  Mon Feb 19 08:31:54 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 19 Feb 2024 08:31:54 GMT
Subject: RFR: JDK-8324930: java/lang/StringBuilder problem with concurrent
 jtreg runs
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Wed, 31 Jan 2024 08:13:25 GMT, Matthias Baesken  wrote:

> Can we maybe see if we can fix these tests without exclusive-accessing them? I find it surprising that `java/lang/StringBuilder` tests are problematic, but `java/lang/StringBuffer` tests are not. Which tests fail?

What do you think about  marking jtreg tests with higher memory requirements with a jtreg key like highmemusage  ? This way we do not need to put these tests into the _exclusiveAccess.dirs_  group, but get a way (only if needed) to execute those with high memory usage separately e.g. with lower concurrency.

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

PR Comment: https://git.openjdk.org/jdk/pull/17625#issuecomment-1951934706

From eirbjo at openjdk.org  Mon Feb 19 09:18:00 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Mon, 19 Feb 2024 09:18:00 GMT
Subject: Integrated: 8326100: DeflaterDictionaryTests should use
 Deflater.getBytesWritten instead of Deflater.getTotalOut
In-Reply-To: 
References: 
Message-ID: 

On Sat, 17 Feb 2024 13:00:08 GMT, Eirik Bj?rsn?s  wrote:

> Please review this test-only cleanup PR in preparation for deprecating `Deflater.getTotalOut()` in JDK-8326096.
> 
> This PR replaces various calls in`test/jdk/java/util/zip/DeflaterDictionaryTests.java` to `Deflater.getTotalOut()` with calls to `Deflater.getBytesWritten()` when formatting some debugging output lines. 
> 
> Additionally, various debug output lines claim to print the result of calling `Deflater.getAdler`, but instead prints the output of `Deflater.getTotalOut'. This PR fixes this to print the actual Adler value instead.
> 
> Testing and verification: This is a test-only fix affecting only debug output. I have added the `noreg-self` label to the issue.

This pull request has now been integrated.

Changeset: 9451677d
Author:    Eirik Bj?rsn?s 
URL:       https://git.openjdk.org/jdk/commit/9451677daaf1184f67759c87114af3f81fa74f23
Stats:     13 lines in 1 file changed: 0 ins; 0 del; 13 mod

8326100: DeflaterDictionaryTests should use Deflater.getBytesWritten instead of Deflater.getTotalOut

Reviewed-by: alanb, jpai

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

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

From jpai at openjdk.org  Mon Feb 19 09:39:08 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 19 Feb 2024 09:39:08 GMT
Subject: RFR: 8326152: Bad copyright header in
 test/jdk/java/util/zip/DeflaterDictionaryTests.java
Message-ID: 

Can I get a review of this change which fixes the copyright header on `DeflaterDictionaryTests.java`?

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

Commit messages:
 - 8326152: Bad copyright header in test/jdk/java/util/zip/DeflaterDictionaryTests.java

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

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

From eirbjo at openjdk.org  Mon Feb 19 09:48:53 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Mon, 19 Feb 2024 09:48:53 GMT
Subject: RFR: 8326099: GZIPOutputStream should use Deflater.getBytesRead()
 instead of Deflater.getTotalIn()
In-Reply-To: 
References: <9TQrYJq04NGGELIp4gx5GP9aVRX5X0Zm-PX-N9czKq4=.72582b38-6636-4d32-a536-a9cbc0d7e1e7@github.com>
 
Message-ID: 

On Mon, 19 Feb 2024 07:18:53 GMT, Jaikiran Pai  wrote:

> Hello Eirik, the change looks OK to me.

Thanks for veryfying and adding helpful context!

I'll let this linger just a bit before integrating in case there is any non-correctness feedback, like about the added comment to clarify the modulo 2^32 aspect.

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

PR Comment: https://git.openjdk.org/jdk/pull/17900#issuecomment-1952069324

From attila at openjdk.org  Mon Feb 19 09:58:13 2024
From: attila at openjdk.org (Attila Szegedi)
Date: Mon, 19 Feb 2024 09:58:13 GMT
Subject: RFR: 8325679: Optimize ArrayList subList sort [v3]
In-Reply-To: 
References: 
Message-ID: 

> Somewhat surprisingly, `ArrayList$Sublist.sort()` is not specialized and will thus fall back to slower default method of `List.sort()` instead of sorting a range of the array in-place in its backing root `ArrayList`. 
> 
> This doesn't change observable behavior, so haven't added tests, and `tier1` tests still all pass except for `test/jdk/java/util/Locale/LocaleProvidersFormat.java` which also currently fails on master too on the machine I tested on.

Attila Szegedi 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:

  Add a test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17818/files
  - new: https://git.openjdk.org/jdk/pull/17818/files/33770e1e..5bfe2d12

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

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

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

From eirbjo at openjdk.org  Mon Feb 19 09:59:59 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Mon, 19 Feb 2024 09:59:59 GMT
Subject: RFR: 8326152: Bad copyright header in
 test/jdk/java/util/zip/DeflaterDictionaryTests.java
In-Reply-To: 
References: 
Message-ID: 

On Mon, 19 Feb 2024 09:34:12 GMT, Jaikiran Pai  wrote:

> Can I get a review of this change which fixes the copyright header on `DeflaterDictionaryTests.java`?

Thanks for spotting this, looks good to me! Would be nice if jcheck could check simple formatting issues like this.

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

PR Review: https://git.openjdk.org/jdk/pull/17911#pullrequestreview-1888004151

From tschatzl at openjdk.org  Mon Feb 19 09:59:59 2024
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 19 Feb 2024 09:59:59 GMT
Subject: RFR: 8326152: Bad copyright header in
 test/jdk/java/util/zip/DeflaterDictionaryTests.java
In-Reply-To: 
References: 
Message-ID: 

On Mon, 19 Feb 2024 09:34:12 GMT, Jaikiran Pai  wrote:

> Can I get a review of this change which fixes the copyright header on `DeflaterDictionaryTests.java`?

Ship it.

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

Marked as reviewed by tschatzl (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17911#pullrequestreview-1888008996

From jpai at openjdk.org  Mon Feb 19 09:59:59 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 19 Feb 2024 09:59:59 GMT
Subject: RFR: 8326152: Bad copyright header in
 test/jdk/java/util/zip/DeflaterDictionaryTests.java
In-Reply-To: 
References: 
Message-ID: 

On Mon, 19 Feb 2024 09:34:12 GMT, Jaikiran Pai  wrote:

> Can I get a review of this change which fixes the copyright header on `DeflaterDictionaryTests.java`?

Thank you Eirik and Thomas for the reviews.

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

PR Comment: https://git.openjdk.org/jdk/pull/17911#issuecomment-1952086875

From jpai at openjdk.org  Mon Feb 19 10:00:00 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 19 Feb 2024 10:00:00 GMT
Subject: Integrated: 8326152: Bad copyright header in
 test/jdk/java/util/zip/DeflaterDictionaryTests.java
In-Reply-To: 
References: 
Message-ID: <3VSKcNxEH1ABhDF3ID-6rEgBxpZMyZNiSjQRg4fcUOA=.eb5a1ea3-0215-4c6d-8ac8-f203be0ec02e@github.com>

On Mon, 19 Feb 2024 09:34:12 GMT, Jaikiran Pai  wrote:

> Can I get a review of this change which fixes the copyright header on `DeflaterDictionaryTests.java`?

This pull request has now been integrated.

Changeset: b3664927
Author:    Jaikiran Pai 
URL:       https://git.openjdk.org/jdk/commit/b3664927616d898ce099808b34e91cc226c8f8ad
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8326152: Bad copyright header in test/jdk/java/util/zip/DeflaterDictionaryTests.java

Reviewed-by: tschatzl

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

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

From attila at openjdk.org  Mon Feb 19 10:05:24 2024
From: attila at openjdk.org (Attila Szegedi)
Date: Mon, 19 Feb 2024 10:05:24 GMT
Subject: RFR: 8325679: Optimize ArrayList subList sort [v4]
In-Reply-To: 
References: 
Message-ID: 

> Somewhat surprisingly, `ArrayList$Sublist.sort()` is not specialized and will thus fall back to slower default method of `List.sort()` instead of sorting a range of the array in-place in its backing root `ArrayList`. 
> 
> This doesn't change observable behavior, so haven't added tests, and `tier1` tests still all pass except for `test/jdk/java/util/Locale/LocaleProvidersFormat.java` which also currently fails on master too on the machine I tested on.

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

  Remove test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17818/files
  - new: https://git.openjdk.org/jdk/pull/17818/files/5bfe2d12..a5537664

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

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

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

From cstein at openjdk.org  Mon Feb 19 10:11:55 2024
From: cstein at openjdk.org (Christian Stein)
Date: Mon, 19 Feb 2024 10:11:55 GMT
Subject: RFR: 8326126: Update the java manpage with the changes from
 JDK-8322478
In-Reply-To: 
References: 
Message-ID: 

On Mon, 19 Feb 2024 07:04:07 GMT, David Holmes  wrote:

> Please reviews these manpage updates in relation to "JEP 458: Launch Multi-File Source-Code Programs".  The manpage sources had previously been updated internally at Oracle under JDK-8322478, but the open troff file was not regenerated at the time in mainline (it was for JDK 22).
> 
> The main gist of the change is that with multi-file support now available,  occurrences of "single source-file" should just refer to "source-file".
> 
> Thanks

Marked as reviewed by cstein (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/17908#pullrequestreview-1888038946

From coffeys at openjdk.org  Mon Feb 19 10:32:54 2024
From: coffeys at openjdk.org (Sean Coffey)
Date: Mon, 19 Feb 2024 10:32:54 GMT
Subject: RFR: 8318812: LauncherHelper.checkAndLoadMain closes jar file
 that's about to be re-opened [v2]
In-Reply-To: <5p6LlYPi8V2bxmBvggJJqfrEeOEr9r-foY9yZOQMFbg=.616900a0-6652-4fde-aa74-1e9745d0fe07@github.com>
References: 
 <5p6LlYPi8V2bxmBvggJJqfrEeOEr9r-foY9yZOQMFbg=.616900a0-6652-4fde-aa74-1e9745d0fe07@github.com>
Message-ID: 

On Thu, 15 Feb 2024 06:29:24 GMT, Christian Stein  wrote:

>> Please review this PR that makes the launcher helper keep a reference to the executable JAR file active after extracting the name of the main class and returning it as Class instance. Now, when loading classes from the JAR file, it hasn't to be re-opened.
>
> Christian Stein has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove `String jarname` from `getMainClassFromJar`'s signature
>  - Introduce and use dedicated on-close error message

src/java.base/share/classes/sun/launcher/LauncherHelper.java line 821:

> 819:         // In LM_JAR mode, put the underlying file in the JarFile/ZipFile cache.
> 820:         // This will avoid needing to re-parse the manifest when the JAR file
> 821:         // is opened on the class path, triggered by Class.forName below.

Nice improvement to have. would it be ok to pad out this comment a bit more ? I found it difficult to understand the specifics. Perhaps :


		// In LM_JAR mode, keep the underlying file open to retain it in 
		// the ZipFile HashMap cache. This will avoid needing to re-parse
                // the central directory when the file is opened on the class path,
		// triggered by Class.forName below.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17843#discussion_r1494339239

From alanb at openjdk.org  Mon Feb 19 10:46:00 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 19 Feb 2024 10:46:00 GMT
Subject: RFR: 8318812: LauncherHelper.checkAndLoadMain closes jar file
 that's about to be re-opened [v2]
In-Reply-To: 
References: 
 <5p6LlYPi8V2bxmBvggJJqfrEeOEr9r-foY9yZOQMFbg=.616900a0-6652-4fde-aa74-1e9745d0fe07@github.com>
 
Message-ID: 

On Mon, 19 Feb 2024 10:30:24 GMT, Sean Coffey  wrote:

> Nice improvement to have. would it be ok to pad out this comment a bit more ? I found it difficult to understand the specifics. Perhaps :
> 
> ```
> 		// In LM_JAR mode, keep the underlying file open to retain it in 
> 		// the ZipFile HashMap cache. This will avoid needing to re-parse
>                 // the central directory when the file is opened on the class path,
> 		// triggered by Class.forName below.
> ```

No issue with expanding the comment but I think leave it as "ZipFile cache" as a more specific comment will quickly bit rot and confuse reader, and of course the Launcher code doesn't care which collection is used internally in the ZipFile code.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17843#discussion_r1494352861

From viktor.klang at oracle.com  Mon Feb 19 11:41:23 2024
From: viktor.klang at oracle.com (Viktor Klang)
Date: Mon, 19 Feb 2024 11:41:23 +0000
Subject: [External] : Re: OpenJDK 17: Loitering
 AbstractQueuedSynchronizer$ConditionNode instances (also on latest master
 branch) [JDK-8325754]
In-Reply-To: <127f2696-5f6d-4bab-b45e-e7597f267add@gmx.net>
References: <591b0e9c-1d7a-405d-ace1-bd94f8dbbe22@gmx.net>
 
 
 <64bc8cbd-78f4-44f4-90ae-80466c563281@gmx.net>
 <6d3b62cb-15f4-471c-97b6-b72977223f91@gmx.net>
 <59c3b1bc-fd60-4215-b8f7-96421f1881e2@gmail.com>
 <127f2696-5f6d-4bab-b45e-e7597f267add@gmx.net>
Message-ID: 

Hi Frank,

We'll see what the option are. ?

Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: Frank Kretschmer 
Sent: Sunday, 18 February 2024 15:36
To: Jaikiran Pai ; Viktor Klang ; Java Core Libs 
Subject: [External] : Re: OpenJDK 17: Loitering AbstractQueuedSynchronizer$ConditionNode instances (also on latest master branch) [JDK-8325754]


Hello Jaikiran, hello Viktor,

in the meantime, I've seen that the JBS issue has been assigned to Viktor Klang. @Viktor: I totally agree with your comment that the proposed solution may not be the best possible option, and that further explorations were required.

My intention to propose unlinking ConditionNodes by null'ing their ?nextWaiter? reference was just to verify that the chain of ?nextWaiter? references leads to the observed garbage collection behavior, and that the GC is able to collect the nodes during minor / young collections if the references are cleaned in time.

I checked also a few other variants (null'ing the ?nextWaiter? reference at the end of all await...() methods in ConditionObject, or in/just before enqueue()), but at the end of the day, I felt that null'ing it in doSignal() explains what I want to show the easiest. On the other hand, the other options could be better in order to avoid race conditions with canceled nodes.

For sure there are many other options that I am not aware of, so please take my proposal just as an example.

Looking forward to your explorations.

Best regards

Frank


Am 14.02.2024 um 07:43 schrieb Jaikiran Pai:

Hello Frank,

I see that a JBS issue has been created for this same issue https://bugs.openjdk.org/browse/JDK-8325754.

I don't have enough knowledge of this area and haven't reviewed this part of the code in detail to see if there are any obvious issues with what you are proposing as a solution. Since there's now a JBS issue created for this and you seem to have done enough investigation and work on this one already, would you be interested in creating a pull request against the https://github.com/openjdk/jdk repo with this proposed change? (you'll have to sign a OCA). This guide https://openjdk.org/guide/ should help you get started. It can then go through the usual reviews that a bug fix/enhancement goes through.

-Jaikiran

On 11/02/24 7:27 pm, Frank Kretschmer wrote:

Hello Core-Libs-Dev team,

may I ask you about your opinion about a tiny one-liner change in AbstractQueuedSynchronizer, just as a suggestion how to make ConditionObjects / Nodes even more garbage collector friendly?

Checked out https://github.com/openjdk/jdk/blob/jdk-17%2B35/src/java.base/share/classes/java/util/concurrent/locks/AbstractQueuedSynchronizer.java (the same on master branch with different line numbers near to line 1506):

@@ -1431,40 +1431,41 @@ public abstract class AbstractQueuedSynchronizer
     public class ConditionObject implements Condition, java.io.Serializable {
         // ...
         private void doSignal(ConditionNode first, boolean all) {
             while (first != null) {
                 ConditionNode next = first.nextWaiter;
+                first.nextWaiter = null;  // GC-friendly: avoid chains of dead ConditionNodes
                 if ((firstWaiter = next) == null)
                     lastWaiter = null;
                 if ((first.getAndUnsetStatus(COND) & COND) != 0) {
                     enqueue(first);
                 // ...

By setting the nextWaiter to null of the first condition node, which is transferred from the condition queue to the sync queue in this method, long chains of ConditionNode instances can be avoided. Though a single ConditionNode is small, these chains of ConditionNodes become very huge on the heap (I've seen more than 1GB on an application server over time) if at least one node was promoted to the old generation for any reason. They survive minor collections and are cleaned up only on mixed / full collections, and thus put unnecessary pressure on G1 garbage collector.

The same change could also be applied to 'AbstractQueuedLongSynchronizer'.

I know premature optimization is the root of all evil, on the other hand I could image that many applications benefit from GC-friendly ConditionObjects, since they are frequently used in various classes like PriorityBlockingQueue / LinkedBlockingDeque / LinkedBlockingQueue, the latter one as default work queue for executor services like fixed thread pools for processing asynchronous tasks.

Thank you all for your time and help!

Best regards
Frank

Am 08.02.2024 um 12:15 schrieb Frank Kretschmer:
Hello Thomas, hello Core-Libs-Dev,

thank you for cc'ing my email. In deed my idea/suggestion is to modify
the AbstractQueuedSynchronizer$ConditionNode handling in such a way that
it gets unlinked from the chain of condition nodes if it is not needed
any more (it might be the "nextWaiter" node), in order to be more
GC-friendly.

@core-libs-dev: I've just attached the ?G1LoiteringConditionNodes? demo
class and "gc.log" again so that you can have a look if you like.

Best regards

Frank


Am 08.02.2024 um 11:04 schrieb Thomas Schatzl:
Hi,

  since this looks like a suggestion for a change to the libraries
similar to the mentioned JDK-6805775, and not actually GC, cc'ing the
core-libs-dev mailing list.

Hth,
  Thomas

On 07.02.24 15:20, Frank Kretschmer wrote:
Hi Java GC-experts,

I'm facing an interesting G1 garbage collector observation in OpenJDK
17.0.9+9, which I would like to share with you.

My application runs many asynchronous tasks in a fixed thread pool,
utilizing its standard LinkedBlockingQueue. Usually, it generates just a
little garbage, but from time to time, I observed that the survivor
spaces grow unexpectedly, and minor collection times increase.

This being the case, many
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionNode
instances can be found on the heap. In fact, the whole heap (rank 1 as
shown in jmap) was filled up with ConditionNode instances after a while.

After some tests, I figured out that G1 seems to be able to collect
?dead? ConditionNode instances during minor collections only if no
formerly alive ConditionNode instances were promoted to the old
generation and died there.

To illustrate that, I've attached a ?G1LoiteringConditionNodes? class
that can be run for demo purposes, e.g. under Linux with OpenJDK
17.0.9+9 (VM options see comments within the class), and its gc-log
output. It shows that during the first two minutes, everything is fine,
but after a promotion to the old generation, survivors grow and minor
pause time increase from 3 to 10ms.

For me, it looks like an issue similar to
https://bugs.openjdk.org/browse/JDK-6805775 ?LinkedBlockingQueue Nodes
should unlink themselves before becoming garbage?, which was fixed in
OpenJDK 7.

What?s your opinion about that? Wouldn?t it be worth to enable G1 to
collect those AbstractQueuedSynchronizer$ConditionNode instances during
minor collections, as it is done for LinkedBlockingQueue Nodes?

Best regards

Frank

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

From goetz at openjdk.org  Mon Feb 19 13:10:58 2024
From: goetz at openjdk.org (Goetz Lindenmaier)
Date: Mon, 19 Feb 2024 13:10:58 GMT
Subject: RFR: 8325579: Inconsistent behavior in
 com.sun.jndi.ldap.Connection::createSocket [v5]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 16 Feb 2024 10:27:11 GMT, Christoph Langer  wrote:

>> During analysing a customer case I figured out that we have an inconsistency between documentation and actual behavior in class com.sun.jndi.ldap.Connection. The [method documentation of com.sun.jndi.ldap.Connection::createSocket](https://github.com/openjdk/jdk/blob/3ebe6c192a5dd5cc46ae2d263713c9ff38cd46bb/src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java#L281) states: "If a timeout is supplied but unconnected sockets are not supported then the timeout is ignored and a connected socket is created."
>> 
>> This, however does not happen. If a SocketFactory would not support unconnected sockets, it would likely throw a SocketException in [SocketFactory::createSocket()](https://github.com/openjdk/jdk/blob/6303c0e7136436a2d3cb6043b88edf788c0067cc/src/java.base/share/classes/javax/net/SocketFactory.java#L123). And since [the code](https://github.com/openjdk/jdk/blob/3ebe6c192a5dd5cc46ae2d263713c9ff38cd46bb/src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java#L336) does not check for this behavior, a connection with timeout value through a SocketFactory that does not support unconnected sockets would simply fail with an IOException.
>> 
>> So we should either make the code adhere to what is documented or adapt the documentation to the actual behavior.
>> 
>> I hereby try to fix the connect coding. Alternatively, we could also adapt the description - I have no strong opinion. What do the experts suggest?
>
> Christoph Langer has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Typo
>  - Merge branch 'master' into JDK-8325579
>  - Rename test and refine comment
>  - Enhance test
>  - JDK-8325579

test/jdk/com/sun/jndi/ldap/LdapSSLHandshakeTest.java line 246:

> 244: 
> 245:         @Override
> 246:         public Socket createSocket(String s, int timeout) throws IOException {

The argument should be "int port" instead of timeout.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17797#discussion_r1494526322

From jvernee at openjdk.org  Mon Feb 19 13:18:54 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 19 Feb 2024 13:18:54 GMT
Subject: RFR: 8326112: Javadoc snippet for Linker.Option.captureCallState
 is wrong
In-Reply-To: 
References: 
Message-ID: <-czSXoXis2Y3B8EV04ccGDtWYmwXWGEKmP9CUP42LAE=.04cf7481-ba16-41b1-b6f0-60804b37c00e@github.com>

On Mon, 19 Feb 2024 08:19:58 GMT, Per Minborg  wrote:

> This PR proposes to add an offset parameter for a `VarHandle` invocation in the Javadoc snippet for `Linker.Option.captureCallState()`. The offset parameter was added in 22 but it was forgotten to add it in said Javadoc.

Marked as reviewed by jvernee (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17909#pullrequestreview-1888395806

From goetz at openjdk.org  Mon Feb 19 13:20:55 2024
From: goetz at openjdk.org (Goetz Lindenmaier)
Date: Mon, 19 Feb 2024 13:20:55 GMT
Subject: RFR: 8325579: Inconsistent behavior in
 com.sun.jndi.ldap.Connection::createSocket [v5]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 16 Feb 2024 10:27:11 GMT, Christoph Langer  wrote:

>> During analysing a customer case I figured out that we have an inconsistency between documentation and actual behavior in class com.sun.jndi.ldap.Connection. The [method documentation of com.sun.jndi.ldap.Connection::createSocket](https://github.com/openjdk/jdk/blob/3ebe6c192a5dd5cc46ae2d263713c9ff38cd46bb/src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java#L281) states: "If a timeout is supplied but unconnected sockets are not supported then the timeout is ignored and a connected socket is created."
>> 
>> This, however does not happen. If a SocketFactory would not support unconnected sockets, it would likely throw a SocketException in [SocketFactory::createSocket()](https://github.com/openjdk/jdk/blob/6303c0e7136436a2d3cb6043b88edf788c0067cc/src/java.base/share/classes/javax/net/SocketFactory.java#L123). And since [the code](https://github.com/openjdk/jdk/blob/3ebe6c192a5dd5cc46ae2d263713c9ff38cd46bb/src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java#L336) does not check for this behavior, a connection with timeout value through a SocketFactory that does not support unconnected sockets would simply fail with an IOException.
>> 
>> So we should either make the code adhere to what is documented or adapt the documentation to the actual behavior.
>> 
>> I hereby try to fix the connect coding. Alternatively, we could also adapt the description - I have no strong opinion. What do the experts suggest?
>
> Christoph Langer has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Typo
>  - Merge branch 'master' into JDK-8325579
>  - Rename test and refine comment
>  - Enhance test
>  - JDK-8325579

test/jdk/com/sun/jndi/ldap/LdapSSLHandshakeTest.java line 224:

> 222: 
> 223:         public CustomSocket(String s, int timeout) throws IOException {
> 224:             super(s, timeout);

The argument should be called "port" not timeout.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17797#discussion_r1494537202

From jpai at openjdk.org  Mon Feb 19 13:34:54 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 19 Feb 2024 13:34:54 GMT
Subject: RFR: JDK-8324930: java/lang/StringBuilder problem with concurrent
 jtreg runs
In-Reply-To: 
References: 
Message-ID: 

On Tue, 30 Jan 2024 09:08:28 GMT, Matthias Baesken  wrote:

> On some Windows machines we see sometimes OOM errors because of high resource (memory/swap) consumption. This is especially seen when the jtreg runs have higher concurrency. A solution is to put the java/lang/StringBuilder tests in the exclusiveAccess.dirs group so that they are not executed concurrently, which helps to mitigate the resource shortages.
> Of course this has the downside that on very large machines the concurrent execution is not done any more.

Hello Matthias,

> What do you think about marking jtreg tests with higher memory requirements with a jtreg key like highmemusage ?

I still don't have any concrete suggestions - it isn't fully clear to me what we should do here. Part of the reason is because, details like the exact command that's being used to run these tests, the "-concurrency" that's either getting computed or explicitly set, the exact Windows OS version and Windows system configurations like the total memory available, the number of CPUs etc... are all unknown right now. Having those details I think would be good to understand what approach to take here. Those details will also help understand why this isn't observed in our internal CI runs.

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

PR Comment: https://git.openjdk.org/jdk/pull/17625#issuecomment-1952463101

From pminborg at openjdk.org  Mon Feb 19 13:36:01 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 19 Feb 2024 13:36:01 GMT
Subject: Integrated: 8326112: Javadoc snippet for
 Linker.Option.captureCallState is wrong
In-Reply-To: 
References: 
Message-ID: 

On Mon, 19 Feb 2024 08:19:58 GMT, Per Minborg  wrote:

> This PR proposes to add an offset parameter for a `VarHandle` invocation in the Javadoc snippet for `Linker.Option.captureCallState()`. The offset parameter was added in 22 but it was forgotten to add it in said Javadoc.

This pull request has now been integrated.

Changeset: 82609b1e
Author:    Per Minborg 
URL:       https://git.openjdk.org/jdk/commit/82609b1ebceb658c612c7ed58959cb159a77d4df
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8326112: Javadoc snippet for Linker.Option.captureCallState is wrong

Reviewed-by: jvernee

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

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

From jpai at openjdk.org  Mon Feb 19 13:42:54 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 19 Feb 2024 13:42:54 GMT
Subject: RFR: JDK-8324930: java/lang/StringBuilder problem with concurrent
 jtreg runs
In-Reply-To: 
References: 
Message-ID: 

On Tue, 30 Jan 2024 09:08:28 GMT, Matthias Baesken  wrote:

> On some Windows machines we see sometimes OOM errors because of high resource (memory/swap) consumption. This is especially seen when the jtreg runs have higher concurrency. A solution is to put the java/lang/StringBuilder tests in the exclusiveAccess.dirs group so that they are not executed concurrently, which helps to mitigate the resource shortages.
> Of course this has the downside that on very large machines the concurrent execution is not done any more.

The other unanswered question is - why is this happening now? I did:


git log test/jdk/java/lang/StringBuilder/

which shows:


commit df22fb322e6c4c9931a770bd0abf4c43b83c4e4a
Author: Jim Laskey 
Date:   Thu Jan 4 12:46:31 2024 +0000

    8322512: StringBuffer.repeat does not work correctly after toString() was called
    
    Reviewed-by: rriggs, jpai

commit 9b9b5a7a5c624f3512567f5d9b2e9eec231cabb3
Author: Jim Laskey 
Date:   Mon Apr 3 15:29:21 2023 +0000

    8302323: Add repeat methods to StringBuilder/StringBuffer
    
    Reviewed-by: tvaleev, redestad

So there's been only 1 commit in that test directory since April 2023. That commit happened on Jan 4th 2024, but at first glance, that change itself doesn't look like something that can cause this issue. The JBS issue you filed is on Jan 30th 2024. Have you noticed such failures with these `test/jdk/java/lang/StringBuilder/` last year?

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

PR Comment: https://git.openjdk.org/jdk/pull/17625#issuecomment-1952476504

From mbaesken at openjdk.org  Mon Feb 19 13:50:54 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 19 Feb 2024 13:50:54 GMT
Subject: RFR: JDK-8324930: java/lang/StringBuilder problem with concurrent
 jtreg runs
In-Reply-To: 
References: 
Message-ID: <9fetGkBdkmae3nRT9GJLYBDrwEuzLBaAwMMtX3VA054=.319a04a8-a8bf-4959-ba74-84a50e210139@github.com>

On Tue, 30 Jan 2024 09:08:28 GMT, Matthias Baesken  wrote:

> On some Windows machines we see sometimes OOM errors because of high resource (memory/swap) consumption. This is especially seen when the jtreg runs have higher concurrency. A solution is to put the java/lang/StringBuilder tests in the exclusiveAccess.dirs group so that they are not executed concurrently, which helps to mitigate the resource shortages.
> Of course this has the downside that on very large machines the concurrent execution is not done any more.

It happens on various machines, two for example

 Windows Server 2022 Standard     16 cores  32G  RAM
 Windows Server 2019 Standard     16 cores  32G  RAM

On both machines we run :tier1  -avm  with  -conc:15   (concurrency jtreg flag) .

> The other unanswered question is - why is this happening now?

I filed the issue this year but there are a couple of occurrences also from last year.  
I find also similar older failures  from 2022 of  java/lang/StringBuilder/HugeCapacity.java because of resource shortages (but those did not generate a hserr file for some reasons just some text output).
So the issue is there for months already (maybe years?) .

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

PR Comment: https://git.openjdk.org/jdk/pull/17625#issuecomment-1952490909

From jpai at openjdk.org  Mon Feb 19 14:10:01 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 19 Feb 2024 14:10:01 GMT
Subject: RFR: 8294977: Convert test/jdk/java tests from ASM library to
 Classfile API [v11]
In-Reply-To: 
References: 
 
Message-ID: 

On Sun, 17 Dec 2023 23:11:10 GMT, Chen Liang  wrote:

>> Summaries:
>> 1. A few recommendations about updating the constant API is made at https://mail.openjdk.org/pipermail/classfile-api-dev/2023-March/000233.html and I may update this patch shall the API changes be integrated before
>> 2. One ASM library-specific test, `LambdaAsm` is removed. Others have their code generation infrastructure upgraded from ASM to Classfile API.
>> 3. Most tests are included in tier1, but some are not:
>> In `:jdk_io`: (tier2, part 2)
>> 
>> test/jdk/java/io/Serializable/records/SerialPersistentFieldsTest.java
>> test/jdk/java/io/Serializable/records/ProhibitedMethods.java
>> test/jdk/java/io/Serializable/records/BadCanonicalCtrTest.java
>> 
>> In `:jdk_instrument`: (tier 3)
>> 
>> test/jdk/java/lang/instrument/RetransformAgent.java
>> test/jdk/java/lang/instrument/NativeMethodPrefixAgent.java
>> test/jdk/java/lang/instrument/asmlib/Instrumentor.java
>> 
>> 
>> @asotona Would you mind reviewing?
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix the 2 failing tests and add notes

tier1, tier2 and tier3 tests went fine with these changes on top of latest master branch.

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

PR Comment: https://git.openjdk.org/jdk/pull/13009#issuecomment-1952526367

From liach at openjdk.org  Mon Feb 19 14:10:01 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 19 Feb 2024 14:10:01 GMT
Subject: Integrated: 8294977: Convert test/jdk/java tests from ASM library to
 Classfile API
In-Reply-To: 
References: 
Message-ID: 

On Tue, 14 Mar 2023 02:43:41 GMT, Chen Liang  wrote:

> Summaries:
> 1. A few recommendations about updating the constant API is made at https://mail.openjdk.org/pipermail/classfile-api-dev/2023-March/000233.html and I may update this patch shall the API changes be integrated before
> 2. One ASM library-specific test, `LambdaAsm` is removed. Others have their code generation infrastructure upgraded from ASM to Classfile API.
> 3. Most tests are included in tier1, but some are not:
> In `:jdk_io`: (tier2, part 2)
> 
> test/jdk/java/io/Serializable/records/SerialPersistentFieldsTest.java
> test/jdk/java/io/Serializable/records/ProhibitedMethods.java
> test/jdk/java/io/Serializable/records/BadCanonicalCtrTest.java
> 
> In `:jdk_instrument`: (tier 3)
> 
> test/jdk/java/lang/instrument/RetransformAgent.java
> test/jdk/java/lang/instrument/NativeMethodPrefixAgent.java
> test/jdk/java/lang/instrument/asmlib/Instrumentor.java
> 
> 
> @asotona Would you mind reviewing?

This pull request has now been integrated.

Changeset: f6d7e30b
Author:    Chen Liang 
Committer: Jaikiran Pai 
URL:       https://git.openjdk.org/jdk/commit/f6d7e30b84fedbf42077526610ba7a5bcfaece4c
Stats:     1829 lines in 31 files changed: 350 ins; 717 del; 762 mod

8294977: Convert test/jdk/java tests from ASM library to Classfile API

Reviewed-by: asotona

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

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

From jpai at openjdk.org  Mon Feb 19 14:28:55 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 19 Feb 2024 14:28:55 GMT
Subject: RFR: JDK-8324930: java/lang/StringBuilder problem with concurrent
 jtreg runs
In-Reply-To: 
References: 
Message-ID: 

On Tue, 30 Jan 2024 09:08:28 GMT, Matthias Baesken  wrote:

> On some Windows machines we see sometimes OOM errors because of high resource (memory/swap) consumption. This is especially seen when the jtreg runs have higher concurrency. A solution is to put the java/lang/StringBuilder tests in the exclusiveAccess.dirs group so that they are not executed concurrently, which helps to mitigate the resource shortages.
> Of course this has the downside that on very large machines the concurrent execution is not done any more.

Thank you for those additional details.

> It happens on various machines, two for example

>Windows Server 2022 Standard 16 cores 32G RAM
>Windows Server 2019 Standard 16 cores 32G RAM
>
>On both machines we run :tier1 -avm with -conc:15 (concurrency jtreg flag) .

That then looks like (an extremely high) concurrency of 15 that has been explicitly set when launching those tests. By default, the concurrency gets set to `num_cores/2` (so should have been 8 in your case) https://github.com/openjdk/jdk/blob/master/make/RunTests.gmk#L152.

I had a quick look at our internal CI, a lot of our Windows systems use 12 core and 24 GB setups (I haven't looked at all of them). The tests on those systems end up using a concurrency of 6 (which is default computed in that RunTests.gmk and matches the `num_cores/2` arithmetic).

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

PR Comment: https://git.openjdk.org/jdk/pull/17625#issuecomment-1952559923

From jpai at openjdk.org  Mon Feb 19 14:35:55 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 19 Feb 2024 14:35:55 GMT
Subject: RFR: JDK-8324930: java/lang/StringBuilder problem with concurrent
 jtreg runs
In-Reply-To: 
References: 
Message-ID: 

On Tue, 30 Jan 2024 09:08:28 GMT, Matthias Baesken  wrote:

> On some Windows machines we see sometimes OOM errors because of high resource (memory/swap) consumption. This is especially seen when the jtreg runs have higher concurrency. A solution is to put the java/lang/StringBuilder tests in the exclusiveAccess.dirs group so that they are not executed concurrently, which helps to mitigate the resource shortages.
> Of course this has the downside that on very large machines the concurrent execution is not done any more.

> What do you think about marking jtreg tests with higher memory requirements with a jtreg key like highmemusage ? This way we do not need to put these tests into the exclusiveAccess.dirs group, but get a way (only if needed) to execute those with high memory usage separately e.g. with lower concurrency.

`jtreg --help Tests` shows this (among other things):


Test Selection Options
                These options can be used to refine the set of tests to be
                executed.
...

    -exclude: | -Xexclude:
                    Provide a file specifying tests that should not be run

...

    -match:   Provide a file specifying tests that can be run (inverse of
                    -exclude)



Maybe you could experiment with these options to exclude the `java/lang/StringBuilder` test directory from your high concurrency run and then only run those in a low concurrency run?

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

PR Comment: https://git.openjdk.org/jdk/pull/17625#issuecomment-1952574423

From cstein at openjdk.org  Mon Feb 19 15:27:53 2024
From: cstein at openjdk.org (Christian Stein)
Date: Mon, 19 Feb 2024 15:27:53 GMT
Subject: RFR: 8318812: LauncherHelper.checkAndLoadMain closes jar file
 that's about to be re-opened [v2]
In-Reply-To: 
References: 
 <5p6LlYPi8V2bxmBvggJJqfrEeOEr9r-foY9yZOQMFbg=.616900a0-6652-4fde-aa74-1e9745d0fe07@github.com>
 
 
Message-ID: <6cT2oCo1-qRB-Yvvr9ZV2YHhqvU6Jjp_XtaeYYnQDGw=.4f414d4d-4387-4c5d-8ff2-8ccd26e7aa02@github.com>

On Mon, 19 Feb 2024 10:41:03 GMT, Alan Bateman  wrote:

>> src/java.base/share/classes/sun/launcher/LauncherHelper.java line 821:
>> 
>>> 819:         // In LM_JAR mode, put the underlying file in the JarFile/ZipFile cache.
>>> 820:         // This will avoid needing to re-parse the manifest when the JAR file
>>> 821:         // is opened on the class path, triggered by Class.forName below.
>> 
>> Nice improvement to have. would it be ok to pad out this comment a bit more ? I found it difficult to understand the specifics. Perhaps :
>> 
>> 
>> 		// In LM_JAR mode, keep the underlying file open to retain it in 
>> 		// the ZipFile HashMap cache. This will avoid needing to re-parse
>>                 // the central directory when the file is opened on the class path,
>> 		// triggered by Class.forName below.
>
>> Nice improvement to have. would it be ok to pad out this comment a bit more ? I found it difficult to understand the specifics. Perhaps :
>> 
>> ```
>> 		// In LM_JAR mode, keep the underlying file open to retain it in 
>> 		// the ZipFile HashMap cache. This will avoid needing to re-parse
>>                 // the central directory when the file is opened on the class path,
>> 		// triggered by Class.forName below.
>> ```
> 
> No issue with expanding the comment but I think leave it as "ZipFile cache" as a more specific comment will quickly bit rot and confuse reader, and of course the Launcher code doesn't care which collection is used internally in the ZipFile code.

I'll expand the comment as suggest, keeping the "JarFile/ZipFile cache" phrase.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17843#discussion_r1494722308

From duke at openjdk.org  Mon Feb 19 15:31:00 2024
From: duke at openjdk.org (David M. Lloyd)
Date: Mon, 19 Feb 2024 15:31:00 GMT
Subject: RFR: 8323707: Adjust Classfile API's type arg model to better
 represent the embodied type [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 15 Jan 2024 02:30:39 GMT, ExE Boss  wrote:

>> Chen Liang 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 fix/typearg-model
>>  - redundant line
>>  - Fix a test in langtools, copyright year
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/typearg-model
>>  - Implementation cleanup, test update
>>  - Merge branch 'master' into fix/typearg-model
>>  - Formatting
>>  - Nuke signatureString and fix test fialure from bad cast
>>  - Adjust the type arg model to better represent the embodied type
>
> src/java.base/share/classes/java/lang/classfile/Signature.java line 219:
> 
>> 217:                  * no wildcard (empty), an exact type
>> 218:                  */
>> 219:                 DEFAULT,
> 
> I?m?personally in?favour of?naming this?`NONE`.

A belated +1 to this, at least not calling it `DEFAULT` because that has at best no meaning, and at worst it's outright confusing. If not `NONE`, then what about `EXACT`?

In my own old parsing code I have an enum called `Variance` with values `INVARIANT`, `COVARIANT`, and `CONTRAVARIANT`, but that might be a bit confusing considering that `EXTENDS` and `SUPER` match the Java language keywords directly.

As an aside, the javadoc here could be a little better IMO.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16517#discussion_r1494726792

From cstein at openjdk.org  Mon Feb 19 15:31:54 2024
From: cstein at openjdk.org (Christian Stein)
Date: Mon, 19 Feb 2024 15:31:54 GMT
Subject: RFR: 8318812: LauncherHelper.checkAndLoadMain closes jar file
 that's about to be re-opened [v2]
In-Reply-To: 
References: 
 <5p6LlYPi8V2bxmBvggJJqfrEeOEr9r-foY9yZOQMFbg=.616900a0-6652-4fde-aa74-1e9745d0fe07@github.com>
 
Message-ID: 

On Mon, 19 Feb 2024 07:32:31 GMT, Jaikiran Pai  wrote:

> Both the files will need a copyright year update.

Right. Updating both files.

> The JBS issue would need an appropriate noreg label too https://openjdk.org/guide/#noreg

Added `noreg-cleanup` to the issue.

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

PR Comment: https://git.openjdk.org/jdk/pull/17843#issuecomment-1952694603

From cstein at openjdk.org  Mon Feb 19 15:42:05 2024
From: cstein at openjdk.org (Christian Stein)
Date: Mon, 19 Feb 2024 15:42:05 GMT
Subject: RFR: 8318812: LauncherHelper.checkAndLoadMain closes jar file
 that's about to be re-opened [v3]
In-Reply-To: 
References: 
Message-ID: 

> Please review this PR that makes the launcher helper keep a reference to the executable JAR file active after extracting the name of the main class and returning it as Class instance. Now, when loading classes from the JAR file, it hasn't to be re-opened.

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

 - Improve comment
 - Update copyright year

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17843/files
  - new: https://git.openjdk.org/jdk/pull/17843/files/202a4ef4..03d91efa

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

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

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

From coffeys at openjdk.org  Mon Feb 19 15:46:54 2024
From: coffeys at openjdk.org (Sean Coffey)
Date: Mon, 19 Feb 2024 15:46:54 GMT
Subject: RFR: 8318812: LauncherHelper.checkAndLoadMain closes jar file
 that's about to be re-opened [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 19 Feb 2024 15:42:05 GMT, Christian Stein  wrote:

>> Please review this PR that makes the launcher helper keep a reference to the executable JAR file active after extracting the name of the main class and returning it as Class instance. Now, when loading classes from the JAR file, it hasn't to be re-opened.
>
> Christian Stein has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Improve comment
>  - Update copyright year

Marked as reviewed by coffeys (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17843#pullrequestreview-1888733805

From cstein at openjdk.org  Mon Feb 19 15:55:53 2024
From: cstein at openjdk.org (Christian Stein)
Date: Mon, 19 Feb 2024 15:55:53 GMT
Subject: RFR: 8318812: LauncherHelper.checkAndLoadMain closes jar file
 that's about to be re-opened [v3]
In-Reply-To: 
References: 
 
 <3GZWKZF6hJQw6Q5iQR40bVocP8qGj2dNLLwDhK9RrLM=.3a3aa6cb-e91e-4d4a-b8f8-e771772ca48b@github.com>
 
Message-ID: 

On Thu, 15 Feb 2024 08:53:12 GMT, Alan Bateman  wrote:

>> `String jarname` is filled by the caller with the value of `String what`, and therefore contains the entire path to the executable JAR file. Using only `jarFile.getName()` will prevent any parent directories from being noted in error messages; which might affect some tests
>
>> `String jarname` is filled by the caller with the value of `String what`, and therefore contains the entire path to the executable JAR file. Using only `jarFile.getName()` will prevent any parent directories from being noted in error messages; which might affect some tests
> 
> It returns the path name so I think it does what we want. Do you observe a behavior difference?

No, I don't.

Also double-checked via `JarFile/ZipFile::getName`'s implementation returning the entire path to the JAR file.

Re-running tier1-3 tests just in case...

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17843#discussion_r1494762559

From ihse at openjdk.org  Mon Feb 19 16:16:00 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 19 Feb 2024 16:16:00 GMT
Subject: Integrated: 8325950: Make sure all files in the JDK pass jcheck
In-Reply-To: <8OFfLzjcABtbqaxklrESgILudN93NzwtNzEJxoOBMoM=.50f8e451-2ef4-467c-9c6b-7ae795428748@github.com>
References: <8OFfLzjcABtbqaxklrESgILudN93NzwtNzEJxoOBMoM=.50f8e451-2ef4-467c-9c6b-7ae795428748@github.com>
Message-ID: <8lQWgT0JhzAP5uuraMs8UjJXJcyTacHziySbnLN9XaQ=.16d4233d-1815-4cf8-8761-368fe425a131@github.com>

On Thu, 15 Feb 2024 12:19:31 GMT, Magnus Ihse Bursie  wrote:

> Since jcheck only checks file in a commit, there is a possibility of us getting files in the repository that would not be accepted by jcheck. This can happen when extending the set of files checked by jcheck, or if jcheck changes how it checks files (perhaps due to bug fixes).
> 
> I have now run jcheck over the entire code base, and fixed a handful of issues. With these changes, jcheck accept the entire code base.

This pull request has now been integrated.

Changeset: 5c5a282f
Author:    Magnus Ihse Bursie 
URL:       https://git.openjdk.org/jdk/commit/5c5a282f91dd28b306673ca2bcc30dec451e7a7d
Stats:     113 lines in 38 files changed: 0 ins; 10 del; 103 mod

8325950: Make sure all files in the JDK pass jcheck

Reviewed-by: prr, wetmore, erikj, naoto

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

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

From aefimov at openjdk.org  Mon Feb 19 16:48:53 2024
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Mon, 19 Feb 2024 16:48:53 GMT
Subject: RFR: 8325579: Inconsistent behavior in
 com.sun.jndi.ldap.Connection::createSocket [v5]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 16 Feb 2024 10:27:11 GMT, Christoph Langer  wrote:

>> During analysing a customer case I figured out that we have an inconsistency between documentation and actual behavior in class com.sun.jndi.ldap.Connection. The [method documentation of com.sun.jndi.ldap.Connection::createSocket](https://github.com/openjdk/jdk/blob/3ebe6c192a5dd5cc46ae2d263713c9ff38cd46bb/src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java#L281) states: "If a timeout is supplied but unconnected sockets are not supported then the timeout is ignored and a connected socket is created."
>> 
>> This, however does not happen. If a SocketFactory would not support unconnected sockets, it would likely throw a SocketException in [SocketFactory::createSocket()](https://github.com/openjdk/jdk/blob/6303c0e7136436a2d3cb6043b88edf788c0067cc/src/java.base/share/classes/javax/net/SocketFactory.java#L123). And since [the code](https://github.com/openjdk/jdk/blob/3ebe6c192a5dd5cc46ae2d263713c9ff38cd46bb/src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java#L336) does not check for this behavior, a connection with timeout value through a SocketFactory that does not support unconnected sockets would simply fail with an IOException.
>> 
>> So we should either make the code adhere to what is documented or adapt the documentation to the actual behavior.
>> 
>> I hereby try to fix the connect coding. Alternatively, we could also adapt the description - I have no strong opinion. What do the experts suggest?
>
> Christoph Langer has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Typo
>  - Merge branch 'master' into JDK-8325579
>  - Rename test and refine comment
>  - Enhance test
>  - JDK-8325579

Currently, it is hard to distinguish what part of the test responsible for [JDK-8314063](https://bugs.openjdk.org/browse/JDK-8314063) testing, and which part is for [JDK-8325579](https://bugs.openjdk.org/browse/JDK-8325579).
I would prefer to add a new test for the current fix instead: that could be done as additional test mode, OR even better to add a completely new test.
As Daniel stated before, it is hard to review the change made in this PR because of the test name change. Previous suggestion might help to address that too.

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

PR Comment: https://git.openjdk.org/jdk/pull/17797#issuecomment-1952861854

From frank.kretschmer at gmx.net  Mon Feb 19 17:07:56 2024
From: frank.kretschmer at gmx.net (Frank Kretschmer)
Date: Mon, 19 Feb 2024 18:07:56 +0100
Subject: [External] : Re: OpenJDK 17: Loitering
 AbstractQueuedSynchronizer$ConditionNode instances (also on latest master
 branch) [JDK-8325754]
In-Reply-To: 
References: <591b0e9c-1d7a-405d-ace1-bd94f8dbbe22@gmx.net>
 
 
 <64bc8cbd-78f4-44f4-90ae-80466c563281@gmx.net>
 <6d3b62cb-15f4-471c-97b6-b72977223f91@gmx.net>
 <59c3b1bc-fd60-4215-b8f7-96421f1881e2@gmail.com>
 <127f2696-5f6d-4bab-b45e-e7597f267add@gmx.net>
 
Message-ID: 

Hi Viktor,


may I add one option to your evaluation?


    @@ -1506,14 +1506,15 @@ public ConditionObject() { }
     ???????? private void doSignal(ConditionNode first, boolean all) {
     ???????????? while (first != null) {
     ???????????????? ConditionNode next = first.nextWaiter;
     ???????????????? if ((firstWaiter = next) == null)
     ???????????????????? lastWaiter = null;
     ???????????????? if ((first.getAndUnsetStatus(COND) & COND) != 0) {
     ???????????????????? enqueue(first);
    +??????????????????? first.nextWaiter = null; // GC-friendly
     ???????????????????? if (!all)
     ???????????????????????? break;
     ???????????????? }
     ???????????????? first = next;
     ???????????? }
     ???????? }


(AbstractQueuedSynchronizer line numbers as in gitlab current master)


This variant takes care about race conditions on cancellation
(unlinkCancelledWaiters() needs 'nextWaiter'), as thanks to
"getAndUnsetStatus(COND) & COND) != 0" only alternatively/once executed.


So this option is definitively better / more robust than my first one ?



Best regards

Frank




Am 19.02.2024 um 12:41 schrieb Viktor Klang:
> Hi Frank,
>
> We'll see what the option are. ?
>
> Cheers,
> ?
>
> *
> *
> *Viktor Klang*
> Software Architect, Java Platform Group
> Oracle
> ------------------------------------------------------------------------
> *From:* Frank Kretschmer 
> *Sent:* Sunday, 18 February 2024 15:36
> *To:* Jaikiran Pai ; Viktor Klang
> ; Java Core Libs 
> *Subject:* [External] : Re: OpenJDK 17: Loitering
> AbstractQueuedSynchronizer$ConditionNode instances (also on latest
> master branch) [JDK-8325754]
>
> Hello Jaikiran, hello Viktor,
>
> in the meantime, I've seen that the JBS issue has been assigned to
> Viktor Klang. @Viktor: I totally agree with your comment that the
> proposed solution may not be the best possible option, and that
> further explorations were required.
>
> My intention to propose unlinking ConditionNodes by null'ing their
> ?nextWaiter? reference was just to verify that the chain of
> ?nextWaiter? references leads to the observed garbage collection
> behavior, and that the GC is able to collect the nodes during minor /
> young collections if the references are cleaned in time.
>
> I checked also a few other variants (null'ing the ?nextWaiter?
> reference at the end of all await...() methods in ConditionObject, or
> in/just before enqueue()), but at the end of the day, I felt that
> null'ing it in doSignal() explains what I want to show the easiest. On
> the other hand, the other options could be better in order to avoid
> race conditions with canceled nodes.
>
> For sure there are many other options that I am not aware of, so
> please take my proposal just as an example.
>
> Looking forward to your explorations.
>
> Best regards
>
> Frank
>
>
> Am 14.02.2024 um 07:43 schrieb Jaikiran Pai:
>>
>> Hello Frank,
>>
>> I see that a JBS issue has been created for this same issue
>> https://bugs.openjdk.org/browse/JDK-8325754
>> .
>>
>> I don't have enough knowledge of this area and haven't reviewed this
>> part of the code in detail to see if there are any obvious issues
>> with what you are proposing as a solution. Since there's now a JBS
>> issue created for this and you seem to have done enough investigation
>> and work on this one already, would you be interested in creating a
>> pull request against the https://github.com/openjdk/jdk
>> 
>> repo with this proposed change? (you'll have to sign a OCA). This
>> guide https://openjdk.org/guide/  should
>> help you get started. It can then go through the usual reviews that a
>> bug fix/enhancement goes through.
>>
>> -Jaikiran
>>
>> On 11/02/24 7:27 pm, Frank Kretschmer wrote:
>>>
>>> Hello Core-Libs-Dev team,
>>>
>>> may I ask you about your opinion about a tiny one-liner change in
>>> AbstractQueuedSynchronizer, just as a suggestion how to make
>>> ConditionObjects / Nodes even more garbage collector friendly?
>>>
>>> Checked out
>>> https://github.com/openjdk/jdk/blob/jdk-17%2B35/src/java.base/share/classes/java/util/concurrent/locks/AbstractQueuedSynchronizer.java
>>> 
>>> (the same on master branch with different line numbers near to line
>>> 1506):
>>>
>>> @@ -1431,40 +1431,41 @@ public abstract class AbstractQueuedSynchronizer
>>> ???? public class ConditionObject implements Condition,
>>> java.io.Serializable {
>>> ???????? // ...
>>> ???????? private void doSignal(ConditionNode first, boolean all) {
>>> ???????????? while (first != null) {
>>> ???????????????? ConditionNode next = first.nextWaiter;
>>> +??????????????? first.nextWaiter = null;? // GC-friendly: avoid
>>> chains of dead ConditionNodes
>>> ???????????????? if ((firstWaiter = next) == null)
>>> ???????????????????? lastWaiter = null;
>>> ???????????????? if ((first.getAndUnsetStatus(COND) & COND) != 0) {
>>> ???????????????????? enqueue(first);
>>> ???????????????? // ...
>>>
>>> By setting the nextWaiter to null of the first condition node, which
>>> is transferred from the condition queue to the sync queue in this
>>> method, long chains of ConditionNode instances can be avoided.
>>> Though a single ConditionNode is small, these chains of
>>> ConditionNodes become very huge on the heap (I've seen more than 1GB
>>> on an application server over time) if at least one node was
>>> promoted to the old generation for any reason. They survive minor
>>> collections and are cleaned up only on mixed / full collections, and
>>> thus put unnecessary pressure on G1 garbage collector.
>>>
>>> The same change could also be applied to
>>> 'AbstractQueuedLongSynchronizer'.
>>>
>>> I know premature optimization is the root of all evil, on the other
>>> hand I could image that many applications benefit from GC-friendly
>>> ConditionObjects, since they are frequently used in various classes
>>> like PriorityBlockingQueue / LinkedBlockingDeque /
>>> LinkedBlockingQueue, the latter one as default work queue for
>>> executor services like fixed thread pools for processing
>>> asynchronous tasks.
>>>
>>> Thank you all for your time and help!
>>>
>>> Best regards
>>> Frank
>>>
>>> Am 08.02.2024 um 12:15 schrieb Frank Kretschmer:
>>>> Hello Thomas, hello Core-Libs-Dev,
>>>>
>>>> thank you for cc'ing my email. In deed my idea/suggestion is to modify
>>>> the AbstractQueuedSynchronizer$ConditionNode handling in such a way
>>>> that
>>>> it gets unlinked from the chain of condition nodes if it is not needed
>>>> any more (it might be the "nextWaiter" node), in order to be more
>>>> GC-friendly.
>>>>
>>>> @core-libs-dev: I've just attached the ?G1LoiteringConditionNodes?
>>>> demo
>>>> class and "gc.log" again so that you can have a look if you like.
>>>>
>>>> Best regards
>>>>
>>>> Frank
>>>>
>>>>
>>>> Am 08.02.2024 um 11:04 schrieb Thomas Schatzl:
>>>>> Hi,
>>>>>
>>>>> ? since this looks like a suggestion for a change to the libraries
>>>>> similar to the mentioned JDK-6805775, and not actually GC, cc'ing the
>>>>> core-libs-dev mailing list.
>>>>>
>>>>> Hth,
>>>>> ? Thomas
>>>>>
>>>>> On 07.02.24 15:20, Frank Kretschmer wrote:
>>>>>> Hi Java GC-experts,
>>>>>>
>>>>>> I'm facing an interesting G1 garbage collector observation in
>>>>>> OpenJDK
>>>>>> 17.0.9+9, which I would like to share with you.
>>>>>>
>>>>>> My application runs many asynchronous tasks in a fixed thread pool,
>>>>>> utilizing its standard LinkedBlockingQueue. Usually, it generates
>>>>>> just a
>>>>>> little garbage, but from time to time, I observed that the survivor
>>>>>> spaces grow unexpectedly, and minor collection times increase.
>>>>>>
>>>>>> This being the case, many
>>>>>> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionNode
>>>>>> instances can be found on the heap. In fact, the whole heap (rank
>>>>>> 1 as
>>>>>> shown in jmap) was filled up with ConditionNode instances after a
>>>>>> while.
>>>>>>
>>>>>> After some tests, I figured out that G1 seems to be able to collect
>>>>>> ?dead? ConditionNode instances during minor collections only if no
>>>>>> formerly alive ConditionNode instances were promoted to the old
>>>>>> generation and died there.
>>>>>>
>>>>>> To illustrate that, I've attached a ?G1LoiteringConditionNodes?
>>>>>> class
>>>>>> that can be run for demo purposes, e.g. under Linux with OpenJDK
>>>>>> 17.0.9+9 (VM options see comments within the class), and its gc-log
>>>>>> output. It shows that during the first two minutes, everything is
>>>>>> fine,
>>>>>> but after a promotion to the old generation, survivors grow and
>>>>>> minor
>>>>>> pause time increase from 3 to 10ms.
>>>>>>
>>>>>> For me, it looks like an issue similar to
>>>>>> https://bugs.openjdk.org/browse/JDK-6805775
>>>>>> 
>>>>>> ?LinkedBlockingQueue Nodes
>>>>>> should unlink themselves before becoming garbage?, which was
>>>>>> fixed in
>>>>>> OpenJDK 7.
>>>>>>
>>>>>> What?s your opinion about that? Wouldn?t it be worth to enable G1 to
>>>>>> collect those AbstractQueuedSynchronizer$ConditionNode instances
>>>>>> during
>>>>>> minor collections, as it is done for LinkedBlockingQueue Nodes?
>>>>>>
>>>>>> Best regards
>>>>>>
>>>>>> Frank
>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From aefimov at openjdk.org  Mon Feb 19 17:22:58 2024
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Mon, 19 Feb 2024 17:22:58 GMT
Subject: RFR: 8325579: Inconsistent behavior in
 com.sun.jndi.ldap.Connection::createSocket [v5]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 16 Feb 2024 10:27:11 GMT, Christoph Langer  wrote:

>> During analysing a customer case I figured out that we have an inconsistency between documentation and actual behavior in class com.sun.jndi.ldap.Connection. The [method documentation of com.sun.jndi.ldap.Connection::createSocket](https://github.com/openjdk/jdk/blob/3ebe6c192a5dd5cc46ae2d263713c9ff38cd46bb/src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java#L281) states: "If a timeout is supplied but unconnected sockets are not supported then the timeout is ignored and a connected socket is created."
>> 
>> This, however does not happen. If a SocketFactory would not support unconnected sockets, it would likely throw a SocketException in [SocketFactory::createSocket()](https://github.com/openjdk/jdk/blob/6303c0e7136436a2d3cb6043b88edf788c0067cc/src/java.base/share/classes/javax/net/SocketFactory.java#L123). And since [the code](https://github.com/openjdk/jdk/blob/3ebe6c192a5dd5cc46ae2d263713c9ff38cd46bb/src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java#L336) does not check for this behavior, a connection with timeout value through a SocketFactory that does not support unconnected sockets would simply fail with an IOException.
>> 
>> So we should either make the code adhere to what is documented or adapt the documentation to the actual behavior.
>> 
>> I hereby try to fix the connect coding. Alternatively, we could also adapt the description - I have no strong opinion. What do the experts suggest?
>
> Christoph Langer has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Typo
>  - Merge branch 'master' into JDK-8325579
>  - Rename test and refine comment
>  - Enhance test
>  - JDK-8325579

src/java.naming/share/classes/module-info.java line 51:

> 49:  *         network times out.
> 50:  *         
 If a custom socket factory is provided via property
> 51:  *         {@code java.naming.ldap.factory.socket} and unconnected sockets

Suggestion:

 *         
 If a custom socket factory is provided via  {@code java.naming.ldap.factory.socket}  environment 
 *        property and unconnected sockets

src/java.naming/share/classes/module-info.java line 51:

> 49:  *         network times out.
> 50:  *         
 If a custom socket factory is provided via property
> 51:  *         {@code java.naming.ldap.factory.socket} and unconnected sockets

Suggestion:

 *         
 If a custom socket factory is provided via  {@code java.naming.ldap.factory.socket}  environment 
 *        property and unconnected sockets

src/java.naming/share/classes/module-info.java line 51:

> 49:  *         network times out.
> 50:  *         
 If a custom socket factory is provided via property
> 51:  *         {@code java.naming.ldap.factory.socket} and unconnected sockets

Since we're referencing socket factory env property, maybe we can also document it here. Something like: 


  • {@code com.sun.jndi.ldap.connect.timeout}:
    
    The value of this environment property specifies the fully
     qualified class name of the socket factory used by the LDAP provider.
     This class must implement the javax.net.SocketFactory abstract class.
     By default the environment property is not set.

    • 

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17797#discussion_r1494840144
PR Review Comment: https://git.openjdk.org/jdk/pull/17797#discussion_r1494840513
PR Review Comment: https://git.openjdk.org/jdk/pull/17797#discussion_r1494861825

From eirbjo at openjdk.org  Mon Feb 19 20:14:06 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Mon, 19 Feb 2024 20:14:06 GMT
Subject: RFR: 8326096: Deprecate getTotalIn,
 getTotalOut methods of java.util.zip.Inflater, java.util.zip.Deflater
Message-ID: 

Please review this PR which proposes that we officially deprecate the following four methods in the `java.util.zip` package:

* `Inflater.getTotalIn()`
* `Inflater.getTotalOut()`
* `Deflater.getTotalIn()`
* `Deflater.getTotalOut()`

Since these legacy methods return `int`, they cannot safely return the number of bytes processed without the risk of losing information  about the magnitude or even sign of the returned value.

The corresponding methods `getBytesRead()` and `getBytesWritten()` methods introduced in Java 5 return `long`, and should be used instead when obtaining this information. 


Unrelated to the deprecation itself, the documentation currently does not specify what these methods are expected to return when the number of processed bytes is higher than `Integer.MAX_VALUE`. This PR aims to clarify this in the API specification.

Initally, this PR handles only `Inflater.getTotalIn()`. The other three methods will be updated once the wordsmithing for this method stabilizes.

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

Commit messages:
 - Initial deprecation notice, starting with Inflater.getTotalIn as an example

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

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

From eirbjo at openjdk.org  Mon Feb 19 20:14:06 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Mon, 19 Feb 2024 20:14:06 GMT
Subject: RFR: 8326096: Deprecate getTotalIn,
 getTotalOut methods of java.util.zip.Inflater, java.util.zip.Deflater
In-Reply-To: 
References: 
Message-ID: 

On Mon, 19 Feb 2024 18:35:58 GMT, Eirik Bj?rsn?s  wrote:

> Please review this PR which proposes that we officially deprecate the following four methods in the `java.util.zip` package:
> 
> * `Inflater.getTotalIn()`
> * `Inflater.getTotalOut()`
> * `Deflater.getTotalIn()`
> * `Deflater.getTotalOut()`
> 
> Since these legacy methods return `int`, they cannot safely return the number of bytes processed without the risk of losing information  about the magnitude or even sign of the returned value.
> 
> The corresponding methods `getBytesRead()` and `getBytesWritten()` methods introduced in Java 5 return `long`, and should be used instead when obtaining this information. 
> 
> 
> Unrelated to the deprecation itself, the documentation currently does not specify what these methods are expected to return when the number of processed bytes is higher than `Integer.MAX_VALUE`. This PR aims to clarify this in the API specification.
> 
> Initally, this PR handles only `Inflater.getTotalIn()`. The other three methods will be updated once the wordsmithing for this method stabilizes.

Since these four methods are very similar, let's use `Inflater.getTotalIn()` for the initial round of review of the deprecation note and return value clarification.

Once feedback on this method converges, I'll go ahead and update the other three methods accordingly and also file a CSR for review.

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

PR Comment: https://git.openjdk.org/jdk/pull/17919#issuecomment-1953100167

From eirbjo at openjdk.org  Mon Feb 19 20:55:06 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Mon, 19 Feb 2024 20:55:06 GMT
Subject: RFR: 8326096: Deprecate getTotalIn,
 getTotalOut methods of java.util.zip.Inflater, java.util.zip.Deflater [v2]
In-Reply-To: 
References: 
Message-ID: 

> Please review this PR which proposes that we officially deprecate the following four methods in the `java.util.zip` package:
> 
> * `Inflater.getTotalIn()`
> * `Inflater.getTotalOut()`
> * `Deflater.getTotalIn()`
> * `Deflater.getTotalOut()`
> 
> Since these legacy methods return `int`, they cannot safely return the number of bytes processed without the risk of losing information  about the magnitude or even sign of the returned value.
> 
> The corresponding methods `getBytesRead()` and `getBytesWritten()` methods introduced in Java 5 return `long`, and should be used instead when obtaining this information. 
> 
> Unrelated to the deprecation itself, the documentation currently does not specify what these methods are expected to return when the number of processed bytes is higher than `Integer.MAX_VALUE`. This PR aims to clarify this in the API specification.
> 
> Initally, this PR handles only `Inflater.getTotalIn()`. The other three methods will be updated once the wordsmithing for this method stabilizes.

Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:

  Fix {@link #getBytesRead}

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17919/files
  - new: https://git.openjdk.org/jdk/pull/17919/files/0d41a196..752230d4

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

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

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

From dholmes at openjdk.org  Mon Feb 19 22:02:58 2024
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 19 Feb 2024 22:02:58 GMT
Subject: Integrated: 8326126: Update the java manpage with the changes from
 JDK-8322478
In-Reply-To: 
References: 
Message-ID: 

On Mon, 19 Feb 2024 07:04:07 GMT, David Holmes  wrote:

> Please reviews these manpage updates in relation to "JEP 458: Launch Multi-File Source-Code Programs".  The manpage sources had previously been updated internally at Oracle under JDK-8322478, but the open troff file was not regenerated at the time in mainline (it was for JDK 22).
> 
> The main gist of the change is that with multi-file support now available,  occurrences of "single source-file" should just refer to "source-file".
> 
> Thanks

This pull request has now been integrated.

Changeset: a3d7f9f2
Author:    David Holmes 
URL:       https://git.openjdk.org/jdk/commit/a3d7f9f2422cb4b65de7a086dc27dadc0858bf82
Stats:     61 lines in 1 file changed: 27 ins; 5 del; 29 mod

8326126: Update the java manpage with the changes from JDK-8322478

Reviewed-by: alanb, cstein

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

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

From dholmes at openjdk.org  Mon Feb 19 22:02:57 2024
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 19 Feb 2024 22:02:57 GMT
Subject: RFR: 8326126: Update the java manpage with the changes from
 JDK-8322478
In-Reply-To: 
References: 
Message-ID: 

On Mon, 19 Feb 2024 07:04:07 GMT, David Holmes  wrote:

> Please reviews these manpage updates in relation to "JEP 458: Launch Multi-File Source-Code Programs".  The manpage sources had previously been updated internally at Oracle under JDK-8322478, but the open troff file was not regenerated at the time in mainline (it was for JDK 22).
> 
> The main gist of the change is that with multi-file support now available,  occurrences of "single source-file" should just refer to "source-file".
> 
> Thanks

Thanks for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/17908#issuecomment-1953205703

From stuart.marks at oracle.com  Mon Feb 19 23:40:10 2024
From: stuart.marks at oracle.com (Stuart Marks)
Date: Mon, 19 Feb 2024 15:40:10 -0800
Subject: CFV: New Core Libraries Group Member: Viktor Klang
Message-ID: <5a5a3d2c-34d7-f6fb-8736-c3bb5cf5d5fc@oracle.com>


I hereby nominate Viktor Klang [6] to Membership in the Core Libraries Group [4].

Viktor has been a member of the Java team in Oracle since 2022, and he is currently 
a Committer on the JDK project. Viktor has led JEP 461 [1], an enhancement to the 
Streams API to support new intermediate stream operations. Viktor has also 
contributed several other changes to the JDK [2][3], focusing primarily on the 
java.util.concurrent package. Prior to his work on OpenJDK, Viktor's past work 
includes Akka, Reactive Streams, and many other contributions to the Scala world.

Votes are due by 23:59 UTC on March 4, 2024.

Only current Members of the Core Libraries Group [4] are eligible to vote on this 
nomination. Votes must be cast in the open by replying to this mailing list.

For Lazy Consensus voting instructions, see [5].

s'marks


[1] https://openjdk.org/jeps/461
[2] https://github.com/openjdk/jdk/commits?author=vklang%40openjdk.org
[3] https://github.com/openjdk/jdk/commits?author=viktorklang-ora
[4] https://openjdk.org/census#core-libs
[5] https://openjdk.org/groups/#member-vote
[6] https://openjdk.org/census#vklang

From jpai at openjdk.org  Tue Feb 20 05:52:55 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 20 Feb 2024 05:52:55 GMT
Subject: RFR: 8318812: LauncherHelper.checkAndLoadMain closes jar file
 that's about to be re-opened [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 19 Feb 2024 15:42:05 GMT, Christian Stein  wrote:

>> Please review this PR that makes the launcher helper keep a reference to the executable JAR file active after extracting the name of the main class and returning it as Class instance. Now, when loading classes from the JAR file, it hasn't to be re-opened.
>
> Christian Stein has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Improve comment
>  - Update copyright year

Marked as reviewed by jpai (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17843#pullrequestreview-1889544193

From dholmes at openjdk.org  Tue Feb 20 06:53:58 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 20 Feb 2024 06:53:58 GMT
Subject: RFR: JDK-8252802: java launcher should set MALLOCOPTIONS and
 LDR_CNTRL in order to use 64KB pages on AIX
In-Reply-To: 
References: 
Message-ID: 

On Mon, 19 Feb 2024 05:52:22 GMT, Varada M  wrote:

> DeCapo Benchmark Results (3 runs) :  
> 
> Before : 
> ===== DaCapo 9.12 h2 PASSED in 281402 msec =====
> ===== DaCapo 9.12 h2 PASSED in 269818 msec =====
> ===== DaCapo 9.12 h2 PASSED in 279279 msec =====
>  
> After:
> ===== DaCapo 9.12 h2 PASSED in 279192 msec =====
> ===== DaCapo 9.12 h2 PASSED in 269769 msec =====
> ===== DaCapo 9.12 h2 PASSED in 271577 msec ===== 
> 
> Environmental variables LDR_CNTRL and MALLOCOPTIONS has caused test/jdk/java/lang/ProcessBuilder/Basic.java failure.
> Additional environmental variables has to removed from removeAixExpectedVars().
> 
> JBS Issue : [JDK-8252802](https://bugs.openjdk.org/browse/JDK-8252802)

I concur with Alan: is this the right way to fix this? And is it really the case that every single Java application on AIX wants this setting?

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

PR Comment: https://git.openjdk.org/jdk/pull/17906#issuecomment-1953585384

From cstein at openjdk.org  Tue Feb 20 07:04:58 2024
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 20 Feb 2024 07:04:58 GMT
Subject: RFR: 8318812: LauncherHelper.checkAndLoadMain closes jar file
 that's about to be re-opened [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 19 Feb 2024 15:42:05 GMT, Christian Stein  wrote:

>> Please review this PR that makes the launcher helper keep a reference to the executable JAR file active after extracting the name of the main class and returning it as Class instance. Now, when loading classes from the JAR file, it hasn't to be re-opened.
>
> Christian Stein has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Improve comment
>  - Update copyright year

Re-tested Tier1-3 OK

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

PR Comment: https://git.openjdk.org/jdk/pull/17843#issuecomment-1953594654

From cstein at openjdk.org  Tue Feb 20 07:04:58 2024
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 20 Feb 2024 07:04:58 GMT
Subject: Integrated: 8318812: LauncherHelper.checkAndLoadMain closes jar file
 that's about to be re-opened
In-Reply-To: 
References: 
Message-ID: <7OLjZX1T3rb3NOuyaXaxqh2VC0prFL5FJvl0Yl1y1sI=.380ce3ba-a117-4be4-8836-c17762e087d7@github.com>

On Wed, 14 Feb 2024 11:03:07 GMT, Christian Stein  wrote:

> Please review this PR that makes the launcher helper keep a reference to the executable JAR file active after extracting the name of the main class and returning it as Class instance. Now, when loading classes from the JAR file, it hasn't to be re-opened.

This pull request has now been integrated.

Changeset: 0d285312
Author:    Christian Stein 
URL:       https://git.openjdk.org/jdk/commit/0d285312a958c159d2efb8bd00fc29dd6a5a4d16
Stats:     96 lines in 2 files changed: 33 ins; 17 del; 46 mod

8318812: LauncherHelper.checkAndLoadMain closes jar file that's about to be re-opened

Reviewed-by: alanb, jpai, coffeys

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

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

From jpai at openjdk.org  Tue Feb 20 07:15:54 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 20 Feb 2024 07:15:54 GMT
Subject: RFR: 8326096: Deprecate getTotalIn,
 getTotalOut methods of java.util.zip.Inflater, java.util.zip.Deflater [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 19 Feb 2024 20:55:06 GMT, Eirik Bj?rsn?s  wrote:

>> Please review this PR which proposes that we officially deprecate the following four methods in the `java.util.zip` package:
>> 
>> * `Inflater.getTotalIn()`
>> * `Inflater.getTotalOut()`
>> * `Deflater.getTotalIn()`
>> * `Deflater.getTotalOut()`
>> 
>> Since these legacy methods return `int`, they cannot safely return the number of bytes processed without the risk of losing information  about the magnitude or even sign of the returned value.
>> 
>> The corresponding methods `getBytesRead()` and `getBytesWritten()` methods introduced in Java 5 return `long`, and should be used instead when obtaining this information. 
>> 
>> Unrelated to the deprecation itself, the documentation currently does not specify what these methods are expected to return when the number of processed bytes is higher than `Integer.MAX_VALUE`. This PR aims to clarify this in the API specification.
>> 
>> Initally, this PR handles only `Inflater.getTotalIn()`. The other three methods will be updated once the wordsmithing for this method stabilizes.
>
> Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix {@link #getBytesRead}

src/java.base/share/classes/java/util/zip/Inflater.java line 642:

> 640:      * the 32 highest order bits, as if the {@link #getBytesRead()}
> 641:      * method was called followed by a narrowing conversion from long
> 642:      * to int.

I think we should leave this part of the javadoc comment as-is and not change it.

src/java.base/share/classes/java/util/zip/Inflater.java line 651:

> 649:      * the 32 highest order bits
> 650:      */
> 651:     @Deprecated

Hello Eirik, the `Deprecated` annotation allows for a `since` property. I think we should use it here `@Deprecated(since=23)`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17919#discussion_r1495336375
PR Review Comment: https://git.openjdk.org/jdk/pull/17919#discussion_r1495335607

From jpai at openjdk.org  Tue Feb 20 07:20:58 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 20 Feb 2024 07:20:58 GMT
Subject: RFR: 8326096: Deprecate getTotalIn,
 getTotalOut methods of java.util.zip.Inflater, java.util.zip.Deflater [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 19 Feb 2024 20:55:06 GMT, Eirik Bj?rsn?s  wrote:

>> Please review this PR which proposes that we officially deprecate the following four methods in the `java.util.zip` package:
>> 
>> * `Inflater.getTotalIn()`
>> * `Inflater.getTotalOut()`
>> * `Deflater.getTotalIn()`
>> * `Deflater.getTotalOut()`
>> 
>> Since these legacy methods return `int`, they cannot safely return the number of bytes processed without the risk of losing information  about the magnitude or even sign of the returned value.
>> 
>> The corresponding methods `getBytesRead()` and `getBytesWritten()` methods introduced in Java 5 return `long`, and should be used instead when obtaining this information. 
>> 
>> Unrelated to the deprecation itself, the documentation currently does not specify what these methods are expected to return when the number of processed bytes is higher than `Integer.MAX_VALUE`. This PR aims to clarify this in the API specification.
>> 
>> Initally, this PR handles only `Inflater.getTotalIn()`. The other three methods will be updated once the wordsmithing for this method stabilizes.
>
> Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix {@link #getBytesRead}

src/java.base/share/classes/java/util/zip/Inflater.java line 644:

> 642:      * to int.
> 643:      *
> 644:      * @deprecated This method cannot safely return a result without a potential

Perhaps word this as:
>
>This method cannot return the right value when the number of compressed bytes is greater than {@link Integer.MAX_VALUE}. It is recommended that the {@link #getBytesRead()} method be used instead.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17919#discussion_r1495339856

From stuefe at openjdk.org  Tue Feb 20 07:48:57 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 20 Feb 2024 07:48:57 GMT
Subject: RFR: JDK-8252802: java launcher should set MALLOCOPTIONS and
 LDR_CNTRL in order to use 64KB pages on AIX
In-Reply-To: 
References: 
Message-ID: 

On Mon, 19 Feb 2024 05:52:22 GMT, Varada M  wrote:

> DeCapo Benchmark Results (3 runs) :  
> 
> Before : 
> ===== DaCapo 9.12 h2 PASSED in 281402 msec =====
> ===== DaCapo 9.12 h2 PASSED in 269818 msec =====
> ===== DaCapo 9.12 h2 PASSED in 279279 msec =====
>  
> After:
> ===== DaCapo 9.12 h2 PASSED in 279192 msec =====
> ===== DaCapo 9.12 h2 PASSED in 269769 msec =====
> ===== DaCapo 9.12 h2 PASSED in 271577 msec ===== 
> 
> Environmental variables LDR_CNTRL and MALLOCOPTIONS has caused test/jdk/java/lang/ProcessBuilder/Basic.java failure.
> Additional environmental variables has to removed from removeAixExpectedVars().
> 
> JBS Issue : [JDK-8252802](https://bugs.openjdk.org/browse/JDK-8252802)

I don't think this works as intended. 

IIRC, both variables must be set *before process invocation*. Setting them inside the launcher will only affect child processes. The dacapo results posted seem to support this, they seem random-ish to me.

Note that we already use 64KB pages for all large memory regions (everything that goes through  `os::reserve_memory`). So, while the value of LDRCNTRL is not nil, it is very diminished. Mostly just the Heap is affected.

But I would not change defaults for options like these anyway, especially not hard-coded. These knobs have far-ranging implications. If we want that, we need to investigate carefully.

(for example: would using 64KB pages increase average heap size? Possibly, depending on the implementation. But AIX still has this problem where the heap can only live in the break and can bump against low-hanging regions. So, AIX is especially vulnerable against any changes that increase average heap usage)

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

PR Comment: https://git.openjdk.org/jdk/pull/17906#issuecomment-1953643518

From varadam at openjdk.org  Tue Feb 20 08:43:57 2024
From: varadam at openjdk.org (Varada M)
Date: Tue, 20 Feb 2024 08:43:57 GMT
Subject: RFR: JDK-8252802: java launcher should set MALLOCOPTIONS and
 LDR_CNTRL in order to use 64KB pages on AIX
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 20 Feb 2024 07:45:59 GMT, Thomas Stuefe  wrote:

>> DeCapo Benchmark Results (3 runs) :  
>> 
>> Before : 
>> ===== DaCapo 9.12 h2 PASSED in 281402 msec =====
>> ===== DaCapo 9.12 h2 PASSED in 269818 msec =====
>> ===== DaCapo 9.12 h2 PASSED in 279279 msec =====
>>  
>> After:
>> ===== DaCapo 9.12 h2 PASSED in 279192 msec =====
>> ===== DaCapo 9.12 h2 PASSED in 269769 msec =====
>> ===== DaCapo 9.12 h2 PASSED in 271577 msec ===== 
>> 
>> Environmental variables LDR_CNTRL and MALLOCOPTIONS has caused test/jdk/java/lang/ProcessBuilder/Basic.java failure.
>> Additional environmental variables has to removed from removeAixExpectedVars().
>> 
>> JBS Issue : [JDK-8252802](https://bugs.openjdk.org/browse/JDK-8252802)
>
> I don't think this works as intended. 
> 
> IIRC, both variables must be set *before process invocation*. Setting them inside the launcher will only affect child processes. The dacapo results posted seem to support this, they seem random-ish to me.
> 
> Note that we already use 64KB pages for all large memory regions (everything that goes through  `os::reserve_memory`). So, while the value of LDRCNTRL is not nil, it is very diminished. Mostly just the C-Heap would be affected.
> 
> But I would not change defaults for options like these anyway, especially not hard-coded. These knobs have far-ranging implications. If we want that, we need to investigate carefully.
> 
> (for example: would using 64KB pages increase average heap size? Possibly, depending on the implementation. But AIX still has this problem where the heap can only live in the break and can bump against low-hanging regions. So, AIX is especially vulnerable against any changes that increase average heap usage)

Thanks @tstuefe for the response. Closing the PR since it is not advisable to do.

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

PR Comment: https://git.openjdk.org/jdk/pull/17906#issuecomment-1953721220

From varadam at openjdk.org  Tue Feb 20 08:43:57 2024
From: varadam at openjdk.org (Varada M)
Date: Tue, 20 Feb 2024 08:43:57 GMT
Subject: Withdrawn: JDK-8252802: java launcher should set MALLOCOPTIONS and
 LDR_CNTRL in order to use 64KB pages on AIX
In-Reply-To: 
References: 
Message-ID: <3ejbZffmjfuY61i-YWW_9oE-Tpt8im2pPkGeq7pCi1Y=.9508633d-1d25-4c96-b1eb-0d4ac3d7b632@github.com>

On Mon, 19 Feb 2024 05:52:22 GMT, Varada M  wrote:

> DeCapo Benchmark Results (3 runs) :  
> 
> Before : 
> ===== DaCapo 9.12 h2 PASSED in 281402 msec =====
> ===== DaCapo 9.12 h2 PASSED in 269818 msec =====
> ===== DaCapo 9.12 h2 PASSED in 279279 msec =====
>  
> After:
> ===== DaCapo 9.12 h2 PASSED in 279192 msec =====
> ===== DaCapo 9.12 h2 PASSED in 269769 msec =====
> ===== DaCapo 9.12 h2 PASSED in 271577 msec ===== 
> 
> Environmental variables LDR_CNTRL and MALLOCOPTIONS has caused test/jdk/java/lang/ProcessBuilder/Basic.java failure.
> Additional environmental variables has to removed from removeAixExpectedVars().
> 
> JBS Issue : [JDK-8252802](https://bugs.openjdk.org/browse/JDK-8252802)

This pull request has been closed without being integrated.

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

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

From epeter at openjdk.org  Tue Feb 20 08:53:02 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Tue, 20 Feb 2024 08:53:02 GMT
Subject: RFR: 8318650: Optimized subword gather for x86 targets. [v13]
In-Reply-To: <-jaGezbfx9ZylmA6EBQY2TxqjfIHNhT8TXI6_KCL11Y=.d48ef20a-21c1-4486-ada6-4e1acf86a9ea@github.com>
References: 
 <-jaGezbfx9ZylmA6EBQY2TxqjfIHNhT8TXI6_KCL11Y=.d48ef20a-21c1-4486-ada6-4e1acf86a9ea@github.com>
Message-ID: 

On Wed, 7 Feb 2024 18:38:29 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 using 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.5-10x 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.
>> 
>> 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 the email-ping!
A really nice feature :)
I left some more requests, comments and questions.

src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 1582:

> 1580:   if (elem_bt == T_SHORT) {
> 1581:     Label case0, case1, case2, case3;
> 1582:     Label *larr[] = {&case0, &case1, &case2, &case3};

Suggestion:

    Label* larr[] = {&case0, &case1, &case2, &case3};

src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 1584:

> 1582:     Label *larr[] = {&case0, &case1, &case2, &case3};
> 1583:     for (int i = 0; i < 4; i++) {
> 1584:       // dst[i] = mask ? src[index[i]] : 0

I like these comments a lot!
They would be even better if they had a more clear relation to the register names.

`dst[i] = mask[i+midx] ? src[idx_base[i]] : 0`
It would then be helpful to know the types of these arrays.
It seems that `idx_base` is an array with type int, right?

src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 1585:

> 1583:     for (int i = 0; i < 4; i++) {
> 1584:       // dst[i] = mask ? src[index[i]] : 0
> 1585:       btq(mask, midx);

Do I see it right, that `midx` selects what bit is selected? Why this name? Can we have something more descriptive?
I know it seems to be generally the style in the AD files to not have comments and use non-descriptive register names. But that really makes the code hard to read, I basically need to reverse-engineer everything, and figure out all invariants, preconditions, postconditions etc myself. That makes reviewing hard.
With so many register arguments: how am I supposed to know which registers have what meaning, which ones are modified, etc?

src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 1595:

> 1593:     assert(elem_bt == T_BYTE, "");
> 1594:     Label case0, case1, case2, case3, case4, case5, case6, case7;
> 1595:     Label *larr[] = {&case0, &case1, &case2, &case3,

Suggestion:

    Label* larr[] = {&case0, &case1, &case2, &case3,

src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 1604:

> 1602:       pinsrb(dst, Address(base, rtmp), i);
> 1603:       bind(*larr[i]);
> 1604:       incq(midx);

I don't know much about labels. But why can they not be local to the scope of the loop?

src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 1624:

> 1622:       jccb(Assembler::carryClear, *larr[i]);
> 1623:       movl(rtmp, Address(idx_base, i * 4));
> 1624:       addl(rtmp, offset);

This is really the only line that is additional to the code in `vgather8b_masked`. Why not just put it under a `bool has_offset` flag, and then you ran just reuse this code here from `vgather8b_masked`, and reduce code duplication?

src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 1694:

> 1692:  * Gather loop first packs 4 short / 8 byte values from gather indices
> 1693:  * into quadword lane and then permutes quadword lane into appropriate
> 1694:  * location in destination vector. Following pseudo code describes the

I found this a bit confusing. Would this be another way of saying this:
`We divide the gather operations into quadwords of 8 bytes (or 4 shorts). Each quadword is gathered using the vgather8b instruction. We combine the quadwords into the destination register via OR and shifting (i.e. rotating / permuting) the destination register, until every quadword is in the desired location.`

src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 1695:

> 1693:  * into quadword lane and then permutes quadword lane into appropriate
> 1694:  * location in destination vector. Following pseudo code describes the
> 1695:  * algorithm in detail:-

Suggestion:

 * algorithm in detail:

src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 1707:

> 1705:  *
> 1706:  * With each iteration, doubleword permute indices (0,1) corresponding
> 1707:  * to assembled quadword gets right shifted by two lane position.

Suggestion:

 * With each iteration, doubleword permute indices (0,1) corresponding to gathered
 * quadword gets right shifted by two lane position (i.e. 8 bytes).

src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 1716:

> 1714:                                         XMMRegister xtmp3, Register rtmp,
> 1715:                                         Register midx, Register length,
> 1716:                                         int vector_len, int vlen_enc) {

I would like to see more descriptive names, where I don't have to reverse-engineer their meaning.
What are the pre/post-conditions on `midx`?

src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 1723:

> 1721:   vpxor(dst, dst, dst, vlen_enc);
> 1722:   vallones(xtmp2, vlen_enc);
> 1723:   vpsubd(xtmp2, xtmp1, xtmp2 ,vlen_enc);

Suggestion:

  vpsubd(xtmp2, xtmp1, xtmp2, vlen_enc);

src/hotspot/cpu/x86/x86.ad line 4111:

> 4109: %}
> 4110: 
> 4111: instruct vgather_subwordLE8B(vec dst, memory mem, rRegP idx, immI_0 offset, rRegP tmp, rRegI rtmp) %{

Suggestion:

instruct vgather_subwordLE8B(vec dst, memory mem, rRegP base_index, immI_0 offset, rRegP tmp, rRegI rtmp) %{

For consistency

src/hotspot/cpu/x86/x86.ad line 4120:

> 4118:     BasicType elem_bt = Matcher::vector_element_basic_type(this);
> 4119:     __ lea($tmp$$Register, $mem$$Address);
> 4120:     __ vgather8b(elem_bt, $dst$$XMMRegister, $tmp$$Register, $idx$$Register, $rtmp$$Register, vlen_enc);

The `LE8B` and `Matcher::vector_length_in_bytes(n) <= 8` suggest we can perform this with 4 bytes as well.
Is that correct?
Would that not lead to issues, when we are then reading `base_index` at bytes 4...7, which possibly have garbage, and then use that to gather?
Do we have tests for that?

src/hotspot/cpu/x86/x86.ad line 4143:

> 4141: %}
> 4142: 
> 4143: instruct vgather_subwordLE8B_off(vec dst, memory mem, rRegP idx, rRegI offset, rRegP tmp, rRegI rtmp, rFlagsReg cr) %{

Suggestion:

instruct vgather_subwordLE8B_offset(vec dst, memory mem, rRegP idx, rRegI offset, rRegP tmp, rRegI rtmp, rFlagsReg cr) %{

src/hotspot/cpu/x86/x86.ad line 4147:

> 4145:   match(Set dst (LoadVectorGather mem (Binary idx offset)));
> 4146:   effect(TEMP tmp, TEMP rtmp, KILL cr);
> 4147:   format %{ "vector_gatherLE8 $dst, $mem, $idx, $offset\t! using $tmp and $rtmp as TEMP" %}

Suggestion:

  format %{ "vector_gatherLE8_offset $dst, $mem, $idx, $offset\t! using $tmp and $rtmp as TEMP" %}

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ByteVector.java line 3071:

> 3069:                 .fromArray(lsp, indexMap, mapOffset + i)
> 3070:                 .add(offset);
> 3071:             vix = VectorIntrinsics.checkIndex(vix, a.length);

are you using the `vix` after this assignment?

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ShortVector.java line 3809:

> 3807: 
> 3808:         // Check indices are within array bounds.
> 3809:         // FIXME: Check index under mask controlling.

Did you mean to leave a FIXME? If so, please reference a JIRA bug number where you intend to fix it.

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

Changes requested by epeter (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16354#pullrequestreview-1889647285
PR Review Comment: https://git.openjdk.org/jdk/pull/16354#discussion_r1495342140
PR Review Comment: https://git.openjdk.org/jdk/pull/16354#discussion_r1495355989
PR Review Comment: https://git.openjdk.org/jdk/pull/16354#discussion_r1495351192
PR Review Comment: https://git.openjdk.org/jdk/pull/16354#discussion_r1495342349
PR Review Comment: https://git.openjdk.org/jdk/pull/16354#discussion_r1495341931
PR Review Comment: https://git.openjdk.org/jdk/pull/16354#discussion_r1495361896
PR Review Comment: https://git.openjdk.org/jdk/pull/16354#discussion_r1495400579
PR Review Comment: https://git.openjdk.org/jdk/pull/16354#discussion_r1495366111
PR Review Comment: https://git.openjdk.org/jdk/pull/16354#discussion_r1495405212
PR Review Comment: https://git.openjdk.org/jdk/pull/16354#discussion_r1495414923
PR Review Comment: https://git.openjdk.org/jdk/pull/16354#discussion_r1495415770
PR Review Comment: https://git.openjdk.org/jdk/pull/16354#discussion_r1495418305
PR Review Comment: https://git.openjdk.org/jdk/pull/16354#discussion_r1495424410
PR Review Comment: https://git.openjdk.org/jdk/pull/16354#discussion_r1495426048
PR Review Comment: https://git.openjdk.org/jdk/pull/16354#discussion_r1495426552
PR Review Comment: https://git.openjdk.org/jdk/pull/16354#discussion_r1495434432
PR Review Comment: https://git.openjdk.org/jdk/pull/16354#discussion_r1495440107

From epeter at openjdk.org  Tue Feb 20 08:53:03 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Tue, 20 Feb 2024 08:53:03 GMT
Subject: RFR: 8318650: Optimized subword gather for x86 targets. [v13]
In-Reply-To: 
References: 
 <-jaGezbfx9ZylmA6EBQY2TxqjfIHNhT8TXI6_KCL11Y=.d48ef20a-21c1-4486-ada6-4e1acf86a9ea@github.com>
 
Message-ID: 

On Tue, 20 Feb 2024 07:35:28 GMT, Emanuel Peter  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 1584:
> 
>> 1582:     Label *larr[] = {&case0, &case1, &case2, &case3};
>> 1583:     for (int i = 0; i < 4; i++) {
>> 1584:       // dst[i] = mask ? src[index[i]] : 0
> 
> I like these comments a lot!
> They would be even better if they had a more clear relation to the register names.
> 
> `dst[i] = mask[i+midx] ? src[idx_base[i]] : 0`
> It would then be helpful to know the types of these arrays.
> It seems that `idx_base` is an array with type int, right?

Ah, and can we use `base_index`? Otherwise we have an inconsistency with `index` vs `idx`.

> src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 1624:
> 
>> 1622:       jccb(Assembler::carryClear, *larr[i]);
>> 1623:       movl(rtmp, Address(idx_base, i * 4));
>> 1624:       addl(rtmp, offset);
> 
> This is really the only line that is additional to the code in `vgather8b_masked`. Why not just put it under a `bool has_offset` flag, and then you ran just reuse this code here from `vgather8b_masked`, and reduce code duplication?

Ok, you basically are implementing the cross-product of gather with `offset` and `mask`.
Why not have 2 flags then, and a bit more comments to explain?

> src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 1716:
> 
>> 1714:                                         XMMRegister xtmp3, Register rtmp,
>> 1715:                                         Register midx, Register length,
>> 1716:                                         int vector_len, int vlen_enc) {
> 
> I would like to see more descriptive names, where I don't have to reverse-engineer their meaning.
> What are the pre/post-conditions on `midx`?

I'll rereview after

> src/hotspot/cpu/x86/x86.ad line 4143:
> 
>> 4141: %}
>> 4142: 
>> 4143: instruct vgather_subwordLE8B_off(vec dst, memory mem, rRegP idx, rRegI offset, rRegP tmp, rRegI rtmp, rFlagsReg cr) %{
> 
> Suggestion:
> 
> instruct vgather_subwordLE8B_offset(vec dst, memory mem, rRegP idx, rRegI offset, rRegP tmp, rRegI rtmp, rFlagsReg cr) %{

There are more instances

> src/hotspot/cpu/x86/x86.ad line 4147:
> 
>> 4145:   match(Set dst (LoadVectorGather mem (Binary idx offset)));
>> 4146:   effect(TEMP tmp, TEMP rtmp, KILL cr);
>> 4147:   format %{ "vector_gatherLE8 $dst, $mem, $idx, $offset\t! using $tmp and $rtmp as TEMP" %}
> 
> Suggestion:
> 
>   format %{ "vector_gatherLE8_offset $dst, $mem, $idx, $offset\t! using $tmp and $rtmp as TEMP" %}

There may be more instances

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16354#discussion_r1495386503
PR Review Comment: https://git.openjdk.org/jdk/pull/16354#discussion_r1495364719
PR Review Comment: https://git.openjdk.org/jdk/pull/16354#discussion_r1495416109
PR Review Comment: https://git.openjdk.org/jdk/pull/16354#discussion_r1495426766
PR Review Comment: https://git.openjdk.org/jdk/pull/16354#discussion_r1495426957

From epeter at openjdk.org  Tue Feb 20 08:55:56 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Tue, 20 Feb 2024 08:55:56 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: 

On Sun, 17 Dec 2023 17:51:37 GMT, Jatin Bhateja  wrote:

>> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix incorrect comment
>
> Refined implementation using integral gather operation for AVX512 targets. As per Intel Optimization manual section 4.8.1.6 gather are micro coded atom with 50+ cycles latency, existing hybrid algorithm is performant for Intel Atom family CPUs and with runtime flag UseAVX=2.

@jatin-bhateja I'm not sure I can review the Vector API (java) code changes. It would be better if someone more familiar had a look as well.

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

PR Comment: https://git.openjdk.org/jdk/pull/16354#issuecomment-1953741437

From clanger at openjdk.org  Tue Feb 20 09:45:22 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Tue, 20 Feb 2024 09:45:22 GMT
Subject: RFR: 8325579: Inconsistent behavior in
 com.sun.jndi.ldap.Connection::createSocket [v6]
In-Reply-To: 
References: 
Message-ID: 

> During analysing a customer case I figured out that we have an inconsistency between documentation and actual behavior in class com.sun.jndi.ldap.Connection. The [method documentation of com.sun.jndi.ldap.Connection::createSocket](https://github.com/openjdk/jdk/blob/3ebe6c192a5dd5cc46ae2d263713c9ff38cd46bb/src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java#L281) states: "If a timeout is supplied but unconnected sockets are not supported then the timeout is ignored and a connected socket is created."
> 
> This, however does not happen. If a SocketFactory would not support unconnected sockets, it would likely throw a SocketException in [SocketFactory::createSocket()](https://github.com/openjdk/jdk/blob/6303c0e7136436a2d3cb6043b88edf788c0067cc/src/java.base/share/classes/javax/net/SocketFactory.java#L123). And since [the code](https://github.com/openjdk/jdk/blob/3ebe6c192a5dd5cc46ae2d263713c9ff38cd46bb/src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java#L336) does not check for this behavior, a connection with timeout value through a SocketFactory that does not support unconnected sockets would simply fail with an IOException.
> 
> So we should either make the code adhere to what is documented or adapt the documentation to the actual behavior.
> 
> I hereby try to fix the connect coding. Alternatively, we could also adapt the description - I have no strong opinion. What do the experts suggest?

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

 - Review feedback
 - Rename back to LdapSSLHandshakeFailureTest to ease reviewing
 - Merge branch 'master' into JDK-8325579
 - Typo
 - Merge branch 'master' into JDK-8325579
 - Rename test and refine comment
 - Enhance test
 - JDK-8325579

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17797/files
  - new: https://git.openjdk.org/jdk/pull/17797/files/d8d1d6db..ec6579d2

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

  Stats: 5175 lines in 157 files changed: 1842 ins; 1842 del; 1491 mod
  Patch: https://git.openjdk.org/jdk/pull/17797.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17797/head:pull/17797

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

From jbhateja at openjdk.org  Tue Feb 20 09:51:57 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 20 Feb 2024 09:51:57 GMT
Subject: RFR: JDK-8320448 Accelerate IndexOf using AVX2 [v8]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Wed, 14 Feb 2024 14:31:03 GMT, Scott Gibbons  wrote:

>> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove gcc lib fn; reduce spacial cases to 10 from 32
>
> Thank you all for the reviews.  I have been asked to simplify this code to facilitate easier review, and to remove the gcc library code I used for memcmp.  We also discovered that special-casing up to 31 bytes of needle was not necessary to get the performance gain.  I will be commenting the code and fixing the single build failure soon.

Hi @asgibbons ,

I am getting following error with slowdebug build on Meteor Lake system.


ERROR: Build failed for target 'images' in configuration 'linux-x86_64-server-slowdebug' (exit code 2) 

=== Output from failing command(s) repeated here ===
* For target buildtools_create_symbols_javac__the.COMPILE_CREATE_SYMBOLS_batch:
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (/home/jatinbha/sandboxes/jdk-reviews/jdk/src/hotspot/share/asm/assembler.hpp:169), pid=237140, tid=237235
#  assert(is_bound() || is_unused()) failed: Label was never bound to a location, but it was used as a jmp target
#
# JRE version: OpenJDK Runtime Environment (23.0) (slowdebug build 23-internal-adhoc.sdp.jdk)
# Java VM: OpenJDK 64-Bit Server VM (slowdebug 23-internal-adhoc.sdp.jdk, mixed mode, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
# Problematic frame:
# V  [libjvm.so+0x4c9e3e]  Label::~Label()+0x5c
#
# Core dump will be written. Default location: Core dumps may be processed with "/usr/share/apport/apport -p%p -s%s -c%c -d%d -P%P -u%u -g%g -- %E" (or dumping to /home/jatinbha/sandboxes/jdk-reviews/jdk/make/core.237140)
#
# An error report file with more information is saved as:
# /home/jatinbha/sandboxes/jdk-reviews/jdk/make/hs_err_pid237140.log
   ... (rest of output omitted)

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

PR Comment: https://git.openjdk.org/jdk/pull/16753#issuecomment-1953840322

From eirbjo at openjdk.org  Tue Feb 20 10:12:09 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Tue, 20 Feb 2024 10:12:09 GMT
Subject: RFR: 8326096: Deprecate getTotalIn,
 getTotalOut methods of java.util.zip.Inflater, java.util.zip.Deflater [v3]
In-Reply-To: 
References: 
Message-ID: <92sE1BjR7Y3aj2zK5j5UwZFjeXNJs9LmRlUCG-Mha64=.0e9f5e87-8903-4bf8-8912-579f9d257d74@github.com>

> Please review this PR which proposes that we officially deprecate the following four methods in the `java.util.zip` package:
> 
> * `Inflater.getTotalIn()`
> * `Inflater.getTotalOut()`
> * `Deflater.getTotalIn()`
> * `Deflater.getTotalOut()`
> 
> Since these legacy methods return `int`, they cannot safely return the number of bytes processed without the risk of losing information  about the magnitude or even sign of the returned value.
> 
> The corresponding methods `getBytesRead()` and `getBytesWritten()` methods introduced in Java 5 return `long`, and should be used instead when obtaining this information. 
> 
> Unrelated to the deprecation itself, the documentation currently does not specify what these methods are expected to return when the number of processed bytes is higher than `Integer.MAX_VALUE`. This PR aims to clarify this in the API specification.
> 
> Initally, this PR handles only `Inflater.getTotalIn()`. The other three methods will be updated once the wordsmithing for this method stabilizes.

Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:

  Add since="23" to @Deprecated

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17919/files
  - new: https://git.openjdk.org/jdk/pull/17919/files/752230d4..61e2e40d

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

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

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

From eirbjo at openjdk.org  Tue Feb 20 10:12:09 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Tue, 20 Feb 2024 10:12:09 GMT
Subject: RFR: 8326096: Deprecate getTotalIn,
 getTotalOut methods of java.util.zip.Inflater, java.util.zip.Deflater [v2]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Tue, 20 Feb 2024 07:12:41 GMT, Jaikiran Pai  wrote:

>> Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix {@link #getBytesRead}
>
> src/java.base/share/classes/java/util/zip/Inflater.java line 651:
> 
>> 649:      * the 32 highest order bits
>> 650:      */
>> 651:     @Deprecated
> 
> Hello Eirik, the `Deprecated` annotation allows for a `since` property. I think we should use it here `@Deprecated(since=23)`.

Fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17919#discussion_r1495557824

From clanger at openjdk.org  Tue Feb 20 10:27:55 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Tue, 20 Feb 2024 10:27:55 GMT
Subject: RFR: 8325579: Inconsistent behavior in
 com.sun.jndi.ldap.Connection::createSocket [v6]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 20 Feb 2024 09:45:22 GMT, Christoph Langer  wrote:

>> During analysing a customer case I figured out that we have an inconsistency between documentation and actual behavior in class com.sun.jndi.ldap.Connection. The [method documentation of com.sun.jndi.ldap.Connection::createSocket](https://github.com/openjdk/jdk/blob/3ebe6c192a5dd5cc46ae2d263713c9ff38cd46bb/src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java#L281) states: "If a timeout is supplied but unconnected sockets are not supported then the timeout is ignored and a connected socket is created."
>> 
>> This, however does not happen. If a SocketFactory would not support unconnected sockets, it would likely throw a SocketException in [SocketFactory::createSocket()](https://github.com/openjdk/jdk/blob/6303c0e7136436a2d3cb6043b88edf788c0067cc/src/java.base/share/classes/javax/net/SocketFactory.java#L123). And since [the code](https://github.com/openjdk/jdk/blob/3ebe6c192a5dd5cc46ae2d263713c9ff38cd46bb/src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java#L336) does not check for this behavior, a connection with timeout value through a SocketFactory that does not support unconnected sockets would simply fail with an IOException.
>> 
>> So we should either make the code adhere to what is documented or adapt the documentation to the actual behavior.
>> 
>> I hereby try to fix the connect coding. Alternatively, we could also adapt the description - I have no strong opinion. What do the experts suggest?
>
> Christoph Langer has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:
> 
>  - Review feedback
>  - Rename back to LdapSSLHandshakeFailureTest to ease reviewing
>  - Merge branch 'master' into JDK-8325579
>  - Typo
>  - Merge branch 'master' into JDK-8325579
>  - Rename test and refine comment
>  - Enhance test
>  - JDK-8325579

I made some updates and addressed the review comments. I reverted the renaming of the test for the sake of reviewing. While I still think LdapSSLHandshakeTest is a better, more generic name for the test's purpose, we could change its name in a separate change.

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

PR Comment: https://git.openjdk.org/jdk/pull/17797#issuecomment-1953904252

From clanger at openjdk.org  Tue Feb 20 10:27:57 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Tue, 20 Feb 2024 10:27:57 GMT
Subject: RFR: 8325579: Inconsistent behavior in
 com.sun.jndi.ldap.Connection::createSocket [v5]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Mon, 19 Feb 2024 16:57:23 GMT, Aleksei Efimov  wrote:

>> Christoph Langer has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
>> 
>>  - Typo
>>  - Merge branch 'master' into JDK-8325579
>>  - Rename test and refine comment
>>  - Enhance test
>>  - JDK-8325579
>
> src/java.naming/share/classes/module-info.java line 51:
> 
>> 49:  *         network times out.
>> 50:  *         
     If a custom socket factory is provided via property
>> 51:  *         {@code java.naming.ldap.factory.socket} and unconnected sockets
> 
> Suggestion:
> 
>  *         
     If a custom socket factory is provided via  {@code java.naming.ldap.factory.socket}  environment 
>  *        property and unconnected sockets

Addressed.

> src/java.naming/share/classes/module-info.java line 51:
> 
>> 49:  *         network times out.
>> 50:  *         
     If a custom socket factory is provided via property
>> 51:  *         {@code java.naming.ldap.factory.socket} and unconnected sockets
> 
> Since we're referencing socket factory env property, maybe we can also document it here. Something like: 
> 
> 
  • {@code java.naming.ldap.factory.socket}:
>     
    The value of this environment property specifies the fully
>      qualified class name of the socket factory used by the LDAP provider.
>      This class must implement the javax.net.SocketFactory abstract class.
>      By default the environment property is not set.
> 
    • 

Added.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17797#discussion_r1495580384
PR Review Comment: https://git.openjdk.org/jdk/pull/17797#discussion_r1495580620

From clanger at openjdk.org  Tue Feb 20 10:27:58 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Tue, 20 Feb 2024 10:27:58 GMT
Subject: RFR: 8325579: Inconsistent behavior in
 com.sun.jndi.ldap.Connection::createSocket [v5]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Fri, 16 Feb 2024 16:39:33 GMT, Daniel Fuchs  wrote:

>> Christoph Langer has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
>> 
>>  - Typo
>>  - Merge branch 'master' into JDK-8325579
>>  - Rename test and refine comment
>>  - Enhance test
>>  - JDK-8325579
>
> test/jdk/com/sun/jndi/ldap/LdapSSLHandshakeTest.java line 62:
> 
>> 60:  * whether the socket is closed after closing the Context.
>> 61:  *
>> 62:  * @run main/othervm --add-opens java.naming/javax.naming=ALL-UNNAMED --add-opens java.naming/com.sun.jndi.ldap=ALL-UNNAMED
> 
> sigh... git handles the renaming of this test file as a deleted file + a new file which makes it hard to review the changes.
> 
> The --add-opens directive are very strange here. I suggest removing them and replacing them with a single `@modules` directive:
> 
> 
> @modules java.naming/javax.naming:+open
>                   java.naming/com.sun.jndi.ldap:+open

Good suggestion. Done.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17797#discussion_r1495579467

From clanger at openjdk.org  Tue Feb 20 10:27:59 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Tue, 20 Feb 2024 10:27:59 GMT
Subject: RFR: 8325579: Inconsistent behavior in
 com.sun.jndi.ldap.Connection::createSocket [v5]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Mon, 19 Feb 2024 13:17:48 GMT, Goetz Lindenmaier  wrote:

>> Christoph Langer has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
>> 
>>  - Typo
>>  - Merge branch 'master' into JDK-8325579
>>  - Rename test and refine comment
>>  - Enhance test
>>  - JDK-8325579
>
> test/jdk/com/sun/jndi/ldap/LdapSSLHandshakeTest.java line 224:
> 
>> 222: 
>> 223:         public CustomSocket(String s, int timeout) throws IOException {
>> 224:             super(s, timeout);
> 
> The argument should be called "port" not timeout.

Correct.

> test/jdk/com/sun/jndi/ldap/LdapSSLHandshakeTest.java line 246:
> 
>> 244: 
>> 245:         @Override
>> 246:         public Socket createSocket(String s, int timeout) throws IOException {
> 
> The argument should be "int port" instead of timeout.

Right.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17797#discussion_r1495579995
PR Review Comment: https://git.openjdk.org/jdk/pull/17797#discussion_r1495579746

From clanger at openjdk.org  Tue Feb 20 10:30:55 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Tue, 20 Feb 2024 10:30:55 GMT
Subject: RFR: 8325579: Inconsistent behavior in
 com.sun.jndi.ldap.Connection::createSocket [v5]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Mon, 19 Feb 2024 16:46:18 GMT, Aleksei Efimov  wrote:

> Currently, it is hard to distinguish what part of the test responsible for [JDK-8314063](https://bugs.openjdk.org/browse/JDK-8314063) testing, and which part is for [JDK-8325579](https://bugs.openjdk.org/browse/JDK-8325579). I would prefer to add a new test for the current fix instead: that could be done as additional test mode, OR even better to add a completely new test. 

Hm, I think the test was overpurposed already. Creating another test file with duplicating code does not sound too good IMHO. Maybe it is acceptable without the renaming?

Another question: Do we need a CSR/Release note as there is some behavioral change involved (although it should always have been like with this change)?

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

PR Comment: https://git.openjdk.org/jdk/pull/17797#issuecomment-1953911292

From eirbjo at openjdk.org  Tue Feb 20 10:44:54 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Tue, 20 Feb 2024 10:44:54 GMT
Subject: RFR: 8326096: Deprecate getTotalIn,
 getTotalOut methods of java.util.zip.Inflater, java.util.zip.Deflater [v2]
In-Reply-To: 
References: 
 
 
Message-ID: <-OsIJpQYdh16dLpKfEDxdEdIZe2-MvbTSRz4pcspgNg=.dbb96d2a-2e05-4899-be2c-4c42da07c60e@github.com>

On Tue, 20 Feb 2024 07:13:41 GMT, Jaikiran Pai  wrote:

>> Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix {@link #getBytesRead}
>
> src/java.base/share/classes/java/util/zip/Inflater.java line 642:
> 
>> 640:      * the 32 highest order bits, as if the {@link #getBytesRead()}
>> 641:      * method was called followed by a narrowing conversion from long
>> 642:      * to int.
> 
> I think we should leave this part of the javadoc comment as-is and not change it.

@jaikiran 

This PR has two (somewhat independent) goals:

1) Officially deprecate the methods by adding `@Deprecated` annotations and Javadoc tags, and cleaning up the deprecation notice including the recommendation to use getBytes[Read|Written].

2) Clarify what the method actually returns when the number of processed bytes is larger than `Integer.MAX_VALUE`. This is currently unspecified.

The need to clarify the return value was raised by @AlanBateman, here: 

https://mail.openjdk.org/pipermail/core-libs-dev/2024-February/119334.html


I'm surprised the spec for these methods wasn't clarified 
in Java 5 when the new methods to return long were added. Right not, 
it's not clear from the spec how the older methods behave when the 
number of bytes is greater than Integer.MAX_VALUE.


(I'll add that it isn't even possible for the caller to know whether the number of processed bytes was in fact larger than `Integer.MAX_VALUE` without some form of external heuristics.)

I added the verbiage in the leading sentence specificallty to address this "clarify the return value" concern. If we drop it like you suggest, I think that would leave return value when the number of bytes processed is larger than Integer.MAX_VALUE unspecified.

If we decide to leave the leading sentence as-is, then it would be misleading so I think it should be followed by a sentence with some form of clarification. 

Perhaps it would be better to specify the return value by the implementation? So adding a `{@snippet}` or similar showing `(int)getBytesRead()`? I'm guessing there should be some prior art to take inspiration from here?

@AlanBateman Do you have input on how to specify the return value of this method concisely?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17919#discussion_r1495602576

From viktor.klang at oracle.com  Tue Feb 20 11:06:20 2024
From: viktor.klang at oracle.com (Viktor Klang)
Date: Tue, 20 Feb 2024 11:06:20 +0000
Subject: [External] : Re: OpenJDK 17: Loitering
 AbstractQueuedSynchronizer$ConditionNode instances (also on latest master
 branch) [JDK-8325754]
In-Reply-To: 
References: <591b0e9c-1d7a-405d-ace1-bd94f8dbbe22@gmx.net>
 
 
 <64bc8cbd-78f4-44f4-90ae-80466c563281@gmx.net>
 <6d3b62cb-15f4-471c-97b6-b72977223f91@gmx.net>
 <59c3b1bc-fd60-4215-b8f7-96421f1881e2@gmail.com>
 <127f2696-5f6d-4bab-b45e-e7597f267add@gmx.net>
 
 
Message-ID: 

Hi Frank,

Thanks for the input?currently I'm contemplating whether it is not the most efficient to perform the nulling out of the nextWaiter in the else-branch of the update to firstWaiter and lastWaiter as such:


private void doSignal(ConditionNode first, boolean all) {
    while (first != null) {
        ConditionNode next = first.nextWaiter;

        if ((firstWaiter = next) == null)
            lastWaiter = null;
        else
            first.nextWaiter = null; // GC assistance

        if ((first.getAndUnsetStatus(COND) & COND) != 0) {
            enqueue(first);
            if (!all)
                break;
        }

        first = next;
    }
}

The reason for this is that we're already branching, and the update to `nextWaiter` is a plain write, which should be made visible earlier by the update to the status succeeding it.

Updating nextWaiter after enqueue means that `first` has its COND cleared *before*, which means that it should be eligible to be cleared by await:ers in unlinkCancelledWaiters anyway.

I'll let Doug weigh in before I settle on anything.

Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: Frank Kretschmer 
Sent: Monday, 19 February 2024 18:07
To: Viktor Klang ; Jaikiran Pai ; Java Core Libs 
Subject: Re: [External] : Re: OpenJDK 17: Loitering AbstractQueuedSynchronizer$ConditionNode instances (also on latest master branch) [JDK-8325754]


Hi Viktor,


may I add one option to your evaluation?


@@ -1506,14 +1506,15 @@ public ConditionObject() { }
         private void doSignal(ConditionNode first, boolean all) {
             while (first != null) {
                 ConditionNode next = first.nextWaiter;
                 if ((firstWaiter = next) == null)
                     lastWaiter = null;
                 if ((first.getAndUnsetStatus(COND) & COND) != 0) {
                     enqueue(first);
+                    first.nextWaiter = null; // GC-friendly
                     if (!all)
                         break;
                 }
                 first = next;
             }
         }


(AbstractQueuedSynchronizer line numbers as in gitlab current master)


This variant takes care about race conditions on cancellation (unlinkCancelledWaiters() needs 'nextWaiter'), as thanks to "getAndUnsetStatus(COND) & COND) != 0" only alternatively/once executed.


So this option is definitively better / more robust than my first one ?



Best regards

Frank




Am 19.02.2024 um 12:41 schrieb Viktor Klang:
Hi Frank,

We'll see what the option are. ?

Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: Frank Kretschmer 
Sent: Sunday, 18 February 2024 15:36
To: Jaikiran Pai ; Viktor Klang ; Java Core Libs 
Subject: [External] : Re: OpenJDK 17: Loitering AbstractQueuedSynchronizer$ConditionNode instances (also on latest master branch) [JDK-8325754]


Hello Jaikiran, hello Viktor,

in the meantime, I've seen that the JBS issue has been assigned to Viktor Klang. @Viktor: I totally agree with your comment that the proposed solution may not be the best possible option, and that further explorations were required.

My intention to propose unlinking ConditionNodes by null'ing their ?nextWaiter? reference was just to verify that the chain of ?nextWaiter? references leads to the observed garbage collection behavior, and that the GC is able to collect the nodes during minor / young collections if the references are cleaned in time.

I checked also a few other variants (null'ing the ?nextWaiter? reference at the end of all await...() methods in ConditionObject, or in/just before enqueue()), but at the end of the day, I felt that null'ing it in doSignal() explains what I want to show the easiest. On the other hand, the other options could be better in order to avoid race conditions with canceled nodes.

For sure there are many other options that I am not aware of, so please take my proposal just as an example.

Looking forward to your explorations.

Best regards

Frank


Am 14.02.2024 um 07:43 schrieb Jaikiran Pai:

Hello Frank,

I see that a JBS issue has been created for this same issue https://bugs.openjdk.org/browse/JDK-8325754.

I don't have enough knowledge of this area and haven't reviewed this part of the code in detail to see if there are any obvious issues with what you are proposing as a solution. Since there's now a JBS issue created for this and you seem to have done enough investigation and work on this one already, would you be interested in creating a pull request against the https://github.com/openjdk/jdk repo with this proposed change? (you'll have to sign a OCA). This guide https://openjdk.org/guide/ should help you get started. It can then go through the usual reviews that a bug fix/enhancement goes through.

-Jaikiran

On 11/02/24 7:27 pm, Frank Kretschmer wrote:

Hello Core-Libs-Dev team,

may I ask you about your opinion about a tiny one-liner change in AbstractQueuedSynchronizer, just as a suggestion how to make ConditionObjects / Nodes even more garbage collector friendly?

Checked out https://github.com/openjdk/jdk/blob/jdk-17%2B35/src/java.base/share/classes/java/util/concurrent/locks/AbstractQueuedSynchronizer.java (the same on master branch with different line numbers near to line 1506):

@@ -1431,40 +1431,41 @@ public abstract class AbstractQueuedSynchronizer
     public class ConditionObject implements Condition, java.io.Serializable {
         // ...
         private void doSignal(ConditionNode first, boolean all) {
             while (first != null) {
                 ConditionNode next = first.nextWaiter;
+                first.nextWaiter = null;  // GC-friendly: avoid chains of dead ConditionNodes
                 if ((firstWaiter = next) == null)
                     lastWaiter = null;
                 if ((first.getAndUnsetStatus(COND) & COND) != 0) {
                     enqueue(first);
                 // ...

By setting the nextWaiter to null of the first condition node, which is transferred from the condition queue to the sync queue in this method, long chains of ConditionNode instances can be avoided. Though a single ConditionNode is small, these chains of ConditionNodes become very huge on the heap (I've seen more than 1GB on an application server over time) if at least one node was promoted to the old generation for any reason. They survive minor collections and are cleaned up only on mixed / full collections, and thus put unnecessary pressure on G1 garbage collector.

The same change could also be applied to 'AbstractQueuedLongSynchronizer'.

I know premature optimization is the root of all evil, on the other hand I could image that many applications benefit from GC-friendly ConditionObjects, since they are frequently used in various classes like PriorityBlockingQueue / LinkedBlockingDeque / LinkedBlockingQueue, the latter one as default work queue for executor services like fixed thread pools for processing asynchronous tasks.

Thank you all for your time and help!

Best regards
Frank

Am 08.02.2024 um 12:15 schrieb Frank Kretschmer:
Hello Thomas, hello Core-Libs-Dev,

thank you for cc'ing my email. In deed my idea/suggestion is to modify
the AbstractQueuedSynchronizer$ConditionNode handling in such a way that
it gets unlinked from the chain of condition nodes if it is not needed
any more (it might be the "nextWaiter" node), in order to be more
GC-friendly.

@core-libs-dev: I've just attached the ?G1LoiteringConditionNodes? demo
class and "gc.log" again so that you can have a look if you like.

Best regards

Frank


Am 08.02.2024 um 11:04 schrieb Thomas Schatzl:
Hi,

  since this looks like a suggestion for a change to the libraries
similar to the mentioned JDK-6805775, and not actually GC, cc'ing the
core-libs-dev mailing list.

Hth,
  Thomas

On 07.02.24 15:20, Frank Kretschmer wrote:
Hi Java GC-experts,

I'm facing an interesting G1 garbage collector observation in OpenJDK
17.0.9+9, which I would like to share with you.

My application runs many asynchronous tasks in a fixed thread pool,
utilizing its standard LinkedBlockingQueue. Usually, it generates just a
little garbage, but from time to time, I observed that the survivor
spaces grow unexpectedly, and minor collection times increase.

This being the case, many
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionNode
instances can be found on the heap. In fact, the whole heap (rank 1 as
shown in jmap) was filled up with ConditionNode instances after a while.

After some tests, I figured out that G1 seems to be able to collect
?dead? ConditionNode instances during minor collections only if no
formerly alive ConditionNode instances were promoted to the old
generation and died there.

To illustrate that, I've attached a ?G1LoiteringConditionNodes? class
that can be run for demo purposes, e.g. under Linux with OpenJDK
17.0.9+9 (VM options see comments within the class), and its gc-log
output. It shows that during the first two minutes, everything is fine,
but after a promotion to the old generation, survivors grow and minor
pause time increase from 3 to 10ms.

For me, it looks like an issue similar to
https://bugs.openjdk.org/browse/JDK-6805775 ?LinkedBlockingQueue Nodes
should unlink themselves before becoming garbage?, which was fixed in
OpenJDK 7.

What?s your opinion about that? Wouldn?t it be worth to enable G1 to
collect those AbstractQueuedSynchronizer$ConditionNode instances during
minor collections, as it is done for LinkedBlockingQueue Nodes?

Best regards

Frank

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

From eirbjo at openjdk.org  Tue Feb 20 11:28:08 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Tue, 20 Feb 2024 11:28:08 GMT
Subject: RFR: 8326096: Deprecate getTotalIn,
 getTotalOut methods of java.util.zip.Inflater, java.util.zip.Deflater [v4]
In-Reply-To: 
References: 
Message-ID: 

> Please review this PR which proposes that we officially deprecate the following four methods in the `java.util.zip` package:
> 
> * `Inflater.getTotalIn()`
> * `Inflater.getTotalOut()`
> * `Deflater.getTotalIn()`
> * `Deflater.getTotalOut()`
> 
> Since these legacy methods return `int`, they cannot safely return the number of bytes processed without the risk of losing information  about the magnitude or even sign of the returned value.
> 
> The corresponding methods `getBytesRead()` and `getBytesWritten()` methods introduced in Java 5 return `long`, and should be used instead when obtaining this information. 
> 
> Unrelated to the deprecation itself, the documentation currently does not specify what these methods are expected to return when the number of processed bytes is higher than `Integer.MAX_VALUE`. This PR aims to clarify this in the API specification.
> 
> Initally, this PR handles only `Inflater.getTotalIn()`. The other three methods will be updated once the wordsmithing for this method stabilizes.

Eirik Bj?rsn?s has updated the pull request incrementally with two additional commits since the last revision:

 - Use "greater than" instead of "larger than"
 - Leave first sentence as-is. Simplify the deprecation notice.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17919/files
  - new: https://git.openjdk.org/jdk/pull/17919/files/61e2e40d..86695619

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

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

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

From eirbjo at openjdk.org  Tue Feb 20 11:28:09 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Tue, 20 Feb 2024 11:28:09 GMT
Subject: RFR: 8326096: Deprecate getTotalIn,
 getTotalOut methods of java.util.zip.Inflater, java.util.zip.Deflater [v2]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Tue, 20 Feb 2024 07:17:53 GMT, Jaikiran Pai  wrote:

>> Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix {@link #getBytesRead}
>
> src/java.base/share/classes/java/util/zip/Inflater.java line 644:
> 
>> 642:      * to int.
>> 643:      *
>> 644:      * @deprecated This method cannot safely return a result without a potential
> 
> Perhaps word this as:
>>
>>This method cannot return the right value when the number of compressed bytes is greater than {@link Integer.MAX_VALUE}. It is recommended that the {@link #getBytesRead()} method be used instead.

I've simplified the `@deprecated` note to the following:

> This method cannot return the correct value when the number of compressed bytes is 
> greater than {@link Integer#MAX_VALUE}. Use {@link #getBytesRead()} instead.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17919#discussion_r1495657905

From eirbjo at openjdk.org  Tue Feb 20 13:31:53 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Tue, 20 Feb 2024 13:31:53 GMT
Subject: RFR: 8326096: Deprecate getTotalIn,
 getTotalOut methods of java.util.zip.Inflater, java.util.zip.Deflater [v4]
In-Reply-To: 
References: 
 
Message-ID: <3gTPWxpnS5VRTXK4P1gNtI5c-3BCL9OwR2FSHqZ9Nbo=.e0e49dc5-736a-4f7d-81a0-7a5e1fe9aa57@github.com>

On Tue, 20 Feb 2024 11:28:08 GMT, Eirik Bj?rsn?s  wrote:

>> Please review this PR which proposes that we officially deprecate the following four methods in the `java.util.zip` package:
>> 
>> * `Inflater.getTotalIn()`
>> * `Inflater.getTotalOut()`
>> * `Deflater.getTotalIn()`
>> * `Deflater.getTotalOut()`
>> 
>> Since these legacy methods return `int`, they cannot safely return the number of bytes processed without the risk of losing information  about the magnitude or even sign of the returned value.
>> 
>> The corresponding methods `getBytesRead()` and `getBytesWritten()` methods introduced in Java 5 return `long`, and should be used instead when obtaining this information. 
>> 
>> Unrelated to the deprecation itself, the documentation currently does not specify what these methods are expected to return when the number of processed bytes is higher than `Integer.MAX_VALUE`. This PR aims to clarify this in the API specification.
>> 
>> Initally, this PR handles only `Inflater.getTotalIn()`. The other three methods will be updated once the wordsmithing for this method stabilizes.
>
> Eirik Bj?rsn?s has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Use "greater than" instead of "larger than"
>  - Leave first sentence as-is. Simplify the deprecation notice.

Before any further wordsmithing of API changes, we should perhaps take one step back and try to reach consensus on the following question:

> Should these methods specify return values when the number of processed bytes exceed `Integer.MAX_VALUE`?

On one hand, it's in general good practise to specify the full range of possible return values for a method. 

On the other hand, one can argue that the value returned by the current implementation isn't particularly useful. Since the higher 32 bits are simply discarded, the loss of precision in magitude and even sign of the returned number makes it hard to see how the returned value can have any practical use for the caller. In fact, the caller cannot even distinguish a correct return value from an incorrect one. Basically, a return value from these methods cannot be trusted, regardless of the value.

Because of this, perhaps it is better to only specify the boundry conditions where a correct result cannot be returned?

I think we want to make it abundantly clear that the return values from calling these methods cannot be trusted. Meanwhile, we want to be concise and quickly lead the user down the correct path, which is to use the replacement methods instead.

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

PR Comment: https://git.openjdk.org/jdk/pull/17919#issuecomment-1954221075

From alanb at openjdk.org  Tue Feb 20 14:25:54 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 20 Feb 2024 14:25:54 GMT
Subject: RFR: 8326096: Deprecate getTotalIn,
 getTotalOut methods of java.util.zip.Inflater, java.util.zip.Deflater [v4]
In-Reply-To: <3gTPWxpnS5VRTXK4P1gNtI5c-3BCL9OwR2FSHqZ9Nbo=.e0e49dc5-736a-4f7d-81a0-7a5e1fe9aa57@github.com>
References: 
 
 <3gTPWxpnS5VRTXK4P1gNtI5c-3BCL9OwR2FSHqZ9Nbo=.e0e49dc5-736a-4f7d-81a0-7a5e1fe9aa57@github.com>
Message-ID: 

On Tue, 20 Feb 2024 13:29:28 GMT, Eirik Bj?rsn?s  wrote:

> Should these methods specify return values when the number of processed bytes exceed Integer.MAX_VALUE?

I think they should, otherwise it's not clear if the return value is clamped at Integer.MAX_VALUE. The wording can make it clear that the return value is useless in cases where the total exceeds Integer.MAX_VALUE.

(The wording that you have for the deprecation text looks fine).

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

PR Comment: https://git.openjdk.org/jdk/pull/17919#issuecomment-1954323561

From mbaesken at openjdk.org  Tue Feb 20 14:49:53 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 20 Feb 2024 14:49:53 GMT
Subject: RFR: JDK-8324930: java/lang/StringBuilder problem with concurrent
 jtreg runs
In-Reply-To: 
References: 
Message-ID: 

On Tue, 30 Jan 2024 09:08:28 GMT, Matthias Baesken  wrote:

> On some Windows machines we see sometimes OOM errors because of high resource (memory/swap) consumption. This is especially seen when the jtreg runs have higher concurrency. A solution is to put the java/lang/StringBuilder tests in the exclusiveAccess.dirs group so that they are not executed concurrently, which helps to mitigate the resource shortages.
> Of course this has the downside that on very large machines the concurrent execution is not done any more.

Hi [~[jaikiran] the exclude and match files sound promising, this could be helpful to achieve what we need/want .

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

PR Comment: https://git.openjdk.org/jdk/pull/17625#issuecomment-1954373348

From jkratochvil at openjdk.org  Tue Feb 20 15:15:09 2024
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Tue, 20 Feb 2024 15:15:09 GMT
Subject: RFR: 8322420: [Linux] cgroup v2: Limits in parent nested control
 groups are not detected [v2]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Wed, 31 Jan 2024 15:33:01 GMT, Jan Kratochvil  wrote:

>> It looks like this patch needs a bit more discussion. Generally, it would be good to have the functionality, but I'm unsure about the proposed implementation.
>> 
>> Walking the directory hierarchy (**and** interface files) on every call of `physical_memory()` (or `active_processor_count()` for CPU) seems concerning. Since it seems unlikely for cgroup interface file paths changing during runtime, walking the hierarchy for every look-up seems overkill. Note that the prime users of this feature are in-container use, where most runtimes have the limit settings at the leaf. A few more comments below:
>> 
>> - After this patch, AFAIUI for a cgroup path like `/foo/bar/baz/memory.max` the following files are being looked at for the memory limit (for example for the interface file `memory.max`):
>>   ```
>>    /foo/bar/baz/memory.max
>>    /foo/bar/memory.max
>>    /foo/memory.max
>>   ```
>>   This used to be just one file at the leaf, `/foo/bar/baz/memory.max` (prior this patch). So this change has an effect on file IO. `N` files per metric to look at where it used to be one file (i.e. constant). Note that switches like `UseDynamicNumberOfCompilerThreads` make this particularly worrying.  I wonder if it would be sufficient to "lock" into the cgroup path where the lowest  limits are set in the hierarchy and only use the interface files at that path of a specific controller. This would mean adjusting `CgroupsV2Subsystem` similar to `CgroupsV1Subsystem` to have unique controller paths (i.e. `cpu` and `memory` controller paths could potentially be different). But the code would already be mostly there for this. The idea would be to do the initial walk of the tree at JVM startup, and from then on, only look at the path with a limit set (if any) for subsequent calls. That is `controller->subsystem_path()` would return the correct path at runtime when initialization is done
 . Thoughts?
>> - There seems to be an inconsistency between cgroups v1 (no recursive look-up) and cgroups v2  (recursive look-up). Why? I think we should employ the same semantics to both  versions (and drop the hierarchical work-around - [JDK-8217338](https://bugs.openjdk.java.net/browse/JDK-8217338) - for cg v1).
>> - There also seems to be an inconsistency between metrics being iterated. `memory.max` and `memory.swap.max`  and `memory.swap.current` are being iterated, others, like CPU quotas (`cpu.max` or
>>   `cpu.weight`) not. Why? Both limits could potentially be one path up the hierarchy, meaning that cp...
>
>> Walking the directory hierarchy (**and** interface files) on every call of `physical_memory()` (or `active_processor_count()` for CPU) seems concerning.
> 
> I have therefore implemented a hierarchical `memory.stat` extension for cgroup2 which already exists for cgroup1 - if the patch is agreed upon I will submit it to Linux kernel: [cgroup2-hierarchical_memory_limit.patch.txt](https://github.com/openjdk/jdk/files/14113452/cgroup2-hierarchical_memory_limit.patch.txt)
> 
>> Since it seems unlikely for cgroup interface file paths changing during runtime, walking the hierarchy for every look-up seems overkill. Note that the prime users of this feature are in-container use, where most runtimes have the limit settings at the leaf.
> 
> While I understand the most common change of the limits is at the leaf technically any parent group limit can change. Which is also what this patch is implementing. For the performance issue I have implemented the Linux kernel extension above.
> 
>> `N` files per metric to look at where it used to be one file (i.e. constant).
> 
> The problem is any of the files can change. But to fix the performance I have implemented the Linux kernel patch above.
> 
>> I wonder if it would be sufficient to "lock" into the cgroup path where the lowest  limits are set in the hierarchy and only use the interface files at that path of a specific controller.
> 
> That mostly disables the functionality of this patch.
> 
> 
>>     * There seems to be an inconsistency between cgroups v1 (no recursive look-up) and cgroups v2  (recursive look-up). Why? I think we should employ the same semantics to both  versions (and drop the hierarchical work-around - [JDK-8217338](https://bugs.openjdk.java.net/browse/JDK-8217338) - for cg v1).
> 
> I did not much expect anyone still uses cgroup1. Plus customer was also interested in cgroup2. AFAIK a last OS using cgroup1 was RHEL-7 which will have EOL in a few months. But then I tried to implement cgroup1 but there it sort of already worked thanks for your [JDK-8217338](https://bugs.openjdk.java.net/browse/JDK-8217338). I just fixed there to prefer the hierarchical limit over the leaf limit (and the testcase does test it now) as that is what is used by Linux kernel.
> 
> And then my Linux kernel patch implements the same `memory.stat` way even for cgroup2.
> 
>>     * There also seems to be an inconsistency between metrics being iterated. `memory.max` and `memory.swap.max`  and `memory.swap.current` are being iterated, others, like CPU quotas (`cpu.max` or...

> @jankratochvil The "use hierarchical limit" was a work-around that bites us now.

What is the current problem? I see one problem of the cgroup1 hierarchical implementation in OpenJDK which is fixed by this patch incl. a testcase.


> So instead we should attempt to unify cgv1 and cgv2 by walking the hierarchy

When you are concerned about the performance I have rather implemented the hierarchical interface also for Linux kernel.
  https://lore.kernel.org/linux-mm/ZcvlhOZ4VBEX9raZ at host1.jankratochvil.net/T/
It has been welcomed by SuSE:
  https://lore.kernel.org/linux-mm/8f8d5a2d-dde3-42e5-9988-fab042666f40 at redhat.com/T/#m1238300cf818badebed0183f1b5ab798bf1f2e9f


> and find the place in the hierarchy where the interface files - with actual limits imposed - are to be found.

That is being done if the patch above is not found on the running kernel.


> Since this patch attempts to solve a similar goal to what the old work-around solved for cg v1, we should re-think how to solve it properly. My suggestion would be to go with walking the hierarchy for both: cg v1 and cg v2.

I hope I have fixed the same problem in a more performance wise way.


> As to the walking the hierarchy on every invocation problem, I don't think fixing it by relying on a kernel patch is the way to go.

Why not to support both ways. Time flies like wind.


> It'll take time for the ecosystem to pick those up and existing cg v2 systems won't be fixed (consider RHEL 8 or RHEL 9 systems and their derivatives).

Particuarly for RHEL it depends whether any of the paying customers is interested in the performance wise solution (I doubt so as the performance difference is small). Backport for a hotfix delivery for the specific customer will be done in a few days. Included in the next RHEL y-release it will be in a few months (and also released then in CentOS).


> Therefore, the idea would be to do the iteration **once** when the `OSContainer` code initializes.

Done that in this patch. I think it could also occasionally re-read the hierarchical structure but that hasn't been implemented.

I expect I would remove the "memory.max.effective" dependency from this patch for the OpenJDK commit as the kernel patch has not been approved yet and so the kernel interface ("memory.max.effective") still may change.

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

PR Comment: https://git.openjdk.org/jdk/pull/17198#issuecomment-1954420583

From jkratochvil at openjdk.org  Tue Feb 20 15:15:09 2024
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Tue, 20 Feb 2024 15:15:09 GMT
Subject: RFR: 8322420: [Linux] cgroup v2: Limits in parent nested control
 groups are not detected [v7]
In-Reply-To: 
References: 
Message-ID: 

> The testcase requires root permissions.

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

 - Disable cgroup.subtree_control testcase on cgroup1
 - Extend the testcase
 - Implement cgroup.subtree_control .
 - Remove dir_ix; only the trivial cases.
 - Use *.effective kernel hints also in *.java
 - Update for the kernel update *.effective
 - Update for the kernel patch update hierarchical_memsw_limit->hierarchical_swap_limit
 - Merge branch 'master' into master-cgroup
 - Merge branch 'master' into master-cgroup
 - Fail reading memory.stat only once
 - ... and 13 more: https://git.openjdk.org/jdk/compare/2546afe2...4d3b3aa9

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

Changes: https://git.openjdk.org/jdk/pull/17198/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17198&range=06
  Stats: 404 lines in 8 files changed: 363 ins; 18 del; 23 mod
  Patch: https://git.openjdk.org/jdk/pull/17198.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17198/head:pull/17198

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

From redestad at openjdk.org  Tue Feb 20 16:38:05 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 20 Feb 2024 16:38:05 GMT
Subject: RFR: 8325730: StringBuilder.toString allocation for the empty String
Message-ID: <-H_R3FJXtq6Bg4NvDmev410GWip08RXxknmyQPe-aA8=.c63a942e-b990-466d-998c-7bcd2b748eb7@github.com>

JDK-8282429 accidentally removed an optimization (JDK-8240094) that ensured StringBuilder/StringBuffer::toString returns `""` when the builders are empty.


Name                         Cnt     Base      Error   Test   Error   Unit  Change
StringBuffers.emptyToString    5   12,289 ?    0,384  9,883 ? 0,721  ns/op   1,24x (p = 0,000*)
  :gc.alloc.rate                 1862,398 ?   57,647  0,007 ? 0,000 MB/sec   0,00x (p = 0,000*)
  :gc.alloc.rate.norm              24,000 ?    0,000  0,000 ? 0,000   B/op   0,00x (p = 0,000*)
  :gc.count                        31,000             0,000         counts
  :gc.time                         21,000                               ms
StringBuilders.emptyToString   5    4,146 ?    0,567  0,646 ? 0,003  ns/op   6,42x (p = 0,000*)
  :gc.alloc.rate                 9208,656 ? 1234,399  0,007 ? 0,000 MB/sec   0,00x (p = 0,000*)
  :gc.alloc.rate.norm              40,000 ?    0,000  0,000 ? 0,000   B/op   0,00x (p = 0,000*)
  :gc.count                        96,000             0,000         counts
  :gc.time                         64,000                               ms
  * = significant

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

Commit messages:
 - Copyrights
 - 8325730: StringBuilder.toString allocation for the empty String

Changes: https://git.openjdk.org/jdk/pull/17931/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17931&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8325730
  Stats: 53 lines in 5 files changed: 14 ins; 31 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/17931.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17931/head:pull/17931

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

From jlaskey at openjdk.org  Tue Feb 20 16:53:53 2024
From: jlaskey at openjdk.org (Jim Laskey)
Date: Tue, 20 Feb 2024 16:53:53 GMT
Subject: RFR: 8325730: StringBuilder.toString allocation for the empty
 String
In-Reply-To: <-H_R3FJXtq6Bg4NvDmev410GWip08RXxknmyQPe-aA8=.c63a942e-b990-466d-998c-7bcd2b748eb7@github.com>
References: <-H_R3FJXtq6Bg4NvDmev410GWip08RXxknmyQPe-aA8=.c63a942e-b990-466d-998c-7bcd2b748eb7@github.com>
Message-ID: 

On Tue, 20 Feb 2024 16:32:54 GMT, Claes Redestad  wrote:

> JDK-8282429 accidentally removed an optimization (JDK-8240094) that ensured StringBuilder/StringBuffer::toString returns `""` when the builders are empty.
> 
> 
> Name                         Cnt     Base      Error   Test   Error   Unit  Change
> StringBuffers.emptyToString    5   12,289 ?    0,384  9,883 ? 0,721  ns/op   1,24x (p = 0,000*)
>   :gc.alloc.rate                 1862,398 ?   57,647  0,007 ? 0,000 MB/sec   0,00x (p = 0,000*)
>   :gc.alloc.rate.norm              24,000 ?    0,000  0,000 ? 0,000   B/op   0,00x (p = 0,000*)
>   :gc.count                        31,000             0,000         counts
>   :gc.time                         21,000                               ms
> StringBuilders.emptyToString   5    4,146 ?    0,567  0,646 ? 0,003  ns/op   6,42x (p = 0,000*)
>   :gc.alloc.rate                 9208,656 ? 1234,399  0,007 ? 0,000 MB/sec   0,00x (p = 0,000*)
>   :gc.alloc.rate.norm              40,000 ?    0,000  0,000 ? 0,000   B/op   0,00x (p = 0,000*)
>   :gc.count                        96,000             0,000         counts
>   :gc.time                         64,000                               ms
>   * = significant

LGTM

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

Marked as reviewed by jlaskey (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17931#pullrequestreview-1890964061

From shade at openjdk.org  Tue Feb 20 17:07:54 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 20 Feb 2024 17:07:54 GMT
Subject: RFR: 8325730: StringBuilder.toString allocation for the empty
 String
In-Reply-To: <-H_R3FJXtq6Bg4NvDmev410GWip08RXxknmyQPe-aA8=.c63a942e-b990-466d-998c-7bcd2b748eb7@github.com>
References: <-H_R3FJXtq6Bg4NvDmev410GWip08RXxknmyQPe-aA8=.c63a942e-b990-466d-998c-7bcd2b748eb7@github.com>
Message-ID: 

On Tue, 20 Feb 2024 16:32:54 GMT, Claes Redestad  wrote:

> JDK-8282429 accidentally removed an optimization (JDK-8240094) that ensured StringBuilder/StringBuffer::toString returns `""` when the builders are empty.
> 
> 
> Name                         Cnt     Base      Error   Test   Error   Unit  Change
> StringBuffers.emptyToString    5   12,289 ?    0,384  9,883 ? 0,721  ns/op   1,24x (p = 0,000*)
>   :gc.alloc.rate                 1862,398 ?   57,647  0,007 ? 0,000 MB/sec   0,00x (p = 0,000*)
>   :gc.alloc.rate.norm              24,000 ?    0,000  0,000 ? 0,000   B/op   0,00x (p = 0,000*)
>   :gc.count                        31,000             0,000         counts
>   :gc.time                         21,000                               ms
> StringBuilders.emptyToString   5    4,146 ?    0,567  0,646 ? 0,003  ns/op   6,42x (p = 0,000*)
>   :gc.alloc.rate                 9208,656 ? 1234,399  0,007 ? 0,000 MB/sec   0,00x (p = 0,000*)
>   :gc.alloc.rate.norm              40,000 ?    0,000  0,000 ? 0,000   B/op   0,00x (p = 0,000*)
>   :gc.count                        96,000             0,000         counts
>   :gc.time                         64,000                               ms
>   * = significant

OK, so before [JDK-8282429](https://bugs.openjdk.org/browse/JDK-8282429) this was handled by `String{Latin1|UTF16}.newString`, gotcha.

src/java.base/share/classes/java/lang/StringBuilder.java line 478:

> 476:         }
> 477:         // Create a copy, don't share the array
> 478:         return new String(this, null);

Ok, this got me a bit confused, but I think this just inlines the call to this constructor:


    public String(StringBuilder builder) {
        this(builder, null);
    }

test/micro/org/openjdk/bench/java/lang/StringBuffers.java line 49:

> 47: 
> 48:     @Benchmark
> 49:     public String emptyToString() {

Do we actually need to remove the `substring` test here?

test/micro/org/openjdk/bench/java/lang/StringBuilderToString.java line 33:

> 31: import org.openjdk.jmh.annotations.Param;
> 32: import org.openjdk.jmh.annotations.Scope;
> 33: import org.openjdk.jmh.annotations.Setup;

Is this needed?

test/micro/org/openjdk/bench/java/lang/StringBuilders.java line 407:

> 405: 
> 406:         private void generateData() {
> 407:             sb = new StringBuilder(length);

This looks weird, given there is a `sb` initialization two lines below. Is this `sbEmpty`, really?

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

PR Review: https://git.openjdk.org/jdk/pull/17931#pullrequestreview-1890982087
PR Review Comment: https://git.openjdk.org/jdk/pull/17931#discussion_r1496181978
PR Review Comment: https://git.openjdk.org/jdk/pull/17931#discussion_r1496178639
PR Review Comment: https://git.openjdk.org/jdk/pull/17931#discussion_r1496177666
PR Review Comment: https://git.openjdk.org/jdk/pull/17931#discussion_r1496182725

From naoto.sato at oracle.com  Tue Feb 20 17:51:33 2024
From: naoto.sato at oracle.com (Naoto Sato)
Date: Tue, 20 Feb 2024 09:51:33 -0800
Subject: CFV: New Core Libraries Group Member: Viktor Klang
In-Reply-To: <5a5a3d2c-34d7-f6fb-8736-c3bb5cf5d5fc@oracle.com>
References: <5a5a3d2c-34d7-f6fb-8736-c3bb5cf5d5fc@oracle.com>
Message-ID: <9f6a44d1-da01-4463-9adf-fcc0f3c07fd7@oracle.com>

Vote: yes

Naoto

On 2/19/24 3:40 PM, Stuart Marks wrote:
> 
> I hereby nominate Viktor Klang [6] to Membership in the Core Libraries 
> Group [4].
> 
> Viktor has been a member of the Java team in Oracle since 2022, and he 
> is currently a Committer on the JDK project. Viktor has led JEP 461 [1], 
> an enhancement to the Streams API to support new intermediate stream 
> operations. Viktor has also contributed several other changes to the JDK 
> [2][3], focusing primarily on the java.util.concurrent package. Prior to 
> his work on OpenJDK, Viktor's past work includes Akka, Reactive Streams, 
> and many other contributions to the Scala world.
> 
> Votes are due by 23:59 UTC on March 4, 2024.
> 
> Only current Members of the Core Libraries Group [4] are eligible to 
> vote on this nomination. Votes must be cast in the open by replying to 
> this mailing list.
> 
> For Lazy Consensus voting instructions, see [5].
> 
> s'marks
> 
> 
> [1] https://openjdk.org/jeps/461
> [2] https://github.com/openjdk/jdk/commits?author=vklang%40openjdk.org
> [3] https://github.com/openjdk/jdk/commits?author=viktorklang-ora
> [4] https://openjdk.org/census#core-libs
> [5] https://openjdk.org/groups/#member-vote
> [6] https://openjdk.org/census#vklang

From redestad at openjdk.org  Tue Feb 20 18:02:54 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 20 Feb 2024 18:02:54 GMT
Subject: RFR: 8325730: StringBuilder.toString allocation for the empty
 String
In-Reply-To: 
References: <-H_R3FJXtq6Bg4NvDmev410GWip08RXxknmyQPe-aA8=.c63a942e-b990-466d-998c-7bcd2b748eb7@github.com>
 
Message-ID: <-iPzyn2l_C14Y0lvDDu7ytiBRWNpwVODzuvXpSca1j8=.5e7e6d58-4d4f-48cf-aefa-8e6e1b85fbba@github.com>

On Tue, 20 Feb 2024 17:00:14 GMT, Aleksey Shipilev  wrote:

>> JDK-8282429 accidentally removed an optimization (JDK-8240094) that ensured StringBuilder/StringBuffer::toString returns `""` when the builders are empty.
>> 
>> 
>> Name                         Cnt     Base      Error   Test   Error   Unit  Change
>> StringBuffers.emptyToString    5   12,289 ?    0,384  9,883 ? 0,721  ns/op   1,24x (p = 0,000*)
>>   :gc.alloc.rate                 1862,398 ?   57,647  0,007 ? 0,000 MB/sec   0,00x (p = 0,000*)
>>   :gc.alloc.rate.norm              24,000 ?    0,000  0,000 ? 0,000   B/op   0,00x (p = 0,000*)
>>   :gc.count                        31,000             0,000         counts
>>   :gc.time                         21,000                               ms
>> StringBuilders.emptyToString   5    4,146 ?    0,567  0,646 ? 0,003  ns/op   6,42x (p = 0,000*)
>>   :gc.alloc.rate                 9208,656 ? 1234,399  0,007 ? 0,000 MB/sec   0,00x (p = 0,000*)
>>   :gc.alloc.rate.norm              40,000 ?    0,000  0,000 ? 0,000   B/op   0,00x (p = 0,000*)
>>   :gc.count                        96,000             0,000         counts
>>   :gc.time                         64,000                               ms
>>   * = significant
>
> test/micro/org/openjdk/bench/java/lang/StringBuffers.java line 49:
> 
>> 47: 
>> 48:     @Benchmark
>> 49:     public String emptyToString() {
> 
> Do we actually need to remove the `substring` test here?

I couldn't figure out why we'd want to have `String::substring` micros in a test `StringBuffers` (there's also a `StringSubstring` micro), though I could deal with that as an explicit cleanup RFE.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17931#discussion_r1496266477

From redestad at openjdk.org  Tue Feb 20 18:15:05 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 20 Feb 2024 18:15:05 GMT
Subject: RFR: 8325730: StringBuilder.toString allocation for the empty
 String [v2]
In-Reply-To: <-H_R3FJXtq6Bg4NvDmev410GWip08RXxknmyQPe-aA8=.c63a942e-b990-466d-998c-7bcd2b748eb7@github.com>
References: <-H_R3FJXtq6Bg4NvDmev410GWip08RXxknmyQPe-aA8=.c63a942e-b990-466d-998c-7bcd2b748eb7@github.com>
Message-ID: 

> JDK-8282429 accidentally removed an optimization (JDK-8240094) that ensured StringBuilder/StringBuffer::toString returns `""` when the builders are empty.
> 
> 
> Name                         Cnt     Base      Error   Test   Error   Unit  Change
> StringBuffers.emptyToString    5   12,289 ?    0,384  9,883 ? 0,721  ns/op   1,24x (p = 0,000*)
>   :gc.alloc.rate                 1862,398 ?   57,647  0,007 ? 0,000 MB/sec   0,00x (p = 0,000*)
>   :gc.alloc.rate.norm              24,000 ?    0,000  0,000 ? 0,000   B/op   0,00x (p = 0,000*)
>   :gc.count                        31,000             0,000         counts
>   :gc.time                         21,000                               ms
> StringBuilders.emptyToString   5    4,146 ?    0,567  0,646 ? 0,003  ns/op   6,42x (p = 0,000*)
>   :gc.alloc.rate                 9208,656 ? 1234,399  0,007 ? 0,000 MB/sec   0,00x (p = 0,000*)
>   :gc.alloc.rate.norm              40,000 ?    0,000  0,000 ? 0,000   B/op   0,00x (p = 0,000*)
>   :gc.count                        96,000             0,000         counts
>   :gc.time                         64,000                               ms
>   * = significant

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

 - Revert StringBuffers removals
 - Update from review comments by @shipilev

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17931/files
  - new: https://git.openjdk.org/jdk/pull/17931/files/7f9566b8..40cca3e3

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

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

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

From redestad at openjdk.org  Tue Feb 20 18:15:05 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 20 Feb 2024 18:15:05 GMT
Subject: RFR: 8325730: StringBuilder.toString allocation for the empty
 String [v2]
In-Reply-To: 
References: <-H_R3FJXtq6Bg4NvDmev410GWip08RXxknmyQPe-aA8=.c63a942e-b990-466d-998c-7bcd2b748eb7@github.com>
 
Message-ID: <-60QMTGve_BNpkQnkYUJKp20L-rBEvS-FmdXjUzuAGs=.6f29c19c-390d-4d65-b8c9-144c63e802c7@github.com>

On Tue, 20 Feb 2024 17:02:40 GMT, Aleksey Shipilev  wrote:

>> Claes Redestad has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Revert StringBuffers removals
>>  - Update from review comments by @shipilev
>
> src/java.base/share/classes/java/lang/StringBuilder.java line 478:
> 
>> 476:         }
>> 477:         // Create a copy, don't share the array
>> 478:         return new String(this, null);
> 
> Ok, this got me a bit confused, but I think this just inlines the call to this constructor:
> 
> 
>     public String(StringBuilder builder) {
>         this(builder, null);
>     }

Yes, I was mostly reaching for increased consistency with `StringBuffer` here.

> test/micro/org/openjdk/bench/java/lang/StringBuilderToString.java line 33:
> 
>> 31: import org.openjdk.jmh.annotations.Param;
>> 32: import org.openjdk.jmh.annotations.Scope;
>> 33: import org.openjdk.jmh.annotations.Setup;
> 
> Is this needed?

It's needed again now that I reverted the code removals.. :-)

> test/micro/org/openjdk/bench/java/lang/StringBuilders.java line 407:
> 
>> 405: 
>> 406:         private void generateData() {
>> 407:             sb = new StringBuilder(length);
> 
> This looks weird, given there is a `sb` initialization two lines below. Is this `sbEmpty`, really?

Yes, updating the name to avoid the confusing shadowing.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17931#discussion_r1496273112
PR Review Comment: https://git.openjdk.org/jdk/pull/17931#discussion_r1496282094
PR Review Comment: https://git.openjdk.org/jdk/pull/17931#discussion_r1496275704

From shade at openjdk.org  Tue Feb 20 18:15:05 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 20 Feb 2024 18:15:05 GMT
Subject: RFR: 8325730: StringBuilder.toString allocation for the empty
 String [v2]
In-Reply-To: <-iPzyn2l_C14Y0lvDDu7ytiBRWNpwVODzuvXpSca1j8=.5e7e6d58-4d4f-48cf-aefa-8e6e1b85fbba@github.com>
References: <-H_R3FJXtq6Bg4NvDmev410GWip08RXxknmyQPe-aA8=.c63a942e-b990-466d-998c-7bcd2b748eb7@github.com>
 
 <-iPzyn2l_C14Y0lvDDu7ytiBRWNpwVODzuvXpSca1j8=.5e7e6d58-4d4f-48cf-aefa-8e6e1b85fbba@github.com>
Message-ID: <4sezvQeTxgGawawJ3iZoxD-95NhUyZB43IQUSsWiktQ=.46a8288d-d65a-4ad6-a75c-dad082b69196@github.com>

On Tue, 20 Feb 2024 18:00:42 GMT, Claes Redestad  wrote:

>> test/micro/org/openjdk/bench/java/lang/StringBuffers.java line 49:
>> 
>>> 47: 
>>> 48:     @Benchmark
>>> 49:     public String emptyToString() {
>> 
>> Do we actually need to remove the `substring` test here?
>
> I couldn't figure out why we'd want to have `String::substring` micros in a test `StringBuffers` (there's also a `StringSubstring` micro), though I could deal with that as an explicit cleanup RFE.

Yeah, I would like to keep this change clean for backports. Do the cleanup in a separate PR?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17931#discussion_r1496277852

From redestad at openjdk.org  Tue Feb 20 18:15:05 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 20 Feb 2024 18:15:05 GMT
Subject: RFR: 8325730: StringBuilder.toString allocation for the empty
 String [v2]
In-Reply-To: <4sezvQeTxgGawawJ3iZoxD-95NhUyZB43IQUSsWiktQ=.46a8288d-d65a-4ad6-a75c-dad082b69196@github.com>
References: <-H_R3FJXtq6Bg4NvDmev410GWip08RXxknmyQPe-aA8=.c63a942e-b990-466d-998c-7bcd2b748eb7@github.com>
 
 <-iPzyn2l_C14Y0lvDDu7ytiBRWNpwVODzuvXpSca1j8=.5e7e6d58-4d4f-48cf-aefa-8e6e1b85fbba@github.com>
 <4sezvQeTxgGawawJ3iZoxD-95NhUyZB43IQUSsWiktQ=.46a8288d-d65a-4ad6-a75c-dad082b69196@github.com>
Message-ID: 

On Tue, 20 Feb 2024 18:08:11 GMT, Aleksey Shipilev  wrote:

>> I couldn't figure out why we'd want to have `String::substring` micros in a test `StringBuffers` (there's also a `StringSubstring` micro), though I could deal with that as an explicit cleanup RFE.
>
> Yeah, I would like to keep this change clean for backports. Do the cleanup in a separate PR?

Reverted.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17931#discussion_r1496281834

From lance.andersen at oracle.com  Tue Feb 20 18:18:22 2024
From: lance.andersen at oracle.com (Lance Andersen)
Date: Tue, 20 Feb 2024 18:18:22 +0000
Subject: CFV: New Core Libraries Group Member: Viktor Klang
In-Reply-To: <5a5a3d2c-34d7-f6fb-8736-c3bb5cf5d5fc@oracle.com>
References: <5a5a3d2c-34d7-f6fb-8736-c3bb5cf5d5fc@oracle.com>
Message-ID: 

Vote: yes


On 2/19/24 3:40 PM, Stuart Marks wrote:
> I hereby nominate Viktor Klang [6] to Membership in the Core Libraries Group [4].
> Viktor has been a member of the Java team in Oracle since 2022, and he is currently a Committer on the JDK project. Viktor has led JEP 461 [1], an enhancement to the Streams API to support new intermediate stream operations. Viktor has also contributed several other changes to the JDK [2][3], focusing primarily on the java.util.concurrent package. Prior to his work on OpenJDK, Viktor's past work includes Akka, Reactive Streams, and many other contributions to the Scala world.
> Votes are due by 23:59 UTC on March 4, 2024.
> Only current Members of the Core Libraries Group [4] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list.
> For Lazy Consensus voting instructions, see [5].
> s'marks
> [1] https://openjdk.org/jeps/461
> [2] https://github.com/openjdk/jdk/commits?author=vklang%40openjdk.org
> [3] https://github.com/openjdk/jdk/commits?author=viktorklang-ora
> [4] https://openjdk.org/census#core-libs
> [5] https://openjdk.org/groups/#member-vote
> [6] https://openjdk.org/census#vklang

From daniel.fuchs at oracle.com  Tue Feb 20 18:32:27 2024
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Tue, 20 Feb 2024 18:32:27 +0000
Subject: CFV: New Core Libraries Group Member: Viktor Klang
In-Reply-To: <5a5a3d2c-34d7-f6fb-8736-c3bb5cf5d5fc@oracle.com>
References: <5a5a3d2c-34d7-f6fb-8736-c3bb5cf5d5fc@oracle.com>
Message-ID: <45d80ac5-b9aa-401f-9886-b86007cdd5f2@oracle.com>

Vote: yes

best regards,

-- daniel

On 19/02/2024 23:40, Stuart Marks wrote:
> 
> I hereby nominate Viktor Klang [6] to Membership in the Core Libraries 
> Group [4].


From shade at openjdk.org  Tue Feb 20 18:32:54 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 20 Feb 2024 18:32:54 GMT
Subject: RFR: 8325730: StringBuilder.toString allocation for the empty
 String [v2]
In-Reply-To: <-60QMTGve_BNpkQnkYUJKp20L-rBEvS-FmdXjUzuAGs=.6f29c19c-390d-4d65-b8c9-144c63e802c7@github.com>
References: <-H_R3FJXtq6Bg4NvDmev410GWip08RXxknmyQPe-aA8=.c63a942e-b990-466d-998c-7bcd2b748eb7@github.com>
 
 <-60QMTGve_BNpkQnkYUJKp20L-rBEvS-FmdXjUzuAGs=.6f29c19c-390d-4d65-b8c9-144c63e802c7@github.com>
Message-ID: 

On Tue, 20 Feb 2024 18:04:18 GMT, Claes Redestad  wrote:

>> src/java.base/share/classes/java/lang/StringBuilder.java line 478:
>> 
>>> 476:         }
>>> 477:         // Create a copy, don't share the array
>>> 478:         return new String(this, null);
>> 
>> Ok, this got me a bit confused, but I think this just inlines the call to this constructor:
>> 
>> 
>>     public String(StringBuilder builder) {
>>         this(builder, null);
>>     }
>
> Yes, I was mostly reaching for increased consistency with `StringBuffer` here.

Good then, thanks.

>> test/micro/org/openjdk/bench/java/lang/StringBuilderToString.java line 33:
>> 
>>> 31: import org.openjdk.jmh.annotations.Param;
>>> 32: import org.openjdk.jmh.annotations.Scope;
>>> 33: import org.openjdk.jmh.annotations.Setup;
>> 
>> Is this needed?
>
> It's needed again now that I reverted the code removals.. :-)

Mhm. I don't see any new `@Setup` methods anywhere. Just checked out the PR locally, removed this import and benchmarks still build, and `StringBuilderToString` bench still runs. Am I missing something here?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17931#discussion_r1496297773
PR Review Comment: https://git.openjdk.org/jdk/pull/17931#discussion_r1496315384

From naoto at openjdk.org  Tue Feb 20 18:40:02 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 20 Feb 2024 18:40:02 GMT
Subject: RFR: 8326158: Javadoc for java.time.DayOfWeek#minus(long)
Message-ID: 

Fixing a typo in the said method.

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

Commit messages:
 - initial commit

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

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

From redestad at openjdk.org  Tue Feb 20 18:42:16 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 20 Feb 2024 18:42:16 GMT
Subject: RFR: 8325730: StringBuilder.toString allocation for the empty
 String [v3]
In-Reply-To: <-H_R3FJXtq6Bg4NvDmev410GWip08RXxknmyQPe-aA8=.c63a942e-b990-466d-998c-7bcd2b748eb7@github.com>
References: <-H_R3FJXtq6Bg4NvDmev410GWip08RXxknmyQPe-aA8=.c63a942e-b990-466d-998c-7bcd2b748eb7@github.com>
Message-ID: 

> JDK-8282429 accidentally removed an optimization (JDK-8240094) that ensured StringBuilder/StringBuffer::toString returns `""` when the builders are empty.
> 
> 
> Name                         Cnt     Base      Error   Test   Error   Unit  Change
> StringBuffers.emptyToString    5   12,289 ?    0,384  9,883 ? 0,721  ns/op   1,24x (p = 0,000*)
>   :gc.alloc.rate                 1862,398 ?   57,647  0,007 ? 0,000 MB/sec   0,00x (p = 0,000*)
>   :gc.alloc.rate.norm              24,000 ?    0,000  0,000 ? 0,000   B/op   0,00x (p = 0,000*)
>   :gc.count                        31,000             0,000         counts
>   :gc.time                         21,000                               ms
> StringBuilders.emptyToString   5    4,146 ?    0,567  0,646 ? 0,003  ns/op   6,42x (p = 0,000*)
>   :gc.alloc.rate                 9208,656 ? 1234,399  0,007 ? 0,000 MB/sec   0,00x (p = 0,000*)
>   :gc.alloc.rate.norm              40,000 ?    0,000  0,000 ? 0,000   B/op   0,00x (p = 0,000*)
>   :gc.count                        96,000             0,000         counts
>   :gc.time                         64,000                               ms
>   * = significant

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

  Revert accidental import

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17931/files
  - new: https://git.openjdk.org/jdk/pull/17931/files/40cca3e3..1846746b

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

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

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

From shade at openjdk.org  Tue Feb 20 18:42:16 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 20 Feb 2024 18:42:16 GMT
Subject: RFR: 8325730: StringBuilder.toString allocation for the empty
 String [v3]
In-Reply-To: 
References: <-H_R3FJXtq6Bg4NvDmev410GWip08RXxknmyQPe-aA8=.c63a942e-b990-466d-998c-7bcd2b748eb7@github.com>
 
Message-ID: 

On Tue, 20 Feb 2024 18:38:48 GMT, Claes Redestad  wrote:

>> JDK-8282429 accidentally removed an optimization (JDK-8240094) that ensured StringBuilder/StringBuffer::toString returns `""` when the builders are empty.
>> 
>> 
>> Name                         Cnt     Base      Error   Test   Error   Unit  Change
>> StringBuffers.emptyToString    5   12,289 ?    0,384  9,883 ? 0,721  ns/op   1,24x (p = 0,000*)
>>   :gc.alloc.rate                 1862,398 ?   57,647  0,007 ? 0,000 MB/sec   0,00x (p = 0,000*)
>>   :gc.alloc.rate.norm              24,000 ?    0,000  0,000 ? 0,000   B/op   0,00x (p = 0,000*)
>>   :gc.count                        31,000             0,000         counts
>>   :gc.time                         21,000                               ms
>> StringBuilders.emptyToString   5    4,146 ?    0,567  0,646 ? 0,003  ns/op   6,42x (p = 0,000*)
>>   :gc.alloc.rate                 9208,656 ? 1234,399  0,007 ? 0,000 MB/sec   0,00x (p = 0,000*)
>>   :gc.alloc.rate.norm              40,000 ?    0,000  0,000 ? 0,000   B/op   0,00x (p = 0,000*)
>>   :gc.count                        96,000             0,000         counts
>>   :gc.time                         64,000                               ms
>>   * = significant
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert accidental import

Marked as reviewed by shade (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17931#pullrequestreview-1891220541

From redestad at openjdk.org  Tue Feb 20 18:42:16 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 20 Feb 2024 18:42:16 GMT
Subject: RFR: 8325730: StringBuilder.toString allocation for the empty
 String [v3]
In-Reply-To: 
References: <-H_R3FJXtq6Bg4NvDmev410GWip08RXxknmyQPe-aA8=.c63a942e-b990-466d-998c-7bcd2b748eb7@github.com>
 
 <-60QMTGve_BNpkQnkYUJKp20L-rBEvS-FmdXjUzuAGs=.6f29c19c-390d-4d65-b8c9-144c63e802c7@github.com>
 
Message-ID: <8nvWIDUSBMS7iDwHDM--PxZIJIxaKiyFzSVwWDeSLi8=.bebb1963-e360-4bfa-87c2-9882df39f9a7@github.com>

On Tue, 20 Feb 2024 18:30:25 GMT, Aleksey Shipilev  wrote:

>> It's needed again now that I reverted the code removals.. :-)
>
> Mhm. I don't see any new `@Setup` methods anywhere. Just checked out the PR locally, removed this import and benchmarks still build, and `StringBuilderToString` bench still runs. Am I missing something here?

Gah, I was looking in the wrong place. Fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17931#discussion_r1496321177

From iris at openjdk.org  Tue Feb 20 18:48:54 2024
From: iris at openjdk.org (Iris Clark)
Date: Tue, 20 Feb 2024 18:48:54 GMT
Subject: RFR: 8326158: Javadoc for java.time.DayOfWeek#minus(long)
In-Reply-To: 
References: 
Message-ID: 

On Tue, 20 Feb 2024 18:34:59 GMT, Naoto Sato  wrote:

> Fixing a typo in the said method.

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17933#pullrequestreview-1891250872

From lancea at openjdk.org  Tue Feb 20 18:53:54 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 20 Feb 2024 18:53:54 GMT
Subject: RFR: 8326158: Javadoc for java.time.DayOfWeek#minus(long)
In-Reply-To: 
References: 
Message-ID: 

On Tue, 20 Feb 2024 18:34:59 GMT, Naoto Sato  wrote:

> Fixing a typo in the said method.

Marked as reviewed by lancea (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17933#pullrequestreview-1891265805

From brian.burkhalter at oracle.com  Tue Feb 20 19:29:08 2024
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Tue, 20 Feb 2024 19:29:08 +0000
Subject: CFV: New Core Libraries Group Member: Viktor Klang
In-Reply-To: <5a5a3d2c-34d7-f6fb-8736-c3bb5cf5d5fc@oracle.com>
References: <5a5a3d2c-34d7-f6fb-8736-c3bb5cf5d5fc@oracle.com>
Message-ID: 

Vote: yes

From lancea at openjdk.org  Tue Feb 20 20:01:04 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 20 Feb 2024 20:01:04 GMT
Subject: RFR: 8326351: Update the Zlib version in
 open/src/java.base/share/legal/zlib.md to 1.3.1
Message-ID: 

Please review the updates to open/src/java.base/share/legal/zlib.md to update the file  from zlib 1.2.13 to zlib 1.3.1 which was missed as part of the PR for [JDK-8324632](https://bugs.openjdk.org/browse/JDK-8324632)

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

Commit messages:
 - Update zlib.md for zlib 1.3.1

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

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

From iris at openjdk.org  Tue Feb 20 20:07:54 2024
From: iris at openjdk.org (Iris Clark)
Date: Tue, 20 Feb 2024 20:07:54 GMT
Subject: RFR: 8326351: Update the Zlib version in
 open/src/java.base/share/legal/zlib.md to 1.3.1
In-Reply-To: 
References: 
Message-ID: <5aEiY5haj33ENcDabtTZJo_QgXD9YySRKu4vcHTnen4=.94320321-2e5c-4700-9a18-5676a282af08@github.com>

On Tue, 20 Feb 2024 19:56:53 GMT, Lance Andersen  wrote:

> Please review the updates to open/src/java.base/share/legal/zlib.md to update the file  from zlib 1.2.13 to zlib 1.3.1 which was missed as part of the PR for [JDK-8324632](https://bugs.openjdk.org/browse/JDK-8324632)

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17935#pullrequestreview-1891486155

From duke at openjdk.org  Tue Feb 20 20:11:07 2024
From: duke at openjdk.org (Chris Hennick)
Date: Tue, 20 Feb 2024 20:11:07 GMT
Subject: RFR: 8326227: Fix a rare rounding error affecting
 RandomSupport::computeNextGaussian
Message-ID: 

This provides a slightly more accurate bounding limit for `computeNextExponentialSoftCapped` when the computed bound is greater than `(1.0p53 - 1.0) * DoubleZigguratTables.exponentialX0`. This could cause the `while (computeNextExponentialSoftCapped(rng, limit) < limit)` check in `computeNextGaussian` on line 1402 to always be true, making the `nextGaussian` runtime unbounded in the worst case.

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

Commit messages:
 - Bug fix: Math is in java.lang, not java.util
 - Fix a possible rounding error in RandomSupport::computeNextExponential

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

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

From jpai at openjdk.org  Tue Feb 20 20:11:07 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 20 Feb 2024 20:11:07 GMT
Subject: RFR: 8326227: Fix a rare rounding error affecting
 RandomSupport::computeNextGaussian
In-Reply-To: 
References: 
Message-ID: 

On Mon, 5 Feb 2024 04:25:16 GMT, Chris Hennick  wrote:

> This provides a slightly more accurate bounding limit for `computeNextExponentialSoftCapped` when the computed bound is greater than `(1.0p53 - 1.0) * DoubleZigguratTables.exponentialX0`. This could cause the `while (computeNextExponentialSoftCapped(rng, limit) < limit)` check in `computeNextGaussian` on line 1402 to always be true, making the `nextGaussian` runtime unbounded in the worst case.

Hello Chris @Pr0methean, I don't have knowledge of this area to know if this is indeed a bug that is being addressed. I think it will be better to open a bug for this through https://bugs.java.com/bugdatabase/ and once it gets triaged and assigned JDK bug id then you can link this PR to that issue so that it goes through the usual review process.

Hello Chris, the issue has now made it to the JDK project https://bugs.openjdk.org/browse/JDK-8326227. Please update the title of this PR to `8326227: Rounding error that may distort computeNextGaussian results` to officially trigger the review.

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

PR Comment: https://git.openjdk.org/jdk/pull/17703#issuecomment-1951881768
PR Comment: https://git.openjdk.org/jdk/pull/17703#issuecomment-1953587306

From duke at openjdk.org  Tue Feb 20 20:11:07 2024
From: duke at openjdk.org (Chris Hennick)
Date: Tue, 20 Feb 2024 20:11:07 GMT
Subject: RFR: 8326227: Fix a rare rounding error affecting
 RandomSupport::computeNextGaussian
In-Reply-To: 
References: 
Message-ID: 

On Mon, 5 Feb 2024 04:25:16 GMT, Chris Hennick  wrote:

> This provides a slightly more accurate bounding limit for `computeNextExponentialSoftCapped` when the computed bound is greater than `(1.0p53 - 1.0) * DoubleZigguratTables.exponentialX0`. This could cause the `while (computeNextExponentialSoftCapped(rng, limit) < limit)` check in `computeNextGaussian` on line 1402 to always be true, making the `nextGaussian` runtime unbounded in the worst case.

I've submitted a bug report for this issue at https://bugs.java.com/bugdatabase/view_bug.do?bug_id=9076599; it hasn't been published yet.

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

PR Comment: https://git.openjdk.org/jdk/pull/17703#issuecomment-1953438988

From redestad at openjdk.org  Tue Feb 20 20:31:58 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 20 Feb 2024 20:31:58 GMT
Subject: RFR: 8325730: StringBuilder.toString allocation for the empty
 String [v3]
In-Reply-To: 
References: <-H_R3FJXtq6Bg4NvDmev410GWip08RXxknmyQPe-aA8=.c63a942e-b990-466d-998c-7bcd2b748eb7@github.com>
 
Message-ID: <1rSc7pfXUWhLh4XovSwH7dPO7EcGMi3BpMYOjHK2kNM=.bece48ae-2654-46db-aa57-2e457ec266eb@github.com>

On Tue, 20 Feb 2024 18:42:16 GMT, Claes Redestad  wrote:

>> JDK-8282429 accidentally removed an optimization (JDK-8240094) that ensured StringBuilder/StringBuffer::toString returns `""` when the builders are empty.
>> 
>> 
>> Name                         Cnt     Base      Error   Test   Error   Unit  Change
>> StringBuffers.emptyToString    5   12,289 ?    0,384  9,883 ? 0,721  ns/op   1,24x (p = 0,000*)
>>   :gc.alloc.rate                 1862,398 ?   57,647  0,007 ? 0,000 MB/sec   0,00x (p = 0,000*)
>>   :gc.alloc.rate.norm              24,000 ?    0,000  0,000 ? 0,000   B/op   0,00x (p = 0,000*)
>>   :gc.count                        31,000             0,000         counts
>>   :gc.time                         21,000                               ms
>> StringBuilders.emptyToString   5    4,146 ?    0,567  0,646 ? 0,003  ns/op   6,42x (p = 0,000*)
>>   :gc.alloc.rate                 9208,656 ? 1234,399  0,007 ? 0,000 MB/sec   0,00x (p = 0,000*)
>>   :gc.alloc.rate.norm              40,000 ?    0,000  0,000 ? 0,000   B/op   0,00x (p = 0,000*)
>>   :gc.count                        96,000             0,000         counts
>>   :gc.time                         64,000                               ms
>>   * = significant
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert accidental import

Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/17931#issuecomment-1955020047

From redestad at openjdk.org  Tue Feb 20 20:31:58 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 20 Feb 2024 20:31:58 GMT
Subject: Integrated: 8325730: StringBuilder.toString allocation for the empty
 String
In-Reply-To: <-H_R3FJXtq6Bg4NvDmev410GWip08RXxknmyQPe-aA8=.c63a942e-b990-466d-998c-7bcd2b748eb7@github.com>
References: <-H_R3FJXtq6Bg4NvDmev410GWip08RXxknmyQPe-aA8=.c63a942e-b990-466d-998c-7bcd2b748eb7@github.com>
Message-ID: 

On Tue, 20 Feb 2024 16:32:54 GMT, Claes Redestad  wrote:

> JDK-8282429 accidentally removed an optimization (JDK-8240094) that ensured StringBuilder/StringBuffer::toString returns `""` when the builders are empty.
> 
> 
> Name                         Cnt     Base      Error   Test   Error   Unit  Change
> StringBuffers.emptyToString    5   12,289 ?    0,384  9,883 ? 0,721  ns/op   1,24x (p = 0,000*)
>   :gc.alloc.rate                 1862,398 ?   57,647  0,007 ? 0,000 MB/sec   0,00x (p = 0,000*)
>   :gc.alloc.rate.norm              24,000 ?    0,000  0,000 ? 0,000   B/op   0,00x (p = 0,000*)
>   :gc.count                        31,000             0,000         counts
>   :gc.time                         21,000                               ms
> StringBuilders.emptyToString   5    4,146 ?    0,567  0,646 ? 0,003  ns/op   6,42x (p = 0,000*)
>   :gc.alloc.rate                 9208,656 ? 1234,399  0,007 ? 0,000 MB/sec   0,00x (p = 0,000*)
>   :gc.alloc.rate.norm              40,000 ?    0,000  0,000 ? 0,000   B/op   0,00x (p = 0,000*)
>   :gc.count                        96,000             0,000         counts
>   :gc.time                         64,000                               ms
>   * = significant

This pull request has now been integrated.

Changeset: d2590c69
Author:    Claes Redestad 
URL:       https://git.openjdk.org/jdk/commit/d2590c69b4efe5aa2b48b08070e0dbafb04ef202
Stats:     25 lines in 4 files changed: 20 ins; 0 del; 5 mod

8325730: StringBuilder.toString allocation for the empty String

Reviewed-by: jlaskey, shade

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

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

From joe.darcy at oracle.com  Tue Feb 20 20:35:05 2024
From: joe.darcy at oracle.com (Joseph D. Darcy)
Date: Tue, 20 Feb 2024 12:35:05 -0800
Subject: CFV: New Core Libraries Group Member: Viktor Klang
In-Reply-To: <5a5a3d2c-34d7-f6fb-8736-c3bb5cf5d5fc@oracle.com>
References: <5a5a3d2c-34d7-f6fb-8736-c3bb5cf5d5fc@oracle.com>
Message-ID: <12e9ebd0-a013-455e-ad10-bca04293d09d@oracle.com>

Vote: yes

-Joe

On 2/19/2024 3:40 PM, Stuart Marks wrote:
>
> I hereby nominate Viktor Klang [6] to Membership in the Core Libraries 
> Group [4].
>
> Viktor has been a member of the Java team in Oracle since 2022, and he 
> is currently a Committer on the JDK project. Viktor has led JEP 461 
> [1], an enhancement to the Streams API to support new intermediate 
> stream operations. Viktor has also contributed several other changes 
> to the JDK [2][3], focusing primarily on the java.util.concurrent 
> package. Prior to his work on OpenJDK, Viktor's past work includes 
> Akka, Reactive Streams, and many other contributions to the Scala world.
>
> Votes are due by 23:59 UTC on March 4, 2024.
>
> Only current Members of the Core Libraries Group [4] are eligible to 
> vote on this nomination. Votes must be cast in the open by replying to 
> this mailing list.
>
> For Lazy Consensus voting instructions, see [5].
>
> s'marks
>
>
> [1] https://openjdk.org/jeps/461
> [2] https://github.com/openjdk/jdk/commits?author=vklang%40openjdk.org
> [3] https://github.com/openjdk/jdk/commits?author=viktorklang-ora
> [4] https://openjdk.org/census#core-libs
> [5] https://openjdk.org/groups/#member-vote
> [6] https://openjdk.org/census#vklang

From darcy at openjdk.org  Tue Feb 20 20:48:52 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 20 Feb 2024 20:48:52 GMT
Subject: RFR: 8326227: Fix a rare rounding error affecting
 RandomSupport::computeNextGaussian
In-Reply-To: 
References: 
Message-ID: 

On Mon, 5 Feb 2024 04:25:16 GMT, Chris Hennick  wrote:

> This provides a slightly more accurate bounding limit for `computeNextExponentialSoftCapped` when the computed bound is greater than `(1.0p53 - 1.0) * DoubleZigguratTables.exponentialX0`. This could cause the `while (computeNextExponentialSoftCapped(rng, limit) < limit)` check in `computeNextGaussian` on line 1402 to always be true, making the `nextGaussian` runtime unbounded in the worst case.

Is it practical to write a regression test for this situation?

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

PR Comment: https://git.openjdk.org/jdk/pull/17703#issuecomment-1955052913

From naoto at openjdk.org  Tue Feb 20 20:55:53 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 20 Feb 2024 20:55:53 GMT
Subject: RFR: 8326351: Update the Zlib version in
 open/src/java.base/share/legal/zlib.md to 1.3.1
In-Reply-To: 
References: 
Message-ID: 

On Tue, 20 Feb 2024 19:56:53 GMT, Lance Andersen  wrote:

> Please review the updates to open/src/java.base/share/legal/zlib.md to update the file  from zlib 1.2.13 to zlib 1.3.1 which was missed as part of the PR for [JDK-8324632](https://bugs.openjdk.org/browse/JDK-8324632)

Marked as reviewed by naoto (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17935#pullrequestreview-1891566752

From redestad at openjdk.org  Tue Feb 20 21:03:14 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 20 Feb 2024 21:03:14 GMT
Subject: RFR: 8326370: Remove redundant and misplaced micros from StringBuffers
Message-ID: <_uXLLG-AvKLqNwYCCAt7fJx0EblqQaQ4X8fH3MnxZLo=.437c87c3-a262-4c7a-9d3f-973a85bf2a90@github.com>

Some microbenchmarks in org.openjdk.bench.java.lang.StringBuffers seem out-of-place (not testing `StringBuffer`), redundant (covered by other tests like StringSubstring or the various String concatenation tests), or both. This cleans them out. 

My apologies to Sigurd.

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

Commit messages:
 - 8326370: Remove redundant and misplaced micros from StringBuffers

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

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

From huizhe.wang at oracle.com  Tue Feb 20 21:51:58 2024
From: huizhe.wang at oracle.com (Joe Wang)
Date: Tue, 20 Feb 2024 13:51:58 -0800
Subject: CFV: New Core Libraries Group Member: Viktor Klang
In-Reply-To: <5a5a3d2c-34d7-f6fb-8736-c3bb5cf5d5fc@oracle.com>
References: <5a5a3d2c-34d7-f6fb-8736-c3bb5cf5d5fc@oracle.com>
Message-ID: <4a47f8ef-93ff-438f-9aa6-b62984c496c0@oracle.com>

Vote: yes

Joe (joehw)

On 2/19/24 3:40 PM, Stuart Marks wrote:
> I hereby nominate Viktor Klang [6] to Membership in the Core Libraries 
> Group [4]. 


From naoto at openjdk.org  Tue Feb 20 23:16:54 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 20 Feb 2024 23:16:54 GMT
Subject: RFR: JDK-8325898: ChoiceFormat returns erroneous result when
 formatting bad pattern
In-Reply-To: 
References: 
Message-ID: <40mnnPuoUSvoCdi8sSYzFVRbMAIy71N5IB8zsDRIT5U=.d8fd023d-dcd8-41ab-9ee6-e76aa3202cd3@github.com>

On Thu, 15 Feb 2024 19:44:42 GMT, Justin Lu  wrote:

> Please review this PR which handles an edge case pattern bug with ChoiceFormat.
> 
> 
> var d = new ChoiceFormat("0#foo|1#bar|baz|") // creates cFmt equivalent to "0.0#foo|1.0#bar|1.0#"
> d.format(1) // unexpectedly returns ""
> 
> 
> Not only does this lead to faulty formatting results, but breaks the ChoiceFormat class invariant of duplicate limits.
> 
> It would have been preferable if either an exception was thrown when the ChoiceFormat was initially created, or the ChoiceFormat formatting 1 returned a value of "bar".
> 
> For comparison,
> 
> var d = new ChoiceFormat("0#foo|1#bar|baz") // creates cFmt equivalent to "0.0#foo|1.0#bar"
> d.format(1) // returns "bar"
> 
> 
> After this change, the first code snippet now returns "bar" when formatting 1 and discards the "baz" as the second code snippet does.
> 
> 
> This PR includes a lot of cleanup to the applyPattern implementation, the specific fix for this bug is addressed with the following, on line 305,
> 
> if (seg != Segment.FORMAT) {
>     // Discard incorrect portion and finish building cFmt
>     break;
> }
> 
> This prevents a limit/format entry from being built when the current parsing mode has not yet processed the limit and relation. The previous implementation would build an additional limit/format of 1 with an empty string. The `break` allows for the discarding of the incorrect portion and continuing. Alternatively an exception could have been thrown. For consistency with the second code snippet, the former was picked.
> 
> https://github.com/openjdk/jdk/pull/17856 may be of interest, which is a semi-related specification fix.

src/java.base/share/classes/java/text/ChoiceFormat.java line 254:

> 252:      */
> 253:     private void applyPatternImpl(String newPattern) {
> 254:         Objects.requireNonNull(newPattern, "newPattern must not be null");

I think this null check should be at the public method level, not the internal implementation. This technically ends up revealing the internal variable name (although it is the same with the public argument names as of now)

src/java.base/share/classes/java/text/ChoiceFormat.java line 332:

> 330: 
> 331:     // Used to explicitly define the segment mode while applying a pattern
> 332:     private enum Segment {

Do we need a new enum? Would introducing a new enum solve something that cannot be done with the existing implementation?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17883#discussion_r1496662702
PR Review Comment: https://git.openjdk.org/jdk/pull/17883#discussion_r1496669083

From brent.christian at oracle.com  Wed Feb 21 00:22:04 2024
From: brent.christian at oracle.com (Brent Christian)
Date: Tue, 20 Feb 2024 16:22:04 -0800
Subject: CFV: New Core Libraries Group Member: Viktor Klang
In-Reply-To: <5a5a3d2c-34d7-f6fb-8736-c3bb5cf5d5fc@oracle.com>
References: <5a5a3d2c-34d7-f6fb-8736-c3bb5cf5d5fc@oracle.com>
Message-ID: 

Vote: Yes

On 2/19/24 3:40 PM, Stuart Marks wrote:
> 
> I hereby nominate Viktor Klang [6] to Membership in the Core Libraries Group [4].
> 

From bchristi at openjdk.org  Wed Feb 21 01:20:24 2024
From: bchristi at openjdk.org (Brent Christian)
Date: Wed, 21 Feb 2024 01:20:24 GMT
Subject: RFR: 8314480: Memory ordering spec updates in java.lang.ref [v8]
In-Reply-To: 
References: 
Message-ID: <3fEi5vgq7nDQDCgbWZ2bSEZAMXWNKMRc8vppLwP7R70=.e78cd44d-66b9-4c7c-b706-f7f9e5bcd0b9@github.com>

> 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."_

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

  Updates to reachabilityFence()

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16644/files
  - new: https://git.openjdk.org/jdk/pull/16644/files/7eb3397c..1ca169ec

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

  Stats: 6 lines in 1 file changed: 2 ins; 0 del; 4 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 duke at openjdk.org  Wed Feb 21 01:23:14 2024
From: duke at openjdk.org (Chris Hennick)
Date: Wed, 21 Feb 2024 01:23:14 GMT
Subject: RFR: 8326227: Rounding error that may distort computeNextGaussian
 results [v2]
In-Reply-To: 
References: 
Message-ID: 

> This provides a slightly more accurate bounding limit for `computeNextExponentialSoftCapped` when the computed bound is greater than `(1.0p53 - 1.0) * DoubleZigguratTables.exponentialX0`. This could cause the `while (computeNextExponentialSoftCapped(rng, limit) < limit)` check in `computeNextGaussian` on line 1402 to always be true, making the `nextGaussian` runtime unbounded in the worst case.

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

  Tweak boundary cases and add unit test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17703/files
  - new: https://git.openjdk.org/jdk/pull/17703/files/8af150e0..e68d03eb

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

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

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

From jpai at openjdk.org  Wed Feb 21 01:43:01 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 21 Feb 2024 01:43:01 GMT
Subject: RFR: 8326351: Update the Zlib version in
 open/src/java.base/share/legal/zlib.md to 1.3.1
In-Reply-To: 
References: 
Message-ID: 

On Tue, 20 Feb 2024 19:56:53 GMT, Lance Andersen  wrote:

> Please review the updates to open/src/java.base/share/legal/zlib.md to update the file  from zlib 1.2.13 to zlib 1.3.1 which was missed as part of the PR for [JDK-8324632](https://bugs.openjdk.org/browse/JDK-8324632)

The change looks good to me.

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17935#pullrequestreview-1891886887

From dholmes at openjdk.org  Wed Feb 21 01:56:00 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 21 Feb 2024 01:56:00 GMT
Subject: RFR: 8314480: Memory ordering spec updates in java.lang.ref [v8]
In-Reply-To: <3fEi5vgq7nDQDCgbWZ2bSEZAMXWNKMRc8vppLwP7R70=.e78cd44d-66b9-4c7c-b706-f7f9e5bcd0b9@github.com>
References: 
 <3fEi5vgq7nDQDCgbWZ2bSEZAMXWNKMRc8vppLwP7R70=.e78cd44d-66b9-4c7c-b706-f7f9e5bcd0b9@github.com>
Message-ID: <8HCDFFXZabfZmPP73HfWruxv5L3toGRUx_4m6QLaxzU=.f1905f08-8206-4754-9914-1711ba59e704@github.com>

On Wed, 21 Feb 2024 01:20:24 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."_
>
> Brent Christian has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updates to reachabilityFence()

src/java.base/share/classes/java/lang/ref/package-info.java line 118:

> 116:  *
> 117:  * 
  • The Cleaner thread dequeues a reference to a registered object before
> 118:  * running the cleaning action for that object.
    • 

Do you want to rephrase this so that it too mentions `happens-before`? e.g.

Dequeuing of a reference to a registered object, by the Cleaner thread, 
happens-before the execution of the cleaning action for that object.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16644#discussion_r1496767354

From duke at openjdk.org  Wed Feb 21 02:18:08 2024
From: duke at openjdk.org (Chris Hennick)
Date: Wed, 21 Feb 2024 02:18:08 GMT
Subject: RFR: 8326227: Rounding error that may distort computeNextGaussian
 results [v3]
In-Reply-To: 
References: 
Message-ID: 

> This provides a slightly more accurate bounding limit for `computeNextExponentialSoftCapped` when the computed bound is greater than `(1.0p53 - 1.0) * DoubleZigguratTables.exponentialX0`. This could cause the `while (computeNextExponentialSoftCapped(rng, limit) < limit)` check in `computeNextGaussian` on line 1402 to always be true, making the `nextGaussian` runtime unbounded in the worst case.

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

  Bug fix: add-exports was for wrong package

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17703/files
  - new: https://git.openjdk.org/jdk/pull/17703/files/e68d03eb..b8be051c

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

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

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

From duke at openjdk.org  Wed Feb 21 03:13:55 2024
From: duke at openjdk.org (Chris Hennick)
Date: Wed, 21 Feb 2024 03:13:55 GMT
Subject: RFR: 8326227: Rounding error that may distort computeNextGaussian
 results
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 20 Feb 2024 20:46:47 GMT, Joe Darcy  wrote:

>> This provides a slightly more accurate bounding limit for `computeNextExponentialSoftCapped` when the computed bound is greater than `(1.0p53 - 1.0) * DoubleZigguratTables.exponentialX0`. This could cause the `while (computeNextExponentialSoftCapped(rng, limit) < limit)` check in `computeNextGaussian` on line 1402 to always be true, making the `nextGaussian` runtime unbounded in the worst case.
>
> Is it practical to write a regression test for this situation?

@jddarcy Added a regression test. Once some of my GitHub Actions runners are free to run it, https://github.com/Pr0methean/jdk/actions/runs/7983430797 will confirm that the test fails without the fix.

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

PR Comment: https://git.openjdk.org/jdk/pull/17703#issuecomment-1955797533

From sgehwolf at openjdk.org  Wed Feb 21 09:09:59 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Wed, 21 Feb 2024 09:09:59 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v15]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 23 Jan 2024 15:46:04 GMT, Severin Gehwolf  wrote:

>> Please review this patch which adds a jlink mode to the JDK which doesn't need the packaged modules being present. A.k.a run-time image based jlink. 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 `JRTArchive` 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 jdk.jlink) <(../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.i...
>
> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename singleHop field.

I'm working on an update. Please keep open.

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

PR Comment: https://git.openjdk.org/jdk/pull/14787#issuecomment-1956190334

From shade at openjdk.org  Wed Feb 21 10:06:53 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 21 Feb 2024 10:06:53 GMT
Subject: RFR: 8326370: Remove redundant and misplaced micros from
 StringBuffers
In-Reply-To: <_uXLLG-AvKLqNwYCCAt7fJx0EblqQaQ4X8fH3MnxZLo=.437c87c3-a262-4c7a-9d3f-973a85bf2a90@github.com>
References: <_uXLLG-AvKLqNwYCCAt7fJx0EblqQaQ4X8fH3MnxZLo=.437c87c3-a262-4c7a-9d3f-973a85bf2a90@github.com>
Message-ID: <8Nk7upqIJTJ9G0kJyb9Ky0Uzo4q5MU8lV-YEsPbQCXo=.d2338a77-ee63-49ce-bf0c-12dcfd88cf48@github.com>

On Tue, 20 Feb 2024 20:58:50 GMT, Claes Redestad  wrote:

> Some microbenchmarks in org.openjdk.bench.java.lang.StringBuffers seem out-of-place (not testing `StringBuffer`), redundant (covered by other tests like StringSubstring or the various String concatenation tests), or both. This cleans them out. 
> 
> My apologies to Sigurd.

Marked as reviewed by shade (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17937#pullrequestreview-1892606135

From sspitsyn at openjdk.org  Wed Feb 21 10:36:05 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 21 Feb 2024 10:36:05 GMT
Subject: RFR: 8256314: JVM TI GetCurrentContendedMonitor is implemented
 incorrectly
Message-ID: <-Yf2Qj_kbyZAA-LDK96IIOcHWMh8__QT1XfnD9jR8kU=.507d5503-1544-44fb-9e81-438ba3458dcd@github.com>

The implementation of the JVM TI `GetCurrentContendedMonitor` does not match the spec. It can sometimes return an incorrect information about the contended monitor. Such a behavior does not match the function spec. 
With this update the `GetCurrentContendedMonitor` is returning the monitor only when the specified thread is waiting to enter or re-enter the monitor, and the monitor is not returned when the specified thread is waiting in the `java.lang.Object.wait` to be notified.

The implementation of the JDWP `ThreadReference.CurrentContendedMonitor` command is based and depends on this JVMTI function. The command was both specified incorrectly and had an incorrect behavior. The fix slightly corrects the JDWP spec to make it right (the JDWP implementation has been fixed by the JVM TI update). Please, see and review the related CSR and Release-Note.

CSR: [8326024](https://bugs.openjdk.org/browse/JDK-8326024): JVM TI GetCurrentContendedMonitor is implemented incorrectly
RN:   [8326038](https://bugs.openjdk.org/browse/JDK-8326038): Release Note: JVM TI GetCurrentContendedMonitor is implemented incorrectly

Testing:
 - tested with the mach5 tiers 1-6

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

Commit messages:
 - 8256314: JVM TI GetCurrentContendedMonitor is implemented incorrectly

Changes: https://git.openjdk.org/jdk/pull/17944/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17944&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8256314
  Stats: 46 lines in 5 files changed: 27 ins; 10 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/17944.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17944/head:pull/17944

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

From redestad at openjdk.org  Wed Feb 21 11:21:56 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 21 Feb 2024 11:21:56 GMT
Subject: RFR: 8326370: Remove redundant and misplaced micros from
 StringBuffers
In-Reply-To: <_uXLLG-AvKLqNwYCCAt7fJx0EblqQaQ4X8fH3MnxZLo=.437c87c3-a262-4c7a-9d3f-973a85bf2a90@github.com>
References: <_uXLLG-AvKLqNwYCCAt7fJx0EblqQaQ4X8fH3MnxZLo=.437c87c3-a262-4c7a-9d3f-973a85bf2a90@github.com>
Message-ID: <0hsd8DjfIFxO7bekU_41VtTRhYmjnwHwbrino-RkfWA=.e16e2c6e-9d8d-4883-b156-4fea2d4975cc@github.com>

On Tue, 20 Feb 2024 20:58:50 GMT, Claes Redestad  wrote:

> Some microbenchmarks in org.openjdk.bench.java.lang.StringBuffers seem out-of-place (not testing `StringBuffer`), redundant (covered by other tests like StringSubstring or the various String concatenation tests), or both. This cleans them out. 
> 
> My apologies to Sigurd.

Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/17937#issuecomment-1956432700

From redestad at openjdk.org  Wed Feb 21 11:21:57 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 21 Feb 2024 11:21:57 GMT
Subject: Integrated: 8326370: Remove redundant and misplaced micros from
 StringBuffers
In-Reply-To: <_uXLLG-AvKLqNwYCCAt7fJx0EblqQaQ4X8fH3MnxZLo=.437c87c3-a262-4c7a-9d3f-973a85bf2a90@github.com>
References: <_uXLLG-AvKLqNwYCCAt7fJx0EblqQaQ4X8fH3MnxZLo=.437c87c3-a262-4c7a-9d3f-973a85bf2a90@github.com>
Message-ID: <_Ecx093n4Qj6sXTsr5TPqZBkRt2uTJgEHRpvzKYzJUQ=.ed97f13c-cd37-407c-bf3d-9ba96b953a85@github.com>

On Tue, 20 Feb 2024 20:58:50 GMT, Claes Redestad  wrote:

> Some microbenchmarks in org.openjdk.bench.java.lang.StringBuffers seem out-of-place (not testing `StringBuffer`), redundant (covered by other tests like StringSubstring or the various String concatenation tests), or both. This cleans them out. 
> 
> My apologies to Sigurd.

This pull request has now been integrated.

Changeset: 5f16f342
Author:    Claes Redestad 
URL:       https://git.openjdk.org/jdk/commit/5f16f342d9be955b87054bf4b6369ed47cca964d
Stats:     38 lines in 1 file changed: 0 ins; 38 del; 0 mod

8326370: Remove redundant and misplaced micros from StringBuffers

Reviewed-by: shade

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

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

From michael.x.mcmahon at oracle.com  Wed Feb 21 11:50:03 2024
From: michael.x.mcmahon at oracle.com (Michael McMahon)
Date: Wed, 21 Feb 2024 11:50:03 +0000
Subject: CFV: New Core Libraries Group Member: Viktor Klang
In-Reply-To: <9f6a44d1-da01-4463-9adf-fcc0f3c07fd7@oracle.com>
References: <5a5a3d2c-34d7-f6fb-8736-c3bb5cf5d5fc@oracle.com>
 <9f6a44d1-da01-4463-9adf-fcc0f3c07fd7@oracle.com>
Message-ID: 

Vote: Yes

On 20/02/2024 17:51, Naoto Sato wrote:
> Vote: yes
>
> Naoto
>
> On 2/19/24 3:40 PM, Stuart Marks wrote:
>>
>> I hereby nominate Viktor Klang [6] to Membership in the Core 
>> Libraries Group [4].
>>
>> Viktor has been a member of the Java team in Oracle since 2022, and 
>> he is currently a Committer on the JDK project. Viktor has led JEP 
>> 461 [1], an enhancement to the Streams API to support new 
>> intermediate stream operations. Viktor has also contributed several 
>> other changes to the JDK [2][3], focusing primarily on the 
>> java.util.concurrent package. Prior to his work on OpenJDK, Viktor's 
>> past work includes Akka, Reactive Streams, and many other 
>> contributions to the Scala world.
>>
>> Votes are due by 23:59 UTC on March 4, 2024.
>>
>> Only current Members of the Core Libraries Group [4] are eligible to 
>> vote on this nomination. Votes must be cast in the open by replying 
>> to this mailing list.
>>
>> For Lazy Consensus voting instructions, see [5].
>>
>> s'marks
>>
>>
>> [1] https://openjdk.org/jeps/461
>> [2] https://github.com/openjdk/jdk/commits?author=vklang%40openjdk.org
>> [3] https://github.com/openjdk/jdk/commits?author=viktorklang-ora
>> [4] https://openjdk.org/census#core-libs
>> [5] https://openjdk.org/groups/#member-vote
>> [6] https://openjdk.org/census#vklang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From lancea at openjdk.org  Wed Feb 21 14:54:01 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 21 Feb 2024 14:54:01 GMT
Subject: Integrated: 8326351: Update the Zlib version in
 open/src/java.base/share/legal/zlib.md to 1.3.1
In-Reply-To: 
References: 
Message-ID: 

On Tue, 20 Feb 2024 19:56:53 GMT, Lance Andersen  wrote:

> Please review the updates to open/src/java.base/share/legal/zlib.md to update the file  from zlib 1.2.13 to zlib 1.3.1 which was missed as part of the PR for [JDK-8324632](https://bugs.openjdk.org/browse/JDK-8324632)

This pull request has now been integrated.

Changeset: f0f4d63f
Author:    Lance Andersen 
URL:       https://git.openjdk.org/jdk/commit/f0f4d63fa9c9f487198b2a2b7b410b590e1437bc
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8326351: Update the Zlib version in open/src/java.base/share/legal/zlib.md to 1.3.1

Reviewed-by: iris, naoto, jpai

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

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

From vklang at openjdk.org  Wed Feb 21 15:06:07 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Wed, 21 Feb 2024 15:06:07 GMT
Subject: RFR: 8325754: Dead AbstractQueuedSynchronizer$ConditionNodes survive
 minor garbage collections
Message-ID: 

More aggressively breaking chains in order to prevent nodes promoted to older generations standing in the way for collecting younger nodes. I decided that it was most efficient to add this logic to the else-branch of updating the firstWaiter and lastWaiter.

There's a race with unlinkCancelledWaiters() but according to @DougLea it should be a benign one.

There's a performance impact of this, but as it is a plain write, and one to null at that, it should be acceptable.

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

Commit messages:
 - Minimizes the risk of AQS & AQLS waiter queues to be prematurely promoted to old gen

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

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

From mbaesken at openjdk.org  Wed Feb 21 15:30:00 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 21 Feb 2024 15:30:00 GMT
Subject: RFR: JDK-8326389: [test] improve assertEquals failure output
Message-ID: 

Currently assertEquals has in the failure case sometimes confusing output like :

java.lang.RuntimeException: VM output should contain exactly one RTM locking statistics entry for method compiler.rtm.locking.TestRTMTotalCountIncrRate$Test:? expected 0 to equal 1
       at jdk.test.lib.Asserts.fail(Asserts.java:634)
       at jdk.test.lib.Asserts.assertEquals(Asserts.java:205)

(I don't think we really expected that for some reason 0 equals 1)
This should be improved.

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

Commit messages:
 - JDK-8326389

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

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

From sgibbons at openjdk.org  Wed Feb 21 15:51:09 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Wed, 21 Feb 2024 15:51:09 GMT
Subject: RFR: JDK-8320448 Accelerate IndexOf using AVX2 [v12]
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:

  Fix slowdebug compile issues.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16753/files
  - new: https://git.openjdk.org/jdk/pull/16753/files/71ebf9e7..62e4e8b1

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

  Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 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 Feb 21 15:53:56 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Wed, 21 Feb 2024 15:53:56 GMT
Subject: RFR: JDK-8320448 Accelerate IndexOf using AVX2 [v8]
In-Reply-To: 
References: 
 
 
 
Message-ID: <0FJI4QE-PYy7kUh6b76dZ1jsGQRGP3yR9UhkRsX9U3g=.0900c557-97ce-4be0-829b-79cf007b39c2@github.com>

On Tue, 20 Feb 2024 09:49:23 GMT, Jatin Bhateja  wrote:

>> Thank you all for the reviews.  I have been asked to simplify this code to facilitate easier review, and to remove the gcc library code I used for memcmp.  We also discovered that special-casing up to 31 bytes of needle was not necessary to get the performance gain.  I will be commenting the code and fixing the single build failure soon.
>
> Hi @asgibbons ,
> 
> I am getting following error with slowdebug build on Meteor Lake system.
> 
> 
> ERROR: Build failed for target 'images' in configuration 'linux-x86_64-server-slowdebug' (exit code 2) 
> 
> === Output from failing command(s) repeated here ===
> * For target buildtools_create_symbols_javac__the.COMPILE_CREATE_SYMBOLS_batch:
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #  Internal Error (/home/jatinbha/sandboxes/jdk-reviews/jdk/src/hotspot/share/asm/assembler.hpp:169), pid=237140, tid=237235
> #  assert(is_bound() || is_unused()) failed: Label was never bound to a location, but it was used as a jmp target
> #
> # JRE version: OpenJDK Runtime Environment (23.0) (slowdebug build 23-internal-adhoc.sdp.jdk)
> # Java VM: OpenJDK 64-Bit Server VM (slowdebug 23-internal-adhoc.sdp.jdk, mixed mode, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
> # Problematic frame:
> # V  [libjvm.so+0x4c9e3e]  Label::~Label()+0x5c
> #
> # Core dump will be written. Default location: Core dumps may be processed with "/usr/share/apport/apport -p%p -s%s -c%c -d%d -P%P -u%u -g%g -- %E" (or dumping to /home/jatinbha/sandboxes/jdk-reviews/jdk/make/core.237140)
> #
> # An error report file with more information is saved as:
> # /home/jatinbha/sandboxes/jdk-reviews/jdk/make/hs_err_pid237140.log
>    ... (rest of output omitted)

@jatin-bhateja Thanks for the note.  Fixed a couple of slowdebug compile issues.  Now builds successfully on Meteor Lake system.

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

PR Comment: https://git.openjdk.org/jdk/pull/16753#issuecomment-1957038856

From naoto at openjdk.org  Wed Feb 21 16:56:57 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 21 Feb 2024 16:56:57 GMT
Subject: Integrated: 8326158: Javadoc for java.time.DayOfWeek#minus(long)
In-Reply-To: 
References: 
Message-ID: <8m7lLxlKiiR8OsLb0yu6NXiC_id6TFa499EHpzoFOa8=.76ddfb7a-3752-4267-a71f-823ce5e313f5@github.com>

On Tue, 20 Feb 2024 18:34:59 GMT, Naoto Sato  wrote:

> Fixing a typo in the said method.

This pull request has now been integrated.

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

8326158: Javadoc for java.time.DayOfWeek#minus(long)

Reviewed-by: iris, lancea

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

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

From aefimov at openjdk.org  Wed Feb 21 18:28:54 2024
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Wed, 21 Feb 2024 18:28:54 GMT
Subject: RFR: 8325579: Inconsistent behavior in
 com.sun.jndi.ldap.Connection::createSocket [v5]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Tue, 20 Feb 2024 10:28:37 GMT, Christoph Langer  wrote:

> Hm, I think the test was overpurposed already.  

This test was added by JDK-8314063 fix, and I do not think it was change after that.
 
> Creating another test file with duplicating code does not sound too good IMHO. Maybe it is acceptable without the renaming?

I think it is acceptable. Currently, it is hard to separate the test cases for `a)` the original [JDK-8314063](https://bugs.openjdk.org/browse/JDK-8314063) fix (the opened socket is not closed properly when connection timeout occurs) and `b)` the current fix [JDK-8325579](https://bugs.openjdk.org/browse/JDK-8325579) (unconnected sockets are not supported by SocketFactory). It would be great to have this distinction in the modified test.

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

PR Comment: https://git.openjdk.org/jdk/pull/17797#issuecomment-1957632827

From amenkov at openjdk.org  Wed Feb 21 21:34:19 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Wed, 21 Feb 2024 21:34:19 GMT
Subject: RFR: JDK-8325530: Vague error message when
 com.sun.tools.attach.VirtualMachine fails to load agent library
Message-ID: 

VirtualMachine.loadAgentPath/loadAgentLibrary can fail with AgentLoadException in 2 cases:
- attach listener returns error; in the case the exception is thrown from HotSpotVirtualMachine.processCompletionStatus (called from HotSpotVirtualMachine.execute);
- attach listener returns success, but reply does not contain Agent_onAttach return code ("return code: %d" message).

before jdk21 if attach listener fails to load required library, it returned error (case 1)
from jdk21 attach listener always returns success (case 2)
Both cases are ok, but for 2nd case HotSpotVirtualMachine.loadAgentLibrary read only single line of the response message, so exception message didn't contain error details.

The fix updates HotSpotVirtualMachine.loadAgentLibrary to read the whole response message.
Walking through the code, fixed some other minor things in attach listener and attach API implementation (commented in the code)

Testing:
  - test/jdk/com/sun/tools;
  - tier1,tier2,tier5-svc

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

Commit messages:
 - fix

Changes: https://git.openjdk.org/jdk/pull/17954/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17954&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8325530
  Stats: 146 lines in 6 files changed: 106 ins; 16 del; 24 mod
  Patch: https://git.openjdk.org/jdk/pull/17954.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17954/head:pull/17954

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

From amenkov at openjdk.org  Wed Feb 21 21:34:19 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Wed, 21 Feb 2024 21:34:19 GMT
Subject: RFR: JDK-8325530: Vague error message when
 com.sun.tools.attach.VirtualMachine fails to load agent library
In-Reply-To: 
References: 
Message-ID: 

On Wed, 21 Feb 2024 21:13:36 GMT, Alex Menkov  wrote:

> VirtualMachine.loadAgentPath/loadAgentLibrary can fail with AgentLoadException in 2 cases:
> - attach listener returns error; in the case the exception is thrown from HotSpotVirtualMachine.processCompletionStatus (called from HotSpotVirtualMachine.execute);
> - attach listener returns success, but reply does not contain Agent_onAttach return code ("return code: %d" message).
> 
> before jdk21 if attach listener fails to load required library, it returned error (case 1)
> from jdk21 attach listener always returns success (case 2)
> Both cases are ok, but for 2nd case HotSpotVirtualMachine.loadAgentLibrary read only single line of the response message, so exception message didn't contain error details.
> 
> The fix updates HotSpotVirtualMachine.loadAgentLibrary to read the whole response message.
> Walking through the code, fixed some other minor things in attach listener and attach API implementation (commented in the code)
> 
> Testing:
>   - test/jdk/com/sun/tools;
>   - tier1,tier2,tier5-svc

src/hotspot/share/prims/jvmtiAgentList.cpp line 127:

> 125: }
> 126: 
> 127: void JvmtiAgentList::add(const char* name, const char* options, bool absolute_path) {

`options` parameter should be const

src/hotspot/share/prims/jvmtiAgentList.cpp line 131:

> 129: }
> 130: 
> 131: void JvmtiAgentList::add_xrun(const char* name, const char* options, bool absolute_path) {

`options` parameter should be const

src/hotspot/share/prims/jvmtiAgentList.cpp line 201:

> 199: 
> 200: // Invokes Agent_OnAttach for agents loaded dynamically during runtime.
> 201: jint JvmtiAgentList::load_agent(const char* agent_name, const char* absParam,

The method never returns error, dropped value return type

src/jdk.attach/share/classes/sun/tools/attach/HotSpotVirtualMachine.java line 402:

> 400:             }
> 401: 
> 402:             // Special-case the "load" command so that the right exception is

We had special logic for "load" command in 2 places (here and in the loadAgentLibrary method)
For simplification moved all logic to loadAgentLibrary()

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17954#discussion_r1498320621
PR Review Comment: https://git.openjdk.org/jdk/pull/17954#discussion_r1498320775
PR Review Comment: https://git.openjdk.org/jdk/pull/17954#discussion_r1498321476
PR Review Comment: https://git.openjdk.org/jdk/pull/17954#discussion_r1498333650

From amenkov at openjdk.org  Wed Feb 21 21:34:19 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Wed, 21 Feb 2024 21:34:19 GMT
Subject: RFR: JDK-8325530: Vague error message when
 com.sun.tools.attach.VirtualMachine fails to load agent library
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 21 Feb 2024 21:16:46 GMT, Alex Menkov  wrote:

>> VirtualMachine.loadAgentPath/loadAgentLibrary can fail with AgentLoadException in 2 cases:
>> - attach listener returns error; in the case the exception is thrown from HotSpotVirtualMachine.processCompletionStatus (called from HotSpotVirtualMachine.execute);
>> - attach listener returns success, but reply does not contain Agent_onAttach return code ("return code: %d" message).
>> 
>> before jdk21 if attach listener fails to load required library, it returned error (case 1)
>> from jdk21 attach listener always returns success (case 2)
>> Both cases are ok, but for 2nd case HotSpotVirtualMachine.loadAgentLibrary read only single line of the response message, so exception message didn't contain error details.
>> 
>> The fix updates HotSpotVirtualMachine.loadAgentLibrary to read the whole response message.
>> Walking through the code, fixed some other minor things in attach listener and attach API implementation (commented in the code)
>> 
>> Testing:
>>   - test/jdk/com/sun/tools;
>>   - tier1,tier2,tier5-svc
>
> src/hotspot/share/prims/jvmtiAgentList.cpp line 201:
> 
>> 199: 
>> 200: // Invokes Agent_OnAttach for agents loaded dynamically during runtime.
>> 201: jint JvmtiAgentList::load_agent(const char* agent_name, const char* absParam,
> 
> The method never returns error, dropped value return type

only 1 caller (load_agent() from attachListener) extract `absParam` from attach command, other pass constants ("true" or "false")
Moved conversion from string to bool there.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17954#discussion_r1498327164

From amenkov at openjdk.org  Wed Feb 21 21:42:08 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Wed, 21 Feb 2024 21:42:08 GMT
Subject: RFR: JDK-8325530: Vague error message when
 com.sun.tools.attach.VirtualMachine fails to load agent library [v2]
In-Reply-To: 
References: 
Message-ID: 

> VirtualMachine.loadAgentPath/loadAgentLibrary can fail with AgentLoadException in 2 cases:
> - attach listener returns error; in the case the exception is thrown from HotSpotVirtualMachine.processCompletionStatus (called from HotSpotVirtualMachine.execute);
> - attach listener returns success, but reply does not contain Agent_onAttach return code ("return code: %d" message).
> 
> before jdk21 if attach listener fails to load required library, it returned error (case 1)
> from jdk21 attach listener always returns success (case 2)
> Both cases are ok, but for 2nd case HotSpotVirtualMachine.loadAgentLibrary read only single line of the response message, so exception message didn't contain error details.
> 
> The fix updates HotSpotVirtualMachine.loadAgentLibrary to read the whole response message.
> Walking through the code, fixed some other minor things in attach listener and attach API implementation (commented in the code)
> 
> Testing:
>   - test/jdk/com/sun/tools;
>   - tier1,tier2,tier5-svc

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

  uncaught error

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17954/files
  - new: https://git.openjdk.org/jdk/pull/17954/files/19f0822e..0304bae2

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

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

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

From naoto at openjdk.org  Thu Feb 22 00:14:23 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 22 Feb 2024 00:14:23 GMT
Subject: RFR: 8309622: Re-examine the cache mechanism in BaseLocale [v7]
In-Reply-To: <5MqmN4P1TLKDCfXPhKWrH1b2FTgOXmjtKgd1bVXDd_M=.2000f20d-365d-48dc-bc37-45d8bcb9447f@github.com>
References: <5MqmN4P1TLKDCfXPhKWrH1b2FTgOXmjtKgd1bVXDd_M=.2000f20d-365d-48dc-bc37-45d8bcb9447f@github.com>
Message-ID: 

> This is stemming from the PR: https://github.com/openjdk/jdk/pull/14211 where aggressive GC can cause NPE in `BaseLocale$Key` class. I refactored the in-house cache with WeakHashMap, and removed the Key class as it is no longer needed (thus the original NPE will no longer be possible). Also with the new JMH test case, it gains some performance improvement:
> 
> (w/o fix)
> 
> Benchmark                       Mode  Cnt      Score     Error  Units
> LocaleCache.testForLanguageTag  avgt   20   5781.275 ? 569.580  ns/op
> LocaleCache.testLocaleOf        avgt   20  62564.079 ? 406.697  ns/op
> 
> (w/ fix)
> Benchmark                       Mode  Cnt      Score     Error  Units
> LocaleCache.testForLanguageTag  avgt   20   4801.175 ? 371.830  ns/op
> LocaleCache.testLocaleOf        avgt   20  60394.652 ? 352.471  ns/op

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

 - Use ReferencedKeySet.intern()
 - Merge branch 'master' into JDK-8309622-Cache-BaseLocale
 - Merge branch 'master' into JDK-8309622-Cache-BaseLocale
 - Restored the test
 - Merge branch 'master' into JDK-8309622-Cache-BaseLocale
 - Merge branch 'master' of https://git.openjdk.org/jdk into JDK-8309622-Cache-BaseLocale
 - small cleanup
 - Merge branch 'pull/14684' into JDK-8309622-Cache-BaseLocale
 - Update ReferencedKeyTest.java
 - Simple versions of create
 - ... and 24 more: https://git.openjdk.org/jdk/compare/b419e951...32ec51f7

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

Changes: https://git.openjdk.org/jdk/pull/14404/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14404&range=06
  Stats: 524 lines in 6 files changed: 129 ins; 267 del; 128 mod
  Patch: https://git.openjdk.org/jdk/pull/14404.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14404/head:pull/14404

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

From tprinzing at openjdk.org  Thu Feb 22 01:04:25 2024
From: tprinzing at openjdk.org (Tim Prinzing)
Date: Thu, 22 Feb 2024 01:04:25 GMT
Subject: RFR: 8310994: Add JFR event for selection operations [v5]
In-Reply-To: 
References: 
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

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

 - update copyright dates
 - Merge branch 'master' into JDK-8310994
   
   # Conflicts:
   #	src/jdk.jfr/share/classes/jdk/jfr/internal/MirrorEvents.java
   #	src/jdk.jfr/share/classes/jdk/jfr/internal/instrument/JDKEvents.java
 - comment fixup
 - add select timeout field to the event
 - Change event generation:
   
   - selectNow is filtered out
   - select that times out is always sent
   - select without timeout uses duration test
 - rename event to SelectorSelect, field to selectionKeyCount.
 - Merge branch 'master' into JDK-8310994
 - remove trailing whitespace
 - event logic outside of the lock, selector in try block
 - remove unused import
 - ... and 6 more: https://git.openjdk.org/jdk/compare/36246c97...2e11e84a

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

Changes: https://git.openjdk.org/jdk/pull/16710/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16710&range=04
  Stats: 321 lines in 9 files changed: 317 ins; 0 del; 4 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 bchristi at openjdk.org  Thu Feb 22 01:09:58 2024
From: bchristi at openjdk.org (Brent Christian)
Date: Thu, 22 Feb 2024 01:09:58 GMT
Subject: RFR: 8314480: Memory ordering spec updates in java.lang.ref [v8]
In-Reply-To: <8HCDFFXZabfZmPP73HfWruxv5L3toGRUx_4m6QLaxzU=.f1905f08-8206-4754-9914-1711ba59e704@github.com>
References: 
 <3fEi5vgq7nDQDCgbWZ2bSEZAMXWNKMRc8vppLwP7R70=.e78cd44d-66b9-4c7c-b706-f7f9e5bcd0b9@github.com>
 <8HCDFFXZabfZmPP73HfWruxv5L3toGRUx_4m6QLaxzU=.f1905f08-8206-4754-9914-1711ba59e704@github.com>
Message-ID: <8Ny8J3Dx66XC4l4Og78WAIsNVKBRb7Vs8vM8cZ2qTyw=.8c933b85-b6e4-4615-950b-9019de4ed8dd@github.com>

On Wed, 21 Feb 2024 01:52:57 GMT, David Holmes  wrote:

>> Brent Christian has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updates to reachabilityFence()
>
> src/java.base/share/classes/java/lang/ref/package-info.java line 118:
> 
>> 116:  *
>> 117:  * 
  • The Cleaner thread dequeues a reference to a registered object before
>> 118:  * running the cleaning action for that object.
    • 
> 
> Do you want to rephrase this so that it too mentions `happens-before`? e.g.
> 
> Dequeuing of a reference to a registered object, by the Cleaner thread, 
> happens-before the execution of the cleaning action for that object.

I hesitated to state it that way because there's not a synchronization action _per se_ between the Cleaning thread dequeuing, and then running the cleaning action.

However, I see that JLS 17.4.5 does state:
_"If x and y are actions of the same thread and x comes before y in program order, then hb(x, y)."_
(That is, x _happens-before_ y).

So yes, we can say _happens-before_ here. Thanks!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16644#discussion_r1498493650

From bchristi at openjdk.org  Thu Feb 22 01:42:17 2024
From: bchristi at openjdk.org (Brent Christian)
Date: Thu, 22 Feb 2024 01:42:17 GMT
Subject: RFR: 8314480: Memory ordering spec updates in java.lang.ref [v9]
In-Reply-To: 
References: 
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."_

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

  Cleaner thread dequeue happens-before running cleaning action

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16644/files
  - new: https://git.openjdk.org/jdk/pull/16644/files/1ca169ec..0f949d3c

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

  Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 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 dholmes at openjdk.org  Thu Feb 22 01:49:56 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 22 Feb 2024 01:49:56 GMT
Subject: RFR: 8314480: Memory ordering spec updates in java.lang.ref [v9]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 22 Feb 2024 01:42:17 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."_
>
> Brent Christian has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Cleaner thread dequeue happens-before running cleaning action

Looks good.

It is a thumbs up from me.

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16644#pullrequestreview-1894716637

From duke at openjdk.org  Thu Feb 22 03:04:59 2024
From: duke at openjdk.org (Chris Hennick)
Date: Thu, 22 Feb 2024 03:04:59 GMT
Subject: RFR: 8326227: Rounding error that may distort computeNextGaussian
 results [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 21 Feb 2024 02:18:08 GMT, Chris Hennick  wrote:

>> This provides a slightly more accurate bounding limit for `computeNextExponentialSoftCapped` when the computed bound is greater than `(1.0p53 - 1.0) * DoubleZigguratTables.exponentialX0`. This could cause the `while (computeNextExponentialSoftCapped(rng, limit) < limit)` check in `computeNextGaussian` on line 1402 to always be true, making the `nextGaussian` runtime unbounded in the worst case.
>> 
>> This change is being tested prior to submission to OpenJDK by https://github.com/openjdk/jdk/pull/17703/commits/b8be051cbf40a6a05fafc6a2c76942e9e0b11fdf.
>
> Chris Hennick has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Bug fix: add-exports was for wrong package

Update: confirmed that the new test fails without the fix.

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

PR Comment: https://git.openjdk.org/jdk/pull/17703#issuecomment-1958571446

From sgibbons at openjdk.org  Thu Feb 22 03:15:10 2024
From: sgibbons at openjdk.org (Scott Gibbons)
Date: Thu, 22 Feb 2024 03:15:10 GMT
Subject: RFR: JDK-8320448 Accelerate IndexOf using AVX2 [v13]
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:

  Addressed some review coments; replaced hard-coded registers with descriptive names.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16753/files
  - new: https://git.openjdk.org/jdk/pull/16753/files/62e4e8b1..82bcd8b3

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

  Stats: 484 lines in 3 files changed: 174 ins; 80 del; 230 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 liach at openjdk.org  Thu Feb 22 05:38:19 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 22 Feb 2024 05:38:19 GMT
Subject: RFR: 8323707: Adjust Classfile API's type arg model to better
 represent the embodied type [v3]
In-Reply-To: 
References: 
Message-ID: 

> API changes as discussed on the mailing list: https://mail.openjdk.org/pipermail/classfile-api-dev/2023-November/000419.html
> 
> Additional questions:
> 1. Whether to rename `WildcardIndicator.DEFAULT` to `NONE`

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

 - Rename no wildcard indicator, improve docs slightly
 - Merge branch 'master' of https://github.com/openjdk/jdk into fix/typearg-model
 - Merge branch 'master' into fix/typearg-model
 - redundant line
 - Fix a test in langtools, copyright year
 - Merge branch 'master' of https://github.com/openjdk/jdk into fix/typearg-model
 - Implementation cleanup, test update
 - Merge branch 'master' into fix/typearg-model
 - Formatting
 - Nuke signatureString and fix test fialure from bad cast
 - ... and 1 more: https://git.openjdk.org/jdk/compare/0bcece99...62d25642

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

Changes: https://git.openjdk.org/jdk/pull/16517/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16517&range=02
  Stats: 132 lines in 6 files changed: 49 ins; 32 del; 51 mod
  Patch: https://git.openjdk.org/jdk/pull/16517.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16517/head:pull/16517

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

From liach at openjdk.org  Thu Feb 22 05:41:55 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 22 Feb 2024 05:41:55 GMT
Subject: RFR: 8323707: Adjust Classfile API's type arg model to better
 represent the embodied type [v3]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Mon, 19 Feb 2024 15:28:23 GMT, David M. Lloyd  wrote:

>> src/java.base/share/classes/java/lang/classfile/Signature.java line 219:
>> 
>>> 217:                  * no wildcard (empty), an exact type
>>> 218:                  */
>>> 219:                 DEFAULT,
>> 
>> I?m?personally in?favour of?naming this?`NONE`.
>
> A belated +1 to this, at least not calling it `DEFAULT` because that has at best no meaning, and at worst it's outright confusing. If not `NONE`, then what about `EXACT`?
> 
> In my own old parsing code I have an enum called `Variance` with values `INVARIANT`, `COVARIANT`, and `CONTRAVARIANT`, but that might be a bit confusing considering that `EXTENDS` and `SUPER` match the Java language keywords directly.
> 
> As an aside, the javadoc here could be a little better IMO.

Performed the rename. `NONE` is better than `EXACT`, as there indeed is no indicator char for this bounded type argument.

I have added the terms of `invariant` `covariant` `contravariant` to the docs, so that they can be searched with the Javadoc search function. (These are official CS terms so shouldn't be ambiguous)

I decided not too add exact descriptions, like "method parameters EXTENDS can only accept null" or "method return type SUPER can only return Object". These details of Java type system may be subject to change in the future, and this is really describing details of a ClassFile attribute instead of the Java type system.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16517#discussion_r1498670793

From darcy at openjdk.org  Thu Feb 22 05:42:56 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 22 Feb 2024 05:42:56 GMT
Subject: RFR: 8326227: Rounding error that may distort computeNextGaussian
 results [v3]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Thu, 22 Feb 2024 03:01:58 GMT, Chris Hennick  wrote:

> Update: confirmed that the new test fails without the fix.

Thanks for verifying the test checks the fix; I'll let others who have worked more directly on the random code review the actual fix.

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

PR Comment: https://git.openjdk.org/jdk/pull/17703#issuecomment-1958740871

From liach at openjdk.org  Thu Feb 22 05:45:54 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 22 Feb 2024 05:45:54 GMT
Subject: RFR: 8323707: Adjust Classfile API's type arg model to better
 represent the embodied type [v3]
In-Reply-To: 
References: 
 
Message-ID: <3ybH_l-uRy3HOz9raNFBRoFGgfuUCTsf-sh357NSkZk=.880ccd32-fcc8-4e70-b08d-1fc350ea19d5@github.com>

On Thu, 22 Feb 2024 05:38:19 GMT, Chen Liang  wrote:

>> API changes as discussed on the mailing list: https://mail.openjdk.org/pipermail/classfile-api-dev/2023-November/000419.html
>> 
>> Additional questions:
>> 1. Whether to rename `WildcardIndicator.DEFAULT` to `NONE`
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:
> 
>  - Rename no wildcard indicator, improve docs slightly
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/typearg-model
>  - Merge branch 'master' into fix/typearg-model
>  - redundant line
>  - Fix a test in langtools, copyright year
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/typearg-model
>  - Implementation cleanup, test update
>  - Merge branch 'master' into fix/typearg-model
>  - Formatting
>  - Nuke signatureString and fix test fialure from bad cast
>  - ... and 1 more: https://git.openjdk.org/jdk/compare/0bcece99...62d25642

@asotona How does this patch look for the roadmap of Class-File API 2nd review? Brian agreed to it before, will we consider or reject this?

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

PR Comment: https://git.openjdk.org/jdk/pull/16517#issuecomment-1958743153

From syan at openjdk.org  Thu Feb 22 07:27:12 2024
From: syan at openjdk.org (SendaoYan)
Date: Thu, 22 Feb 2024 07:27:12 GMT
Subject: RFR: 8326461: tools/jlink/CheckExecutable.java fail after JDK-8325342
Message-ID: 

Before JDK-8325342(commit id:0bcece995840777db660811e4b20bb018e90439b), all the files in build/linux-x86_64-server-release/images/jdk/bin are executable:

![image](https://github.com/openjdk/jdk/assets/24123821/13f0eae2-7125-4d09-8793-8a5a10b785c2)


After JDK-8325342, all the *.debuginfo files in build/linux-x86_64-server-release/images/jdk/bin are not executable:

![image](https://github.com/openjdk/jdk/assets/24123821/c8d190f2-3db0-439b-82b9-5121567cb1d5)


This PR only modifies the testcase to adapt to the modification of the corresponding build script, ignoring the check of debuginfo file executable permissions, and the risk is low

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

Commit messages:
 - 8326461: tools/jlink/CheckExecutable.java fail after JDK-8325342

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

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

From alanb at openjdk.org  Thu Feb 22 08:36:52 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 22 Feb 2024 08:36:52 GMT
Subject: RFR: 8326461: tools/jlink/CheckExecutable.java fail after
 JDK-8325342
In-Reply-To: 
References: 
Message-ID: <4TysyxqSaq0tk4LCVYph44uQNkZUNaDBtkwM_I_TSuU=.13b149ab-6ff7-469d-a785-06ee7b0d6e3c@github.com>

On Thu, 22 Feb 2024 07:23:04 GMT, SendaoYan  wrote:

> Before JDK-8325342(commit id:0bcece995840777db660811e4b20bb018e90439b), all the files in build/linux-x86_64-server-release/images/jdk/bin are executable:
> 
> ![image](https://github.com/openjdk/jdk/assets/24123821/13f0eae2-7125-4d09-8793-8a5a10b785c2)
> 
> 
> After JDK-8325342, all the *.debuginfo files in build/linux-x86_64-server-release/images/jdk/bin are not executable:
> 
> ![image](https://github.com/openjdk/jdk/assets/24123821/c8d190f2-3db0-439b-82b9-5121567cb1d5)
> 
> 
> This PR only modifies the testcase to adapt to the modification of the corresponding build script, ignoring the check of debuginfo file executable permissions, and the risk is low

JDK-8326412 changed the executable bit on the debuginfo files but forgot to update this test.

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

PR Comment: https://git.openjdk.org/jdk/pull/17958#issuecomment-1958947943

From shade at openjdk.org  Thu Feb 22 08:43:54 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 22 Feb 2024 08:43:54 GMT
Subject: RFR: 8326461: tools/jlink/CheckExecutable.java fail after
 JDK-8325342
In-Reply-To: 
References: 
Message-ID: 

On Thu, 22 Feb 2024 07:23:04 GMT, SendaoYan  wrote:

> Before JDK-8325342(commit id:0bcece995840777db660811e4b20bb018e90439b), all the files in build/linux-x86_64-server-release/images/jdk/bin are executable:
> 
> ![image](https://github.com/openjdk/jdk/assets/24123821/13f0eae2-7125-4d09-8793-8a5a10b785c2)
> 
> 
> After JDK-8325342, all the *.debuginfo files in build/linux-x86_64-server-release/images/jdk/bin are not executable:
> 
> ![image](https://github.com/openjdk/jdk/assets/24123821/c8d190f2-3db0-439b-82b9-5121567cb1d5)
> 
> 
> This PR only modifies the testcase to adapt to the modification of the corresponding build script, ignoring the check of debuginfo file executable permissions, and the risk is low

Looks fine to me.

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17958#pullrequestreview-1895241663

From alanb at openjdk.org  Thu Feb 22 08:51:54 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 22 Feb 2024 08:51:54 GMT
Subject: RFR: 8326461: tools/jlink/CheckExecutable.java fail after
 JDK-8325342
In-Reply-To: 
References: 
Message-ID: <6ppNRxE3wQzTZLn8MqoR70HjFyCEX-Kd3QIm9Km05cI=.80a83a55-7e10-4e0c-8a40-4db4e782edde@github.com>

On Thu, 22 Feb 2024 07:23:04 GMT, SendaoYan  wrote:

> Before JDK-8325342(commit id:0bcece995840777db660811e4b20bb018e90439b), all the files in build/linux-x86_64-server-release/images/jdk/bin are executable:
> 
> ![image](https://github.com/openjdk/jdk/assets/24123821/13f0eae2-7125-4d09-8793-8a5a10b785c2)
> 
> 
> After JDK-8325342, all the *.debuginfo files in build/linux-x86_64-server-release/images/jdk/bin are not executable:
> 
> ![image](https://github.com/openjdk/jdk/assets/24123821/c8d190f2-3db0-439b-82b9-5121567cb1d5)
> 
> 
> This PR only modifies the testcase to adapt to the modification of the corresponding build script, ignoring the check of debuginfo file executable permissions, and the risk is low

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17958#pullrequestreview-1895258187

From vklang at openjdk.org  Thu Feb 22 09:10:59 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Thu, 22 Feb 2024 09:10:59 GMT
Subject: RFR: 8314480: Memory ordering spec updates in java.lang.ref [v9]
In-Reply-To: 
References: 
 
Message-ID: <0v28_FMJnjmoOLTL4navEWDAT3DAnfJZRzccbu5-ljU=.9b7e3d63-9e1f-4049-a5e6-17ee0cf451aa@github.com>

On Thu, 22 Feb 2024 01:42:17 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."_
>
> Brent Christian has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Cleaner thread dequeue happens-before running cleaning action

src/java.base/share/classes/java/lang/ref/Reference.java line 550:

> 548:      * strongly reachable.
> 549:      * This reachability is assured regardless of any optimizing transformations
> 550:      * the VM may perform that might otherwise allow the object to become

since "the virtual machine" is spelt out later in the documentation I think we should do the same here.

Suggestion:

     * the virtual machine may perform that might otherwise allow the object to become

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16644#discussion_r1498900890

From vklang at openjdk.org  Thu Feb 22 09:13:58 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Thu, 22 Feb 2024 09:13:58 GMT
Subject: RFR: 8314480: Memory ordering spec updates in java.lang.ref [v9]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 22 Feb 2024 01:42:17 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."_
>
> Brent Christian has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Cleaner thread dequeue happens-before running cleaning action

@bchristi-git Made a suggestion, but beyond that this looks great to me. Thanks for putting this together!

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

PR Comment: https://git.openjdk.org/jdk/pull/16644#issuecomment-1959006509

From jpai at openjdk.org  Thu Feb 22 09:54:13 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 22 Feb 2024 09:54:13 GMT
Subject: RFR: 8278527: java/util/concurrent/tck/JSR166TestCase.java fails
 nanoTime test
Message-ID: 

Can I get a review of this change which proposes to remove the `SystemTest` from among the `JSR166TestCase`?

As noted in https://bugs.openjdk.org/browse/JDK-8278527 the `SystemTest.nanoTime` test has been intermittently failing since a few years now. Martin and Paul have investigated this failure in the past and they note that this test is fragile and should be removed:

https://bugs.openjdk.org/browse/JDK-8278527?focusedId=14463658&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14463658

https://bugs.openjdk.org/browse/JDK-8278527?focusedId=14508958&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14508958

The commit in this PR removes the `SystemTest` that was enrolled into `JSR166TestCase`.

tier1 testing went fine with this change.

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

Commit messages:
 - 8278527: java/util/concurrent/tck/JSR166TestCase.java fails nanoTime test

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

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

From syan at openjdk.org  Thu Feb 22 10:02:00 2024
From: syan at openjdk.org (SendaoYan)
Date: Thu, 22 Feb 2024 10:02:00 GMT
Subject: Integrated: 8326461: tools/jlink/CheckExecutable.java fails as
 .debuginfo files are not executable
In-Reply-To: 
References: 
Message-ID: <6Bxb_yY3Bk4JEHMTcWtYh7ZVyRkolz3rErqXGq35hgQ=.b6f4d041-959a-4193-8085-920d04d9ccb9@github.com>

On Thu, 22 Feb 2024 07:23:04 GMT, SendaoYan  wrote:

> Before JDK-8325342(commit id:0bcece995840777db660811e4b20bb018e90439b), all the files in build/linux-x86_64-server-release/images/jdk/bin are executable:
> 
> ![image](https://github.com/openjdk/jdk/assets/24123821/13f0eae2-7125-4d09-8793-8a5a10b785c2)
> 
> 
> After JDK-8325342, all the *.debuginfo files in build/linux-x86_64-server-release/images/jdk/bin are not executable:
> 
> ![image](https://github.com/openjdk/jdk/assets/24123821/c8d190f2-3db0-439b-82b9-5121567cb1d5)
> 
> 
> This PR only modifies the testcase to adapt to the modification of the corresponding build script, ignoring the check of debuginfo file executable permissions, and the risk is low

This pull request has now been integrated.

Changeset: cc1e216e
Author:    SendaoYan 
Committer: Alan Bateman 
URL:       https://git.openjdk.org/jdk/commit/cc1e216eb9e4c817f6744ec76d62f21f4bd14489
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8326461: tools/jlink/CheckExecutable.java fails as .debuginfo files are not executable

Reviewed-by: shade, alanb

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

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

From aturbanov at openjdk.org  Thu Feb 22 11:26:54 2024
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Thu, 22 Feb 2024 11:26:54 GMT
Subject: RFR: JDK-8325898: ChoiceFormat returns erroneous result when
 formatting bad pattern
In-Reply-To: 
References: 
Message-ID: 

On Thu, 15 Feb 2024 19:44:42 GMT, Justin Lu  wrote:

> Please review this PR which handles an edge case pattern bug with ChoiceFormat.
> 
> 
> var d = new ChoiceFormat("0#foo|1#bar|baz|") // creates cFmt equivalent to "0.0#foo|1.0#bar|1.0#"
> d.format(1) // unexpectedly returns ""
> 
> 
> Not only does this lead to faulty formatting results, but breaks the ChoiceFormat class invariant of duplicate limits.
> 
> It would have been preferable if either an exception was thrown when the ChoiceFormat was initially created, or the ChoiceFormat formatting 1 returned a value of "bar".
> 
> For comparison,
> 
> var d = new ChoiceFormat("0#foo|1#bar|baz") // creates cFmt equivalent to "0.0#foo|1.0#bar"
> d.format(1) // returns "bar"
> 
> 
> After this change, the first code snippet now returns "bar" when formatting 1 and discards the "baz" as the second code snippet does.
> 
> 
> This PR includes a lot of cleanup to the applyPattern implementation, the specific fix for this bug is addressed with the following, on line 305,
> 
> if (seg != Segment.FORMAT) {
>     // Discard incorrect portion and finish building cFmt
>     break;
> }
> 
> This prevents a limit/format entry from being built when the current parsing mode has not yet processed the limit and relation. The previous implementation would build an additional limit/format of 1 with an empty string. The `break` allows for the discarding of the incorrect portion and continuing. Alternatively an exception could have been thrown. For consistency with the second code snippet, the former was picked.
> 
> https://github.com/openjdk/jdk/pull/17856 may be of interest, which is a semi-related specification fix.

src/java.base/share/classes/java/text/ChoiceFormat.java line 268:

> 266:         for (int i = 0; i < newPattern.length(); ++i) {
> 267:             char ch = newPattern.charAt(i);
> 268:             switch(ch) {

Suggestion:

            switch (ch) {

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17883#discussion_r1499095669

From clanger at openjdk.org  Thu Feb 22 11:40:56 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Thu, 22 Feb 2024 11:40:56 GMT
Subject: RFR: 8325579: Inconsistent behavior in
 com.sun.jndi.ldap.Connection::createSocket [v5]
In-Reply-To: 
References: 
 
 
 
 
Message-ID: 

On Wed, 21 Feb 2024 18:26:18 GMT, Aleksei Efimov  wrote:

>>> Currently, it is hard to distinguish what part of the test responsible for [JDK-8314063](https://bugs.openjdk.org/browse/JDK-8314063) testing, and which part is for [JDK-8325579](https://bugs.openjdk.org/browse/JDK-8325579). I would prefer to add a new test for the current fix instead: that could be done as additional test mode, OR even better to add a completely new test. 
>> 
>> Hm, I think the test was overpurposed already. Creating another test file with duplicating code does not sound too good IMHO. Maybe it is acceptable without the renaming?
>> 
>> Another question: Do we need a CSR/Release note as there is some behavioral change involved (although it should always have been like with this change)?
>
>> Hm, I think the test was overpurposed already.  
> 
> This test was added by JDK-8314063 fix, and I do not think it was change after that.
>  
>> Creating another test file with duplicating code does not sound too good IMHO. Maybe it is acceptable without the renaming?
> 
> I think it is acceptable. Currently, it is hard to separate the test cases for `a)` the original [JDK-8314063](https://bugs.openjdk.org/browse/JDK-8314063) fix (the opened socket is not closed properly when connection timeout occurs) and `b)` the current fix [JDK-8325579](https://bugs.openjdk.org/browse/JDK-8325579) (unconnected sockets are not supported by SocketFactory). It would be great to have this distinction in the modified test.

I drafted a CSR. @AlekseiEfimov, would be nice if you could review it.

As for the test, I had a closer look now and I find it hard to separate testing of [JDK-8314063](https://bugs.openjdk.org/browse/JDK-8314063) from [JDK-8325579](https://bugs.openjdk.org/browse/JDK-8325579). Furthermore, most of the entries test things that hadn't been addressed by any of these two bugs at all.

So, [JDK-8314063](https://bugs.openjdk.org/browse/JDK-8314063) is only tested in lines 72, 73, 76 and 77
The original problem of this issue [JDK-8325579](https://bugs.openjdk.org/browse/JDK-8325579) is touched in line 71 and 73.

That means, most of the other test invocations test some generic behavior which was never erroneous so far.

I could, however, give each line its own test id and annotate the bugs accordingly. Do you think that makes sense?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17797#issuecomment-1959271452

From alanb at openjdk.org  Thu Feb 22 11:59:54 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 22 Feb 2024 11:59:54 GMT
Subject: RFR: 8325754: Dead AbstractQueuedSynchronizer$ConditionNodes
 survive minor garbage collections
In-Reply-To: 
References: 
Message-ID: 

On Wed, 21 Feb 2024 15:01:15 GMT, Viktor Klang  wrote:

> More aggressively breaking chains in order to prevent nodes promoted to older generations standing in the way for collecting younger nodes. I decided that it was most efficient to add this logic to the else-branch of updating the firstWaiter and lastWaiter.
> 
> There's a race with unlinkCancelledWaiters() but according to @DougLea it should be a benign one.
> 
> There's a performance impact of this, but as it is a plain write, and one to null at that, it should be acceptable.

If the race with unlinking non-waiting nodes is benign then this should be okay.

-------------

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17950#pullrequestreview-1895672384

From djelinski at openjdk.org  Thu Feb 22 12:08:02 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 22 Feb 2024 12:08:02 GMT
Subject: RFR: 8314480: Memory ordering spec updates in java.lang.ref [v9]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 22 Feb 2024 01:42:17 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."_
>
> Brent Christian has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Cleaner thread dequeue happens-before running cleaning action

src/java.base/share/classes/java/lang/ref/Reference.java line 491:

> 489:      * If this reference is not registered with a queue, or was already enqueued
> 490:      * (by the garbage collector, or a previous call to {@code enqueue}), this
> 491:      * method is unnsuccessful and returns false.

Suggestion:

     * method is unsuccessful and returns false.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16644#discussion_r1499140107

From djelinski at openjdk.org  Thu Feb 22 12:08:02 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 22 Feb 2024 12:08:02 GMT
Subject: RFR: 8314480: Memory ordering spec updates in java.lang.ref [v9]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Thu, 22 Feb 2024 12:04:05 GMT, Daniel Jeli?ski  wrote:

>> Brent Christian has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Cleaner thread dequeue happens-before running cleaning action
>
> src/java.base/share/classes/java/lang/ref/Reference.java line 491:
> 
>> 489:      * If this reference is not registered with a queue, or was already enqueued
>> 490:      * (by the garbage collector, or a previous call to {@code enqueue}), this
>> 491:      * method is unnsuccessful and returns false.
> 
> Suggestion:
> 
>      * method is unsuccessful and returns false.

or, better yet, `fails`

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16644#discussion_r1499141654

From sspitsyn at openjdk.org  Thu Feb 22 13:24:56 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 22 Feb 2024 13:24:56 GMT
Subject: RFR: JDK-8325530: Vague error message when
 com.sun.tools.attach.VirtualMachine fails to load agent library [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 21 Feb 2024 21:42:08 GMT, Alex Menkov  wrote:

>> VirtualMachine.loadAgentPath/loadAgentLibrary can fail with AgentLoadException in 2 cases:
>> - attach listener returns error; in the case the exception is thrown from HotSpotVirtualMachine.processCompletionStatus (called from HotSpotVirtualMachine.execute);
>> - attach listener returns success, but reply does not contain Agent_onAttach return code ("return code: %d" message).
>> 
>> before jdk21 if attach listener fails to load required library, it returned error (case 1)
>> from jdk21 attach listener always returns success (case 2)
>> Both cases are ok, but for 2nd case HotSpotVirtualMachine.loadAgentLibrary read only single line of the response message, so exception message didn't contain error details.
>> 
>> The fix updates HotSpotVirtualMachine.loadAgentLibrary to read the whole response message.
>> Walking through the code, fixed some other minor things in attach listener and attach API implementation (commented in the code)
>> 
>> Testing:
>>   - test/jdk/com/sun/tools;
>>   - tier1,tier2,tier5-svc
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   uncaught error

src/jdk.attach/share/classes/sun/tools/attach/HotSpotVirtualMachine.java line 113:

> 111:                 }
> 112:             } else {
> 113:                 String msg = "Failed to load agent library";

Nit: The line 113 can be moved above the line 99, so the `msg` could be also used at line 122 instead of a literal use of the string.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17954#discussion_r1499234830

From eirbjo at openjdk.org  Thu Feb 22 14:04:07 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Thu, 22 Feb 2024 14:04:07 GMT
Subject: RFR: 8326096: Deprecate getTotalIn,
 getTotalOut methods of java.util.zip.Inflater, java.util.zip.Deflater [v5]
In-Reply-To: 
References: 
Message-ID: 

> Please review this PR which proposes that we officially deprecate the following four methods in the `java.util.zip` package:
> 
> * `Inflater.getTotalIn()`
> * `Inflater.getTotalOut()`
> * `Deflater.getTotalIn()`
> * `Deflater.getTotalOut()`
> 
> Since these legacy methods return `int`, they cannot safely return the number of bytes processed without the risk of losing information  about the magnitude or even sign of the returned value.
> 
> The corresponding methods `getBytesRead()` and `getBytesWritten()` methods introduced in Java 5 return `long`, and should be used instead when obtaining this information. 
> 
> Unrelated to the deprecation itself, the documentation currently does not specify what these methods are expected to return when the number of processed bytes is higher than `Integer.MAX_VALUE`. This PR aims to clarify this in the API specification.
> 
> Initally, this PR handles only `Inflater.getTotalIn()`. The other three methods will be updated once the wordsmithing for this method stabilizes.

Eirik Bj?rsn?s has updated the pull request incrementally with two additional commits since the last revision:

 - Remove empty line
 - Add back a note to specify the long-standing behavior of discarding the highest 32 bits of the return value

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17919/files
  - new: https://git.openjdk.org/jdk/pull/17919/files/86695619..44323ab0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17919&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17919&range=03-04

  Stats: 10 lines in 1 file changed: 10 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/17919.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17919/head:pull/17919

PR: https://git.openjdk.org/jdk/pull/17919

From eirbjo at openjdk.org  Thu Feb 22 14:08:57 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Thu, 22 Feb 2024 14:08:57 GMT
Subject: RFR: 8326096: Deprecate getTotalIn,
 getTotalOut methods of java.util.zip.Inflater, java.util.zip.Deflater [v4]
In-Reply-To: 
References: 
 
 <3gTPWxpnS5VRTXK4P1gNtI5c-3BCL9OwR2FSHqZ9Nbo=.e0e49dc5-736a-4f7d-81a0-7a5e1fe9aa57@github.com>
 
Message-ID: 

On Tue, 20 Feb 2024 14:23:35 GMT, Alan Bateman  wrote:

> > Should these methods specify return values when the number of processed bytes exceed Integer.MAX_VALUE?
> 
> I think they should, otherwise it's not clear if the return value is clamped at Integer.MAX_VALUE. The wording can make it clear that the return value is useless in cases where the total exceeds Integer.MAX_VALUE.

Alan,

Finding a good way to express this while being correct and succinct was surprisingly hard. What I have now is probably far from perfect, but at least something to serve as a starting point for review:

image

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17919#issuecomment-1959521558

From eirbjo at openjdk.org  Thu Feb 22 14:19:37 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Thu, 22 Feb 2024 14:19:37 GMT
Subject: RFR: 8326096: Deprecate getTotalIn,
 getTotalOut methods of java.util.zip.Inflater, java.util.zip.Deflater [v6]
In-Reply-To: 
References: 
Message-ID: 

> Please review this PR which proposes that we officially deprecate the following four methods in the `java.util.zip` package:
> 
> * `Inflater.getTotalIn()`
> * `Inflater.getTotalOut()`
> * `Deflater.getTotalIn()`
> * `Deflater.getTotalOut()`
> 
> Since these legacy methods return `int`, they cannot safely return the number of bytes processed without the risk of losing information  about the magnitude or even sign of the returned value.
> 
> The corresponding methods `getBytesRead()` and `getBytesWritten()` methods introduced in Java 5 return `long`, and should be used instead when obtaining this information. 
> 
> Unrelated to the deprecation itself, the documentation currently does not specify what these methods are expected to return when the number of processed bytes is higher than `Integer.MAX_VALUE`. This PR aims to clarify this in the API specification.
> 
> Initally, this PR handles only `Inflater.getTotalIn()`. The other three methods will be updated once the wordsmithing for this method stabilizes.

Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:

  Use "highest order bits" instead of "highest bits"

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17919/files
  - new: https://git.openjdk.org/jdk/pull/17919/files/44323ab0..c683572c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17919&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17919&range=04-05

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/17919.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17919/head:pull/17919

PR: https://git.openjdk.org/jdk/pull/17919

From mbaesken at openjdk.org  Thu Feb 22 14:57:05 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 22 Feb 2024 14:57:05 GMT
Subject: RFR: JDK-8326389: [test] improve assertEquals failure output [v2]
In-Reply-To: 
References: 
Message-ID: <0bOm-fYFh02RYrlDMmlSkRkMspE4931eoe9UwEmLqlE=.044d5012-664e-4742-8fd7-3ca1805b9adc@github.com>

> Currently assertEquals has in the failure case sometimes confusing output like :
> 
> java.lang.RuntimeException: VM output should contain exactly one RTM locking statistics entry for method compiler.rtm.locking.TestRTMTotalCountIncrRate$Test:? expected 0 to equal 1
>        at jdk.test.lib.Asserts.fail(Asserts.java:634)
>        at jdk.test.lib.Asserts.assertEquals(Asserts.java:205)
> 
> (I don't think we really expected that for some reason 0 equals 1)
> This should be improved.

Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:

  Adjust COPYRIGHT year info

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17952/files
  - new: https://git.openjdk.org/jdk/pull/17952/files/d7b4de35..09989d25

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17952&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17952&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/17952.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17952/head:pull/17952

PR: https://git.openjdk.org/jdk/pull/17952

From clanger at openjdk.org  Thu Feb 22 15:26:56 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Thu, 22 Feb 2024 15:26:56 GMT
Subject: RFR: JDK-8326389: [test] improve assertEquals failure output [v2]
In-Reply-To: <0bOm-fYFh02RYrlDMmlSkRkMspE4931eoe9UwEmLqlE=.044d5012-664e-4742-8fd7-3ca1805b9adc@github.com>
References: 
 <0bOm-fYFh02RYrlDMmlSkRkMspE4931eoe9UwEmLqlE=.044d5012-664e-4742-8fd7-3ca1805b9adc@github.com>
Message-ID: 

On Thu, 22 Feb 2024 14:57:05 GMT, Matthias Baesken  wrote:

>> Currently assertEquals has in the failure case sometimes confusing output like :
>> 
>> java.lang.RuntimeException: VM output should contain exactly one RTM locking statistics entry for method compiler.rtm.locking.TestRTMTotalCountIncrRate$Test:? expected 0 to equal 1
>>        at jdk.test.lib.Asserts.fail(Asserts.java:634)
>>        at jdk.test.lib.Asserts.assertEquals(Asserts.java:205)
>> 
>> (I don't think we really expected that for some reason 0 equals 1)
>> This should be improved.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjust COPYRIGHT year info

I think it is a good idea to improve this. I was irritated by that output more than once.

Maybe a better message would be ... _"..." is not equal to "..."_ ?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17952#issuecomment-1959680638

From mbaesken at openjdk.org  Thu Feb 22 16:01:19 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 22 Feb 2024 16:01:19 GMT
Subject: RFR: JDK-8326389: [test] improve assertEquals failure output [v3]
In-Reply-To: 
References: 
Message-ID: <7xPPisT1fNEHqXyPQVJX8gAYu2i7HCV1PNPDlxNVfJw=.3aa0924c-583f-405c-9c0b-61ff292d6d6d@github.com>

> Currently assertEquals has in the failure case sometimes confusing output like :
> 
> java.lang.RuntimeException: VM output should contain exactly one RTM locking statistics entry for method compiler.rtm.locking.TestRTMTotalCountIncrRate$Test:? expected 0 to equal 1
>        at jdk.test.lib.Asserts.fail(Asserts.java:634)
>        at jdk.test.lib.Asserts.assertEquals(Asserts.java:205)
> 
> (I don't think we really expected that for some reason 0 equals 1)
> This should be improved.

Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:

  assertEquals adjust output

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17952/files
  - new: https://git.openjdk.org/jdk/pull/17952/files/09989d25..03cf3a82

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17952&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17952&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/17952.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17952/head:pull/17952

PR: https://git.openjdk.org/jdk/pull/17952

From mbaesken at openjdk.org  Thu Feb 22 16:01:19 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 22 Feb 2024 16:01:19 GMT
Subject: RFR: JDK-8326389: [test] improve assertEquals failure output [v2]
In-Reply-To: 
References: 
 <0bOm-fYFh02RYrlDMmlSkRkMspE4931eoe9UwEmLqlE=.044d5012-664e-4742-8fd7-3ca1805b9adc@github.com>
 
Message-ID: 

On Thu, 22 Feb 2024 15:23:56 GMT, Christoph Langer  wrote:

> I think it is a good idea to improve this. I was irritated by that output more than once.
> 
> Maybe a better message would be ... _"..." is not equal to "..."_ ?

Thanks , I adjusted the output .

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17952#issuecomment-1959752228

From martin at openjdk.org  Thu Feb 22 17:08:56 2024
From: martin at openjdk.org (Martin Buchholz)
Date: Thu, 22 Feb 2024 17:08:56 GMT
Subject: RFR: 8278527: java/util/concurrent/tck/JSR166TestCase.java fails
 nanoTime test
In-Reply-To: 
References: 
Message-ID: 

On Thu, 22 Feb 2024 09:49:31 GMT, Jaikiran Pai  wrote:

> Can I get a review of this change which proposes to remove the `SystemTest` from among the `JSR166TestCase`?
> 
> As noted in https://bugs.openjdk.org/browse/JDK-8278527 the `SystemTest.nanoTime` test has been intermittently failing since a few years now. Martin and Paul have investigated this failure in the past and they note that this test is fragile and should be removed:
> 
> https://bugs.openjdk.org/browse/JDK-8278527?focusedId=14463658&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14463658
> 
> https://bugs.openjdk.org/browse/JDK-8278527?focusedId=14508958&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14508958
> 
> The commit in this PR removes the `SystemTest` that was enrolled into `JSR166TestCase`.
> 
> tier1 testing went fine with this change.

Marked as reviewed by martin (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/17960#pullrequestreview-1896394436

From lancea at openjdk.org  Thu Feb 22 17:11:54 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Thu, 22 Feb 2024 17:11:54 GMT
Subject: RFR: 8278527: java/util/concurrent/tck/JSR166TestCase.java fails
 nanoTime test
In-Reply-To: 
References: 
Message-ID: 

On Thu, 22 Feb 2024 09:49:31 GMT, Jaikiran Pai  wrote:

> Can I get a review of this change which proposes to remove the `SystemTest` from among the `JSR166TestCase`?
> 
> As noted in https://bugs.openjdk.org/browse/JDK-8278527 the `SystemTest.nanoTime` test has been intermittently failing since a few years now. Martin and Paul have investigated this failure in the past and they note that this test is fragile and should be removed:
> 
> https://bugs.openjdk.org/browse/JDK-8278527?focusedId=14463658&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14463658
> 
> https://bugs.openjdk.org/browse/JDK-8278527?focusedId=14508958&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14508958
> 
> The commit in this PR removes the `SystemTest` that was enrolled into `JSR166TestCase`.
> 
> tier1 testing went fine with this change.

Marked as reviewed by lancea (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/17960#pullrequestreview-1896400193

From jlu at openjdk.org  Thu Feb 22 17:41:53 2024
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 22 Feb 2024 17:41:53 GMT
Subject: RFR: JDK-8325898: ChoiceFormat returns erroneous result when
 formatting bad pattern
In-Reply-To: <40mnnPuoUSvoCdi8sSYzFVRbMAIy71N5IB8zsDRIT5U=.d8fd023d-dcd8-41ab-9ee6-e76aa3202cd3@github.com>
References: 
 <40mnnPuoUSvoCdi8sSYzFVRbMAIy71N5IB8zsDRIT5U=.d8fd023d-dcd8-41ab-9ee6-e76aa3202cd3@github.com>
Message-ID: <23TVLq7PvHdVROjQtoX1dXSDC7XJMtJbNoGYHj8BB6o=.b56d695a-bd1c-4b70-95c5-cb1a3c6b609b@github.com>

On Tue, 20 Feb 2024 23:14:26 GMT, Naoto Sato  wrote:

>> Please review this PR which handles an edge case pattern bug with ChoiceFormat.
>> 
>> 
>> var d = new ChoiceFormat("0#foo|1#bar|baz|") // creates cFmt equivalent to "0.0#foo|1.0#bar|1.0#"
>> d.format(1) // unexpectedly returns ""
>> 
>> 
>> Not only does this lead to faulty formatting results, but breaks the ChoiceFormat class invariant of duplicate limits.
>> 
>> It would have been preferable if either an exception was thrown when the ChoiceFormat was initially created, or the ChoiceFormat formatting 1 returned a value of "bar".
>> 
>> For comparison,
>> 
>> var d = new ChoiceFormat("0#foo|1#bar|baz") // creates cFmt equivalent to "0.0#foo|1.0#bar"
>> d.format(1) // returns "bar"
>> 
>> 
>> After this change, the first code snippet now returns "bar" when formatting 1 and discards the "baz" as the second code snippet does.
>> 
>> 
>> This PR includes a lot of cleanup to the applyPattern implementation, the specific fix for this bug is addressed with the following, on line 305,
>> 
>> if (seg != Segment.FORMAT) {
>>     // Discard incorrect portion and finish building cFmt
>>     break;
>> }
>> 
>> This prevents a limit/format entry from being built when the current parsing mode has not yet processed the limit and relation. The previous implementation would build an additional limit/format of 1 with an empty string. The `break` allows for the discarding of the incorrect portion and continuing. Alternatively an exception could have been thrown. For consistency with the second code snippet, the former was picked.
>> 
>> https://github.com/openjdk/jdk/pull/17856 may be of interest, which is a semi-related specification fix.
>
> src/java.base/share/classes/java/text/ChoiceFormat.java line 332:
> 
>> 330: 
>> 331:     // Used to explicitly define the segment mode while applying a pattern
>> 332:     private enum Segment {
> 
> Do we need a new enum? Would introducing a new enum solve something that cannot be done with the existing implementation?

No, we don't _need_ a new enum, although I prefer it for readability.

For example, I think the following is more clear:
- `Segment.LIMIT.bldr.toString()`over `segments[1].toString();`.
- `seg = Segment.LIMIT;` over `part = 0;`

Can also no longer do something such as `part = 2;` even if unlikely.

Although I can see the argument of not wanting an enum as `part` is either only `0` or `1`. Either is OK with me.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17883#discussion_r1499626656

From jlu at openjdk.org  Thu Feb 22 17:55:18 2024
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 22 Feb 2024 17:55:18 GMT
Subject: RFR: JDK-8325898: ChoiceFormat returns erroneous result when
 formatting bad pattern [v2]
In-Reply-To: 
References: 
Message-ID: <5dkBg1WpBSGVx3bMgy4aJVX50NJoR8ab3TtwpeGZuNQ=.68443066-cdc8-4241-8e52-929b1edf966e@github.com>

> Please review this PR which handles an edge case pattern bug with ChoiceFormat.
> 
> 
> var d = new ChoiceFormat("0#foo|1#bar|baz|") // creates cFmt equivalent to "0.0#foo|1.0#bar|1.0#"
> d.format(1) // unexpectedly returns ""
> 
> 
> Not only does this lead to faulty formatting results, but breaks the ChoiceFormat class invariant of duplicate limits.
> 
> It would have been preferable if either an exception was thrown when the ChoiceFormat was initially created, or the ChoiceFormat formatting 1 returned a value of "bar".
> 
> For comparison,
> 
> var d = new ChoiceFormat("0#foo|1#bar|baz") // creates cFmt equivalent to "0.0#foo|1.0#bar"
> d.format(1) // returns "bar"
> 
> 
> After this change, the first code snippet now returns "bar" when formatting 1 and discards the "baz" as the second code snippet does.
> 
> 
> This PR includes a lot of cleanup to the applyPattern implementation, the specific fix for this bug is addressed with the following, on line 305,
> 
> if (seg != Segment.FORMAT) {
>     // Discard incorrect portion and finish building cFmt
>     break;
> }
> 
> This prevents a limit/format entry from being built when the current parsing mode has not yet processed the limit and relation. The previous implementation would build an additional limit/format of 1 with an empty string. The `break` allows for the discarding of the incorrect portion and continuing. Alternatively an exception could have been thrown. For consistency with the second code snippet, the former was picked.
> 
> https://github.com/openjdk/jdk/pull/17856 may be of interest, which is a semi-related specification fix.

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  null check at public level. spacing adjustment.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17883/files
  - new: https://git.openjdk.org/jdk/pull/17883/files/edfbe7bf..d57fa91a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17883&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17883&range=00-01

  Stats: 5 lines in 1 file changed: 2 ins; 2 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/17883.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17883/head:pull/17883

PR: https://git.openjdk.org/jdk/pull/17883

From jlu at openjdk.org  Thu Feb 22 18:24:06 2024
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 22 Feb 2024 18:24:06 GMT
Subject: RFR: JDK-6801704: ChoiceFormat::applyPattern inconsistency for
 invalid patterns [v4]
In-Reply-To: 
References: 
Message-ID: 

> Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8317756) which defines the behavior for creating ChoiceFormats with incorrect patterns. The wording is added to both the ChoiceFormat constructor and ChoiceFormat::applyPattern method.
> 
> While ideally the inconsistent behavior itself could be fixed, this behavior has been long-standing for 20+ years and the benefit of consistent error handling does not outweigh the risk of breaking applications that may be relying on the "expected" incorrect behavior.
> 
> Examples of the range of behavior, (all examples violate the pattern syntax defined in the class description)
> 
> 
> // no limit -> throws an expected IllegalArgumentException
> var a = new ChoiceFormat("#foo");
> // no limit or relation in the last subPattern -> discards the incorrect portion, 'baz' and continues
> var b = new ChoiceFormat("0#foo|1#bar|baz"); 
> b.format(2); // returns 'bar'
> // no relation or limit -> discards the incorrect portion, 'foo' and continues
> var c = new ChoiceFormat("foo");
> c.format(1); // throws AIOOBE

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  wordsmithing

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17856/files
  - new: https://git.openjdk.org/jdk/pull/17856/files/00f8179a..f1f1dc41

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17856&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17856&range=02-03

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/17856.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17856/head:pull/17856

PR: https://git.openjdk.org/jdk/pull/17856

From ysr at openjdk.org  Thu Feb 22 18:40:00 2024
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Thu, 22 Feb 2024 18:40:00 GMT
Subject: RFR: 8314480: Memory ordering spec updates in java.lang.ref [v9]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Thu, 22 Feb 2024 12:05:31 GMT, Daniel Jeli?ski  wrote:

>> src/java.base/share/classes/java/lang/ref/Reference.java line 491:
>> 
>>> 489:      * If this reference is not registered with a queue, or was already enqueued
>>> 490:      * (by the garbage collector, or a previous call to {@code enqueue}), this
>>> 491:      * method is unnsuccessful and returns false.
>> 
>> Suggestion:
>> 
>>      * method is unsuccessful and returns false.
>
> or, better yet, `fails`

I note that the adjective(s) (un)successful and the adverb(s) (un)successfully are used at several places in these comments, it might makes sense to use those terms here as well such that the documentation in internally consistent in its use of success or failure of actions. In particular, if this terminology is consistent with precedent in the official JLS spec.

However, I note that there are places where these terms are italicized and places where they aren't. I am not sure I follow the convention for italicization. In general, the first use (i.e. introduction) of a term that the reader might want to pay attention to calls for italicization when documents are read sequentially, such as in research papers. These javadoc specs will usually not be read in sequentially. But considering that someone does read them in order, I'd suggest italicizing only the first use of the term or, if not, then perhaps none. Alternatively, you might want to italicize all uses (but why?).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16644#discussion_r1499714011

From ysr at openjdk.org  Thu Feb 22 18:39:59 2024
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Thu, 22 Feb 2024 18:39:59 GMT
Subject: RFR: 8314480: Memory ordering spec updates in java.lang.ref [v9]
In-Reply-To: 
References: 
 
Message-ID: <8RyKlsYbtX_sTBVBtQw2QC5gZkeYXvYNiD6J11VzWec=.0d8911a1-66a8-4cd2-8f10-cbfccb676a0a@github.com>

On Thu, 22 Feb 2024 01:42:17 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."_
>
> Brent Christian has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Cleaner thread dequeue happens-before running cleaning action

Looks good; just some casual remarks on verbage & font at a couple of places.

-------------

PR Review: https://git.openjdk.org/jdk/pull/16644#pullrequestreview-1896527410

From ysr at openjdk.org  Thu Feb 22 18:40:01 2024
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Thu, 22 Feb 2024 18:40:01 GMT
Subject: RFR: 8314480: Memory ordering spec updates in java.lang.ref [v9]
In-Reply-To: 
References: 
 
Message-ID: <4goJd_iQwbtbSz4xedEJqg6HoBwuBvBwgLmHJrSCjVA=.c96c7e88-077e-4e1f-b64d-58e6778dc7c1@github.com>

On Mon, 27 Nov 2023 22:41:25 GMT, Hans Boehm  wrote:

>> Brent Christian has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Cleaner thread dequeue happens-before running cleaning action
>
> 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.

I find the additional suggested "detects that all needed data from the object is available elsewhere" more mysterious and confusing. The current wording seems clearer, as it sets the scene for, and motivates, when and why the `rechabilityFence()` might be needed or used.

I may be missing the significance of the suggested "all needed data from the object is available elsewhere" at this point in the description.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16644#discussion_r1499668692

From naoto at openjdk.org  Thu Feb 22 18:55:54 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 22 Feb 2024 18:55:54 GMT
Subject: RFR: JDK-8325898: ChoiceFormat returns erroneous result when
 formatting bad pattern [v2]
In-Reply-To: <23TVLq7PvHdVROjQtoX1dXSDC7XJMtJbNoGYHj8BB6o=.b56d695a-bd1c-4b70-95c5-cb1a3c6b609b@github.com>
References: 
 <40mnnPuoUSvoCdi8sSYzFVRbMAIy71N5IB8zsDRIT5U=.d8fd023d-dcd8-41ab-9ee6-e76aa3202cd3@github.com>
 <23TVLq7PvHdVROjQtoX1dXSDC7XJMtJbNoGYHj8BB6o=.b56d695a-bd1c-4b70-95c5-cb1a3c6b609b@github.com>
Message-ID: 

On Thu, 22 Feb 2024 17:38:50 GMT, Justin Lu  wrote:

>> src/java.base/share/classes/java/text/ChoiceFormat.java line 332:
>> 
>>> 330: 
>>> 331:     // Used to explicitly define the segment mode while applying a pattern
>>> 332:     private enum Segment {
>> 
>> Do we need a new enum? Would introducing a new enum solve something that cannot be done with the existing implementation?
>
> No, we don't _need_ a new enum, although I prefer it for readability.
> 
> For example, I think the following is more clear:
> - `Segment.LIMIT.bldr.toString()`over `segments[1].toString();`.
> - `seg = Segment.LIMIT;` over `part = 0;`
> 
> Can also no longer do something such as `part = 2;` even if unlikely.
> 
> Although I can see the argument of not wanting an enum as `part` is either only `0` or `1`. Either is OK with me.

OK, now the new enum can be shared with multiple threads with this implementation, but I guess it is OK as ChoiceFormat does not guarantee synchronization.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17883#discussion_r1499732561

From naoto at openjdk.org  Thu Feb 22 18:55:56 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 22 Feb 2024 18:55:56 GMT
Subject: RFR: JDK-8325898: ChoiceFormat returns erroneous result when
 formatting bad pattern [v2]
In-Reply-To: <5dkBg1WpBSGVx3bMgy4aJVX50NJoR8ab3TtwpeGZuNQ=.68443066-cdc8-4241-8e52-929b1edf966e@github.com>
References: 
 <5dkBg1WpBSGVx3bMgy4aJVX50NJoR8ab3TtwpeGZuNQ=.68443066-cdc8-4241-8e52-929b1edf966e@github.com>
Message-ID: 

On Thu, 22 Feb 2024 17:55:18 GMT, Justin Lu  wrote:

>> Please review this PR which handles an edge case pattern bug with ChoiceFormat.
>> 
>> 
>> var d = new ChoiceFormat("0#foo|1#bar|baz|") // creates cFmt equivalent to "0.0#foo|1.0#bar|1.0#"
>> d.format(1) // unexpectedly returns ""
>> 
>> 
>> Not only does this lead to faulty formatting results, but breaks the ChoiceFormat class invariant of duplicate limits.
>> 
>> It would have been preferable if either an exception was thrown when the ChoiceFormat was initially created, or the ChoiceFormat formatting 1 returned a value of "bar".
>> 
>> For comparison,
>> 
>> var d = new ChoiceFormat("0#foo|1#bar|baz") // creates cFmt equivalent to "0.0#foo|1.0#bar"
>> d.format(1) // returns "bar"
>> 
>> 
>> After this change, the first code snippet now returns "bar" when formatting 1 and discards the "baz" as the second code snippet does.
>> 
>> 
>> This PR includes a lot of cleanup to the applyPattern implementation, the specific fix for this bug is addressed with the following, on line 305,
>> 
>> if (seg != Segment.FORMAT) {
>>     // Discard incorrect portion and finish building cFmt
>>     break;
>> }
>> 
>> This prevents a limit/format entry from being built when the current parsing mode has not yet processed the limit and relation. The previous implementation would build an additional limit/format of 1 with an empty string. The `break` allows for the discarding of the incorrect portion and continuing. Alternatively an exception could have been thrown. For consistency with the second code snippet, the former was picked.
>> 
>> https://github.com/openjdk/jdk/pull/17856 may be of interest, which is a semi-related specification fix.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   null check at public level. spacing adjustment.

src/java.base/share/classes/java/text/ChoiceFormat.java line 335:

> 333:         FORMAT(new StringBuilder());
> 334: 
> 335:         private final StringBuilder bldr;

Maybe needs a more meaningful name than `bldr`? At first look, I thought it was intended for building a segment.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17883#discussion_r1499732912

From naoto at openjdk.org  Thu Feb 22 19:05:24 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 22 Feb 2024 19:05:24 GMT
Subject: RFR: 8309622: Re-examine the cache mechanism in BaseLocale [v8]
In-Reply-To: <5MqmN4P1TLKDCfXPhKWrH1b2FTgOXmjtKgd1bVXDd_M=.2000f20d-365d-48dc-bc37-45d8bcb9447f@github.com>
References: <5MqmN4P1TLKDCfXPhKWrH1b2FTgOXmjtKgd1bVXDd_M=.2000f20d-365d-48dc-bc37-45d8bcb9447f@github.com>
Message-ID: 

> This is stemming from the PR: https://github.com/openjdk/jdk/pull/14211 where aggressive GC can cause NPE in `BaseLocale$Key` class. I refactored the in-house cache with WeakHashMap, and removed the Key class as it is no longer needed (thus the original NPE will no longer be possible). Also with the new JMH test case, it gains some performance improvement:
> 
> (w/o fix)
> 
> Benchmark                       Mode  Cnt      Score     Error  Units
> LocaleCache.testForLanguageTag  avgt   20   5781.275 ? 569.580  ns/op
> LocaleCache.testLocaleOf        avgt   20  62564.079 ? 406.697  ns/op
> 
> (w/ fix)
> Benchmark                       Mode  Cnt      Score     Error  Units
> LocaleCache.testForLanguageTag  avgt   20   4801.175 ? 371.830  ns/op
> LocaleCache.testLocaleOf        avgt   20  60394.652 ? 352.471  ns/op

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Comment refined. Removed the perf-test as the fix no longer offers perf improvement.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14404/files
  - new: https://git.openjdk.org/jdk/pull/14404/files/32ec51f7..92cf07f4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14404&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14404&range=06-07

  Stats: 76 lines in 2 files changed: 0 ins; 73 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/14404.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14404/head:pull/14404

PR: https://git.openjdk.org/jdk/pull/14404

From naoto at openjdk.org  Thu Feb 22 19:05:31 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 22 Feb 2024 19:05:31 GMT
Subject: RFR: 8309622: Re-examine the cache mechanism in BaseLocale [v7]
In-Reply-To: 
References: <5MqmN4P1TLKDCfXPhKWrH1b2FTgOXmjtKgd1bVXDd_M=.2000f20d-365d-48dc-bc37-45d8bcb9447f@github.com>
 
Message-ID: 

On Thu, 22 Feb 2024 00:14:23 GMT, Naoto Sato  wrote:

>> This is stemming from the PR: https://github.com/openjdk/jdk/pull/14211 where aggressive GC can cause NPE in `BaseLocale$Key` class. I refactored the in-house cache with WeakHashMap, and removed the Key class as it is no longer needed (thus the original NPE will no longer be possible). Also with the new JMH test case, it gains some performance improvement:
>> 
>> (w/o fix)
>> 
>> Benchmark                       Mode  Cnt      Score     Error  Units
>> LocaleCache.testForLanguageTag  avgt   20   5781.275 ? 569.580  ns/op
>> LocaleCache.testLocaleOf        avgt   20  62564.079 ? 406.697  ns/op
>> 
>> (w/ fix)
>> Benchmark                       Mode  Cnt      Score     Error  Units
>> LocaleCache.testForLanguageTag  avgt   20   4801.175 ? 371.830  ns/op
>> LocaleCache.testLocaleOf        avgt   20  60394.652 ? 352.471  ns/op
>
> Naoto Sato has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 34 commits:
> 
>  - Use ReferencedKeySet.intern()
>  - Merge branch 'master' into JDK-8309622-Cache-BaseLocale
>  - Merge branch 'master' into JDK-8309622-Cache-BaseLocale
>  - Restored the test
>  - Merge branch 'master' into JDK-8309622-Cache-BaseLocale
>  - Merge branch 'master' of https://git.openjdk.org/jdk into JDK-8309622-Cache-BaseLocale
>  - small cleanup
>  - Merge branch 'pull/14684' into JDK-8309622-Cache-BaseLocale
>  - Update ReferencedKeyTest.java
>  - Simple versions of create
>  - ... and 24 more: https://git.openjdk.org/jdk/compare/b419e951...32ec51f7

After a hiatus, I now got back to work on this. I think I reflected all the comments (and removed the performance bench because it no longer offers an improvement).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14404#issuecomment-1960073243

From amenkov at openjdk.org  Thu Feb 22 20:00:03 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 22 Feb 2024 20:00:03 GMT
Subject: RFR: JDK-8326525: com/sun/tools/attach/BasicTests.java does not verify
 AgentLoadException case
Message-ID: 

The change updates the test to throw an exception if expected AgentLoadException is not thrown

-------------

Commit messages:
 - fix

Changes: https://git.openjdk.org/jdk/pull/17971/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17971&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8326525
  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/17971.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17971/head:pull/17971

PR: https://git.openjdk.org/jdk/pull/17971

From jlu at openjdk.org  Thu Feb 22 21:37:06 2024
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 22 Feb 2024 21:37:06 GMT
Subject: RFR: JDK-8325898: ChoiceFormat returns erroneous result when
 formatting bad pattern [v3]
In-Reply-To: 
References: 
Message-ID: <0euUHU502xKdhaFGHmownS8iSOw4DWnbdWjDuV6PzpE=.2fe9a7e5-7846-4d49-858e-f988b0a7910d@github.com>

> Please review this PR which handles an edge case pattern bug with ChoiceFormat.
> 
> 
> var d = new ChoiceFormat("0#foo|1#bar|baz|") // creates cFmt equivalent to "0.0#foo|1.0#bar|1.0#"
> d.format(1) // unexpectedly returns ""
> 
> 
> Not only does this lead to faulty formatting results, but breaks the ChoiceFormat class invariant of duplicate limits.
> 
> It would have been preferable if either an exception was thrown when the ChoiceFormat was initially created, or the ChoiceFormat formatting 1 returned a value of "bar".
> 
> For comparison,
> 
> var d = new ChoiceFormat("0#foo|1#bar|baz") // creates cFmt equivalent to "0.0#foo|1.0#bar"
> d.format(1) // returns "bar"
> 
> 
> After this change, the first code snippet now returns "bar" when formatting 1 and discards the "baz" as the second code snippet does.
> 
> 
> This PR includes a lot of cleanup to the applyPattern implementation, the specific fix for this bug is addressed with the following, on line 305,
> 
> if (seg != Segment.FORMAT) {
>     // Discard incorrect portion and finish building cFmt
>     break;
> }
> 
> This prevents a limit/format entry from being built when the current parsing mode has not yet processed the limit and relation. The previous implementation would build an additional limit/format of 1 with an empty string. The `break` allows for the discarding of the incorrect portion and continuing. Alternatively an exception could have been thrown. For consistency with the second code snippet, the former was picked.
> 
> https://github.com/openjdk/jdk/pull/17856 may be of interest, which is a semi-related specification fix.

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  improve variable name for StringBuilder

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17883/files
  - new: https://git.openjdk.org/jdk/pull/17883/files/d57fa91a..c2b8db01

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17883&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17883&range=01-02

  Stats: 15 lines in 1 file changed: 0 ins; 0 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/17883.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17883/head:pull/17883

PR: https://git.openjdk.org/jdk/pull/17883

From darcy at openjdk.org  Thu Feb 22 22:06:01 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 22 Feb 2024 22:06:01 GMT
Subject: RFR: JDK-8326530: Widen allowable error bound of Math.tan
Message-ID: 

Widen acceptable error bound of Math.tan to accommodate the worst-case observed error which is slightly outside of the allowable range.

-------------

Commit messages:
 - JDK-8326530: Widen allowable error bound of Math.tan

Changes: https://git.openjdk.org/jdk/pull/17973/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17973&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8326530
  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/17973.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17973/head:pull/17973

PR: https://git.openjdk.org/jdk/pull/17973

From jlu at openjdk.org  Thu Feb 22 22:30:03 2024
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 22 Feb 2024 22:30:03 GMT
Subject: Integrated: JDK-8318761: MessageFormat pattern support for
 CompactNumberFormat, ListFormat, and DateTimeFormatter
In-Reply-To: 
References: 
Message-ID: 

On Wed, 31 Jan 2024 22:24:14 GMT, Justin Lu  wrote:

> Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8319344) which adds MessageFormat pattern support for the following subformats: ListFormat, CompactNumberFormat, and DateTimeFormatter. This change is intended to provide pattern support for the more recently added JDK Format subclasses, as well as improving java.time formatting within i18n. The draft javadoc can be viewed here: https://cr.openjdk.org/~jlu/docs/api/java.base/java/text/MessageFormat.html. Please see the CSR for more in-depth behavioral changes, as well as limitations.
> 
> The `FormatTypes`:  dtf_date, dtf_time, dtf_datetime, pre-defined DateTimeFormatter(s), and list are added.
> The `FormatStyles`: compact_short, compact_long, or, and unit are added.
> 
> For example, previously,
> 
> 
> Object[] args = {LocalDate.of(2023, 11, 16), LocalDate.of(2023, 11, 27)};
> MessageFormat.format("It was {0,date,full}, now it is {1,date,full}", args);
> 
> 
> would throw `Exception java.lang.IllegalArgumentException: Cannot format given Object as a Date`
> 
> Now, a user can call
> 
> 
> MessageFormat.format("It was {0,dtf_date,full}, now it is {1,dtf_date,full}", args);
> 
> 
> which returns "It was Thursday, November 16, 2023, now it is Friday, November 17, 2023"

This pull request has now been integrated.

Changeset: 00ffc42c
Author:    Justin Lu 
URL:       https://git.openjdk.org/jdk/commit/00ffc42cef79d82b2f417c133a48bffec4c7e6b9
Stats:     1258 lines in 7 files changed: 929 ins; 197 del; 132 mod

8318761: MessageFormat pattern support for CompactNumberFormat, ListFormat, and DateTimeFormatter

Reviewed-by: naoto, rriggs

-------------

PR: https://git.openjdk.org/jdk/pull/17663

From naoto at openjdk.org  Thu Feb 22 22:43:26 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 22 Feb 2024 22:43:26 GMT
Subject: RFR: 8309622: Re-examine the cache mechanism in BaseLocale [v9]
In-Reply-To: <5MqmN4P1TLKDCfXPhKWrH1b2FTgOXmjtKgd1bVXDd_M=.2000f20d-365d-48dc-bc37-45d8bcb9447f@github.com>
References: <5MqmN4P1TLKDCfXPhKWrH1b2FTgOXmjtKgd1bVXDd_M=.2000f20d-365d-48dc-bc37-45d8bcb9447f@github.com>
Message-ID: 

> This is stemming from the PR: https://github.com/openjdk/jdk/pull/14211 where aggressive GC can cause NPE in `BaseLocale$Key` class. I refactored the in-house cache with WeakHashMap, and removed the Key class as it is no longer needed (thus the original NPE will no longer be possible). Also with the new JMH test case, it gains some performance improvement:
> 
> (w/o fix)
> 
> Benchmark                       Mode  Cnt      Score     Error  Units
> LocaleCache.testForLanguageTag  avgt   20   5781.275 ? 569.580  ns/op
> LocaleCache.testLocaleOf        avgt   20  62564.079 ? 406.697  ns/op
> 
> (w/ fix)
> Benchmark                       Mode  Cnt      Score     Error  Units
> LocaleCache.testForLanguageTag  avgt   20   4801.175 ? 371.830  ns/op
> LocaleCache.testLocaleOf        avgt   20  60394.652 ? 352.471  ns/op

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Refining comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14404/files
  - new: https://git.openjdk.org/jdk/pull/14404/files/92cf07f4..7c1ca90e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14404&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14404&range=07-08

  Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/14404.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14404/head:pull/14404

PR: https://git.openjdk.org/jdk/pull/14404

From jlu at openjdk.org  Thu Feb 22 22:50:03 2024
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 22 Feb 2024 22:50:03 GMT
Subject: RFR: JDK-8325898: ChoiceFormat returns erroneous result when
 formatting bad pattern [v4]
In-Reply-To: 
References: 
Message-ID: 

> Please review this PR which handles an edge case pattern bug with ChoiceFormat.
> 
> 
> var d = new ChoiceFormat("0#foo|1#bar|baz|") // creates cFmt equivalent to "0.0#foo|1.0#bar|1.0#"
> d.format(1) // unexpectedly returns ""
> 
> 
> Not only does this lead to faulty formatting results, but breaks the ChoiceFormat class invariant of duplicate limits.
> 
> It would have been preferable if either an exception was thrown when the ChoiceFormat was initially created, or the ChoiceFormat formatting 1 returned a value of "bar".
> 
> For comparison,
> 
> var d = new ChoiceFormat("0#foo|1#bar|baz") // creates cFmt equivalent to "0.0#foo|1.0#bar"
> d.format(1) // returns "bar"
> 
> 
> After this change, the first code snippet now returns "bar" when formatting 1 and discards the "baz" as the second code snippet does.
> 
> 
> The specific fix for this bug is addressed with the following, on line 305,
> 
> if (seg != Segment.FORMAT) {
>     // Discard incorrect portion and finish building cFmt
>     break;
> }
> 
> This prevents a limit/format entry from being built when the current parsing mode has not yet processed the limit and relation. The previous implementation would build an additional limit/format of 1 with an empty string. The `break` allows for the discarding of the incorrect portion and continuing. Alternatively an exception could have been thrown. For consistency with the second code snippet, the former was picked.
> 
> https://github.com/openjdk/jdk/pull/17856 may be of interest, which is a semi-related specification fix.

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  revert enum change

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17883/files
  - new: https://git.openjdk.org/jdk/pull/17883/files/c2b8db01..7d792777

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17883&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17883&range=02-03

  Stats: 30 lines in 1 file changed: 0 ins; 13 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/17883.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17883/head:pull/17883

PR: https://git.openjdk.org/jdk/pull/17883

From bpb at openjdk.org  Thu Feb 22 22:52:57 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 22 Feb 2024 22:52:57 GMT
Subject: RFR: JDK-8326530: Widen allowable error bound of Math.tan
In-Reply-To: 
References: 
Message-ID: 

On Thu, 22 Feb 2024 22:00:26 GMT, Joe Darcy  wrote:

> Widen acceptable error bound of Math.tan to accommodate the worst-case observed error which is slightly outside of the allowable range.

Looks fine.

-------------

Marked as reviewed by bpb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17973#pullrequestreview-1897113120

From bchristi at openjdk.org  Thu Feb 22 23:17:00 2024
From: bchristi at openjdk.org (Brent Christian)
Date: Thu, 22 Feb 2024 23:17:00 GMT
Subject: RFR: 8314480: Memory ordering spec updates in java.lang.ref [v9]
In-Reply-To: 
References: 
 
 
 
 
Message-ID: 

On Thu, 22 Feb 2024 18:24:39 GMT, Y. Srinivas Ramakrishna  wrote:

>> or, better yet, `fails`
>
> I note that the adjective(s) (un)successful and the adverb(s) (un)successfully are used at several places in these comments, it might makes sense to use those terms here as well such that the documentation in internally consistent in its use of success or failure of actions. In particular, if this terminology is consistent with precedent in the official JLS spec.
> 
> However, I note that there are places where these terms are italicized and places where they aren't. I am not sure I follow the convention for italicization. In general, the first use (i.e. introduction) of a term that the reader might want to pay attention to calls for italicization when documents are read sequentially, such as in research papers. These javadoc specs will usually not be read in sequentially. But considering that someone does read them in order, I'd suggest italicizing only the first use of the term or, if not, then perhaps none. Alternatively, you might want to italicize all uses (but why?).

Thanks for finding my misspelling, djelinski. ?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16644#discussion_r1500054507

From bchristi at openjdk.org  Thu Feb 22 23:45:57 2024
From: bchristi at openjdk.org (Brent Christian)
Date: Thu, 22 Feb 2024 23:45:57 GMT
Subject: RFR: 8314480: Memory ordering spec updates in java.lang.ref [v9]
In-Reply-To: 
References: 
 
 
 
 
 
Message-ID: 

On Thu, 22 Feb 2024 23:14:37 GMT, Brent Christian  wrote:

>> I note that the adjective(s) (un)successful and the adverb(s) (un)successfully are used at several places in these comments, it might makes sense to use those terms here as well such that the documentation in internally consistent in its use of success or failure of actions. In particular, if this terminology is consistent with precedent in the official JLS spec.
>> 
>> However, I note that there are places where these terms are italicized and places where they aren't. I am not sure I follow the convention for italicization. In general, the first use (i.e. introduction) of a term that the reader might want to pay attention to calls for italicization when documents are read sequentially, such as in research papers. These javadoc specs will usually not be read in sequentially. But considering that someone does read them in order, I'd suggest italicizing only the first use of the term or, if not, then perhaps none. Alternatively, you might want to italicize all uses (but why?).
>
> Thanks for finding my misspelling, djelinski. ?

The use of "(un)successful(ly)" in relation to `Reference.enqueue()` is quite deliberate (and builds on the previous wording, "successful").

The intention was to use it consistently (is that not the case somewhere?). For example, it's also used in the new **Memory Consistency Properties** section of the `java.lang.ref` package docs ("The enqueueing of a reference...by a successful call to `Reference.enqueue()`...").

A "successful call to `enqueue()`" is meant to be shorthand for:
"the reference has been enqueued, and the enqueuing was performed by the `enqueue()` method (rather than by the garbage collector). Therefore there is a _happens-before_ edge between the `enqueue()` method call and the dequeuing of the Reference (whereas there would not be this _happens-before_ if the GC had already enqueued the Reference at the time of the `enqueue()` call)."

The text emphasis with italics is to indicate this added significance of the result of the `enqueue()` call -- ala `happens-before`.

I'm not aware of a similar scenario covered in the JLS, so AFAIK there is not precedent to be consistent with in that regard.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16644#discussion_r1500073141

From naoto at openjdk.org  Fri Feb 23 00:33:54 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 23 Feb 2024 00:33:54 GMT
Subject: RFR: JDK-8325898: ChoiceFormat returns erroneous result when
 formatting bad pattern [v4]
In-Reply-To: 
References: 
 
Message-ID: <9CP3TwlRoz2KSGgKtk8zAkFZnQO69iLACqccWSruyQg=.ead2033c-523b-4b48-a422-dbc54017e1be@github.com>

On Thu, 22 Feb 2024 22:50:03 GMT, Justin Lu  wrote:

>> Please review this PR which handles an edge case pattern bug with ChoiceFormat.
>> 
>> 
>> var d = new ChoiceFormat("0#foo|1#bar|baz|") // creates cFmt equivalent to "0.0#foo|1.0#bar|1.0#"
>> d.format(1) // unexpectedly returns ""
>> 
>> 
>> Not only does this lead to faulty formatting results, but breaks the ChoiceFormat class invariant of duplicate limits.
>> 
>> It would have been preferable if either an exception was thrown when the ChoiceFormat was initially created, or the ChoiceFormat formatting 1 returned a value of "bar".
>> 
>> For comparison,
>> 
>> var d = new ChoiceFormat("0#foo|1#bar|baz") // creates cFmt equivalent to "0.0#foo|1.0#bar"
>> d.format(1) // returns "bar"
>> 
>> 
>> After this change, the first code snippet now returns "bar" when formatting 1 and discards the "baz" as the second code snippet does.
>> 
>> 
>> The specific fix for this bug is addressed with the following, on line 305,
>> 
>> if (seg != Segment.FORMAT) {
>>     // Discard incorrect portion and finish building cFmt
>>     break;
>> }
>> 
>> This prevents a limit/format entry from being built when the current parsing mode has not yet processed the limit and relation. The previous implementation would build an additional limit/format of 1 with an empty string. The `break` allows for the discarding of the incorrect portion and continuing. Alternatively an exception could have been thrown. For consistency with the second code snippet, the former was picked.
>> 
>> https://github.com/openjdk/jdk/pull/17856 may be of interest, which is a semi-related specification fix.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert enum change

LGTM, with a minor suggestion.

src/java.base/share/classes/java/text/ChoiceFormat.java line 342:

> 340:         } else {
> 341:             num = Double.parseDouble(str);
> 342:         }

Could use enhanced switch?

-------------

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17883#pullrequestreview-1897207137
PR Review Comment: https://git.openjdk.org/jdk/pull/17883#discussion_r1500096680

From jpai at openjdk.org  Fri Feb 23 00:55:59 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 23 Feb 2024 00:55:59 GMT
Subject: Integrated: 8278527: java/util/concurrent/tck/JSR166TestCase.java
 fails nanoTime test
In-Reply-To: 
References: 
Message-ID: 

On Thu, 22 Feb 2024 09:49:31 GMT, Jaikiran Pai  wrote:

> Can I get a review of this change which proposes to remove the `SystemTest` from among the `JSR166TestCase`?
> 
> As noted in https://bugs.openjdk.org/browse/JDK-8278527 the `SystemTest.nanoTime` test has been intermittently failing since a few years now. Martin and Paul have investigated this failure in the past and they note that this test is fragile and should be removed:
> 
> https://bugs.openjdk.org/browse/JDK-8278527?focusedId=14463658&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14463658
> 
> https://bugs.openjdk.org/browse/JDK-8278527?focusedId=14508958&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14508958
> 
> The commit in this PR removes the `SystemTest` that was enrolled into `JSR166TestCase`.
> 
> tier1 testing went fine with this change.

This pull request has now been integrated.

Changeset: 54f09d73
Author:    Jaikiran Pai 
URL:       https://git.openjdk.org/jdk/commit/54f09d734584a71c648520664447f8395050adbe
Stats:     76 lines in 2 files changed: 0 ins; 76 del; 0 mod

8278527: java/util/concurrent/tck/JSR166TestCase.java fails nanoTime test

Reviewed-by: martin, lancea

-------------

PR: https://git.openjdk.org/jdk/pull/17960

From jpai at openjdk.org  Fri Feb 23 00:55:58 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 23 Feb 2024 00:55:58 GMT
Subject: RFR: 8278527: java/util/concurrent/tck/JSR166TestCase.java fails
 nanoTime test
In-Reply-To: 
References: 
Message-ID: <8TiaVQEkxOETusP2SK3aBNgMNCjEYzOrj3GE0ZcWq58=.6d2a33b3-b96b-4431-88b7-bf775b53ddce@github.com>

On Thu, 22 Feb 2024 09:49:31 GMT, Jaikiran Pai  wrote:

> Can I get a review of this change which proposes to remove the `SystemTest` from among the `JSR166TestCase`?
> 
> As noted in https://bugs.openjdk.org/browse/JDK-8278527 the `SystemTest.nanoTime` test has been intermittently failing since a few years now. Martin and Paul have investigated this failure in the past and they note that this test is fragile and should be removed:
> 
> https://bugs.openjdk.org/browse/JDK-8278527?focusedId=14463658&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14463658
> 
> https://bugs.openjdk.org/browse/JDK-8278527?focusedId=14508958&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14508958
> 
> The commit in this PR removes the `SystemTest` that was enrolled into `JSR166TestCase`.
> 
> tier1 testing went fine with this change.

Thank you Martin and Lance for the reviews.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17960#issuecomment-1960587846

From bchristi at openjdk.org  Fri Feb 23 06:06:21 2024
From: bchristi at openjdk.org (Brent Christian)
Date: Fri, 23 Feb 2024 06:06:21 GMT
Subject: RFR: 8314480: Memory ordering spec updates in java.lang.ref [v10]
In-Reply-To: 
References: 
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."_

Brent Christian has updated the pull request incrementally with one additional commit since the last revision:

  VM -> virtual machine; also fix misspelling

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16644/files
  - new: https://git.openjdk.org/jdk/pull/16644/files/0f949d3c..adb1fbe3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16644&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16644&range=08-09

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 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 mbaesken at openjdk.org  Fri Feb 23 08:16:59 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 23 Feb 2024 08:16:59 GMT
Subject: RFR: JDK-8326389: [test] improve assertEquals failure output [v3]
In-Reply-To: <7xPPisT1fNEHqXyPQVJX8gAYu2i7HCV1PNPDlxNVfJw=.3aa0924c-583f-405c-9c0b-61ff292d6d6d@github.com>
References: 
 <7xPPisT1fNEHqXyPQVJX8gAYu2i7HCV1PNPDlxNVfJw=.3aa0924c-583f-405c-9c0b-61ff292d6d6d@github.com>
Message-ID: 

On Thu, 22 Feb 2024 16:01:19 GMT, Matthias Baesken  wrote:

>> Currently assertEquals has in the failure case sometimes confusing output like :
>> 
>> java.lang.RuntimeException: VM output should contain exactly one RTM locking statistics entry for method compiler.rtm.locking.TestRTMTotalCountIncrRate$Test:? expected 0 to equal 1
>>        at jdk.test.lib.Asserts.fail(Asserts.java:634)
>>        at jdk.test.lib.Asserts.assertEquals(Asserts.java:205)
>> 
>> (I don't think we really expected that for some reason 0 equals 1)
>> This should be improved.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   assertEquals adjust output

now the error output is like
java.lang.RuntimeException: VM output should contain two rtm locking statistics entries for method compiler.testlibrary.rtm.XAbortProvoker::forceAbort: object "0" is not equal to "2"

looks much better to me.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17952#issuecomment-1960895518

From clanger at openjdk.org  Fri Feb 23 08:53:53 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Fri, 23 Feb 2024 08:53:53 GMT
Subject: RFR: JDK-8326389: [test] improve assertEquals failure output [v3]
In-Reply-To: <7xPPisT1fNEHqXyPQVJX8gAYu2i7HCV1PNPDlxNVfJw=.3aa0924c-583f-405c-9c0b-61ff292d6d6d@github.com>
References: 
 <7xPPisT1fNEHqXyPQVJX8gAYu2i7HCV1PNPDlxNVfJw=.3aa0924c-583f-405c-9c0b-61ff292d6d6d@github.com>
Message-ID: 

On Thu, 22 Feb 2024 16:01:19 GMT, Matthias Baesken  wrote:

>> Currently assertEquals has in the failure case sometimes confusing output like :
>> 
>> java.lang.RuntimeException: VM output should contain exactly one RTM locking statistics entry for method compiler.rtm.locking.TestRTMTotalCountIncrRate$Test:? expected 0 to equal 1
>>        at jdk.test.lib.Asserts.fail(Asserts.java:634)
>>        at jdk.test.lib.Asserts.assertEquals(Asserts.java:205)
>> 
>> (I don't think we really expected that for some reason 0 equals 1)
>> This should be improved.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   assertEquals adjust output

Looks good from my end.

-------------

Marked as reviewed by clanger (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17952#pullrequestreview-1897634635

From mbaesken at openjdk.org  Fri Feb 23 10:08:55 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 23 Feb 2024 10:08:55 GMT
Subject: RFR: JDK-8326389: [test] improve assertEquals failure output [v3]
In-Reply-To: <7xPPisT1fNEHqXyPQVJX8gAYu2i7HCV1PNPDlxNVfJw=.3aa0924c-583f-405c-9c0b-61ff292d6d6d@github.com>
References: 
 <7xPPisT1fNEHqXyPQVJX8gAYu2i7HCV1PNPDlxNVfJw=.3aa0924c-583f-405c-9c0b-61ff292d6d6d@github.com>
Message-ID: 

On Thu, 22 Feb 2024 16:01:19 GMT, Matthias Baesken  wrote:

>> Currently assertEquals has in the failure case sometimes confusing output like :
>> 
>> java.lang.RuntimeException: VM output should contain exactly one RTM locking statistics entry for method compiler.rtm.locking.TestRTMTotalCountIncrRate$Test:? expected 0 to equal 1
>>        at jdk.test.lib.Asserts.fail(Asserts.java:634)
>>        at jdk.test.lib.Asserts.assertEquals(Asserts.java:205)
>> 
>> (I don't think we really expected that for some reason 0 equals 1)
>> This should be improved.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   assertEquals adjust output

Hi Christoph, thanks for the review !
Any other opinions/comments/reviews ?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17952#issuecomment-1961045316

From rgiulietti at openjdk.org  Fri Feb 23 10:15:54 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 23 Feb 2024 10:15:54 GMT
Subject: RFR: JDK-8326530: Widen allowable error bound of Math.tan
In-Reply-To: 
References: 
Message-ID: 

On Thu, 22 Feb 2024 22:00:26 GMT, Joe Darcy  wrote:

> Widen acceptable error bound of Math.tan to accommodate the worst-case observed error which is slightly outside of the allowable range.

Marked as reviewed by rgiulietti (Reviewer).

Checked with high precision math. The bound reported on the paper (1.02 ulp) is correct, so 1.25 ulp is fine as well.

-------------

PR Review: https://git.openjdk.org/jdk/pull/17973#pullrequestreview-1897778674
PR Comment: https://git.openjdk.org/jdk/pull/17973#issuecomment-1961054443

From aefimov at openjdk.org  Fri Feb 23 15:32:55 2024
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Fri, 23 Feb 2024 15:32:55 GMT
Subject: RFR: 8325579: Inconsistent behavior in
 com.sun.jndi.ldap.Connection::createSocket [v5]
In-Reply-To: 
References: 
 
 
 
 
 
Message-ID: 

On Thu, 22 Feb 2024 11:38:19 GMT, Christoph Langer  wrote:

> As for the test, I had a closer look now and I find it hard to separate testing of [JDK-8314063](https://bugs.openjdk.org/browse/JDK-8314063) from [JDK-8325579](https://bugs.openjdk.org/browse/JDK-8325579). Furthermore, most of the entries test things that hadn't been addressed by any of these two bugs at all.
>
> So, [JDK-8314063](https://bugs.openjdk.org/browse/JDK-8314063) is only tested in lines 72, 73, 76 and 77 The original problem of this issue [JDK-8325579](https://bugs.openjdk.org/browse/JDK-8325579) is touched in line 71 and 73.
> 
> That means, most of the other test invocations test some generic behavior which was never erroneous so far.

Thanks for exploring the possibility of improving tracebility of test invocations to reported bugs.  

> I could, however, give each line its own test id and annotate the bugs accordingly. Do you think that makes sense?

It does make sense, but I'm not sure how such annotations will look like and if it will be easy to use them for debugging failures. I will leave the final decision to you here.  Your last message with linkage of test invocations to bug id is already a good information to have. 

> I drafted a CSR. @AlekseiEfimov, would be nice if you could review it.

Thanks for drafting a CSR. I will review it in comming days.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17797#issuecomment-1961537850

From ihse at openjdk.org  Fri Feb 23 16:28:01 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 23 Feb 2024 16:28:01 GMT
Subject: RFR: 8326583: Remove over-generalized DefineNativeToolchain solution
Message-ID: 

The idea of setting up general "toolchains" in the native build was good, but it turned out that we really only need a single toolchain, with a single twist: if it should use CC or CPP to link. This is better described by a specific argument to SetupNativeCompilation, LANG := C++ or LANG := C (the default).

There is a single exception to this rule, and that is if we want to compile for the build platform rather than the target platform. (This is only done for adlc) To keep expressing this difference, introduce TARGET_TYPE := BUILD (or TARGET_TYPE := TARGET, the default).

The final odd-case was the hack for building hsdis/bin on mingw. This can be resolved using direct variables to SetupNativeCompilation, instead of first creating a toolchain.

Doing this refactoring will simplify the SetupNativeCompilation code, and make it much clearer if we use the C or C++ linker.

-------------

Commit messages:
 - 8326583: Remove over-generalized DefineNativeToolchain solution

Changes: https://git.openjdk.org/jdk/pull/17986/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17986&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8326583
  Stats: 225 lines in 14 files changed: 55 ins; 137 del; 33 mod
  Patch: https://git.openjdk.org/jdk/pull/17986.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17986/head:pull/17986

PR: https://git.openjdk.org/jdk/pull/17986

From ihse at openjdk.org  Fri Feb 23 17:01:54 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 23 Feb 2024 17:01:54 GMT
Subject: RFR: 8326583: Remove over-generalized DefineNativeToolchain
 solution
In-Reply-To: 
References: 
Message-ID: 

On Fri, 23 Feb 2024 16:23:43 GMT, Magnus Ihse Bursie  wrote:

> The idea of setting up general "toolchains" in the native build was good, but it turned out that we really only need a single toolchain, with a single twist: if it should use CC or CPP to link. This is better described by a specific argument to SetupNativeCompilation, LANG := C++ or LANG := C (the default).
> 
> There is a single exception to this rule, and that is if we want to compile for the build platform rather than the target platform. (This is only done for adlc) To keep expressing this difference, introduce TARGET_TYPE := BUILD (or TARGET_TYPE := TARGET, the default).
> 
> The final odd-case was the hack for building hsdis/bin on mingw. This can be resolved using direct variables to SetupNativeCompilation, instead of first creating a toolchain.
> 
> Doing this refactoring will simplify the SetupNativeCompilation code, and make it much clearer if we use the C or C++ linker.

I have verified that there is no differences in the resulting output using COMPARE_BUILD, for the platforms in Oracle's CI: windows-x64,linux-x64,linux-aarch64,macosx-x64,macosx-aarch64, confirming that this is a pure build system refactoring.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17986#issuecomment-1961679913

From jlu at openjdk.org  Fri Feb 23 17:29:18 2024
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 23 Feb 2024 17:29:18 GMT
Subject: RFR: JDK-8325898: ChoiceFormat returns erroneous result when
 formatting bad pattern [v5]
In-Reply-To: 
References: 
Message-ID: 

> Please review this PR which handles an edge case pattern bug with ChoiceFormat.
> 
> 
> var d = new ChoiceFormat("0#foo|1#bar|baz|") // creates cFmt equivalent to "0.0#foo|1.0#bar|1.0#"
> d.format(1) // unexpectedly returns ""
> 
> 
> Not only does this lead to faulty formatting results, but breaks the ChoiceFormat class invariant of duplicate limits.
> 
> It would have been preferable if either an exception was thrown when the ChoiceFormat was initially created, or the ChoiceFormat formatting 1 returned a value of "bar".
> 
> For comparison,
> 
> var d = new ChoiceFormat("0#foo|1#bar|baz") // creates cFmt equivalent to "0.0#foo|1.0#bar"
> d.format(1) // returns "bar"
> 
> 
> After this change, the first code snippet now returns "bar" when formatting 1 and discards the "baz" as the second code snippet does.
> 
> 
> The specific fix for this bug is addressed with the following, on line 305,
> 
> if (seg != Segment.FORMAT) {
>     // Discard incorrect portion and finish building cFmt
>     break;
> }
> 
> This prevents a limit/format entry from being built when the current parsing mode has not yet processed the limit and relation. The previous implementation would build an additional limit/format of 1 with an empty string. The `break` allows for the discarding of the incorrect portion and continuing. Alternatively an exception could have been thrown. For consistency with the second code snippet, the former was picked.
> 
> https://github.com/openjdk/jdk/pull/17856 may be of interest, which is a semi-related specification fix.

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  use enhanced switch in stringToNum

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17883/files
  - new: https://git.openjdk.org/jdk/pull/17883/files/7d792777..de38a988

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17883&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17883&range=03-04

  Stats: 11 lines in 1 file changed: 1 ins; 4 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/17883.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17883/head:pull/17883

PR: https://git.openjdk.org/jdk/pull/17883

From jlu at openjdk.org  Fri Feb 23 17:29:18 2024
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 23 Feb 2024 17:29:18 GMT
Subject: RFR: JDK-8325898: ChoiceFormat returns erroneous result when
 formatting bad pattern [v4]
In-Reply-To: <9CP3TwlRoz2KSGgKtk8zAkFZnQO69iLACqccWSruyQg=.ead2033c-523b-4b48-a422-dbc54017e1be@github.com>
References: 
 
 <9CP3TwlRoz2KSGgKtk8zAkFZnQO69iLACqccWSruyQg=.ead2033c-523b-4b48-a422-dbc54017e1be@github.com>
Message-ID: 

On Fri, 23 Feb 2024 00:21:57 GMT, Naoto Sato  wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   revert enum change
>
> src/java.base/share/classes/java/text/ChoiceFormat.java line 342:
> 
>> 340:         } else {
>> 341:             num = Double.parseDouble(str);
>> 342:         }
> 
> Could use enhanced switch?

Yes, much cleaner that way.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17883#discussion_r1500969086

From darcy at openjdk.org  Fri Feb 23 18:05:58 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 23 Feb 2024 18:05:58 GMT
Subject: Integrated: JDK-8326530: Widen allowable error bound of Math.tan
In-Reply-To: 
References: 
Message-ID: <7CE1ksbP0AzfW3BlwlfKt8IfiC2sCK3EVNKrZWhjTis=.2059ad23-c935-47c1-9ad3-59f96c2b6f0b@github.com>

On Thu, 22 Feb 2024 22:00:26 GMT, Joe Darcy  wrote:

> Widen acceptable error bound of Math.tan to accommodate the worst-case observed error which is slightly outside of the allowable range.

This pull request has now been integrated.

Changeset: 63f6a563
Author:    Joe Darcy 
URL:       https://git.openjdk.org/jdk/commit/63f6a563a3987d74ef673718d5209cc7c469751c
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8326530: Widen allowable error bound of Math.tan

Reviewed-by: bpb, rgiulietti

-------------

PR: https://git.openjdk.org/jdk/pull/17973

From erikj at openjdk.org  Fri Feb 23 18:19:53 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 23 Feb 2024 18:19:53 GMT
Subject: RFR: 8326583: Remove over-generalized DefineNativeToolchain
 solution
In-Reply-To: 
References: 
Message-ID: 

On Fri, 23 Feb 2024 16:23:43 GMT, Magnus Ihse Bursie  wrote:

> The idea of setting up general "toolchains" in the native build was good, but it turned out that we really only need a single toolchain, with a single twist: if it should use CC or CPP to link. This is better described by a specific argument to SetupNativeCompilation, LANG := C++ or LANG := C (the default).
> 
> There is a single exception to this rule, and that is if we want to compile for the build platform rather than the target platform. (This is only done for adlc) To keep expressing this difference, introduce TARGET_TYPE := BUILD (or TARGET_TYPE := TARGET, the default).
> 
> The final odd-case was the hack for building hsdis/bin on mingw. This can be resolved using direct variables to SetupNativeCompilation, instead of first creating a toolchain.
> 
> Doing this refactoring will simplify the SetupNativeCompilation code, and make it much clearer if we use the C or C++ linker.

Marked as reviewed by erikj (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/17986#pullrequestreview-1898688421

From naoto at openjdk.org  Fri Feb 23 18:55:54 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 23 Feb 2024 18:55:54 GMT
Subject: RFR: JDK-8325898: ChoiceFormat returns erroneous result when
 formatting bad pattern [v5]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 23 Feb 2024 17:29:18 GMT, Justin Lu  wrote:

>> Please review this PR which handles an edge case pattern bug with ChoiceFormat.
>> 
>> 
>> var d = new ChoiceFormat("0#foo|1#bar|baz|") // creates cFmt equivalent to "0.0#foo|1.0#bar|1.0#"
>> d.format(1) // unexpectedly returns ""
>> 
>> 
>> Not only does this lead to faulty formatting results, but breaks the ChoiceFormat class invariant of duplicate limits.
>> 
>> It would have been preferable if either an exception was thrown when the ChoiceFormat was initially created, or the ChoiceFormat formatting 1 returned a value of "bar".
>> 
>> For comparison,
>> 
>> var d = new ChoiceFormat("0#foo|1#bar|baz") // creates cFmt equivalent to "0.0#foo|1.0#bar"
>> d.format(1) // returns "bar"
>> 
>> 
>> After this change, the first code snippet now returns "bar" when formatting 1 and discards the "baz" as the second code snippet does.
>> 
>> 
>> The specific fix for this bug is addressed with the following, on line 305,
>> 
>> if (seg != Segment.FORMAT) {
>>     // Discard incorrect portion and finish building cFmt
>>     break;
>> }
>> 
>> This prevents a limit/format entry from being built when the current parsing mode has not yet processed the limit and relation. The previous implementation would build an additional limit/format of 1 with an empty string. The `break` allows for the discarding of the incorrect portion and continuing. Alternatively an exception could have been thrown. For consistency with the second code snippet, the former was picked.
>> 
>> https://github.com/openjdk/jdk/pull/17856 may be of interest, which is a semi-related specification fix.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use enhanced switch in stringToNum

Marked as reviewed by naoto (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/17883#pullrequestreview-1898741418

From darcy at openjdk.org  Fri Feb 23 19:20:58 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 23 Feb 2024 19:20:58 GMT
Subject: RFR: JDK-8316708: Augment WorstCaseTests with more cases
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 22 Sep 2023 15:48:26 GMT, Raffaello Giulietti  wrote:

> Both `Math.cos` and `StrictMath.cos` produce the correctly rounded result here. I don't know why the paper says otherwise. Perhaps OpenLibm is not exactly fdlibm.

I've looked a bit over the OpenLibm changelog. They've added a few special cases for exp and pow as leaset. OpenLibm itself is a direct derivative of one of the BSD math libraries, which in turn was derived from FDLIBM.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15879#discussion_r1501077887

From clanger at openjdk.org  Fri Feb 23 19:23:02 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Fri, 23 Feb 2024 19:23:02 GMT
Subject: RFR: 8326591: New test JmodExcludedFiles.java fails on Windows when
 --with-external-symbols-in-bundles=public is used
Message-ID: <9RR45_rKFq7Syr1gB7zEPqOBgmPf-TeGPOo62M6aFtc=.fff7854c-7c8b-4c97-acbb-8ec6bce5c8d1@github.com>

The new test JmodExcludedFiles.java checks that no debug symbol files are contained in the jmod files. It does not take into account that with configure option --with-external-symbols-in-bundles=public we want to have stripped pdb files, also in jmods, to get native callstacks with line number.

This modifies the test and checks if equivalent *stripped.pdb files exist when .pdb files are encountered inside jmods. In that case one can assume that --with-external-symbols-in-bundles=public was chosen as configure option.

-------------

Commit messages:
 - JDK-8326591

Changes: https://git.openjdk.org/jdk/pull/17990/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17990&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8326591
  Stats: 48 lines in 1 file changed: 30 ins; 5 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/17990.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17990/head:pull/17990

PR: https://git.openjdk.org/jdk/pull/17990

From darcy at openjdk.org  Fri Feb 23 19:50:57 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 23 Feb 2024 19:50:57 GMT
Subject: RFR: JDK-8316708: Augment WorstCaseTests with more cases
In-Reply-To: 
References: 
Message-ID: 

On Fri, 22 Sep 2023 05:36:02 GMT, Joe Darcy  wrote:

> A new paper
> 
>  "Accuracy of Mathematical Functions in Single, Double, Double Extended, and Quadruple Precision"
> by Brian Gladman, Vincenzo Innocente and Paul Zimmermann
> https://members.loria.fr/PZimmermann/papers/accuracy.pdf
> 
> details the inputs with generate the worst-case observed errors in different math library implementations. The FDLIBM-related worst cases should be added to the test suite.

Upon further reflection, I think it is worthwhile to include the worst-case tests from the more of the other math library implementations to better test potential intrinsifications of the various methods.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15879#issuecomment-1961898103

From darcy at openjdk.org  Fri Feb 23 20:15:31 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 23 Feb 2024 20:15:31 GMT
Subject: RFR: JDK-8316708: Augment WorstCaseTests with more cases [v2]
In-Reply-To: 
References: 
Message-ID: <1IfGA2QzEqei0lSLTI5hNR44jX6_vwaq_szh-OPUt3E=.ebd825eb-d4b0-4db0-bece-1e059fac2062@github.com>

> A new paper
> 
>  "Accuracy of Mathematical Functions in Single, Double, Double Extended, and Quadruple Precision"
> by Brian Gladman, Vincenzo Innocente and Paul Zimmermann
> https://members.loria.fr/PZimmermann/papers/accuracy.pdf
> 
> details the inputs with generate the worst-case observed errors in different math library implementations. The FDLIBM-related worst cases should be added to the test suite.

Joe Darcy has updated the pull request with a new target base 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:

 - Start adding worst-case inputs for other math libraries.
 - Merge branch 'master' into JDK-8316708
 - Merge branch 'master' into JDK-8316708
 - Fix typo found in code review.
 - Add stated error bounds.
 - JDK-8316708: Augment WorstCaseTests with more cases

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15879/files
  - new: https://git.openjdk.org/jdk/pull/15879/files/2442b72f..fb7dbb87

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15879&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15879&range=00-01

  Stats: 996288 lines in 9073 files changed: 292047 ins; 587419 del; 116822 mod
  Patch: https://git.openjdk.org/jdk/pull/15879.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15879/head:pull/15879

PR: https://git.openjdk.org/jdk/pull/15879

From darcy at openjdk.org  Fri Feb 23 20:15:31 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 23 Feb 2024 20:15:31 GMT
Subject: RFR: JDK-8316708: Augment WorstCaseTests with more cases [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 22 Sep 2023 15:33:11 GMT, Raffaello Giulietti  wrote:

>> Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
>> 
>>  - Start adding worst-case inputs for other math libraries.
>>  - Merge branch 'master' into JDK-8316708
>>  - Merge branch 'master' into JDK-8316708
>>  - Fix typo found in code review.
>>  - Add stated error bounds.
>>  - JDK-8316708: Augment WorstCaseTests with more cases
>
> test/jdk/java/lang/Math/WorstCaseTests.java line 293:
> 
>> 291: 
>> 292:             // Worst-case observed error
>> 293:             {-0x1.0068b067c6feep-1,     +0x1.0c335e2f0727p1},
> 
> Similar considerations as for asin above.
> The "expected" value should be `0x1.0c335e2f0726fp1`.

For the new worst-case conditions I've pushed, if there is a "// check" comment, the Math and StrictMath return values were the same and I did not yet check which exact floating-point value should be used as the reference point.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15879#discussion_r1501123440

From darcy at openjdk.org  Fri Feb 23 20:15:31 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 23 Feb 2024 20:15:31 GMT
Subject: RFR: JDK-8316708: Augment WorstCaseTests with more cases [v2]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Fri, 22 Sep 2023 21:32:26 GMT, Joe Darcy  wrote:

> For FDLIBM tan, the stated error in the Math.tan spec is 1 ulp and the FDLIBM sources say tan is "nearly rounded," which could reasonably be interpreted as meaning within 1 ulp. However, the reported error by the paper is 1.02 ulps.
> 
> As you note here, the current testing methodology can only really deal with at most a 1 ulp error, assuming the expected value is at the lower endpoint of the range.
> 
> To avoid any lurking errors in the FDLIBM port to Java, I generated the expected numbers running jshell on JDK 20, which uses the mostly C-based FDLIBM. For a number of cases I had to decrement the expected value for the test to pass against Math and StrictMath. The decremented value and its successor may or may not bracket the exact value; I didn't verify that.
> 
> In other words, there may be other bugs in one or both math libraries the test is detecting.
> 
> So far, I've only tried running the test locally, but this would need a cross-platform run being before pushed to cover all the intrinsics that may be in use on the full set of supported platforms.

Subsequently, the allowable error bound for tan was bumped up to 1.25 ulps to cover the observed 1.02 ulp error under JDK-8326530: Widen allowable error bound of Math.tan.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15879#discussion_r1501122082

From ysr at openjdk.org  Fri Feb 23 20:21:01 2024
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Fri, 23 Feb 2024 20:21:01 GMT
Subject: RFR: 8314480: Memory ordering spec updates in java.lang.ref [v9]
In-Reply-To: 
References: 
 
 
 
 
 
 
Message-ID: 

On Thu, 22 Feb 2024 23:43:41 GMT, Brent Christian  wrote:

>> Thanks for finding my misspelling, djelinski. ?
>
> The use of "(un)successful(ly)" in relation to `Reference.enqueue()` is quite deliberate (and builds on the previous wording, "successful").
> 
> The intention was to use it consistently (is that not the case somewhere?). For example, it's also used in the new **Memory Consistency Properties** section of the `java.lang.ref` package docs ("The enqueueing of a reference...by a successful call to `Reference.enqueue()`...").
> 
> A "successful call to `enqueue()`" is meant to be shorthand for:
> "the reference has been enqueued, and the enqueuing was performed by the `enqueue()` method (rather than by the garbage collector). Therefore there is a _happens-before_ edge between the `enqueue()` method call and the dequeuing of the Reference (whereas there would not be this _happens-before_ if the GC had already enqueued the Reference at the time of the `enqueue()` call)."
> 
> The text emphasis with italics is to indicate this added significance of the result of the `enqueue()` call -- ala `happens-before`.
> 
> I'm not aware of a similar scenario covered in the JLS, so AFAIK there is not precedent to be consistent with in that regard.

Sounds good, thanks!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16644#discussion_r1501127639

From roger.riggs at oracle.com  Fri Feb 23 21:15:19 2024
From: roger.riggs at oracle.com (Roger Riggs)
Date: Fri, 23 Feb 2024 16:15:19 -0500
Subject: CFV: New Core Libraries Group Member: Viktor Klang
In-Reply-To: <5a5a3d2c-34d7-f6fb-8736-c3bb5cf5d5fc@oracle.com>
References: <5a5a3d2c-34d7-f6fb-8736-c3bb5cf5d5fc@oracle.com>
Message-ID: 

Vote: Yes

On 2/19/24 6:40 PM, Stuart Marks wrote:
> I hereby nominate Viktor Klang [6] to Membership in the Core Libraries 
> Group [4]. 


From naoto at openjdk.org  Fri Feb 23 21:29:54 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 23 Feb 2024 21:29:54 GMT
Subject: RFR: 8174269: Remove COMPAT locale data provider from JDK
Message-ID: 

This PR intends to remove the legacy `COMPAT` locale data from the JDK. The `COMPAT` locale data was introduced for applications' migratory purposes transitioning to `CLDR`. It is becoming a technical debt and now is the time to remove it (we've been emitting a warning at JVM startup since JDK21, if the app is using `COMPAT`). A corresponding CSR has also been drafted.

-------------

Commit messages:
 - cleanup
 - BreakIteratorProvider available locales fix
 - clean-up
 - test fixes
 - makeZoneData.pl fix
 - Vanguard fix
 - test fixes
 - tz fixes
 - Specification changes
 - Restoring a test
 - ... and 29 more: https://git.openjdk.org/jdk/compare/b419e951...f3db6099

Changes: https://git.openjdk.org/jdk/pull/17991/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17991&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8174269
  Stats: 67652 lines in 566 files changed: 478 ins; 66408 del; 766 mod
  Patch: https://git.openjdk.org/jdk/pull/17991.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17991/head:pull/17991

PR: https://git.openjdk.org/jdk/pull/17991

From jwaters at openjdk.org  Sat Feb 24 06:06:53 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Sat, 24 Feb 2024 06:06:53 GMT
Subject: RFR: 8326583: Remove over-generalized DefineNativeToolchain
 solution
In-Reply-To: 
References: 
Message-ID: 

On Fri, 23 Feb 2024 16:23:43 GMT, Magnus Ihse Bursie  wrote:

> The idea of setting up general "toolchains" in the native build was good, but it turned out that we really only need a single toolchain, with a single twist: if it should use CC or CPP to link. This is better described by a specific argument to SetupNativeCompilation, LANG := C++ or LANG := C (the default).
> 
> There is a single exception to this rule, and that is if we want to compile for the build platform rather than the target platform. (This is only done for adlc) To keep expressing this difference, introduce TARGET_TYPE := BUILD (or TARGET_TYPE := TARGET, the default).
> 
> The final odd-case was the hack for building hsdis/bin on mingw. This can be resolved using direct variables to SetupNativeCompilation, instead of first creating a toolchain.
> 
> Doing this refactoring will simplify the SetupNativeCompilation code, and make it much clearer if we use the C or C++ linker.

!!!

Not to be a party pooper, but this seems like it removes pretty some useful functionality from the build system. What if this is needed down the line? On the motivation of this change, TOOLCHAIN_LINK_CXX is pretty clear that the linker to be used is g++ instead of gcc for instance, while the new LANG parameter makes it look like SetupNativeCompilation only accepts and compiles C++ files if C++ is passed, and only C files if the new default of C is passed (For anyone looking in on this Pull Request who isn't familiar with the build system, it can compile a mix of both without issue). I'm not particularly sure this is a good idea, since a lot of flexibility seems to be lost with this change. I don't seem to see any simplification to SetupNativeCompilation either, maybe I'm missing something?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17986#issuecomment-1962269640

From alanb at openjdk.org  Sat Feb 24 08:38:53 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 24 Feb 2024 08:38:53 GMT
Subject: RFR: 8174269: Remove COMPAT locale data provider from JDK
In-Reply-To: 
References: 
Message-ID: 

On Fri, 23 Feb 2024 21:24:10 GMT, Naoto Sato  wrote:

> This PR intends to remove the legacy `COMPAT` locale data from the JDK. The `COMPAT` locale data was introduced for applications' migratory purposes transitioning to `CLDR`. It is becoming a technical debt and now is the time to remove it (we've been emitting a warning at JVM startup since JDK21, if the app is using `COMPAT`). A corresponding CSR has also been drafted.

>From a stewardship perspective I think we've done the right steps. To summarize:

- JDK 8 added the option to use CLDR locale data (JEP 127).
- JDK 9 switched to using CLDR locale data by default (JEP 252) with the option to run with -Djava.locale.providers=COMPAT and use the legacy/unmaintained locale data.
- JDK 21 added a warning when you run with -Djava.locale.providers=COMPAT announcing that this provider will be removed in a future release.
- With the proposal here, running with -Djava.locale.providers=COMPAT will print a warning to say that the configuration is ignored.

The reduction of 10Mb will be welcomed. There are likely projects that run their tests with the COMPAT provider. There may be some application deployments too. I've seen a few projects do changes in response to the run-time warning introduced in JDK 21 but there are likely projects/applications that will be "surprised" when they upgrade to JDK 23+ and tests fail. So I think one will need a bit of socialization and a loud release note.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17991#issuecomment-1962299087

From jpai at openjdk.org  Sat Feb 24 11:47:53 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 24 Feb 2024 11:47:53 GMT
Subject: RFR: JDK-8326389: [test] improve assertEquals failure output [v3]
In-Reply-To: <7xPPisT1fNEHqXyPQVJX8gAYu2i7HCV1PNPDlxNVfJw=.3aa0924c-583f-405c-9c0b-61ff292d6d6d@github.com>
References: 
 <7xPPisT1fNEHqXyPQVJX8gAYu2i7HCV1PNPDlxNVfJw=.3aa0924c-583f-405c-9c0b-61ff292d6d6d@github.com>
Message-ID: 

On Thu, 22 Feb 2024 16:01:19 GMT, Matthias Baesken  wrote:

>> Currently assertEquals has in the failure case sometimes confusing output like :
>> 
>> java.lang.RuntimeException: VM output should contain exactly one RTM locking statistics entry for method compiler.rtm.locking.TestRTMTotalCountIncrRate$Test:? expected 0 to equal 1
>>        at jdk.test.lib.Asserts.fail(Asserts.java:634)
>>        at jdk.test.lib.Asserts.assertEquals(Asserts.java:205)
>> 
>> (I don't think we really expected that for some reason 0 equals 1)
>> This should be improved.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   assertEquals adjust output

Hello Matthias, the proposal to improve that failure message looks OK to me. However, I feel that the newly proposed error message isn't too different than what it was earlier. Perhaps, we could do something like:


diff --git a/test/lib/jdk/test/lib/Asserts.java b/test/lib/jdk/test/lib/Asserts.java
index d503ea8e544..3b45d7f4129 100644
--- a/test/lib/jdk/test/lib/Asserts.java
+++ b/test/lib/jdk/test/lib/Asserts.java
@@ -199,10 +199,11 @@ public static void assertEquals(Object lhs, Object rhs) {
      */
     public static void assertEquals(Object lhs, Object rhs, String msg) {
         if ((lhs != rhs) && ((lhs == null) || !(lhs.equals(rhs)))) {
-            msg = Objects.toString(msg, "assertEquals")
-                    + ": expected " + Objects.toString(lhs)
-                    + " to equal " + Objects.toString(rhs);
-            fail(msg);
+            if (msg != null) {
+                fail(msg);
+            } else {
+                fail("assertEquals expected: " + lhs + " but was: " + rhs);
+            }
         }
     }



This is similar to what other test libraries usually report for such failures.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17952#issuecomment-1962337015

From lancea at openjdk.org  Sat Feb 24 15:01:14 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Sat, 24 Feb 2024 15:01:14 GMT
Subject: RFR: 8321156: Improve the handling of invalid UTF-8 byte sequences for
 ZipInputStream::getNextEntry and ZipFile::getComment
Message-ID: 

Please review this PR which addresses the handling of invalid UTF-8 byte sequences in the entry name of a LOC file header and a Zip file comment which is returned via ZipFile::getComment.

As part of the change, `ZipFile::getComment` will now return `null` if an invalid UTF-8 byte sequence is encountered while converting the byte array to a String.  The CSR for this change has also been approved.

Mach5 tiers 1-3 are clean with this change.

-------------

Commit messages:
 - Add tests for JDK-8321156
 - Merge branch 'master' into JDK-8321156
 - Initial changes for JDK-8321156

Changes: https://git.openjdk.org/jdk/pull/17995/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17995&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8321156
  Stats: 283 lines in 3 files changed: 171 ins; 16 del; 96 mod
  Patch: https://git.openjdk.org/jdk/pull/17995.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17995/head:pull/17995

PR: https://git.openjdk.org/jdk/pull/17995

From clanger at openjdk.org  Sat Feb 24 16:13:55 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Sat, 24 Feb 2024 16:13:55 GMT
Subject: RFR: JDK-8326389: [test] improve assertEquals failure output [v3]
In-Reply-To: 
References: 
 <7xPPisT1fNEHqXyPQVJX8gAYu2i7HCV1PNPDlxNVfJw=.3aa0924c-583f-405c-9c0b-61ff292d6d6d@github.com>
 
Message-ID: 

On Sat, 24 Feb 2024 11:45:46 GMT, Jaikiran Pai  wrote:

> This is similar to what other test libraries usually report for such failures.

But in the case of a non-empty `msg` you would not see the actual values any more which I think could be helpful in a lot of cases...

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17952#issuecomment-1962412001

From eirbjo at openjdk.org  Sat Feb 24 16:31:21 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Sat, 24 Feb 2024 16:31:21 GMT
Subject: RFR: 8326096: Deprecate getTotalIn,
 getTotalOut methods of java.util.zip.Inflater, java.util.zip.Deflater [v7]
In-Reply-To: 
References: 
Message-ID: 

> Please review this PR which proposes that we officially deprecate the following four methods in the `java.util.zip` package:
> 
> * `Inflater.getTotalIn()`
> * `Inflater.getTotalOut()`
> * `Deflater.getTotalIn()`
> * `Deflater.getTotalOut()`
> 
> Since these legacy methods return `int`, they cannot safely return the number of bytes processed without the risk of losing information  about the magnitude or even sign of the returned value.
> 
> The corresponding methods `getBytesRead()` and `getBytesWritten()` methods introduced in Java 5 return `long`, and should be used instead when obtaining this information. 
> 
> Unrelated to the deprecation itself, the documentation currently does not specify what these methods are expected to return when the number of processed bytes is higher than `Integer.MAX_VALUE`. This PR aims to clarify this in the API specification.
> 
> Initally, this PR handles only `Inflater.getTotalIn()`. The other three methods will be updated once the wordsmithing for this method stabilizes.

Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:

  To align with the Java Language Specification, use "all but the 32 lowest order bits"

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17919/files
  - new: https://git.openjdk.org/jdk/pull/17919/files/c683572c..eaddf662

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17919&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17919&range=05-06

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/17919.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17919/head:pull/17919

PR: https://git.openjdk.org/jdk/pull/17919

From eirbjo at openjdk.org  Sat Feb 24 17:01:57 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Sat, 24 Feb 2024 17:01:57 GMT
Subject: RFR: 8321156: Improve the handling of invalid UTF-8 byte sequences
 for ZipInputStream::getNextEntry and ZipFile::getComment
In-Reply-To: 
References: 
Message-ID: 

On Sat, 24 Feb 2024 14:56:01 GMT, Lance Andersen  wrote:

> Please review this PR which addresses the handling of invalid UTF-8 byte sequences in the entry name of a LOC file header and a Zip file comment which is returned via ZipFile::getComment.
> 
> As part of the change, `ZipFile::getComment` will now return `null` if an invalid UTF-8 byte sequence is encountered while converting the byte array to a String.  The CSR for this change has also been approved.
> 
> Mach5 tiers 1-3 are clean with this change.

Left a few comment on the code changes and the test. Some needs to be fixed, others may be a matter of preference.

src/java.base/share/classes/java/util/zip/ZipFile.java line 331:

> 329:             try {
> 330:                 return res.zsrc.zc.toString(res.zsrc.comment);
> 331:             } catch(IllegalArgumentException iae) {

Suggestion:

            } catch (IllegalArgumentException iae) {

src/java.base/share/classes/java/util/zip/ZipInputStream.java line 526:

> 524:             throw  (ZipException) new ZipException(
> 525:                     "invalid LOC header (bad entry name)").initCause(ex);
> 526:         }

There is a lot going on here:

* The creation of a ZipEntry
* The interpretation of the general purpose bit flag
* The split to call either a static or non-static toString depending on the flag interpretation
* The exception handling, including the somewhat unusual initCause and cast

The comment at 517 seems even more detached from the logic it tries to describe after this change.

Perhaps we could benefit from introducing a `zipCoderFromFlag(int flag)` method, similar to that in ZipFile?

This would allow the section to be rewritten to something that hide the flag parsing details, leaves us with a single (polymorphic) toString invocation and extracts `createZipEntry` from the try/catch scope. 

Something like this: (I also changed the exception handling here, that's a bit orthogonal to the main points above)

Suggestion:

        String name;
        try {
            name = zipCoderForFlag(flag).toString(b, len);
        } catch (IllegalArgumentException ex) {
            ZipException e = new ZipException("invalid LOC header (bad entry name)");
            e.initCause(ex);
            throw e;
        }
        ZipEntry e = createZipEntry(name);

test/jdk/java/util/zip/ZipFile/InvalidBytesInEntryNameOrComment.java line 49:

> 47:  * @summary Validate that a ZipException is thrown when opening a ZIP file via
> 48:  * ZipFile, traversing a Zip File via ZipInputStream, with invalid UTF-8
> 49:  * byte sequences in the name or comment fields fails with ZipException.

The leading summary sentence needs a cleanup. Here's one suggestion:

Suggestion:

 * @summary Validate that a ZipException is thrown when a ZIP file with 
 * invalid UTF-8 byte sequences in the name or comment fields is opened via
 * ZipFile or traversed via ZipInputStream.

test/jdk/java/util/zip/ZipFile/InvalidBytesInEntryNameOrComment.java line 60:

> 58:     private static final byte[] INVALID_UTF8_BYTE_SEQUENCE = {(byte) 0xF0, (byte) 0xA4, (byte) 0xAD};
> 59:     // Expected error message when an invalid entry name or entry comment is
> 60:     // encountered when accessing a CEN Header

This two-line comment could benefit from an earlier line break.

test/jdk/java/util/zip/ZipFile/InvalidBytesInEntryNameOrComment.java line 64:

> 62: 
> 63:     // Expected error message when an invalid entry name is encountered when
> 64:     // accessing a LOC Header

This two-line comment could benefit from an earlier line break.

test/jdk/java/util/zip/ZipFile/InvalidBytesInEntryNameOrComment.java line 65:

> 63:     // Expected error message when an invalid entry name is encountered when
> 64:     // accessing a LOC Header
> 65:     private static final String LOC_BAD_ENTRY_NAME_OR_COMMENT = "invalid LOC header (bad entry name)";

Should this be renamed `LOC_BAD_ENTRY_NAME`?

test/jdk/java/util/zip/ZipFile/InvalidBytesInEntryNameOrComment.java line 128:

> 126:      * 0x93: Comment     :   [ZipFileComment]
> 127:      */
> 128:     public static byte[] VALID_ZIP = {

I see this byte array encoding of ZIP files is a pattern used across tests. My preference would be to encode this in Base64 or hex, since that would make the consumption by external command line tools easier and the encoded representation somewhat prettier. But no big deal, this might just come down to personal preference. (This isn't human readable anyhow for the normal definition of "human" :)

test/jdk/java/util/zip/ZipFile/InvalidBytesInEntryNameOrComment.java line 182:

> 180:     /**
> 181:      * Validate that the original Zip file can be opened via ZipFile.
> 182:      * @throws IOException if an entry occurs

Suggestion:

     * @throws IOException if an error occurs

test/jdk/java/util/zip/ZipFile/InvalidBytesInEntryNameOrComment.java line 196:

> 194:      * Validate that the original Zip file can be opened and traversed via
> 195:      * ZipinputStream::getNextEntry.
> 196:      * @throws IOException if an entry occurs

Suggestion:

     * @throws IOException if an error occurs

test/jdk/java/util/zip/ZipFile/InvalidBytesInEntryNameOrComment.java line 201:

> 199:     public void traverseZipWithZipInputStreamTest() throws IOException {
> 200:         Files.write(ZIP_FILE, zipArray);
> 201:         try( ZipInputStream zis = new ZipInputStream(new FileInputStream(ZIP_FILE.toFile()))) {

Suggestion:

        try ( ZipInputStream zis = new ZipInputStream(new FileInputStream(ZIP_FILE.toFile()))) {

test/jdk/java/util/zip/ZipFile/InvalidBytesInEntryNameOrComment.java line 203:

> 201:         try( ZipInputStream zis = new ZipInputStream(new FileInputStream(ZIP_FILE.toFile()))) {
> 202:             ZipEntry ze;
> 203:             while((ze = zis.getNextEntry()) != null ) {

Suggestion:

            while ((ze = zis.getNextEntry()) != null ) {

test/jdk/java/util/zip/ZipFile/InvalidBytesInEntryNameOrComment.java line 243:

> 241: 
> 242:     /**
> 243:      * Validate that a ZipException is thrown when an entry name is encountered

Is the "is" here out of place or are we missing a "which"?

Suggestion:

     * Validate that a ZipException is thrown when an entry name encountered

test/jdk/java/util/zip/ZipFile/InvalidBytesInEntryNameOrComment.java line 267:

> 265:      * @throws IOException if an error occurs
> 266:      */
> 267:     private void createInvalidUTFEntryInZipFile(int offset) throws IOException {

Is the "In" in this method name helpful? (To me it suggests a file argument, not a result) 
Suggestion:

    private void createInvalidUTFEntryInZipFile(int offset) throws IOException {

test/jdk/java/util/zip/ZipFile/InvalidBytesInEntryNameOrComment.java line 304:

> 302:      *        System.out.println(result);
> 303:      *      }
> 304:      * 
    

Can we use `@snippet` in tests? Would allow syntax highlighting in IDEs

-------------

PR Review: https://git.openjdk.org/jdk/pull/17995#pullrequestreview-1899525053
PR Review Comment: https://git.openjdk.org/jdk/pull/17995#discussion_r1501631653
PR Review Comment: https://git.openjdk.org/jdk/pull/17995#discussion_r1501630004
PR Review Comment: https://git.openjdk.org/jdk/pull/17995#discussion_r1501613107
PR Review Comment: https://git.openjdk.org/jdk/pull/17995#discussion_r1501601638
PR Review Comment: https://git.openjdk.org/jdk/pull/17995#discussion_r1501603203
PR Review Comment: https://git.openjdk.org/jdk/pull/17995#discussion_r1501600929
PR Review Comment: https://git.openjdk.org/jdk/pull/17995#discussion_r1501605456
PR Review Comment: https://git.openjdk.org/jdk/pull/17995#discussion_r1501606660
PR Review Comment: https://git.openjdk.org/jdk/pull/17995#discussion_r1501606918
PR Review Comment: https://git.openjdk.org/jdk/pull/17995#discussion_r1501607429
PR Review Comment: https://git.openjdk.org/jdk/pull/17995#discussion_r1501607377
PR Review Comment: https://git.openjdk.org/jdk/pull/17995#discussion_r1501609316
PR Review Comment: https://git.openjdk.org/jdk/pull/17995#discussion_r1501610399
PR Review Comment: https://git.openjdk.org/jdk/pull/17995#discussion_r1501615750

From eirbjo at openjdk.org  Sat Feb 24 17:17:52 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Sat, 24 Feb 2024 17:17:52 GMT
Subject: RFR: 8321156: Improve the handling of invalid UTF-8 byte sequences
 for ZipInputStream::getNextEntry and ZipFile::getComment
In-Reply-To: 
References: 
Message-ID: <1Nj2tmlIoo01DBj5OFkTSy_xMMK-WB1-eda8GgYyWA8=.fcc6ba1b-c1a2-40fa-ac55-8eacf7d0f159@github.com>

On Sat, 24 Feb 2024 14:56:01 GMT, Lance Andersen  wrote:

> Please review this PR which addresses the handling of invalid UTF-8 byte sequences in the entry name of a LOC file header and a Zip file comment which is returned via ZipFile::getComment.
> 
> As part of the change, `ZipFile::getComment` will now return `null` if an invalid UTF-8 byte sequence is encountered while converting the byte array to a String.  The CSR for this change has also been approved.
> 
> Mach5 tiers 1-3 are clean with this change.

Since the CSR is already approved, I'll add a question here:

`ZipFile` performs a lot of validation while opening ZIP files, including throwning ZipException for invalid entry names or comments. Why handle the ZIP file comment differently (lazily)? If this comment was also validated by the constructor, then the API change for ZipFile::getComment would not be needed.

Do we have reason to belive the encoding quality of ZIP file comments is less reliable than that of ZIP entry comments? Or is there some other reason this validation is done lazily?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17995#issuecomment-1962426366

From duke at openjdk.org  Sat Feb 24 17:50:17 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Sat, 24 Feb 2024 17:50:17 GMT
Subject: RFR: 8326617: String Template FMT removes unnecessary int to long type
 cast
Message-ID: 

In the current version, FMT."v =%d{1}" will call the StringConcatHelper.prepend(long/byte[]/long) method, which should behave the same as STR."v ={1}". Call StringConcatHelper.prepend(long/byte[]/int), should not convert int to long

Please review and don't hesitate to critique my approach and patch.

-------------

Commit messages:
 - Merge remote-tracking branch 'upstream/master' into st_prepend_int
 - fix format %d int call prepend(long, byte[], long), should be call prepend(long, byte[], int)

Changes: https://git.openjdk.org/jdk/pull/16017/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16017&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8326617
  Stats: 7 lines in 1 file changed: 4 ins; 2 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/16017.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16017/head:pull/16017

PR: https://git.openjdk.org/jdk/pull/16017

From aturbanov at openjdk.org  Sat Feb 24 18:25:55 2024
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Sat, 24 Feb 2024 18:25:55 GMT
Subject: RFR: 8174269: Remove COMPAT locale data provider from JDK
In-Reply-To: 
References: 
Message-ID: 

On Fri, 23 Feb 2024 21:24:10 GMT, Naoto Sato  wrote:

> This PR intends to remove the legacy `COMPAT` locale data from the JDK. The `COMPAT` locale data was introduced for applications' migratory purposes transitioning to `CLDR`. It is becoming a technical debt and now is the time to remove it (we've been emitting a warning at JVM startup since JDK21, if the app is using `COMPAT`). A corresponding CSR has also been drafted.

make/jdk/src/classes/build/tools/cldrconverter/CLDRConverter.java line 768:

> 766:         var availableIds = getAvailableZoneIds();
> 767: 
> 768:         availableIds.stream().forEach(tzid -> {

Suggestion:

        availableIds.forEach(tzid -> {

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17991#discussion_r1501677693

From lancea at openjdk.org  Sat Feb 24 18:54:07 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Sat, 24 Feb 2024 18:54:07 GMT
Subject: RFR: 8321156: Improve the handling of invalid UTF-8 byte sequences
 for ZipInputStream::getNextEntry and ZipFile::getComment [v2]
In-Reply-To: 
References: 
Message-ID: 

> Please review this PR which addresses the handling of invalid UTF-8 byte sequences in the entry name of a LOC file header and a Zip file comment which is returned via ZipFile::getComment.
> 
> As part of the change, `ZipFile::getComment` will now return `null` if an invalid UTF-8 byte sequence is encountered while converting the byte array to a String.  The CSR for this change has also been approved.
> 
> Mach5 tiers 1-3 are clean with this change.

Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:

  Updates based on 1st round of feedback

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17995/files
  - new: https://git.openjdk.org/jdk/pull/17995/files/e76ff749..dfd49101

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17995&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17995&range=00-01

  Stats: 24 lines in 3 files changed: 1 ins; 2 del; 21 mod
  Patch: https://git.openjdk.org/jdk/pull/17995.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17995/head:pull/17995

PR: https://git.openjdk.org/jdk/pull/17995

From lancea at openjdk.org  Sat Feb 24 18:54:07 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Sat, 24 Feb 2024 18:54:07 GMT
Subject: RFR: 8321156: Improve the handling of invalid UTF-8 byte sequences
 for ZipInputStream::getNextEntry and ZipFile::getComment [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Sat, 24 Feb 2024 18:51:22 GMT, Lance Andersen  wrote:

>> Please review this PR which addresses the handling of invalid UTF-8 byte sequences in the entry name of a LOC file header and a Zip file comment which is returned via ZipFile::getComment.
>> 
>> As part of the change, `ZipFile::getComment` will now return `null` if an invalid UTF-8 byte sequence is encountered while converting the byte array to a String.  The CSR for this change has also been approved.
>> 
>> Mach5 tiers 1-3 are clean with this change.
>
> Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updates based on 1st round of feedback

Thank you for your input Eirik,  I have pushed updates to address the suggestions you raised

-------------

PR Review: https://git.openjdk.org/jdk/pull/17995#pullrequestreview-1899544786

From lancea at openjdk.org  Sat Feb 24 18:54:09 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Sat, 24 Feb 2024 18:54:09 GMT
Subject: RFR: 8321156: Improve the handling of invalid UTF-8 byte sequences
 for ZipInputStream::getNextEntry and ZipFile::getComment [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Sat, 24 Feb 2024 16:57:50 GMT, Eirik Bj?rsn?s  wrote:

>> Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updates based on 1st round of feedback
>
> src/java.base/share/classes/java/util/zip/ZipFile.java line 331:
> 
>> 329:             try {
>> 330:                 return res.zsrc.zc.toString(res.zsrc.comment);
>> 331:             } catch(IllegalArgumentException iae) {
> 
> Suggestion:
> 
>             } catch (IllegalArgumentException iae) {

fixed

> src/java.base/share/classes/java/util/zip/ZipInputStream.java line 526:
> 
>> 524:             throw  (ZipException) new ZipException(
>> 525:                     "invalid LOC header (bad entry name)").initCause(ex);
>> 526:         }
> 
> There is a lot going on here:
> 
> * The creation of a ZipEntry
> * The interpretation of the general purpose bit flag
> * The split to call either a static or non-static toString depending on the flag interpretation
> * The exception handling, including the somewhat unusual initCause and cast
> 
> The comment at 517 seems even more detached from the logic it tries to describe after this change.
> 
> Perhaps we could benefit from introducing a `zipCoderFromFlag(int flag)` method, similar to that in ZipFile?
> 
> This would allow the section to be rewritten to something that hide the flag parsing details, leaves us with a single (polymorphic) toString invocation and extracts `createZipEntry` from the try/catch scope. 
> 
> Something like this: (I also changed the exception handling here, that's a bit orthogonal to the main points above)
> 
> Suggestion:
> 
>         String name;
>         try {
>             name = zipCoderForFlag(flag).toString(b, len);
>         } catch (IllegalArgumentException ex) {
>             ZipException e = new ZipException("invalid LOC header (bad entry name)");
>             e.initCause(ex);
>             throw e;
>         }
>         ZipEntry e = createZipEntry(name);

I believe you meant `ZipCoderFromPos(int flag)`.  I don't think it is needed in ZipInputStream but I did move the call to createZipEntry out of the try block per your suggestion

> test/jdk/java/util/zip/ZipFile/InvalidBytesInEntryNameOrComment.java line 49:
> 
>> 47:  * @summary Validate that a ZipException is thrown when opening a ZIP file via
>> 48:  * ZipFile, traversing a Zip File via ZipInputStream, with invalid UTF-8
>> 49:  * byte sequences in the name or comment fields fails with ZipException.
> 
> The leading summary sentence needs a cleanup. Here's one suggestion:
> 
> Suggestion:
> 
>  * @summary Validate that a ZipException is thrown when a ZIP file with 
>  * invalid UTF-8 byte sequences in the name or comment fields is opened via
>  * ZipFile or traversed via ZipInputStream.

Updated

> test/jdk/java/util/zip/ZipFile/InvalidBytesInEntryNameOrComment.java line 60:
> 
>> 58:     private static final byte[] INVALID_UTF8_BYTE_SEQUENCE = {(byte) 0xF0, (byte) 0xA4, (byte) 0xAD};
>> 59:     // Expected error message when an invalid entry name or entry comment is
>> 60:     // encountered when accessing a CEN Header
> 
> This two-line comment could benefit from an earlier line break.

The break makes sense as is in IntelliJ, so please clarify

> test/jdk/java/util/zip/ZipFile/InvalidBytesInEntryNameOrComment.java line 64:
> 
>> 62: 
>> 63:     // Expected error message when an invalid entry name is encountered when
>> 64:     // accessing a LOC Header
> 
> This two-line comment could benefit from an earlier line break.

Same comment as above

> test/jdk/java/util/zip/ZipFile/InvalidBytesInEntryNameOrComment.java line 65:
> 
>> 63:     // Expected error message when an invalid entry name is encountered when
>> 64:     // accessing a LOC Header
>> 65:     private static final String LOC_BAD_ENTRY_NAME_OR_COMMENT = "invalid LOC header (bad entry name)";
> 
> Should this be renamed `LOC_BAD_ENTRY_NAME`?

Yep, I thought I made that change but must have just thought about it and never went back to it

> test/jdk/java/util/zip/ZipFile/InvalidBytesInEntryNameOrComment.java line 128:
> 
>> 126:      * 0x93: Comment     :   [ZipFileComment]
>> 127:      */
>> 128:     public static byte[] VALID_ZIP = {
> 
> I see this byte array encoding of ZIP files is a pattern used across tests. My preference would be to encode this in Base64 or hex, since that would make the consumption by external command line tools easier and the encoded representation somewhat prettier. But no big deal, this might just come down to personal preference. (This isn't human readable anyhow for the normal definition of "human" :)

Yes, this is a  style preference and plan to leave as is.

> test/jdk/java/util/zip/ZipFile/InvalidBytesInEntryNameOrComment.java line 182:
> 
>> 180:     /**
>> 181:      * Validate that the original Zip file can be opened via ZipFile.
>> 182:      * @throws IOException if an entry occurs
> 
> Suggestion:
> 
>      * @throws IOException if an error occurs

Not sure how I missed that. fixed

> test/jdk/java/util/zip/ZipFile/InvalidBytesInEntryNameOrComment.java line 196:
> 
>> 194:      * Validate that the original Zip file can be opened and traversed via
>> 195:      * ZipinputStream::getNextEntry.
>> 196:      * @throws IOException if an entry occurs
> 
> Suggestion:
> 
>      * @throws IOException if an error occurs

same comment above fixed

> test/jdk/java/util/zip/ZipFile/InvalidBytesInEntryNameOrComment.java line 201:
> 
>> 199:     public void traverseZipWithZipInputStreamTest() throws IOException {
>> 200:         Files.write(ZIP_FILE, zipArray);
>> 201:         try( ZipInputStream zis = new ZipInputStream(new FileInputStream(ZIP_FILE.toFile()))) {
> 
> Suggestion:
> 
>         try (ZipInputStream zis = new ZipInputStream(new FileInputStream(ZIP_FILE.toFile()))) {

fixed

> test/jdk/java/util/zip/ZipFile/InvalidBytesInEntryNameOrComment.java line 203:
> 
>> 201:         try( ZipInputStream zis = new ZipInputStream(new FileInputStream(ZIP_FILE.toFile()))) {
>> 202:             ZipEntry ze;
>> 203:             while((ze = zis.getNextEntry()) != null ) {
> 
> Suggestion:
> 
>             while ((ze = zis.getNextEntry()) != null) {

fixed

> test/jdk/java/util/zip/ZipFile/InvalidBytesInEntryNameOrComment.java line 243:
> 
>> 241: 
>> 242:     /**
>> 243:      * Validate that a ZipException is thrown when an entry name is encountered
> 
> Is the "is" here out of place or are we missing a "which"?
> 
> Suggestion:
> 
>      * Validate that a ZipException is thrown when an entry name encountered

Modified the comment

> test/jdk/java/util/zip/ZipFile/InvalidBytesInEntryNameOrComment.java line 267:
> 
>> 265:      * @throws IOException if an error occurs
>> 266:      */
>> 267:     private void createInvalidUTFEntryInZipFile(int offset) throws IOException {
> 
> Is the "In" in this method name helpful? (To me it suggests a file argument, not a result) 
> Suggestion:
> 
>     private void createInvalidUTFEntryInZipFile(int offset) throws IOException {

Well,  your change is the same but to your comment we are modifying an entry in the ZipFile.  So I don't mind changing the method name but not sure its is really needed

> test/jdk/java/util/zip/ZipFile/InvalidBytesInEntryNameOrComment.java line 304:
> 
>> 302:      *        System.out.println(result);
>> 303:      *      }
>> 304:      *
    > > Can we use `@snippet` in tests? Would allow syntax highlighting in IDEs Sure changed to use `@snippet` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17995#discussion_r1501653167 PR Review Comment: https://git.openjdk.org/jdk/pull/17995#discussion_r1501677114 PR Review Comment: https://git.openjdk.org/jdk/pull/17995#discussion_r1501670123 PR Review Comment: https://git.openjdk.org/jdk/pull/17995#discussion_r1501655822 PR Review Comment: https://git.openjdk.org/jdk/pull/17995#discussion_r1501662492 PR Review Comment: https://git.openjdk.org/jdk/pull/17995#discussion_r1501656632 PR Review Comment: https://git.openjdk.org/jdk/pull/17995#discussion_r1501657036 PR Review Comment: https://git.openjdk.org/jdk/pull/17995#discussion_r1501657953 PR Review Comment: https://git.openjdk.org/jdk/pull/17995#discussion_r1501658140 PR Review Comment: https://git.openjdk.org/jdk/pull/17995#discussion_r1501658526 PR Review Comment: https://git.openjdk.org/jdk/pull/17995#discussion_r1501658974 PR Review Comment: https://git.openjdk.org/jdk/pull/17995#discussion_r1501663806 PR Review Comment: https://git.openjdk.org/jdk/pull/17995#discussion_r1501660807 PR Review Comment: https://git.openjdk.org/jdk/pull/17995#discussion_r1501666735 From lancea at openjdk.org Sat Feb 24 19:12:56 2024 From: lancea at openjdk.org (Lance Andersen) Date: Sat, 24 Feb 2024 19:12:56 GMT Subject: RFR: 8321156: Improve the handling of invalid UTF-8 byte sequences for ZipInputStream::getNextEntry and ZipFile::getComment In-Reply-To: <1Nj2tmlIoo01DBj5OFkTSy_xMMK-WB1-eda8GgYyWA8=.fcc6ba1b-c1a2-40fa-ac55-8eacf7d0f159@github.com> References: <1Nj2tmlIoo01DBj5OFkTSy_xMMK-WB1-eda8GgYyWA8=.fcc6ba1b-c1a2-40fa-ac55-8eacf7d0f159@github.com> Message-ID: On Sat, 24 Feb 2024 17:15:02 GMT, Eirik Bj?rsn?s wrote: > Since the CSR is already approved, I'll add a question here: > > `ZipFile` performs a lot of validation while opening ZIP files, including throwning ZipException for invalid entry names or comments. Why handle the ZIP file comment differently (lazily)? If this comment was also validated by the constructor, then the API change for ZipFile::getComment would not be needed. > > Do we have reason to belive the encoding quality of ZIP file comments is less reliable than that of ZIP entry comments? Or is there some other reason this validation is done lazily? Yes, there are some libraries/tools that are using the Zip file comment for its own purposes such as idea_rt.jar which is part of IntelliJ. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17995#issuecomment-1962571347 From darcy at openjdk.org Sat Feb 24 20:31:13 2024 From: darcy at openjdk.org (Joe Darcy) Date: Sat, 24 Feb 2024 20:31:13 GMT Subject: RFR: JDK-8316708: Augment WorstCaseTests with more cases [v3] In-Reply-To: References: Message-ID: > A new paper > > "Accuracy of Mathematical Functions in Single, Double, Double Extended, and Quadruple Precision" > by Brian Gladman, Vincenzo Innocente and Paul Zimmermann > https://members.loria.fr/PZimmermann/papers/accuracy.pdf > > details the inputs with generate the worst-case observed errors in different math library implementations. The FDLIBM-related worst cases should be added to the test suite. Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Improve comments, implement review feedback. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15879/files - new: https://git.openjdk.org/jdk/pull/15879/files/fb7dbb87..c0e9cefe Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15879&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15879&range=01-02 Stats: 28 lines in 2 files changed: 11 ins; 0 del; 17 mod Patch: https://git.openjdk.org/jdk/pull/15879.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15879/head:pull/15879 PR: https://git.openjdk.org/jdk/pull/15879 From darcy at openjdk.org Sat Feb 24 23:25:53 2024 From: darcy at openjdk.org (Joe Darcy) Date: Sat, 24 Feb 2024 23:25:53 GMT Subject: RFR: JDK-8316708: Augment WorstCaseTests with more cases [v3] In-Reply-To: References: Message-ID: <8WekfliUjbFjK0filvgDIw4_MSfxDUeGE8TI_GPfz6M=.0c87ac81-3ebc-4240-b95e-e20ba6e685ea@github.com> On Fri, 23 Feb 2024 19:18:22 GMT, Joe Darcy wrote: > > Both `Math.cos` and `StrictMath.cos` produce the correctly rounded result here. I don't know why the paper says otherwise. Perhaps OpenLibm is not exactly fdlibm. > > I've looked a bit over the OpenLibm changelog. They've added a few special cases for exp and pow as least. OpenLibm itself is a direct derivative of one of the BSD math libraries, which in turn was derived from FDLIBM. The BSDs look to have changed/improved the kernel cos computation in their fork. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15879#discussion_r1501713166 From jbhateja at openjdk.org Sun Feb 25 06:27:10 2024 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Sun, 25 Feb 2024 06:27:10 GMT Subject: RFR: 8318650: Optimized subword gather for x86 targets. [v14] 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 using 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.5-10x 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. > > 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/2e3a6143..05e606ff Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16354&range=13 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16354&range=12-13 Stats: 185 lines in 3 files changed: 10 ins; 68 del; 107 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 Feb 25 06:27:10 2024 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Sun, 25 Feb 2024 06:27:10 GMT Subject: RFR: 8318650: Optimized subword gather for x86 targets. [v13] In-Reply-To: References: <-jaGezbfx9ZylmA6EBQY2TxqjfIHNhT8TXI6_KCL11Y=.d48ef20a-21c1-4486-ada6-4e1acf86a9ea@github.com> Message-ID: On Tue, 20 Feb 2024 08:04:27 GMT, Emanuel Peter wrote: >> src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 1584: >> >>> 1582: Label *larr[] = {&case0, &case1, &case2, &case3}; >>> 1583: for (int i = 0; i < 4; i++) { >>> 1584: // dst[i] = mask ? src[index[i]] : 0 >> >> I like these comments a lot! >> They would be even better if they had a more clear relation to the register names. >> >> `dst[i] = mask[i+midx] ? src[idx_base[i]] : 0` >> It would then be helpful to know the types of these arrays. >> It seems that `idx_base` is an array with type int, right? > > Ah, and can we use `base_index`? Otherwise we have an inconsistency with `index` vs `idx`. We are accessing two arrays here, source arrays and index arrays, registers holding their addresses are 'base' and 'idx_base', naming looks appropriate in this context. Comments adjusted to reflect actual register names. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16354#discussion_r1501753568 From jbhateja at openjdk.org Sun Feb 25 06:27:10 2024 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Sun, 25 Feb 2024 06:27:10 GMT Subject: RFR: 8318650: Optimized subword gather for x86 targets. [v13] In-Reply-To: References: <-jaGezbfx9ZylmA6EBQY2TxqjfIHNhT8TXI6_KCL11Y=.d48ef20a-21c1-4486-ada6-4e1acf86a9ea@github.com> Message-ID: On Tue, 20 Feb 2024 08:36:29 GMT, Emanuel Peter wrote: >> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: >> >> Review comments resolutions. > > src/hotspot/cpu/x86/x86.ad line 4120: > >> 4118: BasicType elem_bt = Matcher::vector_element_basic_type(this); >> 4119: __ lea($tmp$$Register, $mem$$Address); >> 4120: __ vgather8b(elem_bt, $dst$$XMMRegister, $tmp$$Register, $idx$$Register, $rtmp$$Register, vlen_enc); > > The `LE8B` and `Matcher::vector_length_in_bytes(n) <= 8` suggest we can perform this with 4 bytes as well. > Is that correct? > Would that not lead to issues, when we are then reading `base_index` at bytes 4...7, which possibly have garbage, and then use that to gather? > Do we have tests for that? 64 bit sub-word SPECIES will either hold 8 bytes values or 4 short values, algorithm appropriately handle it. > src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ByteVector.java line 3071: > >> 3069: .fromArray(lsp, indexMap, mapOffset + i) >> 3070: .add(offset); >> 3071: vix = VectorIntrinsics.checkIndex(vix, a.length); > > are you using the `vix` after this assignment? Its purpose is to check out of bounds indices. > src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ShortVector.java line 3809: > >> 3807: >> 3808: // Check indices are within array bounds. >> 3809: // FIXME: Check index under mask controlling. > > Did you mean to leave a FIXME? If so, please reference a JIRA bug number where you intend to fix it. This is in line with already existing FIXME https://github.com/openjdk/jdk/blob/master/src/jdk.incubator.vector/share/classes/jdk/incubator/vector/X-Vector.java.template#L5035 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16354#discussion_r1501753441 PR Review Comment: https://git.openjdk.org/jdk/pull/16354#discussion_r1501753416 PR Review Comment: https://git.openjdk.org/jdk/pull/16354#discussion_r1501753413 From duke at openjdk.org Sun Feb 25 08:17:04 2024 From: duke at openjdk.org (Korov) Date: Sun, 25 Feb 2024 08:17:04 GMT Subject: RFR: 8310351: Typo in ImmutableCollections Message-ID: <8eUAT9MB4WvdaAFeh6Q99oK-5s4lhNuW9bNjHF5J20k=.5b31f180-4309-458f-8937-93d5d11b17a4@github.com> Fix the @param name ------------- Commit messages: - 8310351: Typo in ImmutableCollections Changes: https://git.openjdk.org/jdk/pull/17996/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17996&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8310351 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/17996.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17996/head:pull/17996 PR: https://git.openjdk.org/jdk/pull/17996 From jlaskey at openjdk.org Sun Feb 25 08:29:52 2024 From: jlaskey at openjdk.org (Jim Laskey) Date: Sun, 25 Feb 2024 08:29:52 GMT Subject: RFR: 8310351: Typo in ImmutableCollections In-Reply-To: <8eUAT9MB4WvdaAFeh6Q99oK-5s4lhNuW9bNjHF5J20k=.5b31f180-4309-458f-8937-93d5d11b17a4@github.com> References: <8eUAT9MB4WvdaAFeh6Q99oK-5s4lhNuW9bNjHF5J20k=.5b31f180-4309-458f-8937-93d5d11b17a4@github.com> Message-ID: On Sun, 25 Feb 2024 08:13:08 GMT, Korov wrote: > Fix the @param name Marked as reviewed by jlaskey (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/17996#pullrequestreview-1899627681 From duke at openjdk.org Sun Feb 25 10:57:52 2024 From: duke at openjdk.org (Korov) Date: Sun, 25 Feb 2024 10:57:52 GMT Subject: RFR: 8310351: Typo in ImmutableCollections In-Reply-To: References: <8eUAT9MB4WvdaAFeh6Q99oK-5s4lhNuW9bNjHF5J20k=.5b31f180-4309-458f-8937-93d5d11b17a4@github.com> Message-ID: On Sun, 25 Feb 2024 08:27:41 GMT, Jim Laskey wrote: >> Fix the @param name > > Marked as reviewed by jlaskey (Reviewer). @JimLaskey Hi, this commit has passed all checks, I also executed the `/integrate` command. I need your help to execute the next command `/sponsor`. If there are other things that need to be modified, I will modify them as soon as possible. Thank you so much for helping out. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17996#issuecomment-1962893247 From jpai at openjdk.org Sun Feb 25 11:20:53 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Sun, 25 Feb 2024 11:20:53 GMT Subject: RFR: 8310351: Typo in ImmutableCollections In-Reply-To: <8eUAT9MB4WvdaAFeh6Q99oK-5s4lhNuW9bNjHF5J20k=.5b31f180-4309-458f-8937-93d5d11b17a4@github.com> References: <8eUAT9MB4WvdaAFeh6Q99oK-5s4lhNuW9bNjHF5J20k=.5b31f180-4309-458f-8937-93d5d11b17a4@github.com> Message-ID: On Sun, 25 Feb 2024 08:13:08 GMT, Korov wrote: > Fix the @param name src/java.base/share/classes/java/util/ImmutableCollections.java line 164: > 162: * > 163: * @param the List's element type > 164: * @param coll the input array Hello @Korov, while at it, can you also change that text to "the input collection". The parameter of the method isn't an array. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17996#discussion_r1501798446 From jpai at openjdk.org Sun Feb 25 11:29:53 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Sun, 25 Feb 2024 11:29:53 GMT Subject: RFR: JDK-8326389: [test] improve assertEquals failure output [v3] In-Reply-To: <7xPPisT1fNEHqXyPQVJX8gAYu2i7HCV1PNPDlxNVfJw=.3aa0924c-583f-405c-9c0b-61ff292d6d6d@github.com> References: <7xPPisT1fNEHqXyPQVJX8gAYu2i7HCV1PNPDlxNVfJw=.3aa0924c-583f-405c-9c0b-61ff292d6d6d@github.com> Message-ID: On Thu, 22 Feb 2024 16:01:19 GMT, Matthias Baesken wrote: >> Currently assertEquals has in the failure case sometimes confusing output like : >> >> java.lang.RuntimeException: VM output should contain exactly one RTM locking statistics entry for method compiler.rtm.locking.TestRTMTotalCountIncrRate$Test:? expected 0 to equal 1 >> at jdk.test.lib.Asserts.fail(Asserts.java:634) >> at jdk.test.lib.Asserts.assertEquals(Asserts.java:205) >> >> (I don't think we really expected that for some reason 0 equals 1) >> This should be improved. > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > assertEquals adjust output Hello Christoph, in that case the `if` block I proposed can be removed. Does the alternate proposed error message look better to you and Matthias? ------------- PR Comment: https://git.openjdk.org/jdk/pull/17952#issuecomment-1962901480 From duke at openjdk.org Sun Feb 25 11:37:05 2024 From: duke at openjdk.org (Korov) Date: Sun, 25 Feb 2024 11:37:05 GMT Subject: RFR: 8310351: Typo in ImmutableCollections [v2] In-Reply-To: <8eUAT9MB4WvdaAFeh6Q99oK-5s4lhNuW9bNjHF5J20k=.5b31f180-4309-458f-8937-93d5d11b17a4@github.com> References: <8eUAT9MB4WvdaAFeh6Q99oK-5s4lhNuW9bNjHF5J20k=.5b31f180-4309-458f-8937-93d5d11b17a4@github.com> Message-ID: > Fix the @param name Korov has updated the pull request incrementally with one additional commit since the last revision: array -> collection ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17996/files - new: https://git.openjdk.org/jdk/pull/17996/files/d7b20743..a1cdf112 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17996&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17996&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/17996.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17996/head:pull/17996 PR: https://git.openjdk.org/jdk/pull/17996 From duke at openjdk.org Sun Feb 25 11:45:53 2024 From: duke at openjdk.org (Korov) Date: Sun, 25 Feb 2024 11:45:53 GMT Subject: RFR: 8310351: Typo in ImmutableCollections [v2] In-Reply-To: References: <8eUAT9MB4WvdaAFeh6Q99oK-5s4lhNuW9bNjHF5J20k=.5b31f180-4309-458f-8937-93d5d11b17a4@github.com> Message-ID: On Sun, 25 Feb 2024 11:37:05 GMT, Korov wrote: >> Fix the @param name > > Korov has updated the pull request incrementally with one additional commit since the last revision: > > array -> collection src/java.base/share/classes/java/util/ImmutableCollections.java line 164: > 162: * > 163: * @param the List's element type > 164: * @param coll the input collection Hi @jaikiran , the text has been modified. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17996#discussion_r1501802622 From jpai at openjdk.org Sun Feb 25 11:51:53 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Sun, 25 Feb 2024 11:51:53 GMT Subject: RFR: 8310351: Typo in ImmutableCollections [v2] In-Reply-To: References: <8eUAT9MB4WvdaAFeh6Q99oK-5s4lhNuW9bNjHF5J20k=.5b31f180-4309-458f-8937-93d5d11b17a4@github.com> Message-ID: On Sun, 25 Feb 2024 11:37:05 GMT, Korov wrote: >> Fix the @param name > > Korov has updated the pull request incrementally with one additional commit since the last revision: > > array -> collection Thank you for the update. The change is trivial and looks good to me. ------------- Marked as reviewed by jpai (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17996#pullrequestreview-1899660556 From duke at openjdk.org Sun Feb 25 11:54:57 2024 From: duke at openjdk.org (Korov) Date: Sun, 25 Feb 2024 11:54:57 GMT Subject: Integrated: 8310351: Typo in ImmutableCollections In-Reply-To: <8eUAT9MB4WvdaAFeh6Q99oK-5s4lhNuW9bNjHF5J20k=.5b31f180-4309-458f-8937-93d5d11b17a4@github.com> References: <8eUAT9MB4WvdaAFeh6Q99oK-5s4lhNuW9bNjHF5J20k=.5b31f180-4309-458f-8937-93d5d11b17a4@github.com> Message-ID: <8kjRKFm2GwuuH5BJI37Y1crTFJ5Cy9Ng5gTLVGzfl58=.1801c480-dbc1-400b-a011-dbcc9e908d72@github.com> On Sun, 25 Feb 2024 08:13:08 GMT, Korov wrote: > Fix the @param name This pull request has now been integrated. Changeset: 1799ffea Author: Korov Committer: Jaikiran Pai URL: https://git.openjdk.org/jdk/commit/1799ffeaa9baa7d703c7acc8d8738211694f946e Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8310351: Typo in ImmutableCollections Reviewed-by: jlaskey, jpai ------------- PR: https://git.openjdk.org/jdk/pull/17996 From jpai at openjdk.org Sun Feb 25 12:22:53 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Sun, 25 Feb 2024 12:22:53 GMT Subject: RFR: 8321156: Improve the handling of invalid UTF-8 byte sequences for ZipInputStream::getNextEntry and ZipFile::getComment [v2] In-Reply-To: References: Message-ID: On Sat, 24 Feb 2024 18:54:07 GMT, Lance Andersen wrote: >> Please review this PR which addresses the handling of invalid UTF-8 byte sequences in the entry name of a LOC file header and a Zip file comment which is returned via ZipFile::getComment. >> >> As part of the change, `ZipFile::getComment` will now return `null` if an invalid UTF-8 byte sequence is encountered while converting the byte array to a String. The CSR for this change has also been approved. >> >> Mach5 tiers 1-3 are clean with this change. > > Lance Andersen has updated the pull request incrementally with one additional commit since the last revision: > > Updates based on 1st round of feedback Hello Lance, the changes look fine to me. `ZipFile.java` file will need a copyright year update. test/jdk/java/util/zip/ZipFile/InvalidBytesInEntryNameOrComment.java line 189: > 187: try (ZipFile zf = new ZipFile(ZIP_FILE.toFile())) { > 188: var comment = zf.getComment(); > 189: System.out.printf("Comment= %s%n", comment); Should we assert for the valid expected `comment` here? ------------- Marked as reviewed by jpai (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17995#pullrequestreview-1899665517 PR Review Comment: https://git.openjdk.org/jdk/pull/17995#discussion_r1501808997 From eirbjo at openjdk.org Sun Feb 25 12:22:53 2024 From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=) Date: Sun, 25 Feb 2024 12:22:53 GMT Subject: RFR: 8321156: Improve the handling of invalid UTF-8 byte sequences for ZipInputStream::getNextEntry and ZipFile::getComment [v2] In-Reply-To: References: Message-ID: On Sat, 24 Feb 2024 18:54:07 GMT, Lance Andersen wrote: >> Please review this PR which addresses the handling of invalid UTF-8 byte sequences in the entry name of a LOC file header and a Zip file comment which is returned via ZipFile::getComment. >> >> As part of the change, `ZipFile::getComment` will now return `null` if an invalid UTF-8 byte sequence is encountered while converting the byte array to a String. The CSR for this change has also been approved. >> >> Mach5 tiers 1-3 are clean with this change. > > Lance Andersen has updated the pull request incrementally with one additional commit since the last revision: > > Updates based on 1st round of feedback src/java.base/share/classes/java/util/zip/ZipInputStream.java line 524: > 522: : zc.toString(b, len); > 523: } catch(Exception ex) { > 524: throw (ZipException) new ZipException( Whitespace nit: Suggestion: } catch (Exception ex) { throw (ZipException) new ZipException( ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17995#discussion_r1501809393 From lancea at openjdk.org Sun Feb 25 14:17:05 2024 From: lancea at openjdk.org (Lance Andersen) Date: Sun, 25 Feb 2024 14:17:05 GMT Subject: RFR: 8321156: Improve the handling of invalid UTF-8 byte sequences for ZipInputStream::getNextEntry and ZipFile::getComment [v3] In-Reply-To: References: Message-ID: > Please review this PR which addresses the handling of invalid UTF-8 byte sequences in the entry name of a LOC file header and a Zip file comment which is returned via ZipFile::getComment. > > As part of the change, `ZipFile::getComment` will now return `null` if an invalid UTF-8 byte sequence is encountered while converting the byte array to a String. The CSR for this change has also been approved. > > Mach5 tiers 1-3 are clean with this change. Lance Andersen has updated the pull request incrementally with one additional commit since the last revision: Updates based on 2nd round of feedback ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17995/files - new: https://git.openjdk.org/jdk/pull/17995/files/dfd49101..637acee4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17995&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17995&range=01-02 Stats: 14 lines in 3 files changed: 6 ins; 0 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/17995.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17995/head:pull/17995 PR: https://git.openjdk.org/jdk/pull/17995 From lancea at openjdk.org Sun Feb 25 14:17:05 2024 From: lancea at openjdk.org (Lance Andersen) Date: Sun, 25 Feb 2024 14:17:05 GMT Subject: RFR: 8321156: Improve the handling of invalid UTF-8 byte sequences for ZipInputStream::getNextEntry and ZipFile::getComment [v2] In-Reply-To: References: Message-ID: <2I5izc2iWHVecz5VEhTW08K_KlWCeFtfNB-1KVElU2s=.39b2f933-dd6f-44b8-bbb0-53795fa93cd6@github.com> On Sat, 24 Feb 2024 18:54:07 GMT, Lance Andersen wrote: >> Please review this PR which addresses the handling of invalid UTF-8 byte sequences in the entry name of a LOC file header and a Zip file comment which is returned via ZipFile::getComment. >> >> As part of the change, `ZipFile::getComment` will now return `null` if an invalid UTF-8 byte sequence is encountered while converting the byte array to a String. The CSR for this change has also been approved. >> >> Mach5 tiers 1-3 are clean with this change. > > Lance Andersen has updated the pull request incrementally with one additional commit since the last revision: > > Updates based on 1st round of feedback Thanks for the feedback. Updated accordingly ------------- PR Review: https://git.openjdk.org/jdk/pull/17995#pullrequestreview-1899679545 From lancea at openjdk.org Sun Feb 25 14:17:05 2024 From: lancea at openjdk.org (Lance Andersen) Date: Sun, 25 Feb 2024 14:17:05 GMT Subject: RFR: 8321156: Improve the handling of invalid UTF-8 byte sequences for ZipInputStream::getNextEntry and ZipFile::getComment [v2] In-Reply-To: References: Message-ID: <_lSEek5TFIO2i7KrbIpVSMHK8Hcsj75Srhe9_8jzd7M=.d83505d5-c5f1-4f96-90e1-545e11dcaf3e@github.com> On Sun, 25 Feb 2024 12:16:14 GMT, Jaikiran Pai wrote: > Hello Lance, the changes look fine to me. `ZipFile.java` file will need a copyright year update. Thank you Jai, updated > test/jdk/java/util/zip/ZipFile/InvalidBytesInEntryNameOrComment.java line 189: > >> 187: try (ZipFile zf = new ZipFile(ZIP_FILE.toFile())) { >> 188: var comment = zf.getComment(); >> 189: System.out.printf("Comment= %s%n", comment); > > Should we assert for the valid expected `comment` here? Sure I can add the validation ------------- PR Comment: https://git.openjdk.org/jdk/pull/17995#issuecomment-1962954345 PR Review Comment: https://git.openjdk.org/jdk/pull/17995#discussion_r1501822988 From lancea at openjdk.org Sun Feb 25 14:17:06 2024 From: lancea at openjdk.org (Lance Andersen) Date: Sun, 25 Feb 2024 14:17:06 GMT Subject: RFR: 8321156: Improve the handling of invalid UTF-8 byte sequences for ZipInputStream::getNextEntry and ZipFile::getComment [v2] In-Reply-To: References: Message-ID: <3_E_wTbwI4hqUHX31DChfRCUe_VJgES4PZIqEoEY6sk=.cb34e3d6-ee75-49b2-b220-8203bd3e7cd4@github.com> On Sun, 25 Feb 2024 12:20:36 GMT, Eirik Bj?rsn?s wrote: >> Lance Andersen has updated the pull request incrementally with one additional commit since the last revision: >> >> Updates based on 1st round of feedback > > src/java.base/share/classes/java/util/zip/ZipInputStream.java line 524: > >> 522: : zc.toString(b, len); >> 523: } catch(Exception ex) { >> 524: throw (ZipException) new ZipException( > > Whitespace nit: > > Suggestion: > > } catch (Exception ex) { > throw (ZipException) new ZipException( fixed ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17995#discussion_r1501822894 From jpai at openjdk.org Sun Feb 25 14:58:53 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Sun, 25 Feb 2024 14:58:53 GMT Subject: RFR: 8321156: Improve the handling of invalid UTF-8 byte sequences for ZipInputStream::getNextEntry and ZipFile::getComment [v3] In-Reply-To: References: Message-ID: On Sun, 25 Feb 2024 14:17:05 GMT, Lance Andersen wrote: >> Please review this PR which addresses the handling of invalid UTF-8 byte sequences in the entry name of a LOC file header and a Zip file comment which is returned via ZipFile::getComment. >> >> As part of the change, `ZipFile::getComment` will now return `null` if an invalid UTF-8 byte sequence is encountered while converting the byte array to a String. The CSR for this change has also been approved. >> >> Mach5 tiers 1-3 are clean with this change. > > Lance Andersen has updated the pull request incrementally with one additional commit since the last revision: > > Updates based on 2nd round of feedback Thank you for the updates, Lance. The changes look good to me. ------------- Marked as reviewed by jpai (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17995#pullrequestreview-1899695125 From alanb at openjdk.org Sun Feb 25 15:22:53 2024 From: alanb at openjdk.org (Alan Bateman) Date: Sun, 25 Feb 2024 15:22:53 GMT Subject: RFR: 8326096: Deprecate getTotalIn, getTotalOut methods of java.util.zip.Inflater, java.util.zip.Deflater [v4] In-Reply-To: References: <3gTPWxpnS5VRTXK4P1gNtI5c-3BCL9OwR2FSHqZ9Nbo=.e0e49dc5-736a-4f7d-81a0-7a5e1fe9aa57@github.com> Message-ID: <87wbBmabvVXFLBmw3sAFKTU2BtHG2kxQG2kGvzrMC7Y=.bdb475dc-f235-4614-9c84-451e7e99db4f@github.com> On Thu, 22 Feb 2024 14:06:25 GMT, Eirik Bj?rsn?s wrote: > Alan, > > Finding a good way to express this while being correct and succinct was surprisingly hard. What I have now is probably far from perfect, but at least something to serve as a starting point for review: The `@depreacted` text looks fine. For the class description then it might be simpler to reduce the new text down to one sentence, e.g. "This method returns the equivalent of {@code (int) getBytesRead()} and therefore cannot return the correct number of compressed bytes input so far when it is greater than Integer.MAX_VALUE." ------------- PR Comment: https://git.openjdk.org/jdk/pull/17919#issuecomment-1962972560 From alanb at openjdk.org Sun Feb 25 15:29:54 2024 From: alanb at openjdk.org (Alan Bateman) Date: Sun, 25 Feb 2024 15:29:54 GMT Subject: RFR: 8321156: Improve the handling of invalid UTF-8 byte sequences for ZipInputStream::getNextEntry and ZipFile::getComment [v3] In-Reply-To: References: Message-ID: <2cG6OdVf5fntURL2DtrbTbEUipt19GS2J31OuFjEyxk=.ae7b96e9-7296-4c8e-baa6-3c4d46b4fcf0@github.com> On Sun, 25 Feb 2024 14:17:05 GMT, Lance Andersen wrote: >> Please review this PR which addresses the handling of invalid UTF-8 byte sequences in the entry name of a LOC file header and a Zip file comment which is returned via ZipFile::getComment. >> >> As part of the change, `ZipFile::getComment` will now return `null` if an invalid UTF-8 byte sequence is encountered while converting the byte array to a String. The CSR for this change has also been approved. >> >> Mach5 tiers 1-3 are clean with this change. > > Lance Andersen has updated the pull request incrementally with one additional commit since the last revision: > > Updates based on 2nd round of feedback Spec + implementation change look fine. I haven't spent time looking at the test. src/java.base/share/classes/java/util/zip/ZipFile.java line 313: > 311: * Returns the zip file comment. If a comment does not exist or an error is > 312: * encountered decoding the comment using the charset specified > 313: * when opening the Zip file, then {@code null} is returned. I've previously discussed options with Lance around this issue and I agree with the proposal to specify that it returns null when the decoding fails. (In passing, the casing of "zip file" is very inconsistent in the javadoc, it's "ZIP file" in some places, "zip file" in others, the change here uses "Zip file"). ------------- Marked as reviewed by alanb (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17995#pullrequestreview-1899700665 PR Review Comment: https://git.openjdk.org/jdk/pull/17995#discussion_r1501843252 From liach at openjdk.org Sun Feb 25 18:10:54 2024 From: liach at openjdk.org (Chen Liang) Date: Sun, 25 Feb 2024 18:10:54 GMT Subject: RFR: 8326617: String Template FMT removes unnecessary int to long type cast In-Reply-To: References: Message-ID: <0fykzesorbUsNVq8GElob0NgtCzHgQlKU6yhcFHhZw8=.0e4f36c5-e477-46be-8383-1d5fe8f6e7c0@github.com> On Mon, 2 Oct 2023 23:05:29 GMT, Shaojin Wen wrote: > In the current version, FMT."v =%d{1}" will call the StringConcatHelper.prepend(long/byte[]/long) method, which should behave the same as STR."v ={1}". Call StringConcatHelper.prepend(long/byte[]/int), should not convert int to long > > Please review and don't hesitate to critique my approach and patch. Marked as reviewed by liach (Author). Good catch. Out of scope of this issue, but with the commented out code, the `explicitCastArguments` call before the switch can be removed, and `itype` can simply become `ptype`. ------------- PR Review: https://git.openjdk.org/jdk/pull/16017#pullrequestreview-1899725121 PR Comment: https://git.openjdk.org/jdk/pull/16017#issuecomment-1963016840 From lancea at openjdk.org Sun Feb 25 19:08:54 2024 From: lancea at openjdk.org (Lance Andersen) Date: Sun, 25 Feb 2024 19:08:54 GMT Subject: RFR: 8321156: Improve the handling of invalid UTF-8 byte sequences for ZipInputStream::getNextEntry and ZipFile::getComment [v3] In-Reply-To: <2cG6OdVf5fntURL2DtrbTbEUipt19GS2J31OuFjEyxk=.ae7b96e9-7296-4c8e-baa6-3c4d46b4fcf0@github.com> References: <2cG6OdVf5fntURL2DtrbTbEUipt19GS2J31OuFjEyxk=.ae7b96e9-7296-4c8e-baa6-3c4d46b4fcf0@github.com> Message-ID: On Sun, 25 Feb 2024 15:26:35 GMT, Alan Bateman wrote: > (In passing, the casing of "zip file" is very inconsistent in the javadoc, it's "ZIP file" in some places, "zip file" in others, the change here uses "Zip file"). Thank you for pointing out the discrepancy above. Let's decide on which way to go and I will update under a separate PR. I would suggest "ZIP file" based on the PKWare APPNOTE.TXT, but the man pages for info-zip command _zip_ command uses "zip file" Apache commons also uses "ZIP file" or "Zip archive" ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17995#discussion_r1501878600 From clanger at openjdk.org Sun Feb 25 22:40:54 2024 From: clanger at openjdk.org (Christoph Langer) Date: Sun, 25 Feb 2024 22:40:54 GMT Subject: RFR: JDK-8326389: [test] improve assertEquals failure output [v3] In-Reply-To: <7xPPisT1fNEHqXyPQVJX8gAYu2i7HCV1PNPDlxNVfJw=.3aa0924c-583f-405c-9c0b-61ff292d6d6d@github.com> References: <7xPPisT1fNEHqXyPQVJX8gAYu2i7HCV1PNPDlxNVfJw=.3aa0924c-583f-405c-9c0b-61ff292d6d6d@github.com> Message-ID: <_LoYc5DfTGAw19p6rk-aFB_kFHshWkugbVVYHiPtxlE=.a8dd1e86-0052-4d76-8236-7eca1af603fc@github.com> On Thu, 22 Feb 2024 16:01:19 GMT, Matthias Baesken wrote: >> Currently assertEquals has in the failure case sometimes confusing output like : >> >> java.lang.RuntimeException: VM output should contain exactly one RTM locking statistics entry for method compiler.rtm.locking.TestRTMTotalCountIncrRate$Test:? expected 0 to equal 1 >> at jdk.test.lib.Asserts.fail(Asserts.java:634) >> at jdk.test.lib.Asserts.assertEquals(Asserts.java:205) >> >> (I don't think we really expected that for some reason 0 equals 1) >> This should be improved. > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > assertEquals adjust output Then maybe it should be > ```diff > + fail((msg == null ? "assertEquals" : msg) + " expected: " + lhs + " but was: " + rhs); > ``` ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/17952#issuecomment-1963086026 From jpai at openjdk.org Mon Feb 26 01:19:53 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 26 Feb 2024 01:19:53 GMT Subject: RFR: JDK-8326389: [test] improve assertEquals failure output [v3] In-Reply-To: <7xPPisT1fNEHqXyPQVJX8gAYu2i7HCV1PNPDlxNVfJw=.3aa0924c-583f-405c-9c0b-61ff292d6d6d@github.com> References: <7xPPisT1fNEHqXyPQVJX8gAYu2i7HCV1PNPDlxNVfJw=.3aa0924c-583f-405c-9c0b-61ff292d6d6d@github.com> Message-ID: On Thu, 22 Feb 2024 16:01:19 GMT, Matthias Baesken wrote: >> Currently assertEquals has in the failure case sometimes confusing output like : >> >> java.lang.RuntimeException: VM output should contain exactly one RTM locking statistics entry for method compiler.rtm.locking.TestRTMTotalCountIncrRate$Test:? expected 0 to equal 1 >> at jdk.test.lib.Asserts.fail(Asserts.java:634) >> at jdk.test.lib.Asserts.assertEquals(Asserts.java:205) >> >> (I don't think we really expected that for some reason 0 equals 1) >> This should be improved. > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > assertEquals adjust output Hello Christoph, yes that looks fine to me. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17952#issuecomment-1963155311 From jpai at openjdk.org Mon Feb 26 06:02:53 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 26 Feb 2024 06:02:53 GMT Subject: RFR: 8321156: Improve the handling of invalid UTF-8 byte sequences for ZipInputStream::getNextEntry and ZipFile::getComment [v3] In-Reply-To: References: <2cG6OdVf5fntURL2DtrbTbEUipt19GS2J31OuFjEyxk=.ae7b96e9-7296-4c8e-baa6-3c4d46b4fcf0@github.com> Message-ID: On Sun, 25 Feb 2024 19:05:58 GMT, Lance Andersen wrote: > I would suggest "ZIP file" based on the PKWare APPNOTE.TXT, I think using this case would be good. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17995#discussion_r1502076153 From dholmes at openjdk.org Mon Feb 26 06:21:55 2024 From: dholmes at openjdk.org (David Holmes) Date: Mon, 26 Feb 2024 06:21:55 GMT Subject: RFR: JDK-8326389: [test] improve assertEquals failure output [v3] In-Reply-To: <7xPPisT1fNEHqXyPQVJX8gAYu2i7HCV1PNPDlxNVfJw=.3aa0924c-583f-405c-9c0b-61ff292d6d6d@github.com> References: <7xPPisT1fNEHqXyPQVJX8gAYu2i7HCV1PNPDlxNVfJw=.3aa0924c-583f-405c-9c0b-61ff292d6d6d@github.com> Message-ID: On Thu, 22 Feb 2024 16:01:19 GMT, Matthias Baesken wrote: >> Currently assertEquals has in the failure case sometimes confusing output like : >> >> java.lang.RuntimeException: VM output should contain exactly one RTM locking statistics entry for method compiler.rtm.locking.TestRTMTotalCountIncrRate$Test:? expected 0 to equal 1 >> at jdk.test.lib.Asserts.fail(Asserts.java:634) >> at jdk.test.lib.Asserts.assertEquals(Asserts.java:205) >> >> (I don't think we really expected that for some reason 0 equals 1) >> This should be improved. > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > assertEquals adjust output Does "expected 0 to equal 1" really cause that much consternation? I just read it as "expected 0 to be equal to 1". Aren't there existing test libraries that already "standardise" these kinds of utilities that we can emulate? testng? junit? ------------- PR Comment: https://git.openjdk.org/jdk/pull/17952#issuecomment-1963396567 From darcy at openjdk.org Mon Feb 26 06:46:23 2024 From: darcy at openjdk.org (Joe Darcy) Date: Mon, 26 Feb 2024 06:46:23 GMT Subject: RFR: JDK-8316708: Augment WorstCaseTests with more cases [v4] In-Reply-To: References: Message-ID: > A new paper > > "Accuracy of Mathematical Functions in Single, Double, Double Extended, and Quadruple Precision" > by Brian Gladman, Vincenzo Innocente and Paul Zimmermann > https://members.loria.fr/PZimmermann/papers/accuracy.pdf > > details the inputs with generate the worst-case observed errors in different math library implementations. The FDLIBM-related worst cases should be added to the test suite. Joe Darcy has updated the pull request incrementally with five additional commits since the last revision: - Fix missing minus sign. - Checkpoint. - Checkpoint StrictMath test for trig, inverse trig, and hyperbolic trig fingerprint values. - Add cos test cases. - Add sin and asin cases. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15879/files - new: https://git.openjdk.org/jdk/pull/15879/files/c0e9cefe..ee28a7f9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15879&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15879&range=02-03 Stats: 150 lines in 6 files changed: 129 ins; 0 del; 21 mod Patch: https://git.openjdk.org/jdk/pull/15879.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15879/head:pull/15879 PR: https://git.openjdk.org/jdk/pull/15879 From darcy at openjdk.org Mon Feb 26 06:46:24 2024 From: darcy at openjdk.org (Joe Darcy) Date: Mon, 26 Feb 2024 06:46:24 GMT Subject: RFR: JDK-8316708: Augment WorstCaseTests with more cases [v3] In-Reply-To: References: Message-ID: On Sat, 24 Feb 2024 20:31:13 GMT, Joe Darcy wrote: >> A new paper >> >> "Accuracy of Mathematical Functions in Single, Double, Double Extended, and Quadruple Precision" >> by Brian Gladman, Vincenzo Innocente and Paul Zimmermann >> https://members.loria.fr/PZimmermann/papers/accuracy.pdf >> >> details the inputs with generate the worst-case observed errors in different math library implementations. The FDLIBM-related worst cases should be added to the test suite. > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > Improve comments, implement review feedback. To improve the "fingerprinting" coverage of the StrictMath tests, I've added test cases where the worst-case of a non-FDLIBM library is larger than the FDLIBM worst-case. Assuming reasonable methodology of the paper, the output of the other math library must differ from FDLIBM at such a point. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15879#issuecomment-1963421766 From darcy at openjdk.org Mon Feb 26 06:50:02 2024 From: darcy at openjdk.org (Joe Darcy) Date: Mon, 26 Feb 2024 06:50:02 GMT Subject: RFR: JDK-8316708: Augment WorstCaseTests with more cases [v3] In-Reply-To: References: Message-ID: <-Xsozyt_sE1OpTHP0O1sBVB9ZNznylXTZfJsKdTmHsc=.297a352a-634a-4c08-a4c8-dbd176f208fd@github.com> On Mon, 26 Feb 2024 06:43:43 GMT, Joe Darcy wrote: > To improve the "fingerprinting" coverage of the StrictMath tests, I've added test cases where the worst-case of a non-FDLIBM library is larger than the FDLIBM worst-case. Assuming reasonable methodology of the paper, the output of the other math library must differ from FDLIBM at such a point. In a subsequent push, I'll fill those in for the functions not already so updated (cbrt, expm1, log10, log1p, etc.) ------------- PR Comment: https://git.openjdk.org/jdk/pull/15879#issuecomment-1963425696 From jpai at openjdk.org Mon Feb 26 06:53:56 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 26 Feb 2024 06:53:56 GMT Subject: RFR: 7036144: GZIPInputStream readTrailer uses faulty available() test for end-of-stream [v6] In-Reply-To: <7eCX4Yx0qM7Ipug5NI-A8I10-22Iyyk-eMh6ELcHV2c=.bd909779-025d-4e71-816d-e4d6539e85ed@github.com> References: <7eCX4Yx0qM7Ipug5NI-A8I10-22Iyyk-eMh6ELcHV2c=.bd909779-025d-4e71-816d-e4d6539e85ed@github.com> Message-ID: On Mon, 5 Feb 2024 23:53:06 GMT, Archie Cobbs wrote: >> `GZIPInputStream`, when looking for a concatenated stream, relies on what the underlying `InputStream` says is how many bytes are `available()`. But this is inappropriate because `InputStream.available()` is just an estimate and is allowed (for example) to always return zero. >> >> The fix is to ignore what's `available()` and just proceed and see what happens. If fewer bytes are available than required, the attempt to extend to another stream is canceled just as it was before, e.g., when the next stream header couldn't be read. > > Archie Cobbs has updated the pull request with a new target base 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-7036144 > - Merge branch 'master' into JDK-7036144 > - Address third round of review comments. > - Address second round of review comments. > - Address review comments. > - Fix bug in GZIPInputStream when underlying available() returns short. Hello Archie, the proposal to not depend on the `available()` method of the underlying `InputStream` to decide whether to read additional bytes from the underlying stream to detect the "next" header seems reasonable. What's being proposed here is that we proceed and read the underlying stream's few additional bytes to detect the presence or absence of a GZIP member header and if that attempt fails (with an IOException) then we consider that we have reached the end of GZIP stream and just return back. For this change, I think we would also need to consider whether we should "unread" the read bytes from the `InputStream` if those don't correspond to a "next" GZIP member header. That way any underlying `InputStream` which was implemented in a way that it would return availability as 0 when it knew that the GZIP stream was done and yet had additional (non GZIP) data to read on the underlying stream, would still be able to read that data after this change. It's arguable whether we should have been doing that "unread" even when we were doing the `available() > 0` check and the decision that comes out of https://bugs.openjdk.org/browse/JDK-8322256 might cover that. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17113#issuecomment-1963429706 From jpai at openjdk.org Mon Feb 26 07:01:01 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 26 Feb 2024 07:01:01 GMT Subject: RFR: JDK-8326389: [test] improve assertEquals failure output [v3] In-Reply-To: <7xPPisT1fNEHqXyPQVJX8gAYu2i7HCV1PNPDlxNVfJw=.3aa0924c-583f-405c-9c0b-61ff292d6d6d@github.com> References: <7xPPisT1fNEHqXyPQVJX8gAYu2i7HCV1PNPDlxNVfJw=.3aa0924c-583f-405c-9c0b-61ff292d6d6d@github.com> Message-ID: On Thu, 22 Feb 2024 16:01:19 GMT, Matthias Baesken wrote: >> Currently assertEquals has in the failure case sometimes confusing output like : >> >> java.lang.RuntimeException: VM output should contain exactly one RTM locking statistics entry for method compiler.rtm.locking.TestRTMTotalCountIncrRate$Test:? expected 0 to equal 1 >> at jdk.test.lib.Asserts.fail(Asserts.java:634) >> at jdk.test.lib.Asserts.assertEquals(Asserts.java:205) >> >> (I don't think we really expected that for some reason 0 equals 1) >> This should be improved. > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > assertEquals adjust output Hello David, the updated text that I proposed to Matthias, of the form "expected: ... but was: ..." was borrowed from what junit5 reports for such assertion failures https://github.com/junit-team/junit5/blob/main/junit-jupiter-api/src/main/java/org/junit/jupiter/api/AssertionFailureBuilder.java#L174 ------------- PR Comment: https://git.openjdk.org/jdk/pull/17952#issuecomment-1963436885 From epeter at openjdk.org Mon Feb 26 09:39:58 2024 From: epeter at openjdk.org (Emanuel Peter) Date: Mon, 26 Feb 2024 09:39:58 GMT Subject: RFR: 8318650: Optimized subword gather for x86 targets. [v13] In-Reply-To: References: <-jaGezbfx9ZylmA6EBQY2TxqjfIHNhT8TXI6_KCL11Y=.d48ef20a-21c1-4486-ada6-4e1acf86a9ea@github.com> Message-ID: On Tue, 20 Feb 2024 08:29:44 GMT, Emanuel Peter wrote: >> src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 1716: >> >>> 1714: XMMRegister xtmp3, Register rtmp, >>> 1715: Register midx, Register length, >>> 1716: int vector_len, int vlen_enc) { >> >> I would like to see more descriptive names, where I don't have to reverse-engineer their meaning. >> What are the pre/post-conditions on `midx`? > > I'll rereview after So xtmp1...3 and rtmp cannot have more descriptive names? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16354#discussion_r1502299116 From epeter at openjdk.org Mon Feb 26 09:39:59 2024 From: epeter at openjdk.org (Emanuel Peter) Date: Mon, 26 Feb 2024 09:39:59 GMT Subject: RFR: 8318650: Optimized subword gather for x86 targets. [v13] In-Reply-To: References: <-jaGezbfx9ZylmA6EBQY2TxqjfIHNhT8TXI6_KCL11Y=.d48ef20a-21c1-4486-ada6-4e1acf86a9ea@github.com> Message-ID: On Sun, 25 Feb 2024 06:23:50 GMT, Jatin Bhateja wrote: >> src/hotspot/cpu/x86/x86.ad line 4120: >> >>> 4118: BasicType elem_bt = Matcher::vector_element_basic_type(this); >>> 4119: __ lea($tmp$$Register, $mem$$Address); >>> 4120: __ vgather8b(elem_bt, $dst$$XMMRegister, $tmp$$Register, $idx$$Register, $rtmp$$Register, vlen_enc); >> >> The `LE8B` and `Matcher::vector_length_in_bytes(n) <= 8` suggest we can perform this with 4 bytes as well. >> Is that correct? >> Would that not lead to issues, when we are then reading `base_index` at bytes 4...7, which possibly have garbage, and then use that to gather? >> Do we have tests for that? > > 64 bit sub-word SPECIES will either hold 8 bytes values or 4 short values, algorithm appropriately handle it. Are you saying that the constraints are too relaxed, but currently no outside algorithm would pass something bad? But then why not tighten the constraint to be correct? What if I at some point start using this node in SuperWord / AutoVectorization? >> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ByteVector.java line 3071: >> >>> 3069: .fromArray(lsp, indexMap, mapOffset + i) >>> 3070: .add(offset); >>> 3071: vix = VectorIntrinsics.checkIndex(vix, a.length); >> >> are you using the `vix` after this assignment? > > Its purpose is to check out of bounds indices. But is it required to do the assignment? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16354#discussion_r1502297241 PR Review Comment: https://git.openjdk.org/jdk/pull/16354#discussion_r1502290579 From epeter at openjdk.org Mon Feb 26 09:54:00 2024 From: epeter at openjdk.org (Emanuel Peter) Date: Mon, 26 Feb 2024 09:54:00 GMT Subject: RFR: 8318650: Optimized subword gather for x86 targets. [v14] In-Reply-To: References: Message-ID: On Sun, 25 Feb 2024 06:27:10 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 using 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.5-10x 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. >> >> 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. Update looks better already! I have not yet reviewed `C2_MacroAssembler::vgather_subword` because of the variable names. Increasing the reviewer count, because I'd like to have someone else review that is more familiar with the Vector API (java) code. src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 1584: > 1582: if (elem_bt == T_SHORT) { > 1583: Label case0, case1, case2, case3; > 1584: Label* larr[] = {&case0, &case1, &case2, &case3}; Not sure if I asked this already: why define them all here, rather than locally in the loop? src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 1651: > 1649: * permutation to place the slice into appropriate vector lanes > 1650: * location in destination vector. Following pseudo code describes the > 1651: * algorithm in detail: Suggestion: * Gather using hybrid algorithm which initially partially unrolls scalar loop * to accumulate values from gather indices into a quad-word(64bit) slice, a * slice may hold 8 bytes or 4 short values. This is followed by a vector * permutation to place the slice into appropriate vector lane * locations in destination vector. Following pseudo code describes the * algorithm in detail: src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 1663: > 1661: * > 1662: * With each iteration, doubleword permute indices (0,1) corresponding > 1663: * to gathered quadword gets right shifted by two lane position. Suggestion: * to gathered quadword gets right shifted by two lane positions. src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 1674: > 1672: int vector_len, int vlen_enc) { > 1673: assert(is_subword_type(elem_ty), ""); > 1674: Label GATHER8_LOOP; Why not define it righ before the first use? src/jdk.incubator.vector/share/classes/jdk/incubator/vector/X-Vector.java.template line 4840: > 4838: > 4839: // Check indices are within array bounds. > 4840: // FIXME: Check index under mask controlling. This is a new FIXME in the template. I see that there are others around from before. Still, if you add a new one, I think you should at least add a bug-number that addresses this. That way, we can track the task. ------------- Changes requested by epeter (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16354#pullrequestreview-1900380735 PR Review Comment: https://git.openjdk.org/jdk/pull/16354#discussion_r1502301147 PR Review Comment: https://git.openjdk.org/jdk/pull/16354#discussion_r1502303881 PR Review Comment: https://git.openjdk.org/jdk/pull/16354#discussion_r1502304352 PR Review Comment: https://git.openjdk.org/jdk/pull/16354#discussion_r1502314411 PR Review Comment: https://git.openjdk.org/jdk/pull/16354#discussion_r1502313404 From ihse at openjdk.org Mon Feb 26 10:46:53 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 26 Feb 2024 10:46:53 GMT Subject: RFR: 8326583: Remove over-generalized DefineNativeToolchain solution In-Reply-To: References: Message-ID: <_PhDAdwBOdLadnoyFkOp3P7i9SC7MkakgujqRJ5shNE=.54492764-dfb5-4a90-a47d-d0a8a7625cdc@github.com> On Fri, 23 Feb 2024 16:23:43 GMT, Magnus Ihse Bursie wrote: > The idea of setting up general "toolchains" in the native build was good, but it turned out that we really only need a single toolchain, with a single twist: if it should use CC or CPP to link. This is better described by a specific argument to SetupNativeCompilation, LANG := C++ or LANG := C (the default). > > There is a single exception to this rule, and that is if we want to compile for the build platform rather than the target platform. (This is only done for adlc) To keep expressing this difference, introduce TARGET_TYPE := BUILD (or TARGET_TYPE := TARGET, the default). > > The final odd-case was the hack for building hsdis/bin on mingw. This can be resolved using direct variables to SetupNativeCompilation, instead of first creating a toolchain. > > Doing this refactoring will simplify the SetupNativeCompilation code, and make it much clearer if we use the C or C++ linker. First some general remarks. The thing about generalization is that you need to take it in right enough doses -- too much is just as problematic as too little. You can represent any program with a Turing machine that can read or write, and move a head back and forth. That is extremely general, and completely hopeless to program in. The right amount of generalization is reached when it helps you express the underlying ideas in a easy-to-understand way. If you got duplication, then it means something needs to be more generalized. But if you have a general solution that is only ever used in a single way, then you have over-generalization. Secondly, trust the VCS. Keeping code around since it might be "needed down the line" is a very bad reason. If we will need it again, we can restore it from the history. My experience is that these things practically never happens -- even if you need something similar in the future, the requirements are almost always different enough that the old system did not work anyway. And now over to more specific comments about this patch. There was a historic need for this function. When it was created, we started a new build system from the ground up to consolidate a myriad of different ways to build parts of the product. There were no good standardized toolchain, and we had a requirement to really handle different toolchains. Then during the years we have chipped away at all the odds bits and pieces, until the entire build uses (basically) the same toolchain -- the only difference is the linker argument. And, of course, the orthogonal question if we're targeting the build machine or the target machine, when cross-compiling. This is a very clear concept in the rest of the build system, but it was diffused in the toolchain profiles by making it look like we just have another "profile", like it was another version of gcc. So in this PR we replace a very general idea of a "profile" with two distinct options that we really care about -- what platform to target, and how we call the linker. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17986#issuecomment-1963821493 From ihse at openjdk.org Mon Feb 26 10:51:54 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 26 Feb 2024 10:51:54 GMT Subject: RFR: 8326583: Remove over-generalized DefineNativeToolchain solution In-Reply-To: References: Message-ID: On Fri, 23 Feb 2024 16:23:43 GMT, Magnus Ihse Bursie wrote: > The idea of setting up general "toolchains" in the native build was good, but it turned out that we really only need a single toolchain, with a single twist: if it should use CC or CPP to link. This is better described by a specific argument to SetupNativeCompilation, LANG := C++ or LANG := C (the default). > > There is a single exception to this rule, and that is if we want to compile for the build platform rather than the target platform. (This is only done for adlc) To keep expressing this difference, introduce TARGET_TYPE := BUILD (or TARGET_TYPE := TARGET, the default). > > The final odd-case was the hack for building hsdis/bin on mingw. This can be resolved using direct variables to SetupNativeCompilation, instead of first creating a toolchain. > > Doing this refactoring will simplify the SetupNativeCompilation code, and make it much clearer if we use the C or C++ linker. I could have chosen to name the `LANG` argument e.g. `LINKER_LANG`. If you insist, I can go back and rename it like this also. But there was a reason I chose the more general `LANG`, and that is because we have other unresolved issues regarding C vs C++ in the build. We don't handle CFLAGS vs CXXFLAGS very well, and we have several convoluted fixes (that just smells "black magic") to get the build to work. My instinct is that these are highly correlated to the choice of linker -- basically, in the old build system, there were a difference between C-libs anc C++-libs that were not properly carried over to the new build system. My intention is to continue this work by aligning flags etc with this property as well. But this is future work, so one could argue that with just this patch, the name `LANG` is overly broad. I thought it was okay, in the light of future development, and the wish to keep argument names succinct, but if you object I can rename it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17986#issuecomment-1963835032 From asotona at openjdk.org Mon Feb 26 11:08:58 2024 From: asotona at openjdk.org (Adam Sotona) Date: Mon, 26 Feb 2024 11:08:58 GMT Subject: RFR: 8323707: Adjust Classfile API's type arg model to better represent the embodied type [v3] In-Reply-To: References: Message-ID: <3xSbNSq-ZXfUrHAbrv6JVM1j4ms61LNamHJaC5Mv6aM=.26ef39cb-51b3-4b59-afec-e3413d6ad94d@github.com> On Thu, 22 Feb 2024 05:38:19 GMT, Chen Liang wrote: >> API changes as discussed on the mailing list: https://mail.openjdk.org/pipermail/classfile-api-dev/2023-November/000419.html >> >> Additional questions: >> 1. Whether to rename `WildcardIndicator.DEFAULT` to `NONE` > > Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits: > > - Rename no wildcard indicator, improve docs slightly > - Merge branch 'master' of https://github.com/openjdk/jdk into fix/typearg-model > - Merge branch 'master' into fix/typearg-model > - redundant line > - Fix a test in langtools, copyright year > - Merge branch 'master' of https://github.com/openjdk/jdk into fix/typearg-model > - Implementation cleanup, test update > - Merge branch 'master' into fix/typearg-model > - Formatting > - Nuke signatureString and fix test fialure from bad cast > - ... and 1 more: https://git.openjdk.org/jdk/compare/0bcece99...62d25642 I would consider it for 2nd preview. Please go ahead and propose the CSR. test/jdk/jdk/classfile/SignaturesTest.java line 188: > 186: var arrayListSig = sig.superclassSignature(); // ArrayList > 187: var arrayListTypeArg = (TypeArg.Bounded) arrayListSig.typeArgs().getFirst(); // Outer.Inner > 188: assertEquals(TypeArg.Bounded.WildcardIndicator.DEFAULT, arrayListTypeArg.wildcardIndicator()); Suggestion: assertEquals(TypeArg.Bounded.WildcardIndicator.NONE, arrayListTypeArg.wildcardIndicator()); test/langtools/tools/javap/classfile/6888367/T6888367.java line 320: > 318: case EXTENDS -> "W{e," + print(b.boundType()) + "}"; > 319: case SUPER -> "W{s," + print(b.boundType()) + "}"; > 320: case DEFAULT -> print(b.boundType()); Suggestion: case NONE -> print(b.boundType()); ------------- PR Review: https://git.openjdk.org/jdk/pull/16517#pullrequestreview-1900572367 PR Review Comment: https://git.openjdk.org/jdk/pull/16517#discussion_r1502422372 PR Review Comment: https://git.openjdk.org/jdk/pull/16517#discussion_r1502423113 From redestad at openjdk.org Mon Feb 26 11:12:00 2024 From: redestad at openjdk.org (Claes Redestad) Date: Mon, 26 Feb 2024 11:12:00 GMT Subject: RFR: 8326653: Remove jdk.internal.reflect.UTF8 Message-ID: jdk.internal.reflect.UTF8 is used for encoding String to encoded UTF-8 when generating some classes. Since JDK 9 we have a fast-path (which avoids creating encoders) for UTF-8-encoding strings which is bootstrapped very early, so it seems safe to rewire this and remove the UTF8 helper class whose stated raison d'?tre is to avoid bootstrapping issues. This cleanup also removes a latent bug since the custom encoder isn't able to deal with classfile constants containing surrogate pairs. For a quick comparison I copied the UTF8 code to the `StringEncode` microbenchmark and set up a benchmark testing the same inputs as `encodeAllMixed`: Benchmark (charsetName) Mode Cnt Score Error Units StringEncode.encodeAllMixed UTF-8 avgt 10 12894,551 ? 164,816 ns/op StringEncode.encodeUTF8InternalAllMixed UTF-8 avgt 10 236614,548 ? 1445,975 ns/op I.e. `String.getBytes(UTF_8.instance)` is about 18x faster on mixed inputs. (I plan on removing `encodeUTF8InternalAllMixed` from the PR before merging, but wanted to include it initially to show what I've measured.) ------------- Commit messages: - 8326653: Remove jdk.internal.reflect.UTF8 Changes: https://git.openjdk.org/jdk/pull/18006/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18006&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8326653 Stats: 143 lines in 3 files changed: 64 ins; 78 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/18006.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18006/head:pull/18006 PR: https://git.openjdk.org/jdk/pull/18006 From redestad at openjdk.org Mon Feb 26 11:34:18 2024 From: redestad at openjdk.org (Claes Redestad) Date: Mon, 26 Feb 2024 11:34:18 GMT Subject: RFR: 8326653: Remove jdk.internal.reflect.UTF8 [v2] In-Reply-To: References: Message-ID: > jdk.internal.reflect.UTF8 is used for encoding String to encoded UTF-8 when generating some classes. > > Since JDK 9 we have a fast-path (which avoids creating encoders) for UTF-8-encoding strings which is bootstrapped very early, so it seems safe to rewire this and remove the UTF8 helper class whose stated raison d'?tre is to avoid bootstrapping issues. > > This cleanup also removes a latent bug since the custom encoder isn't able to deal with classfile constants containing surrogate pairs. > > For a quick comparison I copied the UTF8 code to the `StringEncode` microbenchmark and set up a benchmark testing the same inputs as `encodeAllMixed`: > > > Benchmark (charsetName) Mode Cnt Score Error Units > StringEncode.encodeAllMixed UTF-8 avgt 10 12894,551 ? 164,816 ns/op > StringEncode.encodeUTF8InternalAllMixed UTF-8 avgt 10 236614,548 ? 1445,975 ns/op > > > I.e. `String.getBytes(UTF_8.instance)` is about 18x faster on mixed inputs. (I plan on removing `encodeUTF8InternalAllMixed` from the PR before merging, but wanted to include it initially to show what I've measured.) Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: Remove temporary microbenchmark ------------- Changes: - all: https://git.openjdk.org/jdk/pull/18006/files - new: https://git.openjdk.org/jdk/pull/18006/files/595b464d..1293b167 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=18006&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18006&range=00-01 Stats: 62 lines in 1 file changed: 0 ins; 62 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/18006.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18006/head:pull/18006 PR: https://git.openjdk.org/jdk/pull/18006 From jbhateja at openjdk.org Mon Feb 26 13:08:59 2024 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Mon, 26 Feb 2024 13:08:59 GMT Subject: RFR: 8318650: Optimized subword gather for x86 targets. [v14] In-Reply-To: References: Message-ID: On Mon, 26 Feb 2024 09:47:50 GMT, Emanuel Peter wrote: >> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: >> >> Review comments resolutions. > > src/jdk.incubator.vector/share/classes/jdk/incubator/vector/X-Vector.java.template line 4840: > >> 4838: >> 4839: // Check indices are within array bounds. >> 4840: // FIXME: Check index under mask controlling. > > This is a new FIXME in the template. I see that there are others around from before. Still, if you add a new one, I think you should at least add a bug-number that addresses this. That way, we can track the task. DONE, will address this bug fix in following PR https://bugs.openjdk.org/browse/JDK-8326664 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16354#discussion_r1502584070 From jbhateja at openjdk.org Mon Feb 26 13:14:24 2024 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Mon, 26 Feb 2024 13:14:24 GMT Subject: RFR: 8318650: Optimized subword gather for x86 targets. [v15] In-Reply-To: References: Message-ID: <4Ypl0g8qQVgHVBX0Wbh3rGWxeOAHifAakbMxngTvLHk=.351b6866-df83-4d71-ba94-be172896d6af@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 using 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.5-10x 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. > > 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/05e606ff..2aa07b5a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16354&range=14 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16354&range=13-14 Stats: 17 lines in 5 files changed: 4 ins; 0 del; 13 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 Mon Feb 26 13:14:25 2024 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Mon, 26 Feb 2024 13:14:25 GMT Subject: RFR: 8318650: Optimized subword gather for x86 targets. [v14] In-Reply-To: References: Message-ID: <2_lbsdRrWvzmMfwKAHyeZTWDGAonTIrl-pSTr2JmuRs=.c73d8a1b-acb6-49a0-8aa3-f25004af2c35@github.com> On Mon, 26 Feb 2024 09:39:01 GMT, Emanuel Peter 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 1584: > >> 1582: if (elem_bt == T_SHORT) { >> 1583: Label case0, case1, case2, case3; >> 1584: Label* larr[] = {&case0, &case1, &case2, &case3}; > > Not sure if I asked this already: why define them all here, rather than locally in the loop? To avoid invariant initializations to happen within the loop, compiler will unroll this small loop and will forward the initializations, if it does not then we can save redundant allocation within loop. > src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 1674: > >> 1672: int vector_len, int vlen_enc) { >> 1673: assert(is_subword_type(elem_ty), ""); >> 1674: Label GATHER8_LOOP; > > Why not define it righ before the first use? Its not going to affect generated code, by convention declaration should anyways be at the beginning of block scope. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16354#discussion_r1502587701 PR Review Comment: https://git.openjdk.org/jdk/pull/16354#discussion_r1502587580 From jbhateja at openjdk.org Mon Feb 26 13:14:25 2024 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Mon, 26 Feb 2024 13:14:25 GMT Subject: RFR: 8318650: Optimized subword gather for x86 targets. [v13] In-Reply-To: References: <-jaGezbfx9ZylmA6EBQY2TxqjfIHNhT8TXI6_KCL11Y=.d48ef20a-21c1-4486-ada6-4e1acf86a9ea@github.com> Message-ID: On Mon, 26 Feb 2024 09:37:33 GMT, Emanuel Peter wrote: >> I'll rereview after > > So xtmp1...3 and rtmp cannot have more descriptive names? These are temporary variable and appropriately named. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16354#discussion_r1502587427 From jbhateja at openjdk.org Mon Feb 26 13:14:25 2024 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Mon, 26 Feb 2024 13:14:25 GMT Subject: RFR: 8318650: Optimized subword gather for x86 targets. [v13] In-Reply-To: References: <-jaGezbfx9ZylmA6EBQY2TxqjfIHNhT8TXI6_KCL11Y=.d48ef20a-21c1-4486-ada6-4e1acf86a9ea@github.com> Message-ID: On Mon, 26 Feb 2024 09:36:09 GMT, Emanuel Peter wrote: >> 64 bit sub-word SPECIES will either hold 8 bytes values or 4 short values, algorithm appropriately handle it. > > Are you saying that the constraints are too relaxed, but currently no outside algorithm would pass something bad? > But then why not tighten the constraint to be correct? > What if I at some point start using this node in SuperWord / AutoVectorization? Agree, added a tighter constraint for this in _match_rule_supported_vector_. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16354#discussion_r1502589914 From epeter at openjdk.org Mon Feb 26 13:17:57 2024 From: epeter at openjdk.org (Emanuel Peter) Date: Mon, 26 Feb 2024 13:17:57 GMT Subject: RFR: 8318650: Optimized subword gather for x86 targets. [v14] In-Reply-To: References: Message-ID: On Mon, 26 Feb 2024 13:06:19 GMT, Jatin Bhateja wrote: >> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/X-Vector.java.template line 4840: >> >>> 4838: >>> 4839: // Check indices are within array bounds. >>> 4840: // FIXME: Check index under mask controlling. >> >> This is a new FIXME in the template. I see that there are others around from before. Still, if you add a new one, I think you should at least add a bug-number that addresses this. That way, we can track the task. > > DONE, will address this bug fix in a follow-up PR https://bugs.openjdk.org/browse/JDK-8326664 Great, thanks! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16354#discussion_r1502594840 From epeter at openjdk.org Mon Feb 26 13:27:00 2024 From: epeter at openjdk.org (Emanuel Peter) Date: Mon, 26 Feb 2024 13:27:00 GMT Subject: RFR: 8318650: Optimized subword gather for x86 targets. [v14] In-Reply-To: <2_lbsdRrWvzmMfwKAHyeZTWDGAonTIrl-pSTr2JmuRs=.c73d8a1b-acb6-49a0-8aa3-f25004af2c35@github.com> References: <2_lbsdRrWvzmMfwKAHyeZTWDGAonTIrl-pSTr2JmuRs=.c73d8a1b-acb6-49a0-8aa3-f25004af2c35@github.com> Message-ID: On Mon, 26 Feb 2024 13:09:22 GMT, Jatin Bhateja wrote: >> src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 1584: >> >>> 1582: if (elem_bt == T_SHORT) { >>> 1583: Label case0, case1, case2, case3; >>> 1584: Label* larr[] = {&case0, &case1, &case2, &case3}; >> >> Not sure if I asked this already: why define them all here, rather than locally in the loop? > > To avoid invariant initializations to happen within the loop, compiler will unroll this small loop and will forward the initializations, if it does not then we can save redundant allocation within loop. At the risk of becoming too nit-picky: which allocations are you talking about? Given you only have a single src and a single dst for this label/jump. So you won't use `_patch_overflow`. And therefore, all allocations are on the stack. The way you do it now, it seems you would allocate 4x the stack memory here, compared to doing it locally in the loop, where the stack space could potentially be reused between the iterations. It seems to me this is an optimization at the cost of code-style. Having them local makes it more clear that you are only jumping inside a iteration, and not between iterations. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16354#discussion_r1502606358 From epeter at openjdk.org Mon Feb 26 13:33:57 2024 From: epeter at openjdk.org (Emanuel Peter) Date: Mon, 26 Feb 2024 13:33:57 GMT Subject: RFR: 8318650: Optimized subword gather for x86 targets. [v14] In-Reply-To: References: <2_lbsdRrWvzmMfwKAHyeZTWDGAonTIrl-pSTr2JmuRs=.c73d8a1b-acb6-49a0-8aa3-f25004af2c35@github.com> Message-ID: On Mon, 26 Feb 2024 13:24:05 GMT, Emanuel Peter wrote: >> To avoid invariant initializations to happen within the loop, compiler will unroll this small loop and will forward the initializations, if it does not then we can save redundant allocation within loop. > > At the risk of becoming too nit-picky: which allocations are you talking about? Given you only have a single src and a single dst for this label/jump. So you won't use `_patch_overflow`. And therefore, all allocations are on the stack. The way you do it now, it seems you would allocate 4x the stack memory here, compared to doing it locally in the loop, where the stack space could potentially be reused between the iterations. > It seems to me this is an optimization at the cost of code-style. Having them local makes it more clear that you are only jumping inside a iteration, and not between iterations. I could not find any other case with the same pattern, of initializing a list of Labels. On the other hand, I can find cases where we already do what I am saying: `C2_MacroAssembler::rtm_counters_update` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16354#discussion_r1502617942 From epeter at openjdk.org Mon Feb 26 13:49:57 2024 From: epeter at openjdk.org (Emanuel Peter) Date: Mon, 26 Feb 2024 13:49:57 GMT Subject: RFR: 8318650: Optimized subword gather for x86 targets. [v15] In-Reply-To: <4Ypl0g8qQVgHVBX0Wbh3rGWxeOAHifAakbMxngTvLHk=.351b6866-df83-4d71-ba94-be172896d6af@github.com> References: <4Ypl0g8qQVgHVBX0Wbh3rGWxeOAHifAakbMxngTvLHk=.351b6866-df83-4d71-ba94-be172896d6af@github.com> Message-ID: On Mon, 26 Feb 2024 13:14:24 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 using 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.5-10x 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. >> >> 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 Reposting link to a conversation that is marked "resolved": https://github.com/openjdk/jdk/pull/16354#discussion_r1502617942 src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 1672: > 1670: XMMRegister xtmp3, Register rtmp, > 1671: Register mask_idx, Register length, > 1672: int vector_len, int vlen_enc) { > These are temporary variable and appropriately named. I disagree. Names should be descriptive, and not numbered. At least some of your registers here have only a single use. Those could be named: `xtmp_xxxx` instead of `xtmp1..3`. If for some reason you don't want to do that, then say why, and at least add a comment that helps the reader have a mental map from (meaningless) register names to their meaning. I really don't want to have to reverse-engineer things in a review if it can be avoided. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16354#issuecomment-1964188004 PR Review Comment: https://git.openjdk.org/jdk/pull/16354#discussion_r1502640887 From eirbjo at openjdk.org Mon Feb 26 14:17:58 2024 From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=) Date: Mon, 26 Feb 2024 14:17:58 GMT Subject: Integrated: 8326099: GZIPOutputStream should use Deflater.getBytesRead() instead of Deflater.getTotalIn() In-Reply-To: <9TQrYJq04NGGELIp4gx5GP9aVRX5X0Zm-PX-N9czKq4=.72582b38-6636-4d32-a536-a9cbc0d7e1e7@github.com> References: <9TQrYJq04NGGELIp4gx5GP9aVRX5X0Zm-PX-N9czKq4=.72582b38-6636-4d32-a536-a9cbc0d7e1e7@github.com> Message-ID: On Sat, 17 Feb 2024 12:08:38 GMT, Eirik Bj?rsn?s wrote: > Please review this cleanup PR in preparation for deprecating `Deflater.getTotalIn()` in JDK-8326096. > > This PR replaces `GZIPOutputStream.writeTrailer`'s call to `Deflater.getTotalIn()` with a call to `Deflater.getBytesRead()` followed by an explicit conversion to "modulo 2^32" (a cast to int) as described in RFC 1952: > > > ISIZE (Input SIZE) > This contains the size of the original (uncompressed) input > data modulo 2^32. > > > Testing and verification: This should be trivially verifiable by code inspection. Nevertheless, I wrote a test which writes Integer.MAX_VALUE +1 bytes of uncompressed data and verified that the last four bytes written to the file was indeed as expected. (This test is not included in this PR because of its runtime and resource requirements). This pull request has now been integrated. Changeset: bb6b0489 Author: Eirik Bj?rsn?s URL: https://git.openjdk.org/jdk/commit/bb6b04897b5d83dd89fc11074dd66af024f9c6fc Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod 8326099: GZIPOutputStream should use Deflater.getBytesRead() instead of Deflater.getTotalIn() Reviewed-by: jpai ------------- PR: https://git.openjdk.org/jdk/pull/17900 From erikj at openjdk.org Mon Feb 26 14:24:56 2024 From: erikj at openjdk.org (Erik Joelsson) Date: Mon, 26 Feb 2024 14:24:56 GMT Subject: RFR: 8174269: Remove COMPAT locale data provider from JDK In-Reply-To: References: Message-ID: On Fri, 23 Feb 2024 21:24:10 GMT, Naoto Sato wrote: > This PR intends to remove the legacy `COMPAT` locale data from the JDK. The `COMPAT` locale data was introduced for applications' migratory purposes transitioning to `CLDR`. It is becoming a technical debt and now is the time to remove it (we've been emitting a warning at JVM startup since JDK21, if the app is using `COMPAT`). A corresponding CSR has also been drafted. make/modules/java.base/gensrc/GensrcLocaleData.gmk line 58: > 56: ifeq ($(MODULE), jdk.localedata) > 57: $(shell $(RM) $(SUPPORT_OUTPUTDIR)/gensrc/jdk.localedata/sun/util/resources/cldr/provider/CLDRLocaleDataMetaInfo_jdk_localedata.java) > 58: endif The remainder of this file doesn't seem to be doing anything useful. Do we really need to keep it around? If I understand this correctly, the files referenced and deleted here are generated by the cldrconverter. Is that build tool relying on make removing the file first? Reading the java source, my impression is that it will generate the file unconditionally regardless of the files current existence as long as the tool is run. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17991#discussion_r1502691516 From dfuchs at openjdk.org Mon Feb 26 14:26:57 2024 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Mon, 26 Feb 2024 14:26:57 GMT Subject: RFR: 8310994: Add JFR event for selection operations [v2] In-Reply-To: References: Message-ID: On Wed, 13 Dec 2023 18:58:40 GMT, Tim Prinzing wrote: >> src/java.base/share/classes/jdk/internal/event/SelectorSelectEvent.java line 41: >> >>> 39: public class SelectorSelectEvent extends Event { >>> 40: >>> 41: public int selectionKeyCount; >> >> I still believe we should record the timeout parameter in the event. > > Good point about the wakeup. I'll add the field. Thanks! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16710#discussion_r1502695847 From dfuchs at openjdk.org Mon Feb 26 14:26:58 2024 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Mon, 26 Feb 2024 14:26:58 GMT Subject: RFR: 8310994: Add JFR event for selection operations [v3] In-Reply-To: References: <8lBiUxq1EYaux0j6rOnzmScfwFWfBRbYYT1IwEvSQWQ=.bc31666d-4f00-4ac9-a4f2-242abe231db1@github.com> Message-ID: On Wed, 3 Jan 2024 11:11:40 GMT, Alan Bateman wrote: >> Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision: >> >> add select timeout field to the event > > src/java.base/share/classes/sun/nio/ch/SelectorImpl.java line 153: > >> 151: if ((n == 0) || (SelectorSelectEvent.shouldCommit(duration))) { >> 152: timeout = (timeout < 0) ? 0 : timeout; >> 153: SelectorSelectEvent.commit(start, duration, n, timeout); > > The comment is a bit confusing here. n == 0 means that no selected keys were added or consumed before timeout or wakeup. Is n == 0 intended to detect a spinning condition where the selector goes back into select when the event has not been handled? In that case should we still emit an event if a timeout is present and the duration is greater than the timeout? For instance, in the HttpClient, we have a selector thread that will wake up at regular interval - we set up a timeout which is the min between the next expected timer event and 1500ms. So that could potentially fire an event every 1500ms if for instance the connection threshold is less than 1500ms and the connection is idle. Maybe that's OK - and maybe in that case the onus is on the user to set a threshold greater than 1500ms? Or should it be ((n == 0 && durationToMillis(duration) < timeoutToMillis(timeout)) || ...)) (duration and timeout probably are not in the same unit of time) - also if shouldCommit return false will the event actually be emitted down the road? Because if not then the ( n== 0 || ...) won't work. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16710#discussion_r1502681499 From dfuchs at openjdk.org Mon Feb 26 14:27:03 2024 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Mon, 26 Feb 2024 14:27:03 GMT Subject: RFR: 8310994: Add JFR event for selection operations [v2] In-Reply-To: References: Message-ID: On Wed, 13 Dec 2023 18:49:08 GMT, Daniel Fuchs wrote: >> 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 12 additional commits since the last revision: >> >> - Change event generation: >> >> - selectNow is filtered out >> - select that times out is always sent >> - select without timeout uses duration test >> - rename event to SelectorSelect, field to selectionKeyCount. >> - Merge branch 'master' into JDK-8310994 >> - 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 >> - ... and 2 more: https://git.openjdk.org/jdk/compare/9896b3fb...2f7dafd8 > > src/jdk.jfr/share/classes/jdk/jfr/events/SelectorSelectEvent.java line 44: > >> 42: @Label("SelectionKey Count") >> 43: @Description("Number of channels ready for I/O or added to ready set") >> 44: public int selectionKeyCount; > > same here Thanks for adding the timeout. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16710#discussion_r1502686107 From jvernee at openjdk.org Mon Feb 26 14:27:15 2024 From: jvernee at openjdk.org (Jorn Vernee) Date: Mon, 26 Feb 2024 14:27:15 GMT Subject: RFR: 8326172: Dubious claim on long[]/double[] alignment in MemorySegment javadoc Message-ID: This patch changes the alignment for `JAVA_LONG` and `JAVA_DOUBLE` to 8, regardless of the underlying platform. This means that atomic access modes work on memory segments wrapping `long[]` or `double[]`, as they already do when using `MethodHandless::arrayAccessVarHandle`. After discussion, we came to the conclusion that it is reasonable for the JDK to require the elements of a `long[]` and `double[]` to be 8 byte aligned. It is ultimately up to the JDK to set these requirements, which are for the VM to implement. I was seeing a stack overflow when running test/jdk/java/foreign/stackwalk/TestReentrantUpcalls.java on x86, so I've lowered the recursion to 50 (which is still more than enough I think). Testing: `jdk_foreign` on x64 Windows, x64 Windows + fallback linker, and x86 Linux (uses fallback linker) ------------- Commit messages: - add missing tag - Remove references to 32-bit difference in javadoc - Test fixes - Set alignment of JAVA_LONG and JAVA_DOUBLE to 8 bytes Changes: https://git.openjdk.org/jdk/pull/18007/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18007&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8326172 Stats: 54 lines in 10 files changed: 18 ins; 18 del; 18 mod Patch: https://git.openjdk.org/jdk/pull/18007.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18007/head:pull/18007 PR: https://git.openjdk.org/jdk/pull/18007 From eirbjo at openjdk.org Mon Feb 26 14:29:19 2024 From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=) Date: Mon, 26 Feb 2024 14:29:19 GMT Subject: RFR: 8326096: Deprecate getTotalIn, getTotalOut methods of java.util.zip.Inflater, java.util.zip.Deflater [v8] In-Reply-To: References: Message-ID: > Please review this PR which proposes that we officially deprecate the following four methods in the `java.util.zip` package: > > * `Inflater.getTotalIn()` > * `Inflater.getTotalOut()` > * `Deflater.getTotalIn()` > * `Deflater.getTotalOut()` > > Since these legacy methods return `int`, they cannot safely return the number of bytes processed without the risk of losing information about the magnitude or even sign of the returned value. > > The corresponding methods `getBytesRead()` and `getBytesWritten()` methods introduced in Java 5 return `long`, and should be used instead when obtaining this information. > > Unrelated to the deprecation itself, the documentation currently does not specify what these methods are expected to return when the number of processed bytes is higher than `Integer.MAX_VALUE`. This PR aims to clarify this in the API specification. > > Initally, this PR handles only `Inflater.getTotalIn()`. The other three methods will be updated once the wordsmithing for this method stabilizes. Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision: Reduce new method description text to one sentence ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17919/files - new: https://git.openjdk.org/jdk/pull/17919/files/eaddf662..7e4d6e4d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17919&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17919&range=06-07 Stats: 9 lines in 1 file changed: 0 ins; 6 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/17919.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17919/head:pull/17919 PR: https://git.openjdk.org/jdk/pull/17919 From dl at openjdk.org Mon Feb 26 14:39:55 2024 From: dl at openjdk.org (Doug Lea) Date: Mon, 26 Feb 2024 14:39:55 GMT Subject: RFR: 8325754: Dead AbstractQueuedSynchronizer$ConditionNodes survive minor garbage collections In-Reply-To: References: Message-ID: On Wed, 21 Feb 2024 15:01:15 GMT, Viktor Klang wrote: > More aggressively breaking chains in order to prevent nodes promoted to older generations standing in the way for collecting younger nodes. I decided that it was most efficient to add this logic to the else-branch of updating the firstWaiter and lastWaiter. > > There's a race with unlinkCancelledWaiters() but according to @DougLea it should be a benign one. > > There's a performance impact of this, but as it is a plain write, and one to null at that, it should be acceptable. Thanks for doing this. Looks good. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17950#issuecomment-1964298680 From rriggs at openjdk.org Mon Feb 26 14:49:58 2024 From: rriggs at openjdk.org (Roger Riggs) Date: Mon, 26 Feb 2024 14:49:58 GMT Subject: RFR: 8326653: Remove jdk.internal.reflect.UTF8 [v2] In-Reply-To: References: Message-ID: On Mon, 26 Feb 2024 11:34:18 GMT, Claes Redestad wrote: >> jdk.internal.reflect.UTF8 is used for encoding String to encoded UTF-8 when generating some classes. >> >> Since JDK 9 we have a fast-path (which avoids creating encoders) for UTF-8-encoding strings which is bootstrapped very early, so it seems safe to rewire this and remove the UTF8 helper class whose stated raison d'?tre is to avoid bootstrapping issues. >> >> This cleanup also removes a latent bug since the custom encoder isn't able to deal with classfile constants containing surrogate pairs. >> >> For a quick comparison I copied the UTF8 code to the `StringEncode` microbenchmark and set up a benchmark testing the same inputs as `encodeAllMixed`: >> >> >> Benchmark (charsetName) Mode Cnt Score Error Units >> StringEncode.encodeAllMixed UTF-8 avgt 10 12894,551 ? 164,816 ns/op >> StringEncode.encodeUTF8InternalAllMixed UTF-8 avgt 10 236614,548 ? 1445,975 ns/op >> >> >> I.e. `String.getBytes(UTF_8.instance)` is about 18x faster on mixed inputs. The benchmark is available in 595b464 but as a quick sanity check not intended for integration. >> >> Testing: tier1-3 > > Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: > > Remove temporary microbenchmark Marked as reviewed by rriggs (Reviewer). src/java.base/share/classes/jdk/internal/reflect/ClassFileAssembler.java line 28: > 26: package jdk.internal.reflect; > 27: > 28: import sun.nio.cs.UTF_8; I see about equal numbers of uses of `StandardCharsets.UTF_8` and `sun.nio.cs.UTF_8.INSTANCE` in java.base but would lean toward the one in `StandardCharsets` unless there's a bootstrap order dependency. ------------- PR Review: https://git.openjdk.org/jdk/pull/18006#pullrequestreview-1901076118 PR Review Comment: https://git.openjdk.org/jdk/pull/18006#discussion_r1502733517 From alanb at openjdk.org Mon Feb 26 14:54:56 2024 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 26 Feb 2024 14:54:56 GMT Subject: RFR: 8326653: Remove jdk.internal.reflect.UTF8 [v2] In-Reply-To: References: Message-ID: On Mon, 26 Feb 2024 11:34:18 GMT, Claes Redestad wrote: >> jdk.internal.reflect.UTF8 is used for encoding String to encoded UTF-8 when generating some classes. >> >> Since JDK 9 we have a fast-path (which avoids creating encoders) for UTF-8-encoding strings which is bootstrapped very early, so it seems safe to rewire this and remove the UTF8 helper class whose stated raison d'?tre is to avoid bootstrapping issues. >> >> This cleanup also removes a latent bug since the custom encoder isn't able to deal with classfile constants containing surrogate pairs. >> >> For a quick comparison I copied the UTF8 code to the `StringEncode` microbenchmark and set up a benchmark testing the same inputs as `encodeAllMixed`: >> >> >> Benchmark (charsetName) Mode Cnt Score Error Units >> StringEncode.encodeAllMixed UTF-8 avgt 10 12894,551 ? 164,816 ns/op >> StringEncode.encodeUTF8InternalAllMixed UTF-8 avgt 10 236614,548 ? 1445,975 ns/op >> >> >> I.e. `String.getBytes(UTF_8.instance)` is about 18x faster on mixed inputs. The benchmark is available in 595b464 but as a quick sanity check not intended for integration. >> >> Testing: tier1-3 > > Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: > > Remove temporary microbenchmark Marked as reviewed by alanb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/18006#pullrequestreview-1901089641 From jbhateja at openjdk.org Mon Feb 26 14:54:58 2024 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Mon, 26 Feb 2024 14:54:58 GMT Subject: RFR: JDK-8320448 Accelerate IndexOf using AVX2 [v13] In-Reply-To: References: Message-ID: On Thu, 22 Feb 2024 03:15:10 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: > > Addressed some review coments; replaced hard-coded registers with descriptive names. src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 303: > 301: __ subq(rdi, rax); > 302: __ movq(rdx, rdi); > 303: __ andq(rdx, -16); Hi @asgibbons , may I request you to please use meaningful names instead of directly using actual GRP names. src/hotspot/cpu/x86/stubGenerator_x86_64_string.cpp line 777: > 775: __ movq(rax, rbx); > 776: __ movq(rbx, r14); > 777: __ leaq(r15, Address(r12, -0x2)); Kindly use semantically meaningful names instead of direct GPR names. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1502738843 PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r1502741451 From redestad at openjdk.org Mon Feb 26 14:59:59 2024 From: redestad at openjdk.org (Claes Redestad) Date: Mon, 26 Feb 2024 14:59:59 GMT Subject: RFR: 8326653: Remove jdk.internal.reflect.UTF8 [v2] In-Reply-To: References: Message-ID: On Mon, 26 Feb 2024 14:47:06 GMT, Roger Riggs wrote: >> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove temporary microbenchmark > > src/java.base/share/classes/jdk/internal/reflect/ClassFileAssembler.java line 28: > >> 26: package jdk.internal.reflect; >> 27: >> 28: import sun.nio.cs.UTF_8; > > I see about equal numbers of uses of `StandardCharsets.UTF_8` and `sun.nio.cs.UTF_8.INSTANCE` in java.base but would lean toward the one in `StandardCharsets` unless there's a bootstrap order dependency. Using `UTF_8.INSTANCE` avoids a dependency on a couple of unrelated charset classes and thus _could_ help avoid bootstrap issues. It definitely makes sense in `java.lang` and classes being loaded very early in the bootstrap. Less so here in a utility class used by legacy reflective class spinning, but since there was primordial concern about bootstrap issues it seemed like the safer choice. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18006#discussion_r1502750058 From jbhateja at openjdk.org Mon Feb 26 15:02:00 2024 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Mon, 26 Feb 2024 15:02:00 GMT Subject: RFR: 8318650: Optimized subword gather for x86 targets. [v14] In-Reply-To: References: <2_lbsdRrWvzmMfwKAHyeZTWDGAonTIrl-pSTr2JmuRs=.c73d8a1b-acb6-49a0-8aa3-f25004af2c35@github.com> Message-ID: On Mon, 26 Feb 2024 13:31:05 GMT, Emanuel Peter wrote: >> At the risk of becoming too nit-picky: which allocations are you talking about? Given you only have a single src and a single dst for this label/jump. So you won't use `_patch_overflow`. And therefore, all allocations are on the stack. The way you do it now, it seems you would allocate 4x the stack memory here, compared to doing it locally in the loop, where the stack space could potentially be reused between the iterations. >> It seems to me this is an optimization at the cost of code-style. Having them local makes it more clear that you are only jumping inside a iteration, and not between iterations. > > I could not find any other case with the same pattern, of initializing a list of Labels. > > On the other hand, I can find cases where we already do what I am saying: > `C2_MacroAssembler::rtm_counters_update` Hi @eme64 , I was referring to allocation of label's array. To be concise and avoid hand unrolling of loop, I chose an array of labels. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16354#discussion_r1502752772 From eirbjo at openjdk.org Mon Feb 26 15:06:32 2024 From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=) Date: Mon, 26 Feb 2024 15:06:32 GMT Subject: RFR: 8326096: Deprecate getTotalIn, getTotalOut methods of java.util.zip.Inflater, java.util.zip.Deflater [v4] In-Reply-To: <87wbBmabvVXFLBmw3sAFKTU2BtHG2kxQG2kGvzrMC7Y=.bdb475dc-f235-4614-9c84-451e7e99db4f@github.com> References: <3gTPWxpnS5VRTXK4P1gNtI5c-3BCL9OwR2FSHqZ9Nbo=.e0e49dc5-736a-4f7d-81a0-7a5e1fe9aa57@github.com> <87wbBmabvVXFLBmw3sAFKTU2BtHG2kxQG2kGvzrMC7Y=.bdb475dc-f235-4614-9c84-451e7e99db4f@github.com> Message-ID: On Sun, 25 Feb 2024 15:19:59 GMT, Alan Bateman wrote: > For the class description then it might be simpler to reduce the new text down to one sentence, e.g. @AlanBateman Thanks for the condensed text, that's indeed much better! I've pushed your suggestion, only adding a link around Integer.MAX_VALUE for consistency with the deprecation text. I'm wondering if the somewhat tedious "number of compressed bytes input so far" could be further simplified. Besides being a long repetition from the leading sentence, when used in this sentence, we actually mean to refer to the "actual, correct, real value", potentially different from the return value. (We mean the value returned by getBytesRead(), but we don't say so). Additionally, some amount of brainwork is required to parse what the "it" refers to. (It's pretty clear when you think about it, but you need to think :-) Would it be better to refer to the number returned by getBytesRead() instead? Something like this: * This method returns the equivalent of {@code (int) getBytesRead()} * and therefore cannot return the correct value when the number returned by * {@link #getBytesRead()} is greater than {@link Integer#MAX_VALUE}. For comparison, here is the current text: * This method returns the equivalent of {@code (int) getBytesRead()} * and therefore cannot return the correct number of compressed bytes * input so far when it is greater than {@link Integer#MAX_VALUE}. Do you think this is an improvement? (I'm also fine with the current text) ------------- PR Comment: https://git.openjdk.org/jdk/pull/17919#issuecomment-1964358746 From epeter at openjdk.org Mon Feb 26 15:12:03 2024 From: epeter at openjdk.org (Emanuel Peter) Date: Mon, 26 Feb 2024 15:12:03 GMT Subject: RFR: 8318650: Optimized subword gather for x86 targets. [v14] In-Reply-To: References: <2_lbsdRrWvzmMfwKAHyeZTWDGAonTIrl-pSTr2JmuRs=.c73d8a1b-acb6-49a0-8aa3-f25004af2c35@github.com> Message-ID: On Mon, 26 Feb 2024 14:58:53 GMT, Jatin Bhateja wrote: >> I could not find any other case with the same pattern, of initializing a list of Labels. >> >> On the other hand, I can find cases where we already do what I am saying: >> `C2_MacroAssembler::rtm_counters_update` > > Hi @eme64 , I was referring to allocation of label's array. To be concise and avoid hand unrolling of loop, I chose an array of labels. I was referring to the various arrays as well above. I think it would be exactly more concise if you defined a local label in the loop body. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16354#discussion_r1502762386 From epeter at openjdk.org Mon Feb 26 15:12:12 2024 From: epeter at openjdk.org (Emanuel Peter) Date: Mon, 26 Feb 2024 15:12:12 GMT Subject: RFR: 8318650: Optimized subword gather for x86 targets. [v14] In-Reply-To: References: <2_lbsdRrWvzmMfwKAHyeZTWDGAonTIrl-pSTr2JmuRs=.c73d8a1b-acb6-49a0-8aa3-f25004af2c35@github.com> Message-ID: On Mon, 26 Feb 2024 15:05:03 GMT, Emanuel Peter wrote: >> Hi @eme64 , I was referring to allocation of label's array. To be concise and avoid hand unrolling of loop, I chose an array of labels. > > I was referring to the various arrays as well above. I think it would be exactly more concise if you defined a local label in the loop body. Have you had a look at `C2_MacroAssembler::rtm_counters_update`? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16354#discussion_r1502762936 From mullan at openjdk.org Mon Feb 26 15:23:54 2024 From: mullan at openjdk.org (Sean Mullan) Date: Mon, 26 Feb 2024 15:23:54 GMT Subject: RFR: 8319648: java/lang/SecurityManager tests ignore vm flags In-Reply-To: <8QF-ychCHq3eRcsTlZqFqP68z2NApgazCTWyaDaP2iY=.e261430a-7cff-425a-ba7d-26b7f44fd0bc@github.com> References: <8QF-ychCHq3eRcsTlZqFqP68z2NApgazCTWyaDaP2iY=.e261430a-7cff-425a-ba7d-26b7f44fd0bc@github.com> Message-ID: On Thu, 15 Feb 2024 17:06:25 GMT, Matthew Donovan wrote: > In this PR I updated the tests to use the newer ProcessTools.createTestJavaProcessBuilder methods to pass VM options to child processes. test/jdk/java/lang/System/SecurityManagerWarnings.java line 135: > 133: if (prop == null) { > 134: pb = new ProcessBuilder( > 135: JDKToolFinder.getJDKTool("java"), You can remove the import of `JDKToolFinder` on line 31 now. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17878#discussion_r1502765515 From vklang at openjdk.org Mon Feb 26 15:23:58 2024 From: vklang at openjdk.org (Viktor Klang) Date: Mon, 26 Feb 2024 15:23:58 GMT Subject: RFR: 8326653: Remove jdk.internal.reflect.UTF8 [v2] In-Reply-To: References: Message-ID: On Mon, 26 Feb 2024 11:34:18 GMT, Claes Redestad wrote: >> jdk.internal.reflect.UTF8 is used for encoding String to encoded UTF-8 when generating some classes. >> >> Since JDK 9 we have a fast-path (which avoids creating encoders) for UTF-8-encoding strings which is bootstrapped very early, so it seems safe to rewire this and remove the UTF8 helper class whose stated raison d'?tre is to avoid bootstrapping issues. >> >> This cleanup also removes a latent bug since the custom encoder isn't able to deal with classfile constants containing surrogate pairs. >> >> For a quick comparison I copied the UTF8 code to the `StringEncode` microbenchmark and set up a benchmark testing the same inputs as `encodeAllMixed`: >> >> >> Benchmark (charsetName) Mode Cnt Score Error Units >> StringEncode.encodeAllMixed UTF-8 avgt 10 12894,551 ? 164,816 ns/op >> StringEncode.encodeUTF8InternalAllMixed UTF-8 avgt 10 236614,548 ? 1445,975 ns/op >> >> >> I.e. `String.getBytes(UTF_8.instance)` is about 18x faster on mixed inputs. The benchmark is available in 595b464 but as a quick sanity check not intended for integration. >> >> Testing: tier1-3 > > Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: > > Remove temporary microbenchmark Nice work, @cl4es! ------------- PR Comment: https://git.openjdk.org/jdk/pull/18006#issuecomment-1964403509 From mcimadamore at openjdk.org Mon Feb 26 15:24:09 2024 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 26 Feb 2024 15:24:09 GMT Subject: RFR: 8326172: Dubious claim on long[]/double[] alignment in MemorySegment javadoc In-Reply-To: References: Message-ID: <9WTuz_2iRFHMBacK8ajMsC3wuyNl2IXFV1ihsfPDjaU=.46032b20-f8b3-496f-b766-48cb1ddc66ce@github.com> On Mon, 26 Feb 2024 13:24:11 GMT, Jorn Vernee wrote: > This patch changes the alignment for `JAVA_LONG` and `JAVA_DOUBLE` to 8, regardless of the underlying platform. This means that atomic access modes work on memory segments wrapping `long[]` or `double[]`, as they already do when using `MethodHandless::arrayAccessVarHandle`. > > After discussion, we came to the conclusion that it is reasonable for the JDK to require the elements of a `long[]` and `double[]` to be 8 byte aligned. It is ultimately up to the JDK to set these requirements, which are for the VM to implement. > > I was seeing a stack overflow when running test/jdk/java/foreign/stackwalk/TestReentrantUpcalls.java on x86, so I've lowered the recursion to 50 (which is still more than enough I think). > > Testing: `jdk_foreign` on x64 Windows, x64 Windows + fallback linker, and x86 Linux (uses fallback linker) src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 328: > 326: * physical address 1010. > 327: *
  • The starting physical address of a {@code long[]} array will be 8-byte aligned > 328: * (e.g. 1000), so that successive long elements occur at 8-byte aligned addresses I believe there might be other changes required. I see the following sentences in the javadoc: * In other words, heap segments feature a (platform-dependent) maximum * alignment which is derived from the size of the elements of the Java array backing the * segment, as shown in the following table: ``` * In such circumstances, clients have two options. They can use a heap segment backed * by a different array type (e.g. {@code long[]}), capable of supporting greater maximum * alignment. More specifically, the maximum alignment associated with {@code long[]} is * set to {@code ValueLayout.JAVA_LONG.byteAlignment()} which is a platform-dependent * value (set to {@code ValueLayout.ADDRESS.byteSize()}). That is, {@code long[]}) is * guaranteed to provide at least 8-byte alignment in 64-bit platforms, but only 4-byte * alignment in 32-bit platforms: ``` ``` * In practice, the Java runtime lays out arrays in memory so that each n-byte element * occurs at an n-byte aligned physical address (except for {@code long[]} and * {@code double[]}, where alignment is platform-dependent, as explained below). ``` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18007#discussion_r1502771056 From acobbs at openjdk.org Mon Feb 26 15:24:14 2024 From: acobbs at openjdk.org (Archie Cobbs) Date: Mon, 26 Feb 2024 15:24:14 GMT Subject: RFR: 7036144: GZIPInputStream readTrailer uses faulty available() test for end-of-stream [v6] In-Reply-To: References: <7eCX4Yx0qM7Ipug5NI-A8I10-22Iyyk-eMh6ELcHV2c=.bd909779-025d-4e71-816d-e4d6539e85ed@github.com> Message-ID: On Mon, 26 Feb 2024 06:51:12 GMT, Jaikiran Pai wrote: >> Archie Cobbs has updated the pull request with a new target base 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-7036144 >> - Merge branch 'master' into JDK-7036144 >> - Address third round of review comments. >> - Address second round of review comments. >> - Address review comments. >> - Fix bug in GZIPInputStream when underlying available() returns short. > > Hello Archie, the proposal to not depend on the `available()` method of the underlying `InputStream` to decide whether to read additional bytes from the underlying stream to detect the "next" header seems reasonable. > > What's being proposed here is that we proceed and read the underlying stream's few additional bytes to detect the presence or absence of a GZIP member header and if that attempt fails (with an IOException) then we consider that we have reached the end of GZIP stream and just return back. > > For this change, I think we would also need to consider whether we should "unread" the read bytes from the `InputStream` if those don't correspond to a "next" GZIP member header. That way any underlying `InputStream` which was implemented in a way that it would return availability as 0 when it knew that the GZIP stream was done and yet had additional (non GZIP) data to read on the underlying stream, would still be able to read that data after this change. It's arguable whether we should have been doing that "unread" even when we were doing the `available() > 0` check and the decision that comes out of https://bugs.openjdk.org/browse/JDK-8322256 might cover that. Hi @jaikiran, I agree with your comments. My only question is whether we should do all of this in one stage or two stages. My initial thought is to do this in two stages: * A narrow fix for the bug described here as implemented by this PR * A larger change (requiring a separate bug, CSR, and PR) to: * More precisely define and specify the expected behavior, with support for concatenated streams * Eliminate situations where we read beyond the end-of-stream (i.e., "unreading" if/when necessary) The reason I think this two stage approach is appropriate is because there is no downside to doing it this way - that is, the problem you describe of reading beyond the end-of-stream is _already_ a problem in the current code, with the exception of the one corner case where this bug fix applies, namely, when `in.available()` returns zero and yet there actually _is_ more data available. Your thoughts? ------------- PR Comment: https://git.openjdk.org/jdk/pull/17113#issuecomment-1964372772 From redestad at openjdk.org Mon Feb 26 15:27:26 2024 From: redestad at openjdk.org (Claes Redestad) Date: Mon, 26 Feb 2024 15:27:26 GMT Subject: RFR: 8326653: Remove jdk.internal.reflect.UTF8 [v2] In-Reply-To: References: Message-ID: On Mon, 26 Feb 2024 11:34:18 GMT, Claes Redestad wrote: >> jdk.internal.reflect.UTF8 is used for encoding String to encoded UTF-8 when generating some classes. >> >> Since JDK 9 we have a fast-path (which avoids creating encoders) for UTF-8-encoding strings which is bootstrapped very early, so it seems safe to rewire this and remove the UTF8 helper class whose stated raison d'?tre is to avoid bootstrapping issues. >> >> This cleanup also removes a latent bug since the custom encoder isn't able to deal with classfile constants containing surrogate pairs. >> >> For a quick comparison I copied the UTF8 code to the `StringEncode` microbenchmark and set up a benchmark testing the same inputs as `encodeAllMixed`: >> >> >> Benchmark (charsetName) Mode Cnt Score Error Units >> StringEncode.encodeAllMixed UTF-8 avgt 10 12894,551 ? 164,816 ns/op >> StringEncode.encodeUTF8InternalAllMixed UTF-8 avgt 10 236614,548 ? 1445,975 ns/op >> >> >> I.e. `String.getBytes(UTF_8.instance)` is about 18x faster on mixed inputs. The benchmark is available in 595b464 but as a quick sanity check not intended for integration. >> >> Testing: tier1-3 > > Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: > > Remove temporary microbenchmark Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/18006#issuecomment-1964413518 From redestad at openjdk.org Mon Feb 26 15:33:40 2024 From: redestad at openjdk.org (Claes Redestad) Date: Mon, 26 Feb 2024 15:33:40 GMT Subject: Integrated: 8326653: Remove jdk.internal.reflect.UTF8 In-Reply-To: References: Message-ID: On Mon, 26 Feb 2024 11:05:10 GMT, Claes Redestad wrote: > jdk.internal.reflect.UTF8 is used for encoding String to encoded UTF-8 when generating some classes. > > Since JDK 9 we have a fast-path (which avoids creating encoders) for UTF-8-encoding strings which is bootstrapped very early, so it seems safe to rewire this and remove the UTF8 helper class whose stated raison d'?tre is to avoid bootstrapping issues. > > This cleanup also removes a latent bug since the custom encoder isn't able to deal with classfile constants containing surrogate pairs. > > For a quick comparison I copied the UTF8 code to the `StringEncode` microbenchmark and set up a benchmark testing the same inputs as `encodeAllMixed`: > > > Benchmark (charsetName) Mode Cnt Score Error Units > StringEncode.encodeAllMixed UTF-8 avgt 10 12894,551 ? 164,816 ns/op > StringEncode.encodeUTF8InternalAllMixed UTF-8 avgt 10 236614,548 ? 1445,975 ns/op > > > I.e. `String.getBytes(UTF_8.instance)` is about 18x faster on mixed inputs. The benchmark is available in 595b464 but as a quick sanity check not intended for integration. > > Testing: tier1-3 This pull request has now been integrated. Changeset: c042f086 Author: Claes Redestad URL: https://git.openjdk.org/jdk/commit/c042f0863247633e98ace9757fb8531145286e66 Stats: 81 lines in 2 files changed: 2 ins; 78 del; 1 mod 8326653: Remove jdk.internal.reflect.UTF8 Reviewed-by: rriggs, alanb ------------- PR: https://git.openjdk.org/jdk/pull/18006 From lancea at openjdk.org Mon Feb 26 15:35:17 2024 From: lancea at openjdk.org (Lance Andersen) Date: Mon, 26 Feb 2024 15:35:17 GMT Subject: Integrated: 8321156: Improve the handling of invalid UTF-8 byte sequences for ZipInputStream::getNextEntry and ZipFile::getComment In-Reply-To: References: Message-ID: On Sat, 24 Feb 2024 14:56:01 GMT, Lance Andersen wrote: > Please review this PR which addresses the handling of invalid UTF-8 byte sequences in the entry name of a LOC file header and a Zip file comment which is returned via ZipFile::getComment. > > As part of the change, `ZipFile::getComment` will now return `null` if an invalid UTF-8 byte sequence is encountered while converting the byte array to a String. The CSR for this change has also been approved. > > Mach5 tiers 1-3 are clean with this change. This pull request has now been integrated. Changeset: 20c71cea Author: Lance Andersen URL: https://git.openjdk.org/jdk/commit/20c71ceacdcb791f5b70cda456bdc47bdd9acf6c Stats: 289 lines in 3 files changed: 176 ins; 16 del; 97 mod 8321156: Improve the handling of invalid UTF-8 byte sequences for ZipInputStream::getNextEntry and ZipFile::getComment Reviewed-by: jpai, alanb ------------- PR: https://git.openjdk.org/jdk/pull/17995 From rriggs at openjdk.org Mon Feb 26 15:54:44 2024 From: rriggs at openjdk.org (Roger Riggs) Date: Mon, 26 Feb 2024 15:54:44 GMT Subject: RFR: 8325340: Add ASCII fast-path to Data-/ObjectInputStream.readUTF [v7] In-Reply-To: <5W9u4RJXEclgcBrZt6uWlGDcVYFRGJhkqa79PNJjxo8=.46b06cde-865f-447c-b8d6-bf4d80162686@github.com> References: <5W9u4RJXEclgcBrZt6uWlGDcVYFRGJhkqa79PNJjxo8=.46b06cde-865f-447c-b8d6-bf4d80162686@github.com> Message-ID: On Fri, 16 Feb 2024 15:31:07 GMT, Claes Redestad wrote: >> Adding a fast-path for ASCII-only modified UTF-8 strings deserialied via Data- and ObjectInputStream >> >> Testing: tier1-3 > > Claes Redestad has updated the pull request incrementally with two additional commits since the last revision: > > - Update test/micro/org/openjdk/bench/java/io/DataInputStreamTest.java > > Co-authored-by: Raffaello Giulietti > - Update test/micro/org/openjdk/bench/java/io/ObjectInputStreamTest.java > > Co-authored-by: Raffaello Giulietti Looks good. src/java.base/share/classes/java/io/DataInputStream.java line 622: > 620: "malformed input around byte " + count); > 621: chararr[chararr_count++]=(char)(((c & 0x1F) << 6) | > 622: (char2 & 0x3F)); Seems like the extra space isn't necessary for alignment. ------------- Marked as reviewed by rriggs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17734#pullrequestreview-1901248533 PR Review Comment: https://git.openjdk.org/jdk/pull/17734#discussion_r1502841700 From ihse at openjdk.org Mon Feb 26 15:57:03 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 26 Feb 2024 15:57:03 GMT Subject: RFR: 8326583: Remove over-generalized DefineNativeToolchain solution [v2] In-Reply-To: References: Message-ID: > The idea of setting up general "toolchains" in the native build was good, but it turned out that we really only need a single toolchain, with a single twist: if it should use CC or CPP to link. This is better described by a specific argument to SetupNativeCompilation, LANG := C++ or LANG := C (the default). > > There is a single exception to this rule, and that is if we want to compile for the build platform rather than the target platform. (This is only done for adlc) To keep expressing this difference, introduce TARGET_TYPE := BUILD (or TARGET_TYPE := TARGET, the default). > > The final odd-case was the hack for building hsdis/bin on mingw. This can be resolved using direct variables to SetupNativeCompilation, instead of first creating a toolchain. > > Doing this refactoring will simplify the SetupNativeCompilation code, and make it much clearer if we use the C or C++ linker. Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: - Reword "lib" comment to fit in better - Merge branch 'master' into remove-toolchain-define - 8326583: Remove over-generalized DefineNativeToolchain solution ------------- Changes: https://git.openjdk.org/jdk/pull/17986/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17986&range=01 Stats: 231 lines in 14 files changed: 58 ins; 142 del; 31 mod Patch: https://git.openjdk.org/jdk/pull/17986.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17986/head:pull/17986 PR: https://git.openjdk.org/jdk/pull/17986 From jvernee at openjdk.org Mon Feb 26 16:05:51 2024 From: jvernee at openjdk.org (Jorn Vernee) Date: Mon, 26 Feb 2024 16:05:51 GMT Subject: RFR: 8326172: Dubious claim on long[]/double[] alignment in MemorySegment javadoc [v2] In-Reply-To: References: Message-ID: > This patch changes the alignment for `JAVA_LONG` and `JAVA_DOUBLE` to 8, regardless of the underlying platform. This means that atomic access modes work on memory segments wrapping `long[]` or `double[]`, as they already do when using `MethodHandless::arrayAccessVarHandle`. > > After discussion, we came to the conclusion that it is reasonable for the JDK to require the elements of a `long[]` and `double[]` to be 8 byte aligned. It is ultimately up to the JDK to set these requirements, which are for the VM to implement. > > I was seeing a stack overflow when running test/jdk/java/foreign/stackwalk/TestReentrantUpcalls.java on x86, so I've lowered the recursion to 50 (which is still more than enough I think). > > Testing: `jdk_foreign` on x64 Windows, x64 Windows + fallback linker, and x86 Linux (uses fallback linker) Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: review comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/18007/files - new: https://git.openjdk.org/jdk/pull/18007/files/787e32bb..b145a58b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=18007&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18007&range=00-01 Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/18007.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18007/head:pull/18007 PR: https://git.openjdk.org/jdk/pull/18007 From jvernee at openjdk.org Mon Feb 26 16:05:52 2024 From: jvernee at openjdk.org (Jorn Vernee) Date: Mon, 26 Feb 2024 16:05:52 GMT Subject: RFR: 8326172: Dubious claim on long[]/double[] alignment in MemorySegment javadoc [v2] In-Reply-To: <9WTuz_2iRFHMBacK8ajMsC3wuyNl2IXFV1ihsfPDjaU=.46032b20-f8b3-496f-b766-48cb1ddc66ce@github.com> References: <9WTuz_2iRFHMBacK8ajMsC3wuyNl2IXFV1ihsfPDjaU=.46032b20-f8b3-496f-b766-48cb1ddc66ce@github.com> Message-ID: <2TLUIm0U5akH2ylQ09J11RGVyf83NMqEnfJXSZmcc6M=.4b23cf47-8dcd-4e73-9dc5-f74c27a4e402@github.com> On Mon, 26 Feb 2024 15:10:55 GMT, Maurizio Cimadamore wrote: >> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: >> >> review comments > > src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 328: > >> 326: * physical address 1010.
    • >> 327: *
  • The starting physical address of a {@code long[]} array will be 8-byte aligned >> 328: * (e.g. 1000), so that successive long elements occur at 8-byte aligned addresses > > I believe there might be other changes required. I see the following sentences in the javadoc: > > > * In other words, heap segments feature a (platform-dependent) maximum > * alignment which is derived from the size of the elements of the Java array backing the > * segment, as shown in the following table: > ``` > > > * In such circumstances, clients have two options. They can use a heap segment backed > * by a different array type (e.g. {@code long[]}), capable of supporting greater maximum > * alignment. More specifically, the maximum alignment associated with {@code long[]} is > * set to {@code ValueLayout.JAVA_LONG.byteAlignment()} which is a platform-dependent > * value (set to {@code ValueLayout.ADDRESS.byteSize()}). That is, {@code long[]}) is > * guaranteed to provide at least 8-byte alignment in 64-bit platforms, but only 4-byte > * alignment in 32-bit platforms: > ``` > > ``` > * In practice, the Java runtime lays out arrays in memory so that each n-byte element > * occurs at an n-byte aligned physical address (except for {@code long[]} and > * {@code double[]}, where alignment is platform-dependent, as explained below). > ``` I got the second one already. Will modify the 1st and 3rd ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18007#discussion_r1502882211 From redestad at openjdk.org Mon Feb 26 16:09:03 2024 From: redestad at openjdk.org (Claes Redestad) Date: Mon, 26 Feb 2024 16:09:03 GMT Subject: RFR: 8325340: Add ASCII fast-path to Data-/ObjectInputStream.readUTF [v7] In-Reply-To: References: <5W9u4RJXEclgcBrZt6uWlGDcVYFRGJhkqa79PNJjxo8=.46b06cde-865f-447c-b8d6-bf4d80162686@github.com> Message-ID: On Mon, 26 Feb 2024 15:50:55 GMT, Roger Riggs wrote: >> Claes Redestad has updated the pull request incrementally with two additional commits since the last revision: >> >> - Update test/micro/org/openjdk/bench/java/io/DataInputStreamTest.java >> >> Co-authored-by: Raffaello Giulietti >> - Update test/micro/org/openjdk/bench/java/io/ObjectInputStreamTest.java >> >> Co-authored-by: Raffaello Giulietti > > src/java.base/share/classes/java/io/DataInputStream.java line 622: > >> 620: "malformed input around byte " + count); >> 621: chararr[chararr_count++]=(char)(((c & 0x1F) << 6) | >> 622: (char2 & 0x3F)); > > Seems like the extra space isn't necessary for alignment. Fixed, thanks for reviewing! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17734#discussion_r1502894731 From redestad at openjdk.org Mon Feb 26 16:09:03 2024 From: redestad at openjdk.org (Claes Redestad) Date: Mon, 26 Feb 2024 16:09:03 GMT Subject: Integrated: 8325340: Add ASCII fast-path to Data-/ObjectInputStream.readUTF In-Reply-To: References: Message-ID: <5HZKzdpcBZUjnkXsxyvXdTSXfVK-pgewV7EiZ4XW2OY=.7e7f7339-d169-4519-baad-7b74e3ef312d@github.com> On Tue, 6 Feb 2024 16:17:21 GMT, Claes Redestad wrote: > Adding a fast-path for ASCII-only modified UTF-8 strings deserialied via Data- and ObjectInputStream > > Testing: tier1-3 This pull request has now been integrated. Changeset: 9a9cfbe0 Author: Claes Redestad URL: https://git.openjdk.org/jdk/commit/9a9cfbe0ba18084bbeae212c9e0da2715a3086e7 Stats: 369 lines in 4 files changed: 345 ins; 7 del; 17 mod 8325340: Add ASCII fast-path to Data-/ObjectInputStream.readUTF Reviewed-by: rgiulietti, bpb, rriggs ------------- PR: https://git.openjdk.org/jdk/pull/17734 From redestad at openjdk.org Mon Feb 26 16:09:02 2024 From: redestad at openjdk.org (Claes Redestad) Date: Mon, 26 Feb 2024 16:09:02 GMT Subject: RFR: 8325340: Add ASCII fast-path to Data-/ObjectInputStream.readUTF [v8] In-Reply-To: References: Message-ID: > Adding a fast-path for ASCII-only modified UTF-8 strings deserialied via Data- and ObjectInputStream > > Testing: tier1-3 Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: Stray space ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17734/files - new: https://git.openjdk.org/jdk/pull/17734/files/586635e8..9929cd87 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17734&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17734&range=06-07 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/17734.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17734/head:pull/17734 PR: https://git.openjdk.org/jdk/pull/17734 From mcimadamore at openjdk.org Mon Feb 26 16:24:43 2024 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 26 Feb 2024 16:24:43 GMT Subject: RFR: 8326172: Dubious claim on long[]/double[] alignment in MemorySegment javadoc [v2] In-Reply-To: References: Message-ID: On Mon, 26 Feb 2024 16:05:51 GMT, Jorn Vernee wrote: >> This patch changes the alignment for `JAVA_LONG` and `JAVA_DOUBLE` to 8, regardless of the underlying platform. This means that atomic access modes work on memory segments wrapping `long[]` or `double[]`, as they already do when using `MethodHandless::arrayAccessVarHandle`. >> >> After discussion, we came to the conclusion that it is reasonable for the JDK to require the elements of a `long[]` and `double[]` to be 8 byte aligned. It is ultimately up to the JDK to set these requirements, which are for the VM to implement. >> >> I was seeing a stack overflow when running test/jdk/java/foreign/stackwalk/TestReentrantUpcalls.java on x86, so I've lowered the recursion to 50 (which is still more than enough I think). >> >> Testing: `jdk_foreign` on x64 Windows, x64 Windows + fallback linker, and x86 Linux (uses fallback linker) > > Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: > > review comments test/jdk/java/foreign/TestLayouts.java line 164: > 162: ); > 163: assertEquals(struct.byteSize(), 1 + 1 + 2 + 4 + 8); > 164: assertEquals(struct.byteAlignment(), 8); Looking at this PR: https://github.com/openjdk/jdk/pull/18007 This test seemed to cover more case before that PR - e.g. a layout generator was tweaked to exclude long/doubles. I believe revert the test changes now? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18007#discussion_r1502938943 From ihse at openjdk.org Mon Feb 26 16:35:48 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 26 Feb 2024 16:35:48 GMT Subject: RFR: 8174269: Remove COMPAT locale data provider from JDK In-Reply-To: References: Message-ID: <-T_RAaAiyq9ZHn6kynwrZL4w3UHwq7ANs5xIRC5OOMI=.4e2c4392-c766-4d1c-ba0c-e85d28e377db@github.com> On Mon, 26 Feb 2024 14:20:40 GMT, Erik Joelsson wrote: >> This PR intends to remove the legacy `COMPAT` locale data from the JDK. The `COMPAT` locale data was introduced for applications' migratory purposes transitioning to `CLDR`. It is becoming a technical debt and now is the time to remove it (we've been emitting a warning at JVM startup since JDK21, if the app is using `COMPAT`). A corresponding CSR has also been drafted. > > make/modules/java.base/gensrc/GensrcLocaleData.gmk line 58: > >> 56: ifeq ($(MODULE), jdk.localedata) >> 57: $(shell $(RM) $(SUPPORT_OUTPUTDIR)/gensrc/jdk.localedata/sun/util/resources/cldr/provider/CLDRLocaleDataMetaInfo_jdk_localedata.java) >> 58: endif > > The remainder of this file doesn't seem to be doing anything useful. Do we really need to keep it around? If I understand this correctly, the files referenced and deleted here are generated by the cldrconverter. Is that build tool relying on make removing the file first? Reading the java source, my impression is that it will generate the file unconditionally regardless of the files current existence as long as the tool is run. Actually, as the file currently in the PR, it does not seem like it does anything at all, since we no longer create `_the.locale_resources`. Or... hm, without that file, `PREV_LOCALE_RESOURCES` will always be empty. I wonder what `$(filter-out $(PREV_LOCALE_RESOURCES), $(LOCALE_RESOURCES))` returns in that case. If it is empty, then this file does nothing. If it is `$(LOCALE_RESOURCES)`, then we will unconditionally rm the two files. I believe the original intention was to spot added or removed locale resources, and use that to trigger a re-generation. This does not seem to work at all anymore. Do we still need that kind of behavior? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17991#discussion_r1502955421 From ihse at openjdk.org Mon Feb 26 16:41:46 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 26 Feb 2024 16:41:46 GMT Subject: RFR: 8174269: Remove COMPAT locale data provider from JDK In-Reply-To: <-T_RAaAiyq9ZHn6kynwrZL4w3UHwq7ANs5xIRC5OOMI=.4e2c4392-c766-4d1c-ba0c-e85d28e377db@github.com> References: <-T_RAaAiyq9ZHn6kynwrZL4w3UHwq7ANs5xIRC5OOMI=.4e2c4392-c766-4d1c-ba0c-e85d28e377db@github.com> Message-ID: On Mon, 26 Feb 2024 16:33:02 GMT, Magnus Ihse Bursie wrote: >> make/modules/java.base/gensrc/GensrcLocaleData.gmk line 58: >> >>> 56: ifeq ($(MODULE), jdk.localedata) >>> 57: $(shell $(RM) $(SUPPORT_OUTPUTDIR)/gensrc/jdk.localedata/sun/util/resources/cldr/provider/CLDRLocaleDataMetaInfo_jdk_localedata.java) >>> 58: endif >> >> The remainder of this file doesn't seem to be doing anything useful. Do we really need to keep it around? If I understand this correctly, the files referenced and deleted here are generated by the cldrconverter. Is that build tool relying on make removing the file first? Reading the java source, my impression is that it will generate the file unconditionally regardless of the files current existence as long as the tool is run. > > Actually, as the file currently in the PR, it does not seem like it does anything at all, since we no longer create `_the.locale_resources`. Or... hm, without that file, `PREV_LOCALE_RESOURCES` will always be empty. I wonder what `$(filter-out $(PREV_LOCALE_RESOURCES), $(LOCALE_RESOURCES))` returns in that case. If it is empty, then this file does nothing. If it is `$(LOCALE_RESOURCES)`, then we will unconditionally rm the two files. > > I believe the original intention was to spot added or removed locale resources, and use that to trigger a re-generation. This does not seem to work at all anymore. Do we still need that kind of behavior? Oh, this is a rabbit hole. :-( I tried to figure out where `CLDRBaseLocaleDataMetaInfo.java` comes from; I could not see where we generated that file. Turns out it is created in `make/jdk/src/classes/build/tools/cldrconverter/ResourceBundleGenerator.java`, in the function `generateMetaInfo()`. I assume this is called as part of calling the CLDRConverter buildtool. But this is done in `make/modules/[java.base|jdk.localedata]/Gensrc.gmk`. So if we need to invalidate that build tool result, it should be done in these files. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17991#discussion_r1502964932 From alanb at openjdk.org Mon Feb 26 16:52:47 2024 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 26 Feb 2024 16:52:47 GMT Subject: RFR: 8321156: Improve the handling of invalid UTF-8 byte sequences for ZipInputStream::getNextEntry and ZipFile::getComment [v3] In-Reply-To: References: <2cG6OdVf5fntURL2DtrbTbEUipt19GS2J31OuFjEyxk=.ae7b96e9-7296-4c8e-baa6-3c4d46b4fcf0@github.com> Message-ID: On Mon, 26 Feb 2024 06:00:13 GMT, Jaikiran Pai wrote: >>> (In passing, the casing of "zip file" is very inconsistent in the javadoc, it's "ZIP file" in some places, "zip file" in others, the change here uses "Zip file"). >> >> Thank you for pointing out the discrepancy above. >> >> Let's decide on which way to go and I will update under a separate PR. >> >> I would suggest "ZIP file" based on the PKWare APPNOTE.TXT, but the man pages for info-zip command _zip_ command uses "zip file" >> >> Apache commons also uses "ZIP file" or "ZIP archive" > >> I would suggest "ZIP file" based on the PKWare APPNOTE.TXT, > > I think using this case would be good. > I would suggest "ZIP file" based on the PKWare APPNOTE.TXT, but the man pages for info-zip command _zip_ command uses "zip file" "ZIP" is not an acronym so I assume this is why they use "zip" in their docs. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17995#discussion_r1502980604 From sgehwolf at openjdk.org Mon Feb 26 17:39:58 2024 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Mon, 26 Feb 2024 17:39:58 GMT Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged modules being present [v16] In-Reply-To: References: Message-ID: <6v_wf-v5k_eEb4mph2fp94qfIIz7mPuukxBKTdon4Rc=.df957fe2-d7fd-4034-8e38-6ed43efa8ea8@github.com> > Please review this patch which adds a jlink mode to the JDK which doesn't need the packaged modules being present. A.k.a run-time image based jlink. 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 b eing 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 `JRTArchive` 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 jdk.jlink) <(../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.manage... Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 71 commits: - Update copyright year. - Add support for custom modules via the module path - Add verification step that runtime link is being performed - Fix runtime link tests - Add copyright headers - Initial work for tests - --enable-runtime-link-image now replaces default jdk image - Some sanity checks and clean-ups from the earlier design - Merge branch 'master' into jdk-8311302-jmodless-link-new-approach - Fixes for full build workflow - ... and 61 more: https://git.openjdk.org/jdk/compare/e8ceb718...cd47f3d9 ------------- Changes: https://git.openjdk.org/jdk/pull/14787/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14787&range=15 Stats: 3744 lines in 41 files changed: 3609 ins; 110 del; 25 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 Feb 26 17:43:44 2024 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 26 Feb 2024 17:43:44 GMT Subject: RFR: 8310994: Add JFR event for selection operations [v3] In-Reply-To: References: <8lBiUxq1EYaux0j6rOnzmScfwFWfBRbYYT1IwEvSQWQ=.bc31666d-4f00-4ac9-a4f2-242abe231db1@github.com> Message-ID: On Mon, 26 Feb 2024 14:14:21 GMT, Daniel Fuchs wrote: > Maybe that's OK - and maybe in that case the onus is on the user to set a threshold greater than 1500ms? The threshold is 20ms so these timed-select ops in the HTTP client will record an event when they timeout. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16710#discussion_r1503052233 From liach at openjdk.org Mon Feb 26 17:48:53 2024 From: liach at openjdk.org (Chen Liang) Date: Mon, 26 Feb 2024 17:48:53 GMT Subject: RFR: 8323707: Adjust Classfile API's type arg model to better represent the embodied type [v4] In-Reply-To: References: Message-ID: <1obW1-l1wFpTjbAlnhXqTlgr8i89LStvH8SmhqhniC0=.bf0763f6-bfb3-459b-aed1-a23835226615@github.com> > API changes as discussed on the mailing list: https://mail.openjdk.org/pipermail/classfile-api-dev/2023-November/000419.html > > Additional questions: > 1. Whether to rename `WildcardIndicator.DEFAULT` to `NONE` Chen Liang 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 branch 'master' of https://github.com/openjdk/jdk into fix/typearg-model - Missed renaming in tests, thanks to Adam Sotona Co-authored-by: Adam Sotona <10807609+asotona at users.noreply.github.com> - Rename no wildcard indicator, improve docs slightly - Merge branch 'master' of https://github.com/openjdk/jdk into fix/typearg-model - Merge branch 'master' into fix/typearg-model - redundant line - Fix a test in langtools, copyright year - Merge branch 'master' of https://github.com/openjdk/jdk into fix/typearg-model - Implementation cleanup, test update - Merge branch 'master' into fix/typearg-model - ... and 3 more: https://git.openjdk.org/jdk/compare/f62b5789...839efabd ------------- Changes: https://git.openjdk.org/jdk/pull/16517/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16517&range=03 Stats: 132 lines in 6 files changed: 49 ins; 32 del; 51 mod Patch: https://git.openjdk.org/jdk/pull/16517.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16517/head:pull/16517 PR: https://git.openjdk.org/jdk/pull/16517 From sgehwolf at openjdk.org Mon Feb 26 17:50:53 2024 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Mon, 26 Feb 2024 17:50:53 GMT Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged modules being present [v17] In-Reply-To: References: Message-ID: > Please review this patch which adds a jlink mode to the JDK which doesn't need the packaged modules being present. A.k.a run-time image based jlink. 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 b eing 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 `JRTArchive` 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 jdk.jlink) <(../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.manage... Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 72 commits: - Merge branch 'master' into jdk-8311302-jmodless-link - Update copyright year. - Add support for custom modules via the module path - Add verification step that runtime link is being performed - Fix runtime link tests - Add copyright headers - Initial work for tests - --enable-runtime-link-image now replaces default jdk image - Some sanity checks and clean-ups from the earlier design - Merge branch 'master' into jdk-8311302-jmodless-link-new-approach - ... and 62 more: https://git.openjdk.org/jdk/compare/f62b5789...00caf77c ------------- Changes: https://git.openjdk.org/jdk/pull/14787/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14787&range=16 Stats: 3744 lines in 41 files changed: 3609 ins; 110 del; 25 mod Patch: https://git.openjdk.org/jdk/pull/14787.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14787/head:pull/14787 PR: https://git.openjdk.org/jdk/pull/14787 From sgehwolf at openjdk.org Mon Feb 26 18:10:50 2024 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Mon, 26 Feb 2024 18:10:50 GMT Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged modules being present [v12] In-Reply-To: References: Message-ID: On Fri, 8 Dec 2023 15:44:07 GMT, Alan Bateman wrote: >> Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 46 commits: >> >> - Add @enablePreview for JImageValidator that uses classfile API >> - Fix SystemModulesPlugin after merge >> - Merge branch 'master' into jdk-8311302-jmodless-link >> - Don't show the verbose hint when already verbose >> - Use '_files' over '_resources' as the suffix for listing resources >> - Remove the hidden option hint. >> >> Also adjust the messages being printed when performing >> a run-time image link. >> - Localize messages, switch expression >> - Rename RunImageArchive => JRTArchive and RunImageLinkException => RuntimeImageLinkException >> >> Also moved the stamp file to jdk.jlink module. The resources files per >> module now get unconditionally created (empty if no resources not in the >> jimage). >> - First round of addressing review feedback. >> >> - Share resource names (JlinkTask and JlinkResourcesListPlugin) >> - Exclude resources in JlinkResourcesListPlugin the same way >> as done for other plugins. >> - Rename AddRunImageResourcesPlugin => JlinkResourcesListPlugin >> - ... and 36 more: https://git.openjdk.org/jdk/compare/87516e29...a797ea69 > > I tried out the latest commit (a797ea69). > > The output "The default module path, '$java.home/jmods' not present. Use --verbose to show the full list of plugin options applied" is bit confusing as it looks like jlink failed but it actually succeeded. Blowing away the generated image and retrying with --verbose tripped this assert > > java.lang.AssertionError: handling of scratch options failed > at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.logPackagedModuleEquivalent(JlinkTask.java:675) > at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.createImageProvider(JlinkTask.java:581) > at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.createImage(JlinkTask.java:430) > at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.run(JlinkTask.java:302) > at jdk.jlink/jdk.tools.jlink.internal.Main.run(Main.java:56) > at jdk.jlink/jdk.tools.jlink.internal.Main.main(Main.java:34) > Caused by: jdk.tools.jlink.internal.TaskHelper$BadArgs: (...my-original-jdk-directory..)/build/linux-x64/images/jdk/jmods already exists > at jdk.jlink/jdk.tools.jlink.internal.TaskHelper.newBadArgs(TaskHelper.java:730) > at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.lambda$static$12(JlinkTask.java:183) > at jdk.jlink/jdk.tools.jlink.internal.TaskHelper$Option.process(TaskHelper.java:177) > at jdk.jlink/jdk.tools.jlink.internal.TaskHelper$OptionsHelper.handleOptions(TaskHelper.java:600) > at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.logPackagedModuleEquivalent(JlinkTask.java:672) > ... 5 more > > I haven't dug into this yet but I'm puzzled that the file path to where the original build was created is in the exception messages, is that recorded? @AlanBateman @mlchung I've now pushed an update of this patch which now uses a build-time approach as discussed elsewhere. In order to produce a linkable runtime JDK image, one needs to set `--enable-runtime-link-image` at configure time. This then generates a diff from the optimized jdk image to the classes/resources in the packaged modules. The diff is serialized to disk (a `4kb` file, currently) and taken as input to the new jlink plugin `--create-linkable-runtime`, which then adds the conf/libs resources listing and the diff to the `jdk.jlink` module for runtime link consumption. The diff is then applied in `JRTArchive` as appropriate at jlink time. Therefore, jlink plugin authors no longer need to know about which plugins get applied. Runtime link users get a consistent view (as compared to the packaged modules link) when running jlink. A few things that probably still need to be addressed are: - Figure out a way to not duplicate the `ResourceDiff` class. That's mostly done because otherwise one would need to have a `ResourceDiff`-including JDK as boot JDK. A better approach would probably be to do some build magic to copy the class from the build tools area to the `jdk.jlink` generated sources. - Cleanup the tests. I've saved this for a future update as I wanted to get some general feedback first before polishing. - Update the CSR with this new approach (document `--create-linkable-runtime`). Please let me know if this is going in the right direction. Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/14787#issuecomment-1964809941 From jvernee at openjdk.org Mon Feb 26 19:17:56 2024 From: jvernee at openjdk.org (Jorn Vernee) Date: Mon, 26 Feb 2024 19:17:56 GMT Subject: RFR: 8326172: Dubious claim on long[]/double[] alignment in MemorySegment javadoc [v3] In-Reply-To: References: Message-ID: > This patch changes the alignment for `JAVA_LONG` and `JAVA_DOUBLE` to 8, regardless of the underlying platform. This means that atomic access modes work on memory segments wrapping `long[]` or `double[]`, as they already do when using `MethodHandless::arrayAccessVarHandle`. > > After discussion, we came to the conclusion that it is reasonable for the JDK to require the elements of a `long[]` and `double[]` to be 8 byte aligned. It is ultimately up to the JDK to set these requirements, which are for the VM to implement. > > I was seeing a stack overflow when running test/jdk/java/foreign/stackwalk/TestReentrantUpcalls.java on x86, so I've lowered the recursion to 50 (which is still more than enough I think). > > Testing: `jdk_foreign` on x64 Windows, x64 Windows + fallback linker, and x86 Linux (uses fallback linker) Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: re-widen test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/18007/files - new: https://git.openjdk.org/jdk/pull/18007/files/b145a58b..fad15a66 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=18007&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18007&range=01-02 Stats: 10 lines in 1 file changed: 0 ins; 4 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/18007.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18007/head:pull/18007 PR: https://git.openjdk.org/jdk/pull/18007 From jvernee at openjdk.org Mon Feb 26 19:17:56 2024 From: jvernee at openjdk.org (Jorn Vernee) Date: Mon, 26 Feb 2024 19:17:56 GMT Subject: RFR: 8326172: Dubious claim on long[]/double[] alignment in MemorySegment javadoc [v2] In-Reply-To: References: Message-ID: On Mon, 26 Feb 2024 16:21:38 GMT, Maurizio Cimadamore wrote: >> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: >> >> review comments > > test/jdk/java/foreign/TestLayouts.java line 164: > >> 162: ); >> 163: assertEquals(struct.byteSize(), 1 + 1 + 2 + 4 + 8); >> 164: assertEquals(struct.byteAlignment(), 8); > > Looking at this PR: > https://github.com/openjdk/jdk/pull/18007 > > This test seemed to cover more case before that PR - e.g. a layout generator was tweaked to exclude long/doubles. I believe revert the test changes now? That doesn't seem to be the right PR link? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18007#discussion_r1503163065 From jvernee at openjdk.org Mon Feb 26 19:17:57 2024 From: jvernee at openjdk.org (Jorn Vernee) Date: Mon, 26 Feb 2024 19:17:57 GMT Subject: RFR: 8326172: Dubious claim on long[]/double[] alignment in MemorySegment javadoc [v2] In-Reply-To: References: Message-ID: On Mon, 26 Feb 2024 19:10:39 GMT, Jorn Vernee wrote: >> test/jdk/java/foreign/TestLayouts.java line 164: >> >>> 162: ); >>> 163: assertEquals(struct.byteSize(), 1 + 1 + 2 + 4 + 8); >>> 164: assertEquals(struct.byteAlignment(), 8); >> >> Looking at this PR: >> https://github.com/openjdk/jdk/pull/18007 >> >> This test seemed to cover more case before that PR - e.g. a layout generator was tweaked to exclude long/doubles. I believe revert the test changes now? > > That doesn't seem to be the right PR link? Found the right one: https://github.com/openjdk/jdk/commit/44218b1c9e5daa33557aac9336251cf8398d81eb ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18007#discussion_r1503166930 From jvernee at openjdk.org Mon Feb 26 19:22:42 2024 From: jvernee at openjdk.org (Jorn Vernee) Date: Mon, 26 Feb 2024 19:22:42 GMT Subject: RFR: 8326172: Dubious claim on long[]/double[] alignment in MemorySegment javadoc [v2] In-Reply-To: References: Message-ID: On Mon, 26 Feb 2024 19:13:41 GMT, Jorn Vernee wrote: >> That doesn't seem to be the right PR link? > > Found the right one: https://github.com/openjdk/jdk/commit/44218b1c9e5daa33557aac9336251cf8398d81eb Switched back to using the old generator (and removed the newer one): https://github.com/openjdk/jdk/pull/18007/commits/fad15a66b68b07b8bb17fce3c4a7d8788ef44015 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18007#discussion_r1503174593 From dfuchs at openjdk.org Mon Feb 26 19:30:49 2024 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Mon, 26 Feb 2024 19:30:49 GMT Subject: RFR: 8320699: Add parameter to skip progress logging of OutputAnalyzer [v4] In-Reply-To: References: Message-ID: On Mon, 15 Jan 2024 08:36:43 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. > > Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: > > Update copyright years Hi Stefan - I see that this is an opt-in, so LGTM ------------- Marked as reviewed by dfuchs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16807#pullrequestreview-1901818783 From lancea at openjdk.org Mon Feb 26 19:45:43 2024 From: lancea at openjdk.org (Lance Andersen) Date: Mon, 26 Feb 2024 19:45:43 GMT Subject: RFR: 8326096: Deprecate getTotalIn, getTotalOut methods of java.util.zip.Inflater, java.util.zip.Deflater [v8] In-Reply-To: References: Message-ID: On Mon, 26 Feb 2024 14:29:19 GMT, Eirik Bj?rsn?s wrote: >> Please review this PR which proposes that we officially deprecate the following four methods in the `java.util.zip` package: >> >> * `Inflater.getTotalIn()` >> * `Inflater.getTotalOut()` >> * `Deflater.getTotalIn()` >> * `Deflater.getTotalOut()` >> >> Since these legacy methods return `int`, they cannot safely return the number of bytes processed without the risk of losing information about the magnitude or even sign of the returned value. >> >> The corresponding methods `getBytesRead()` and `getBytesWritten()` methods introduced in Java 5 return `long`, and should be used instead when obtaining this information. >> >> Unrelated to the deprecation itself, the documentation currently does not specify what these methods are expected to return when the number of processed bytes is higher than `Integer.MAX_VALUE`. This PR aims to clarify this in the API specification. >> >> Initally, this PR handles only `Inflater.getTotalIn()`. The other three methods will be updated once the wordsmithing for this method stabilizes. > > Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision: > > Reduce new method description text to one sentence Sorry for the delay, but finally had a chance to take a look at your proposed wording src/java.base/share/classes/java/util/zip/Inflater.java line 642: > 640: *

    > 641: * This method returns the equivalent of {@code (int) getBytesRead()} > 642: * and therefore cannot return the correct number of compressed bytes This sentence to me seems a bit hard to digest and you basically get the point across in the `@deprecated` message Perhaps add `@see getBytesRead` ------------- PR Review: https://git.openjdk.org/jdk/pull/17919#pullrequestreview-1901832690 PR Review Comment: https://git.openjdk.org/jdk/pull/17919#discussion_r1503191920 From alanb at openjdk.org Mon Feb 26 19:56:44 2024 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 26 Feb 2024 19:56:44 GMT Subject: RFR: 8326096: Deprecate getTotalIn, getTotalOut methods of java.util.zip.Inflater, java.util.zip.Deflater [v4] In-Reply-To: References: <3gTPWxpnS5VRTXK4P1gNtI5c-3BCL9OwR2FSHqZ9Nbo=.e0e49dc5-736a-4f7d-81a0-7a5e1fe9aa57@github.com> <87wbBmabvVXFLBmw3sAFKTU2BtHG2kxQG2kGvzrMC7Y=.bdb475dc-f235-4614-9c84-451e7e99db4f@github.com> Message-ID: On Mon, 26 Feb 2024 15:04:01 GMT, Eirik Bj?rsn?s wrote: > I'm wondering if the somewhat tedious "number of compressed bytes input so far" could be further simplified. Besides being a long repetition from the leading sentence, when used in this sentence, we actually mean to refer to the "actual, correct, real value", potentially different from the return value. The end of the sentence could be reduced to "and therefore cannot return the correct value when it is greater than {@link Integer#MAX_VALUE}" and it would be a bit shorter. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17919#issuecomment-1965139940 From lancea at openjdk.org Mon Feb 26 20:01:08 2024 From: lancea at openjdk.org (Lance Andersen) Date: Mon, 26 Feb 2024 20:01:08 GMT Subject: RFR: 8326687: Inconsistent use of "ZIP", "Zip" and "zip" in java.util.zip/jar zipfs javadoc Message-ID: This PR updates the javadoc and comments within java.util.zip/jar and zipfs module summary so that it is consistent with the use of "ZIP". In addition, open/src/java.base/share/classes/java/util/zip/package-info.java has been updated to point to the higher level location of the PKWARE APPNOTE.TXT has PKWare recently changed the direct path the the latest version of the spec. It is also worth noting that error messages were not updated as part of the PR and will be updated separately to keep the javadoc changes separate ------------- Commit messages: - Initial update for JDK-8326687 Changes: https://git.openjdk.org/jdk/pull/18011/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18011&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8326687 Stats: 113 lines in 9 files changed: 0 ins; 0 del; 113 mod Patch: https://git.openjdk.org/jdk/pull/18011.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18011/head:pull/18011 PR: https://git.openjdk.org/jdk/pull/18011 From ihse at openjdk.org Mon Feb 26 20:21:55 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 26 Feb 2024 20:21:55 GMT Subject: RFR: 8326583: Remove over-generalized DefineNativeToolchain solution [v3] In-Reply-To: References: Message-ID: > The idea of setting up general "toolchains" in the native build was good, but it turned out that we really only need a single toolchain, with a single twist: if it should use CC or CPP to link. This is better described by a specific argument to SetupNativeCompilation, LANG := C++ or LANG := C (the default). > > There is a single exception to this rule, and that is if we want to compile for the build platform rather than the target platform. (This is only done for adlc) To keep expressing this difference, introduce TARGET_TYPE := BUILD (or TARGET_TYPE := TARGET, the default). > > The final odd-case was the hack for building hsdis/bin on mingw. This can be resolved using direct variables to SetupNativeCompilation, instead of first creating a toolchain. > > Doing this refactoring will simplify the SetupNativeCompilation code, and make it much clearer if we use the C or C++ linker. Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: Rename LANG to LINK_TYPE ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17986/files - new: https://git.openjdk.org/jdk/pull/17986/files/f8a18690..5f446abd Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17986&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17986&range=01-02 Stats: 27 lines in 13 files changed: 0 ins; 0 del; 27 mod Patch: https://git.openjdk.org/jdk/pull/17986.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17986/head:pull/17986 PR: https://git.openjdk.org/jdk/pull/17986 From ihse at openjdk.org Mon Feb 26 20:21:55 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 26 Feb 2024 20:21:55 GMT Subject: RFR: 8326583: Remove over-generalized DefineNativeToolchain solution In-Reply-To: References: Message-ID: <2eorUGW4rI8MmbcbMAHrIHCm8cetjtaG87C6dyD_UgQ=.75c5ae8c-8ff9-4d0b-8031-66f51baffbbc@github.com> On Sat, 24 Feb 2024 06:04:40 GMT, Julian Waters wrote: >> The idea of setting up general "toolchains" in the native build was good, but it turned out that we really only need a single toolchain, with a single twist: if it should use CC or CPP to link. This is better described by a specific argument to SetupNativeCompilation, LANG := C++ or LANG := C (the default). >> >> There is a single exception to this rule, and that is if we want to compile for the build platform rather than the target platform. (This is only done for adlc) To keep expressing this difference, introduce TARGET_TYPE := BUILD (or TARGET_TYPE := TARGET, the default). >> >> The final odd-case was the hack for building hsdis/bin on mingw. This can be resolved using direct variables to SetupNativeCompilation, instead of first creating a toolchain. >> >> Doing this refactoring will simplify the SetupNativeCompilation code, and make it much clearer if we use the C or C++ linker. > > !!! > > Not to be a party pooper, but this seems like it removes pretty some useful functionality from the build system. What if this is needed down the line? On the motivation of this change, TOOLCHAIN_LINK_CXX is pretty clear that the linker to be used is g++ instead of gcc for instance, while the new LANG parameter makes it look like SetupNativeCompilation only accepts and compiles C++ files if C++ is passed, and only C files if the new default of C is passed (For anyone looking in on this Pull Request who isn't familiar with the build system, it can compile a mix of both without issue). I'm not particularly sure this is a good idea, since a lot of flexibility seems to be lost with this change. I don't seem to see any simplification to SetupNativeCompilation either, maybe I'm missing something? I renamed LANG to LINK_TYPE, to not make it overly general. @TheShermanTanker Are you okay with this patch now? ------------- PR Comment: https://git.openjdk.org/jdk/pull/17986#issuecomment-1965176131 From jiangli at openjdk.org Mon Feb 26 20:25:52 2024 From: jiangli at openjdk.org (Jiangli Zhou) Date: Mon, 26 Feb 2024 20:25:52 GMT Subject: RFR: 8326433: Make libjdwp and libjava closeDescriptors() as static function Message-ID: Please help review this trivial fix for resolving `ld: error: duplicate symbol: closeDescriptors` when static linking with both libjdwp and libjava, thanks. ------------- Commit messages: - Make closeDescriptors() as static function in src/java.base/unix/native/libjava/childproc.c and src/jdk.jdwp.agent/unix/native/libjdwp/exec_md.c. Changes: https://git.openjdk.org/jdk/pull/18013/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18013&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8326433 Stats: 3 lines in 3 files changed: 0 ins; 1 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/18013.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18013/head:pull/18013 PR: https://git.openjdk.org/jdk/pull/18013 From cjplummer at openjdk.org Mon Feb 26 20:43:45 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Mon, 26 Feb 2024 20:43:45 GMT Subject: RFR: 8326433: Make libjdwp and libjava closeDescriptors() as static function In-Reply-To: References: Message-ID: On Mon, 26 Feb 2024 20:20:31 GMT, Jiangli Zhou wrote: > Please help review this trivial fix for resolving `ld: error: duplicate symbol: closeDescriptors` when static linking with both libjdwp and libjava, thanks. src/java.base/unix/native/libjava/childproc.h line 134: > 132: int closeSafely(int fd); > 133: int isAsciiDigit(char c); > 134: int closeDescriptors(void); It seems that most of the APIs in this file should be static. I don't think you should selectively deal with just one of them because of the conflict. Since this ends up being a more involved change, and is in a different component than the jdwp change, it should probably have a separate PR. src/jdk.jdwp.agent/unix/native/libjdwp/exec_md.c line 65: > 63: // by this function. This function returns 0 on failure > 64: // and 1 on success. > 65: static int I think you should also make forkedChildProcess static. It was added at the same time. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18013#discussion_r1503271560 PR Review Comment: https://git.openjdk.org/jdk/pull/18013#discussion_r1503268736 From eirbjo at openjdk.org Mon Feb 26 20:46:01 2024 From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=) Date: Mon, 26 Feb 2024 20:46:01 GMT Subject: RFR: 8326096: Deprecate getTotalIn, getTotalOut methods of java.util.zip.Inflater, java.util.zip.Deflater [v9] In-Reply-To: References: Message-ID: > Please review this PR which proposes that we officially deprecate the following four methods in the `java.util.zip` package: > > * `Inflater.getTotalIn()` > * `Inflater.getTotalOut()` > * `Deflater.getTotalIn()` > * `Deflater.getTotalOut()` > > Since these legacy methods return `int`, they cannot safely return the number of bytes processed without the risk of losing information about the magnitude or even sign of the returned value. > > The corresponding methods `getBytesRead()` and `getBytesWritten()` methods introduced in Java 5 return `long`, and should be used instead when obtaining this information. > > Unrelated to the deprecation itself, the documentation currently does not specify what these methods are expected to return when the number of processed bytes is higher than `Integer.MAX_VALUE`. This PR aims to clarify this in the API specification. > > Initally, this PR handles only `Inflater.getTotalIn()`. The other three methods will be updated once the wordsmithing for this method stabilizes. Eirik Bj?rsn?s has updated the pull request with a new target base 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: - Use "value" instead of "number of compressed bytes input so far" - Merge branch 'master' into deprecate-total-in-out - Reduce new method description text to one sentence - To align with the Java Language Specification, use "all but the 32 lowest order bits" - Use "highest order bits" instead of "highest bits" - Remove empty line - Add back a note to specify the long-standing behavior of discarding the highest 32 bits of the return value - Use "greater than" instead of "larger than" - Leave first sentence as-is. Simplify the deprecation notice. - Add since="23" to @Deprecated - ... and 2 more: https://git.openjdk.org/jdk/compare/ff8c99ba...8d80c776 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17919/files - new: https://git.openjdk.org/jdk/pull/17919/files/7e4d6e4d..8d80c776 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17919&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17919&range=07-08 Stats: 42811 lines in 1253 files changed: 20711 ins; 14092 del; 8008 mod Patch: https://git.openjdk.org/jdk/pull/17919.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17919/head:pull/17919 PR: https://git.openjdk.org/jdk/pull/17919 From eirbjo at openjdk.org Mon Feb 26 21:06:48 2024 From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=) Date: Mon, 26 Feb 2024 21:06:48 GMT Subject: RFR: 8326096: Deprecate getTotalIn, getTotalOut methods of java.util.zip.Inflater, java.util.zip.Deflater [v4] In-Reply-To: References: <3gTPWxpnS5VRTXK4P1gNtI5c-3BCL9OwR2FSHqZ9Nbo=.e0e49dc5-736a-4f7d-81a0-7a5e1fe9aa57@github.com> <87wbBmabvVXFLBmw3sAFKTU2BtHG2kxQG2kGvzrMC7Y=.bdb475dc-f235-4614-9c84-451e7e99db4f@github.com> Message-ID: On Mon, 26 Feb 2024 19:54:11 GMT, Alan Bateman wrote: > > I'm wondering if the somewhat tedious "number of compressed bytes input so far" could be further simplified. Besides being a long repetition from the leading sentence, when used in this sentence, we actually mean to refer to the "actual, correct, real value", potentially different from the return value. > > The end of the sentence could be reduced to "and therefore cannot return the correct value when it is greater than {@link Integer#MAX_VALUE}" and it would be a bit shorter. Thanks Alan, I pushed this suggested change. Your input is welcome on my response to the comment from Lance above where folding the overflow specification into the `@deprecated` note. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17919#issuecomment-1965268619 From eirbjo at openjdk.org Mon Feb 26 21:06:50 2024 From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=) Date: Mon, 26 Feb 2024 21:06:50 GMT Subject: RFR: 8326096: Deprecate getTotalIn, getTotalOut methods of java.util.zip.Inflater, java.util.zip.Deflater [v8] In-Reply-To: References: Message-ID: <5LhdD1IeqqWpYCtZoslef54l6diH5V3Okb3TooCuRbQ=.ad378d9a-97d8-4313-8d6b-2c4cc5b95469@github.com> On Mon, 26 Feb 2024 19:35:26 GMT, Lance Andersen wrote: > This sentence to me seems a bit hard to digest and you basically get the point across in the `@deprecated` message This new text was added after a discussion with Alan (see above) concluded that the method should specify its behavior when the number exceeds Integer.MAX_VALUE. Currently it's not possible for the reader to know if the value is clamped to Integer.MAX_VALUE or if bits are discareded. We found the simplest way to specifiy the long standing behavior would be "returns the equivalent of {@code (int) getBytesRead()}" As you note, there is a good bit of overlap with the `@deprecated` note. One way to solve that would be to move the specification part of the sentence into the deprecation note and just drop this added sentence in the method specification. Are we allowed to have normative specification like this inside a deprecation note, or must this be specified in the outside the `@deprecated` note? The suggested javadoc would look like this: /** * Returns the total number of compressed bytes input so far. * * @deprecated This method returns the equivalent of * {@code (int) getBytesRead()} and therefore cannot return the * correct value when it is greater than {@link Integer#MAX_VALUE}. * Use {@link #getBytesRead()} instead. * * @return the total number of compressed bytes input so far */ ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17919#discussion_r1503292069 From naoto at openjdk.org Mon Feb 26 21:32:22 2024 From: naoto at openjdk.org (Naoto Sato) Date: Mon, 26 Feb 2024 21:32:22 GMT Subject: RFR: 8174269: Remove COMPAT locale data provider from JDK [v2] In-Reply-To: References: Message-ID: > This PR intends to remove the legacy `COMPAT` locale data from the JDK. The `COMPAT` locale data was introduced for applications' migratory purposes transitioning to `CLDR`. It is becoming a technical debt and now is the time to remove it (we've been emitting a warning at JVM startup since JDK21, if the app is using `COMPAT`). A corresponding CSR has also been drafted. Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: Update make/jdk/src/classes/build/tools/cldrconverter/CLDRConverter.java Co-authored-by: Andrey Turbanov ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17991/files - new: https://git.openjdk.org/jdk/pull/17991/files/f3db6099..270afef5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17991&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17991&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/17991.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17991/head:pull/17991 PR: https://git.openjdk.org/jdk/pull/17991 From naoto at openjdk.org Mon Feb 26 21:32:22 2024 From: naoto at openjdk.org (Naoto Sato) Date: Mon, 26 Feb 2024 21:32:22 GMT Subject: RFR: 8174269: Remove COMPAT locale data provider from JDK [v2] In-Reply-To: References: <-T_RAaAiyq9ZHn6kynwrZL4w3UHwq7ANs5xIRC5OOMI=.4e2c4392-c766-4d1c-ba0c-e85d28e377db@github.com> Message-ID: On Mon, 26 Feb 2024 16:39:29 GMT, Magnus Ihse Bursie wrote: >> Actually, as the file currently in the PR, it does not seem like it does anything at all, since we no longer create `_the.locale_resources`. Or... hm, without that file, `PREV_LOCALE_RESOURCES` will always be empty. I wonder what `$(filter-out $(PREV_LOCALE_RESOURCES), $(LOCALE_RESOURCES))` returns in that case. If it is empty, then this file does nothing. If it is `$(LOCALE_RESOURCES)`, then we will unconditionally rm the two files. >> >> I believe the original intention was to spot added or removed locale resources, and use that to trigger a re-generation. This does not seem to work at all anymore. Do we still need that kind of behavior? > > Oh, this is a rabbit hole. :-( > > I tried to figure out where `CLDRBaseLocaleDataMetaInfo.java` comes from; I could not see where we generated that file. Turns out it is created in `make/jdk/src/classes/build/tools/cldrconverter/ResourceBundleGenerator.java`, in the function `generateMetaInfo()`. I assume this is called as part of calling the CLDRConverter buildtool. But this is done in `make/modules/[java.base|jdk.localedata]/Gensrc.gmk`. So if we need to invalidate that build tool result, it should be done in these files. Thanks. Good points. As CLDR tool generates those files, `GensrcLocaleData.gmk` no longer seems necessary. I will remove it after I do some testings. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17991#discussion_r1503323383 From mcimadamore at openjdk.org Mon Feb 26 21:42:43 2024 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 26 Feb 2024 21:42:43 GMT Subject: RFR: 8326172: Dubious claim on long[]/double[] alignment in MemorySegment javadoc [v3] In-Reply-To: References: Message-ID: On Mon, 26 Feb 2024 19:17:56 GMT, Jorn Vernee wrote: >> This patch changes the alignment for `JAVA_LONG` and `JAVA_DOUBLE` to 8, regardless of the underlying platform. This means that atomic access modes work on memory segments wrapping `long[]` or `double[]`, as they already do when using `MethodHandless::arrayAccessVarHandle`. >> >> After discussion, we came to the conclusion that it is reasonable for the JDK to require the elements of a `long[]` and `double[]` to be 8 byte aligned. It is ultimately up to the JDK to set these requirements, which are for the VM to implement. >> >> I was seeing a stack overflow when running test/jdk/java/foreign/stackwalk/TestReentrantUpcalls.java on x86, so I've lowered the recursion to 50 (which is still more than enough I think). >> >> Testing: `jdk_foreign` on x64 Windows, x64 Windows + fallback linker, and x86 Linux (uses fallback linker) > > Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: > > re-widen test Marked as reviewed by mcimadamore (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/18007#pullrequestreview-1902076898 From mcimadamore at openjdk.org Mon Feb 26 21:42:43 2024 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 26 Feb 2024 21:42:43 GMT Subject: RFR: 8326172: Dubious claim on long[]/double[] alignment in MemorySegment javadoc [v2] In-Reply-To: References: Message-ID: On Mon, 26 Feb 2024 19:19:56 GMT, Jorn Vernee wrote: >> Found the right one: https://github.com/openjdk/jdk/commit/44218b1c9e5daa33557aac9336251cf8398d81eb > > Switched back to using the old generator (and removed the newer one): https://github.com/openjdk/jdk/pull/18007/commits/fad15a66b68b07b8bb17fce3c4a7d8788ef44015 Sorry, PR number was similar to this and got confused: https://github.com/openjdk/jdk/pull/14007 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18007#discussion_r1503333336 From valeriep at openjdk.org Mon Feb 26 21:50:45 2024 From: valeriep at openjdk.org (Valerie Peng) Date: Mon, 26 Feb 2024 21:50:45 GMT Subject: RFR: 8325506: Ensure randomness is only read from provided SecureRandom object [v4] In-Reply-To: References: Message-ID: On Sat, 17 Feb 2024 14:08:12 GMT, Weijun Wang wrote: >> Many crypto service classes require a `SecureRandom` object at initialization. This test goes through each of them and calculates (generate, encrypt, sign,...) twice with the same `SecureRandom` object and ensures the output is the same. > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > not not not Marked as reviewed by valeriep (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/17776#pullrequestreview-1902105900 From weijun at openjdk.org Mon Feb 26 21:55:48 2024 From: weijun at openjdk.org (Weijun Wang) Date: Mon, 26 Feb 2024 21:55:48 GMT Subject: Integrated: 8325506: Ensure randomness is only read from provided SecureRandom object In-Reply-To: References: Message-ID: <1AiRtHSqsZz22oxWXMGrCoyYftuafIvi9Sm1aznH3tQ=.3a5b4657-41d1-4dc5-8d65-af3c754105ad@github.com> On Thu, 8 Feb 2024 16:34:00 GMT, Weijun Wang wrote: > Many crypto service classes require a `SecureRandom` object at initialization. This test goes through each of them and calculates (generate, encrypt, sign,...) twice with the same `SecureRandom` object and ensures the output is the same. This pull request has now been integrated. Changeset: b87d9cf2 Author: Weijun Wang URL: https://git.openjdk.org/jdk/commit/b87d9cf2c9d905c15f4c957d42361b1a72974edf Stats: 551 lines in 6 files changed: 546 ins; 0 del; 5 mod 8325506: Ensure randomness is only read from provided SecureRandom object Reviewed-by: kdriver, valeriep ------------- PR: https://git.openjdk.org/jdk/pull/17776 From jiangli at openjdk.org Mon Feb 26 22:17:44 2024 From: jiangli at openjdk.org (Jiangli Zhou) Date: Mon, 26 Feb 2024 22:17:44 GMT Subject: RFR: 8326433: Make libjdwp and libjava closeDescriptors() as static function In-Reply-To: References: Message-ID: <98_cLDcnNTDPzP2XGeGaGvHaafDylPmPL5BXEjOBaNk=.04a2af67-002f-4032-a020-5abd15321eba@github.com> On Mon, 26 Feb 2024 20:40:52 GMT, Chris Plummer wrote: >> Please help review this trivial fix for resolving `ld: error: duplicate symbol: closeDescriptors` when static linking with both libjdwp and libjava, thanks. > > src/java.base/unix/native/libjava/childproc.h line 134: > >> 132: int closeSafely(int fd); >> 133: int isAsciiDigit(char c); >> 134: int closeDescriptors(void); > > It seems that most of the APIs in this file should be static. I don't think you should selectively deal with just one of them because of the conflict. Since this ends up being a more involved change, and is in a different component than the jdwp change, it should probably have a separate PR. @plummercj thanks for looking into this! Sounds good to make the additional local functions static in these files. Perhaps we can use two different FRs. I'll make the current one to handle the ones in src/jdk.jdwp.agent/unix/native/libjdwp/exec_md.c. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18013#discussion_r1503379848 From jlu at openjdk.org Mon Feb 26 22:29:56 2024 From: jlu at openjdk.org (Justin Lu) Date: Mon, 26 Feb 2024 22:29:56 GMT Subject: RFR: JDK-8325898: ChoiceFormat returns erroneous result when formatting bad pattern [v6] In-Reply-To: References: Message-ID: > Please review this PR which handles an edge case pattern bug with ChoiceFormat. > > > var d = new ChoiceFormat("0#foo|1#bar|baz|") // creates cFmt equivalent to "0.0#foo|1.0#bar|1.0#" > d.format(1) // unexpectedly returns "" > > > Not only does this lead to faulty formatting results, but breaks the ChoiceFormat class invariant of duplicate limits. > > It would have been preferable if either an exception was thrown when the ChoiceFormat was initially created, or the ChoiceFormat formatting 1 returned a value of "bar". > > For comparison, > > var d = new ChoiceFormat("0#foo|1#bar|baz") // creates cFmt equivalent to "0.0#foo|1.0#bar" > d.format(1) // returns "bar" > > > After this change, the first code snippet now returns "bar" when formatting 1 and discards the "baz" as the second code snippet does. > > The fix prevents a limit/format entry from being built when the current parsing mode has not yet processed the limit and relation. The previous implementation would build an additional limit/format of 1 with an empty string. The `break` allows for the discarding of the incorrect portion and continuing. Alternatively an exception could have been thrown. For consistency with the second code snippet, the former was picked. > > https://github.com/openjdk/jdk/pull/17856 may be of interest, which is a semi-related specification fix. Justin Lu has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision: - ammend comment on parsing - Merge branch 'master' into JDK-8325898-ChoiceFormat-trailingPipeBug - use enhanced switch in stringToNum - revert enum change - improve variable name for StringBuilder - null check at public level. spacing adjustment. - add additional longer test case - shorten relational symbol in format comment - preserve final modifier for next/previousDouble - reduce visibility of Segment enum - ... and 1 more: https://git.openjdk.org/jdk/compare/f8638598...05051975 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17883/files - new: https://git.openjdk.org/jdk/pull/17883/files/de38a988..05051975 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17883&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17883&range=04-05 Stats: 15147 lines in 427 files changed: 8844 ins; 3288 del; 3015 mod Patch: https://git.openjdk.org/jdk/pull/17883.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17883/head:pull/17883 PR: https://git.openjdk.org/jdk/pull/17883 From jiangli at openjdk.org Mon Feb 26 22:55:06 2024 From: jiangli at openjdk.org (Jiangli Zhou) Date: Mon, 26 Feb 2024 22:55:06 GMT Subject: RFR: 8326433: Make libjdwp and libjava closeDescriptors() as static function [v2] In-Reply-To: References: Message-ID: > Please help review this trivial fix for resolving `ld: error: duplicate symbol: closeDescriptors` when static linking with both libjdwp and libjava, thanks. Jiangli Zhou has updated the pull request incrementally with two additional commits since the last revision: - Address plummercj's comment and make forkedChildProcess static. - Revert src/java.base/unix/native/libjava/childproc.c and src/java.base/unix/native/libjava/childproc.h. Will handle those with JDK-8326714. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/18013/files - new: https://git.openjdk.org/jdk/pull/18013/files/bb9e2791..3816d315 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=18013&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18013&range=00-01 Stats: 3 lines in 3 files changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/18013.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18013/head:pull/18013 PR: https://git.openjdk.org/jdk/pull/18013 From jiangli at openjdk.org Mon Feb 26 22:58:43 2024 From: jiangli at openjdk.org (Jiangli Zhou) Date: Mon, 26 Feb 2024 22:58:43 GMT Subject: RFR: 8326433: Make file-local functions static in src/jdk.jdwp.agent/unix/native/libjdwp/exec_md.c [v2] In-Reply-To: <98_cLDcnNTDPzP2XGeGaGvHaafDylPmPL5BXEjOBaNk=.04a2af67-002f-4032-a020-5abd15321eba@github.com> References: <98_cLDcnNTDPzP2XGeGaGvHaafDylPmPL5BXEjOBaNk=.04a2af67-002f-4032-a020-5abd15321eba@github.com> Message-ID: On Mon, 26 Feb 2024 22:15:00 GMT, Jiangli Zhou wrote: >> src/java.base/unix/native/libjava/childproc.h line 134: >> >>> 132: int closeSafely(int fd); >>> 133: int isAsciiDigit(char c); >>> 134: int closeDescriptors(void); >> >> It seems that most of the APIs in this file should be static. I don't think you should selectively deal with just one of them because of the conflict. Since this ends up being a more involved change, and is in a different component than the jdwp change, it should probably have a separate PR. > > @plummercj thanks for looking into this! Sounds good to make the additional local functions static in these files. Perhaps we can use two different FRs. I'll make the current one to handle the ones in src/jdk.jdwp.agent/unix/native/libjdwp/exec_md.c. Filed https://bugs.openjdk.org/browse/JDK-8326714. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18013#discussion_r1503414392 From jiangli at openjdk.org Mon Feb 26 22:58:44 2024 From: jiangli at openjdk.org (Jiangli Zhou) Date: Mon, 26 Feb 2024 22:58:44 GMT Subject: RFR: 8326433: Make file-local functions static in src/jdk.jdwp.agent/unix/native/libjdwp/exec_md.c [v2] In-Reply-To: References: Message-ID: <2XXTCSfcAFMbMU0_f5i-dxfuga6rONV-ISqR0pptHzE=.06d2a47e-0b9a-4085-94cf-bc4d63019395@github.com> On Mon, 26 Feb 2024 20:37:45 GMT, Chris Plummer wrote: >> Jiangli Zhou has updated the pull request incrementally with two additional commits since the last revision: >> >> - Address plummercj's comment and make forkedChildProcess static. >> - Revert src/java.base/unix/native/libjava/childproc.c and src/java.base/unix/native/libjava/childproc.h. Will handle those with JDK-8326714. > > src/jdk.jdwp.agent/unix/native/libjdwp/exec_md.c line 65: > >> 63: // by this function. This function returns 0 on failure >> 64: // and 1 on success. >> 65: static int > > I think you should also make forkedChildProcess static. It was added at the same time. Updated. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18013#discussion_r1503414683 From naoto at openjdk.org Mon Feb 26 23:37:16 2024 From: naoto at openjdk.org (Naoto Sato) Date: Mon, 26 Feb 2024 23:37:16 GMT Subject: RFR: 8174269: Remove COMPAT locale data provider from JDK [v3] In-Reply-To: References: Message-ID: > This PR intends to remove the legacy `COMPAT` locale data from the JDK. The `COMPAT` locale data was introduced for applications' migratory purposes transitioning to `CLDR`. It is becoming a technical debt and now is the time to remove it (we've been emitting a warning at JVM startup since JDK21, if the app is using `COMPAT`). A corresponding CSR has also been drafted. Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: Remove `GensrcLocaleData.gmk` ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17991/files - new: https://git.openjdk.org/jdk/pull/17991/files/270afef5..f68df434 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17991&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17991&range=01-02 Stats: 71 lines in 3 files changed: 0 ins; 70 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/17991.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17991/head:pull/17991 PR: https://git.openjdk.org/jdk/pull/17991 From jlu at openjdk.org Mon Feb 26 23:46:46 2024 From: jlu at openjdk.org (Justin Lu) Date: Mon, 26 Feb 2024 23:46:46 GMT Subject: Integrated: JDK-8325898: ChoiceFormat returns erroneous result when formatting bad pattern In-Reply-To: References: Message-ID: On Thu, 15 Feb 2024 19:44:42 GMT, Justin Lu wrote: > Please review this PR which handles an edge case pattern bug with ChoiceFormat. > > > var d = new ChoiceFormat("0#foo|1#bar|baz|") // creates cFmt equivalent to "0.0#foo|1.0#bar|1.0#" > d.format(1) // unexpectedly returns "" > > > Not only does this lead to faulty formatting results, but breaks the ChoiceFormat class invariant of duplicate limits. > > It would have been preferable if either an exception was thrown when the ChoiceFormat was initially created, or the ChoiceFormat formatting 1 returned a value of "bar". > > For comparison, > > var d = new ChoiceFormat("0#foo|1#bar|baz") // creates cFmt equivalent to "0.0#foo|1.0#bar" > d.format(1) // returns "bar" > > > After this change, the first code snippet now returns "bar" when formatting 1 and discards the "baz" as the second code snippet does. > > The fix prevents a limit/format entry from being built when the current parsing mode has not yet processed the limit and relation. The previous implementation would build an additional limit/format of 1 with an empty string. The `break` allows for the discarding of the incorrect portion and continuing. Alternatively an exception could have been thrown. For consistency with the second code snippet, the former was picked. > > https://github.com/openjdk/jdk/pull/17856 may be of interest, which is a semi-related specification fix. This pull request has now been integrated. Changeset: d22d890c Author: Justin Lu URL: https://git.openjdk.org/jdk/commit/d22d890cac3c2c27f89445c65a91909c9cb8f9ad Stats: 206 lines in 2 files changed: 94 ins; 91 del; 21 mod 8325898: ChoiceFormat returns erroneous result when formatting bad pattern Reviewed-by: naoto ------------- PR: https://git.openjdk.org/jdk/pull/17883 From cjplummer at openjdk.org Mon Feb 26 23:52:44 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Mon, 26 Feb 2024 23:52:44 GMT Subject: RFR: 8326433: Make file-local functions static in src/jdk.jdwp.agent/unix/native/libjdwp/exec_md.c [v2] In-Reply-To: References: Message-ID: On Mon, 26 Feb 2024 22:55:06 GMT, Jiangli Zhou wrote: >> Please help review this trivial fix for resolving `ld: error: duplicate symbol: closeDescriptors` when static linking with both libjdwp and libjava, thanks. > > Jiangli Zhou has updated the pull request incrementally with two additional commits since the last revision: > > - Address plummercj's comment and make forkedChildProcess static. > - Revert src/java.base/unix/native/libjava/childproc.c and src/java.base/unix/native/libjava/childproc.h. Will handle those with JDK-8326714. Looks good. ------------- Marked as reviewed by cjplummer (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/18013#pullrequestreview-1902255565 From jlu at openjdk.org Mon Feb 26 23:56:46 2024 From: jlu at openjdk.org (Justin Lu) Date: Mon, 26 Feb 2024 23:56:46 GMT Subject: RFR: 8174269: Remove COMPAT locale data provider from JDK [v3] In-Reply-To: References: Message-ID: <095k-M23L8vXjgo9GHoobMhjDXFi3OXbhUEOhRCVKu4=.4a004e22-d5a8-4a7e-b73f-875078dd5239@github.com> On Mon, 26 Feb 2024 23:37:16 GMT, Naoto Sato wrote: >> This PR intends to remove the legacy `COMPAT` locale data from the JDK. The `COMPAT` locale data was introduced for applications' migratory purposes transitioning to `CLDR`. It is becoming a technical debt and now is the time to remove it (we've been emitting a warning at JVM startup since JDK21, if the app is using `COMPAT`). A corresponding CSR has also been drafted. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Remove `GensrcLocaleData.gmk` Still working on getting a better understanding of all the parts here, but left some initial comments. src/java.base/share/classes/java/util/Locale.java line 57: > 55: import jdk.internal.vm.annotation.Stable; > 56: > 57: import sun.security.action.GetPropertyAction; Although trivial change, not sure if the file needs a copyright year bump; not exactly sure on the policy here. src/java.base/share/classes/sun/util/locale/provider/FallbackLocaleProviderAdapter.java line 86: > 84: @Override > 85: // In order to correctly report supported locales > 86: public BreakIteratorProvider getBreakIteratorProvider() { More for my understanding but I am curious why FallbackLocaleProviderAdapter has to override `getBreakIteratorProvider`, but can rely on the `getCollatorProvider` from JRELocaleProviderAdapter? Also wondering why "BreakIteratorRules" is fetched when JRELocaleProviderAdapter fetches "FormatData" if the data is the same COMPAT data. test/jdk/java/text/Format/DateFormat/Bug6683975.java line 27: > 25: * @test > 26: * @bug 6683975 8008577 8174269 > 27: * @summary Make sure that date is formatted correctlyin th locale. not your change and typo doc nit, but, Suggestion: * @summary Make sure that date is formatted correctly in th locale. test/jdk/java/text/Format/NumberFormat/CurrencyFormat.java line 30: > 28: * Tests both COMPAT and CLDR data. > 29: * @modules jdk.localedata > 30: * @run junit/othervm -Djava.locale.providers=COMPAT CurrencyFormat The methods `currencySymbolsTest`, `currencySymbolsDataProvider`, and `getFutureSymbol` can be removed since they are for COMPAT only. The string array `expectedCOMPATData` can be removed from the data provider method `currencyFormatDataProvider` as well as `isCompat` variable and usage. _CurrencySymbols.properties_ can also be deleted since that is what `currencySymbolsDataProvider` uses to build the data and no other tests rely on the file. ------------- PR Review: https://git.openjdk.org/jdk/pull/17991#pullrequestreview-1901683460 PR Review Comment: https://git.openjdk.org/jdk/pull/17991#discussion_r1503317351 PR Review Comment: https://git.openjdk.org/jdk/pull/17991#discussion_r1503375503 PR Review Comment: https://git.openjdk.org/jdk/pull/17991#discussion_r1503301324 PR Review Comment: https://git.openjdk.org/jdk/pull/17991#discussion_r1503105517 From jlu at openjdk.org Mon Feb 26 23:56:48 2024 From: jlu at openjdk.org (Justin Lu) Date: Mon, 26 Feb 2024 23:56:48 GMT Subject: RFR: 8174269: Remove COMPAT locale data provider from JDK [v2] In-Reply-To: References: Message-ID: On Mon, 26 Feb 2024 21:32:22 GMT, Naoto Sato wrote: >> This PR intends to remove the legacy `COMPAT` locale data from the JDK. The `COMPAT` locale data was introduced for applications' migratory purposes transitioning to `CLDR`. It is becoming a technical debt and now is the time to remove it (we've been emitting a warning at JVM startup since JDK21, if the app is using `COMPAT`). A corresponding CSR has also been drafted. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Update make/jdk/src/classes/build/tools/cldrconverter/CLDRConverter.java > > Co-authored-by: Andrey Turbanov test/jdk/java/util/Locale/CompatWarning.java line 28: > 26: * @bug 8304982 8174269 > 27: * @summary Check if a warning is logged with COMPAT locale provider > 28: * @run main/othervm -Djava.locale.providers=COMPAT CompatWarning Is it worth adding runs with COMPAT specified with other providers (both before and/or after) for coverage sake. Such as `@run main/othervm -Djava.locale.providers=SPI,COMPAT CompatWarning`. test/jdk/java/util/Locale/ExpectedAdapterTypes.java line 27: > 25: * @test > 26: * @bug 8008577 8138613 8174269 > 27: * @summary Check whether CLDR locale provider adapter is enabled by default Unless I'm mistaken, there aren't any other dedicated tests to ensuring the FALLBACK adapter is included, it might be worth updating the summary to make it apparent that while the default preference list has CLDR, _FALLBACK_ is always appended, since that is new behavior. test/jdk/java/util/Locale/LocaleProvidersFormat.java line 80: > 78: @Test > 79: @EnabledOnOs(WINDOWS) > 80: @EnabledIfSystemProperty(named = "user.language", matches = "ja") Thanks for fixing, as it is `HOST` the locale value should be based on the machine at startup. Although, I'm wondering how the test passed previously then. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17991#discussion_r1503399036 PR Review Comment: https://git.openjdk.org/jdk/pull/17991#discussion_r1503401752 PR Review Comment: https://git.openjdk.org/jdk/pull/17991#discussion_r1503397390 From jiangli at openjdk.org Mon Feb 26 23:59:45 2024 From: jiangli at openjdk.org (Jiangli Zhou) Date: Mon, 26 Feb 2024 23:59:45 GMT Subject: RFR: 8326433: Make file-local functions static in src/jdk.jdwp.agent/unix/native/libjdwp/exec_md.c [v2] In-Reply-To: References: Message-ID: On Mon, 26 Feb 2024 23:50:11 GMT, Chris Plummer wrote: > Looks good. Thanks for the quick review, @plummercj. ------------- PR Comment: https://git.openjdk.org/jdk/pull/18013#issuecomment-1965539618 From naoto at openjdk.org Tue Feb 27 00:20:39 2024 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 27 Feb 2024 00:20:39 GMT Subject: RFR: 8174269: Remove COMPAT locale data provider from JDK [v4] In-Reply-To: References: Message-ID: > This PR intends to remove the legacy `COMPAT` locale data from the JDK. The `COMPAT` locale data was introduced for applications' migratory purposes transitioning to `CLDR`. It is becoming a technical debt and now is the time to remove it (we've been emitting a warning at JVM startup since JDK21, if the app is using `COMPAT`). A corresponding CSR has also been drafted. Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: Update test/jdk/java/text/Format/DateFormat/Bug6683975.java Co-authored-by: Justin Lu ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17991/files - new: https://git.openjdk.org/jdk/pull/17991/files/f68df434..a75637f2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17991&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17991&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/17991.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17991/head:pull/17991 PR: https://git.openjdk.org/jdk/pull/17991 From naoto at openjdk.org Tue Feb 27 00:24:08 2024 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 27 Feb 2024 00:24:08 GMT Subject: RFR: 8174269: Remove COMPAT locale data provider from JDK [v5] In-Reply-To: References: Message-ID: <5oS5x968YgpeRo6Bf6SQGnPvgLONaDi5hl7fRkeqYbg=.7f120d7c-6719-4a0e-97b8-823eccd0f809@github.com> > This PR intends to remove the legacy `COMPAT` locale data from the JDK. The `COMPAT` locale data was introduced for applications' migratory purposes transitioning to `CLDR`. It is becoming a technical debt and now is the time to remove it (we've been emitting a warning at JVM startup since JDK21, if the app is using `COMPAT`). A corresponding CSR has also been drafted. Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: Addressing review comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17991/files - new: https://git.openjdk.org/jdk/pull/17991/files/a75637f2..d5953788 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17991&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17991&range=03-04 Stats: 232 lines in 4 files changed: 4 ins; 226 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/17991.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17991/head:pull/17991 PR: https://git.openjdk.org/jdk/pull/17991 From naoto at openjdk.org Tue Feb 27 00:31:47 2024 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 27 Feb 2024 00:31:47 GMT Subject: RFR: 8174269: Remove COMPAT locale data provider from JDK [v5] In-Reply-To: <095k-M23L8vXjgo9GHoobMhjDXFi3OXbhUEOhRCVKu4=.4a004e22-d5a8-4a7e-b73f-875078dd5239@github.com> References: <095k-M23L8vXjgo9GHoobMhjDXFi3OXbhUEOhRCVKu4=.4a004e22-d5a8-4a7e-b73f-875078dd5239@github.com> Message-ID: On Mon, 26 Feb 2024 22:11:31 GMT, Justin Lu wrote: >> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: >> >> Addressing review comments > > src/java.base/share/classes/sun/util/locale/provider/FallbackLocaleProviderAdapter.java line 86: > >> 84: @Override >> 85: // In order to correctly report supported locales >> 86: public BreakIteratorProvider getBreakIteratorProvider() { > > More for my understanding but I am curious why FallbackLocaleProviderAdapter has to override `getBreakIteratorProvider`, but can rely on the `getCollatorProvider` from JRELocaleProviderAdapter? Also wondering why "BreakIteratorRules" is fetched when JRELocaleProviderAdapter fetches "FormatData" if the data is the same COMPAT data. `COMPAT` used to offer supported locales for the ones that exist as resource bundles. For `Collator`, `JRELocaleProviderAdapter` had a list for `CollationData` resource bundles, but `BreakIterator` shared with `FormatData`, which now only has root/en/ja (for Gan-nen support). So it had to override the method and return `th` (this is the main function for `BreakIterator` as of now) > test/jdk/java/text/Format/NumberFormat/CurrencyFormat.java line 30: > >> 28: * Tests both COMPAT and CLDR data. >> 29: * @modules jdk.localedata >> 30: * @run junit/othervm -Djava.locale.providers=COMPAT CurrencyFormat > > The methods `currencySymbolsTest`, `currencySymbolsDataProvider`, and `getFutureSymbol` can be removed since they are for COMPAT only. > > The string array `expectedCOMPATData` can be removed from the data provider method `currencyFormatDataProvider` as well as `isCompat` variable and usage. > > _CurrencySymbols.properties_ can also be deleted since that is what `currencySymbolsDataProvider` uses to build the data and no other tests rely on the file. Good catch! Removed `COMPAT` related tests/data. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17991#discussion_r1503478694 PR Review Comment: https://git.openjdk.org/jdk/pull/17991#discussion_r1503478605 From naoto at openjdk.org Tue Feb 27 00:31:49 2024 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 27 Feb 2024 00:31:49 GMT Subject: RFR: 8174269: Remove COMPAT locale data provider from JDK [v2] In-Reply-To: References: Message-ID: <7N_bnofe_S9KafqXU1y4vHCDBuw-HwAaOoh93jHq46k=.1e8271d7-9a48-4b68-acb0-55ae104c1c56@github.com> On Mon, 26 Feb 2024 22:38:50 GMT, Justin Lu wrote: >> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: >> >> Update make/jdk/src/classes/build/tools/cldrconverter/CLDRConverter.java >> >> Co-authored-by: Andrey Turbanov > > test/jdk/java/util/Locale/ExpectedAdapterTypes.java line 27: > >> 25: * @test >> 26: * @bug 8008577 8138613 8174269 >> 27: * @summary Check whether CLDR locale provider adapter is enabled by default > > Unless I'm mistaken, there aren't any other dedicated tests to ensuring the FALLBACK adapter is included, it might be worth updating the summary to make it apparent that while the default preference list has CLDR, _FALLBACK_ is always appended, since that is new behavior. I believe some tests will break if `FALLBACK` is not included in the preferred list. I am kind of hesitant to specify it in the command line for the sake of testing, as it is not a public constant. > test/jdk/java/util/Locale/LocaleProvidersFormat.java line 80: > >> 78: @Test >> 79: @EnabledOnOs(WINDOWS) >> 80: @EnabledIfSystemProperty(named = "user.language", matches = "ja") > > Thanks for fixing, as it is `HOST` the locale value should be based on the machine at startup. Although, I'm wondering how the test passed previously then. Right, it only works if the underlying machine is configured with ja locale as the default. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17991#discussion_r1503478795 PR Review Comment: https://git.openjdk.org/jdk/pull/17991#discussion_r1503478741 From sspitsyn at openjdk.org Tue Feb 27 00:37:46 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 27 Feb 2024 00:37:46 GMT Subject: RFR: 8326433: Make file-local functions static in src/jdk.jdwp.agent/unix/native/libjdwp/exec_md.c [v2] In-Reply-To: References: Message-ID: On Mon, 26 Feb 2024 22:55:06 GMT, Jiangli Zhou wrote: >> Please help review this trivial fix for resolving `ld: error: duplicate symbol: closeDescriptors` when static linking with both libjdwp and libjava, thanks. > > Jiangli Zhou has updated the pull request incrementally with two additional commits since the last revision: > > - Address plummercj's comment and make forkedChildProcess static. > - Revert src/java.base/unix/native/libjava/childproc.c and src/java.base/unix/native/libjava/childproc.h. Will handle those with JDK-8326714. Marked as reviewed by sspitsyn (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/18013#pullrequestreview-1902299044 From jiangli at openjdk.org Tue Feb 27 01:36:47 2024 From: jiangli at openjdk.org (Jiangli Zhou) Date: Tue, 27 Feb 2024 01:36:47 GMT Subject: RFR: 8326433: Make file-local functions static in src/jdk.jdwp.agent/unix/native/libjdwp/exec_md.c [v2] In-Reply-To: References: Message-ID: On Tue, 27 Feb 2024 00:34:49 GMT, Serguei Spitsyn wrote: >> Jiangli Zhou has updated the pull request incrementally with two additional commits since the last revision: >> >> - Address plummercj's comment and make forkedChildProcess static. >> - Revert src/java.base/unix/native/libjava/childproc.c and src/java.base/unix/native/libjava/childproc.h. Will handle those with JDK-8326714. > > Marked as reviewed by sspitsyn (Reviewer). Thanks for the review, @sspitsyn. ------------- PR Comment: https://git.openjdk.org/jdk/pull/18013#issuecomment-1965631861 From jiangli at openjdk.org Tue Feb 27 01:36:48 2024 From: jiangli at openjdk.org (Jiangli Zhou) Date: Tue, 27 Feb 2024 01:36:48 GMT Subject: Integrated: 8326433: Make file-local functions static in src/jdk.jdwp.agent/unix/native/libjdwp/exec_md.c In-Reply-To: References: Message-ID: On Mon, 26 Feb 2024 20:20:31 GMT, Jiangli Zhou wrote: > Please help review this trivial fix for resolving `ld: error: duplicate symbol: closeDescriptors` when static linking with both libjdwp and libjava, thanks. This pull request has now been integrated. Changeset: 0901dede Author: Jiangli Zhou URL: https://git.openjdk.org/jdk/commit/0901dedefe16afa3f7222723b3fec7a22d9df675 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8326433: Make file-local functions static in src/jdk.jdwp.agent/unix/native/libjdwp/exec_md.c Reviewed-by: cjplummer, sspitsyn ------------- PR: https://git.openjdk.org/jdk/pull/18013 From jbhateja at openjdk.org Tue Feb 27 02:47:13 2024 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Tue, 27 Feb 2024 02:47:13 GMT Subject: RFR: 8318650: Optimized subword gather for x86 targets. [v16] 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 using 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.5-10x 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. > > 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 comment resolutions. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16354/files - new: https://git.openjdk.org/jdk/pull/16354/files/2aa07b5a..b971fbb7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16354&range=15 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16354&range=14-15 Stats: 25 lines in 1 file changed: 7 ins; 6 del; 12 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 Tue Feb 27 02:47:13 2024 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Tue, 27 Feb 2024 02:47:13 GMT Subject: RFR: 8318650: Optimized subword gather for x86 targets. [v14] In-Reply-To: References: <2_lbsdRrWvzmMfwKAHyeZTWDGAonTIrl-pSTr2JmuRs=.c73d8a1b-acb6-49a0-8aa3-f25004af2c35@github.com> Message-ID: On Mon, 26 Feb 2024 15:05:24 GMT, Emanuel Peter wrote: >> I was referring to the various arrays as well above. I think it would be exactly more concise if you defined a local label in the loop body. > > Have you had a look at `C2_MacroAssembler::rtm_counters_update`? Correct, with each successive iteration label will be bound to a new offset within code blob, so moving it within loop is a good suggestion. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16354#discussion_r1503563390 From jbhateja at openjdk.org Tue Feb 27 02:56:47 2024 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Tue, 27 Feb 2024 02:56:47 GMT Subject: RFR: 8318650: Optimized subword gather for x86 targets. [v15] In-Reply-To: References: <4Ypl0g8qQVgHVBX0Wbh3rGWxeOAHifAakbMxngTvLHk=.351b6866-df83-4d71-ba94-be172896d6af@github.com> Message-ID: <0zK0b4VSTMyY-U1yrLv-fmYYKwP_MFFqfudfceAMoXw=.afe9441f-7818-46aa-9f65-c8e0537ec8be@github.com> On Mon, 26 Feb 2024 13:47:35 GMT, Emanuel Peter wrote: >> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: >> >> Review comments resolutions > > Reposting link to a conversation that is marked "resolved": > https://github.com/openjdk/jdk/pull/16354#discussion_r1502617942 Hi @eme64, Can you kindly run the latest patch though your test infrastructure. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16354#issuecomment-1965695629 From jiangli at openjdk.org Tue Feb 27 03:15:52 2024 From: jiangli at openjdk.org (Jiangli Zhou) Date: Tue, 27 Feb 2024 03:15:52 GMT Subject: RFR: 8326714: Make file-local functions static in src/java.base/unix/native/libjava/childproc.c Message-ID: Please help review this trivial change. This was branched from https://github.com/openjdk/jdk/pull/18013, based on discussion with @plummercj in https://github.com/openjdk/jdk/pull/18013 comments. Thanks ------------- Commit messages: - 8326714: Make file-local functions static in src/java.base/unix/native/libjava/childproc.c Changes: https://git.openjdk.org/jdk/pull/18019/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18019&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8326714 Stats: 20 lines in 2 files changed: 0 ins; 13 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/18019.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18019/head:pull/18019 PR: https://git.openjdk.org/jdk/pull/18019 From darcy at openjdk.org Tue Feb 27 03:51:56 2024 From: darcy at openjdk.org (Joe Darcy) Date: Tue, 27 Feb 2024 03:51:56 GMT Subject: RFR: JDK-8316708: Augment WorstCaseTests with more cases [v5] In-Reply-To: References: Message-ID: <8Kh6xmT5WCo6onYsiz8kOGMZEMh9HZ0jVUDdGKSmWIA=.5cb1a066-4e23-42b5-99ec-757501b896f6@github.com> > A new paper > > "Accuracy of Mathematical Functions in Single, Double, Double Extended, and Quadruple Precision" > by Brian Gladman, Vincenzo Innocente and Paul Zimmermann > https://members.loria.fr/PZimmermann/papers/accuracy.pdf > > details the inputs with generate the worst-case observed errors in different math library implementations. The FDLIBM-related worst cases should be added to the test suite. Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Expand fingerprinting to more StrictMath tests. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15879/files - new: https://git.openjdk.org/jdk/pull/15879/files/ee28a7f9..bfe31c64 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15879&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15879&range=03-04 Stats: 38 lines in 4 files changed: 32 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/15879.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15879/head:pull/15879 PR: https://git.openjdk.org/jdk/pull/15879 From darcy at openjdk.org Tue Feb 27 05:35:08 2024 From: darcy at openjdk.org (Joe Darcy) Date: Tue, 27 Feb 2024 05:35:08 GMT Subject: RFR: JDK-8316708: Augment WorstCaseTests with more cases [v6] In-Reply-To: References: Message-ID: > A new paper > > "Accuracy of Mathematical Functions in Single, Double, Double Extended, and Quadruple Precision" > by Brian Gladman, Vincenzo Innocente and Paul Zimmermann > https://members.loria.fr/PZimmermann/papers/accuracy.pdf > > details the inputs with generate the worst-case observed errors in different math library implementations. The FDLIBM-related worst cases should be added to the test suite. Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Update atan2 and hypot tests. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15879/files - new: https://git.openjdk.org/jdk/pull/15879/files/bfe31c64..7b8893c2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15879&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15879&range=04-05 Stats: 26 lines in 2 files changed: 24 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/15879.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15879/head:pull/15879 PR: https://git.openjdk.org/jdk/pull/15879 From liach at openjdk.org Tue Feb 27 06:01:49 2024 From: liach at openjdk.org (Chen Liang) Date: Tue, 27 Feb 2024 06:01:49 GMT Subject: RFR: 8325485: IncrementInstructions.of(int, int) is not storing the args [v2] In-Reply-To: References: Message-ID: <295MRH8AWQRAm0EQ5mM_qCEgogwwS7E2LAJwEmZshCg=.9c8f9b04-8f7f-4c84-909c-70dafcea3be8@github.com> On Fri, 9 Feb 2024 10:47:08 GMT, Adam Sotona wrote: >> ClassFile API provides two sets of instructions implementations (bound and unbound). >> Unbound implementation of `IncrementInstruction::constant` returns invalid value. >> This bug discovered a hole in the ClassFile API test coverage. >> >> This patch provides very simple fix of `IncrementInstruction` >> and more complex fix of the test framework to cover all unbound instruction with automated tests. >> >> The test framework fix includes correction of hash calculation of instructions in `ClassRecord` and >> two-pass transformation in `RebuildingTransformation`. Second pass has been added to discover bugs in unbound-to-unbound instruction conversions. >> >> Please review. >> >> Thanks, >> Adam > > Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: > > Update test/jdk/jdk/classfile/helpers/RebuildingTransformation.java > > Co-authored-by: Andrey Turbanov Marked as reviewed by liach (Author). ------------- PR Review: https://git.openjdk.org/jdk/pull/17770#pullrequestreview-1902582836 From darcy at openjdk.org Tue Feb 27 06:13:08 2024 From: darcy at openjdk.org (Joe Darcy) Date: Tue, 27 Feb 2024 06:13:08 GMT Subject: RFR: JDK-8316708: Augment WorstCaseTests with more cases [v7] In-Reply-To: References: Message-ID: <-AJofvZBHcqti2QDKRqA6BTxKBEPkOsgA_YjZ3wtFpI=.4b1d3a4d-d39e-4e80-bd41-a975817e0a9c@github.com> > A new paper > > "Accuracy of Mathematical Functions in Single, Double, Double Extended, and Quadruple Precision" > by Brian Gladman, Vincenzo Innocente and Paul Zimmermann > https://members.loria.fr/PZimmermann/papers/accuracy.pdf > > details the inputs with generate the worst-case observed errors in different math library implementations. The FDLIBM-related worst cases should be added to the test suite. Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Appease jcheck. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15879/files - new: https://git.openjdk.org/jdk/pull/15879/files/7b8893c2..de217d77 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15879&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15879&range=05-06 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/15879.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15879/head:pull/15879 PR: https://git.openjdk.org/jdk/pull/15879 From jbhateja at openjdk.org Tue Feb 27 07:12:47 2024 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Tue, 27 Feb 2024 07:12:47 GMT Subject: RFR: JDK-8320448 Accelerate IndexOf using AVX2 [v8] In-Reply-To: <0FJI4QE-PYy7kUh6b76dZ1jsGQRGP3yR9UhkRsX9U3g=.0900c557-97ce-4be0-829b-79cf007b39c2@github.com> References: <0FJI4QE-PYy7kUh6b76dZ1jsGQRGP3yR9UhkRsX9U3g=.0900c557-97ce-4be0-829b-79cf007b39c2@github.com> Message-ID: On Wed, 21 Feb 2024 15:51:21 GMT, Scott Gibbons wrote: >> Hi @asgibbons , >> >> I am getting following error with slowdebug build on Meteor Lake system. >> >> >> ERROR: Build failed for target 'images' in configuration 'linux-x86_64-server-slowdebug' (exit code 2) >> >> === Output from failing command(s) repeated here === >> * For target buildtools_create_symbols_javac__the.COMPILE_CREATE_SYMBOLS_batch: >> # >> # A fatal error has been detected by the Java Runtime Environment: >> # >> # Internal Error (/home/jatinbha/sandboxes/jdk-reviews/jdk/src/hotspot/share/asm/assembler.hpp:169), pid=237140, tid=237235 >> # assert(is_bound() || is_unused()) failed: Label was never bound to a location, but it was used as a jmp target >> # >> # JRE version: OpenJDK Runtime Environment (23.0) (slowdebug build 23-internal-adhoc.sdp.jdk) >> # Java VM: OpenJDK 64-Bit Server VM (slowdebug 23-internal-adhoc.sdp.jdk, mixed mode, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64) >> # Problematic frame: >> # V [libjvm.so+0x4c9e3e] Label::~Label()+0x5c >> # >> # Core dump will be written. Default location: Core dumps may be processed with "/usr/share/apport/apport -p%p -s%s -c%c -d%d -P%P -u%u -g%g -- %E" (or dumping to /home/jatinbha/sandboxes/jdk-reviews/jdk/make/core.237140) >> # >> # An error report file with more information is saved as: >> # /home/jatinbha/sandboxes/jdk-reviews/jdk/make/hs_err_pid237140.log >> ... (rest of output omitted) > > @jatin-bhateja Thanks for the note. Fixed a couple of slowdebug compile issues. Now builds successfully on Meteor Lake system. Hi @asgibbons , I am still getting build errors with latest patch on a MeteorLake system. Kindly check ERROR: Build failed for target 'images' in configuration 'linux-x86_64-server-fastdebug' (exit code 2) === Output from failing command(s) repeated here === * For target buildtools_create_symbols_javac__the.COMPILE_CREATE_SYMBOLS_batch: # # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x00007f7220495dec, pid=530719, tid=530722 # # JRE version: OpenJDK Runtime Environment (23.0) (fastdebug build 23-internal-adhoc.root.jdk) # Java VM: OpenJDK 64-Bit Server VM (fastdebug 23-internal-adhoc.root.jdk, mixed mode, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64) # Problematic frame: # v ~StubRoutines::stringIndexOf 0x00007f7220495dec # # Core dump will be written. Default location: Core dumps may be processed with "/usr/share/apport/apport -p%p -s%s -c%c -d%d -P%P -u%u -g%g -- %E" (or dumping to /home/jatinbha/sandboxes/jdk-reviews/jdk/make/core.530719) # # An error report file with more information is saved as: # /home/jatinbha/sandboxes/jdk-reviews/jdk/make/hs_err_pid530719.log [5.638s][warning][os] Loading hsdis library failed ... (rest of output omitted) * All command lines available in /home/jatinbha/sandboxes/jdk-reviews/jdk/build/linux-x86_64-server-fastdebug/make-support/failure-logs. === End of repeated output === No indication of failed target found. HELP: Try searching the build log for '] Error'. HELP: Run 'make doctor' to diagnose build problems. make[1]: *** [/home/jatinbha/sandboxes/jdk-reviews/jdk/make/Init.gmk:323: main] Error 2 make: *** [/home/jatinbha/sandboxes/jdk-reviews/jdk/make/Init.gmk:189: images] Error 2 ------------- PR Comment: https://git.openjdk.org/jdk/pull/16753#issuecomment-1965916165 From djelinski at openjdk.org Tue Feb 27 07:32:44 2024 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Tue, 27 Feb 2024 07:32:44 GMT Subject: RFR: 8326714: Make file-local functions static in src/java.base/unix/native/libjava/childproc.c In-Reply-To: References: Message-ID: <9SdW0ASi8yNVMu3f4IEP9Y1vKFxFXVOBD0Js0BbXnuI=.1f36c0af-2a1b-47ae-92d1-13d612a36ebc@github.com> On Tue, 27 Feb 2024 03:11:37 GMT, Jiangli Zhou wrote: > Please help review this trivial change. This was branched from https://github.com/openjdk/jdk/pull/18013, based on discussion with @plummercj in https://github.com/openjdk/jdk/pull/18013 comments. Thanks LGTM ------------- Marked as reviewed by djelinski (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/18019#pullrequestreview-1902717059 From jwaters at openjdk.org Tue Feb 27 07:38:43 2024 From: jwaters at openjdk.org (Julian Waters) Date: Tue, 27 Feb 2024 07:38:43 GMT Subject: RFR: 8326583: Remove over-generalized DefineNativeToolchain solution [v3] In-Reply-To: References: Message-ID: On Mon, 26 Feb 2024 20:21:55 GMT, Magnus Ihse Bursie wrote: >> The idea of setting up general "toolchains" in the native build was good, but it turned out that we really only need a single toolchain, with a single twist: if it should use CC or CPP to link. This is better described by a specific argument to SetupNativeCompilation, LANG := C++ or LANG := C (the default). >> >> There is a single exception to this rule, and that is if we want to compile for the build platform rather than the target platform. (This is only done for adlc) To keep expressing this difference, introduce TARGET_TYPE := BUILD (or TARGET_TYPE := TARGET, the default). >> >> The final odd-case was the hack for building hsdis/bin on mingw. This can be resolved using direct variables to SetupNativeCompilation, instead of first creating a toolchain. >> >> Doing this refactoring will simplify the SetupNativeCompilation code, and make it much clearer if we use the C or C++ linker. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Rename LANG to LINK_TYPE Thanks for the run down on the history of the build system! I'm sorry it took me a day to respond, I must have missed this in my inbox while going over the GitHub activity of the day. Given that the function was meant for the older build system, it now seems reasonable to replace it with this newer solution. In the worst case scenario, a backout is possible, as was suggested. I would have said that LANG is an ok name and that there was no need to rename it to LINK_TYPE after the context given and the knowledge that future work was planned for it, had I read this earlier though :( This is also the first time I've ever had an objection to a Pull Request. Feels weird, really ------------- PR Comment: https://git.openjdk.org/jdk/pull/17986#issuecomment-1965949353 From djelinski at openjdk.org Tue Feb 27 08:10:44 2024 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Tue, 27 Feb 2024 08:10:44 GMT Subject: RFR: 8326583: Remove over-generalized DefineNativeToolchain solution [v3] In-Reply-To: References: Message-ID: On Mon, 26 Feb 2024 20:21:55 GMT, Magnus Ihse Bursie wrote: >> The idea of setting up general "toolchains" in the native build was good, but it turned out that we really only need a single toolchain, with a single twist: if it should use CC or CPP to link. This is better described by a specific argument to SetupNativeCompilation, LANG := C++ or LANG := C (the default). >> >> There is a single exception to this rule, and that is if we want to compile for the build platform rather than the target platform. (This is only done for adlc) To keep expressing this difference, introduce TARGET_TYPE := BUILD (or TARGET_TYPE := TARGET, the default). >> >> The final odd-case was the hack for building hsdis/bin on mingw. This can be resolved using direct variables to SetupNativeCompilation, instead of first creating a toolchain. >> >> Doing this refactoring will simplify the SetupNativeCompilation code, and make it much clearer if we use the C or C++ linker. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Rename LANG to LINK_TYPE can we get rid of LDCXX? On my system LDCXX is mapped to `g++` and LD is `gcc`; I searched for the differences, and the only thing I could find is that `g++` implicitly adds `-lstdc++ -shared-libgcc`; I suppose we could explicitly add these options, and use gcc everywhere. See: https://stackoverflow.com/a/172592 https://gcc.gnu.org/onlinedocs/gcc/Link-Options.html ------------- PR Comment: https://git.openjdk.org/jdk/pull/17986#issuecomment-1965991536 From jwaters at openjdk.org Tue Feb 27 08:17:46 2024 From: jwaters at openjdk.org (Julian Waters) Date: Tue, 27 Feb 2024 08:17:46 GMT Subject: RFR: 8326583: Remove over-generalized DefineNativeToolchain solution [v3] In-Reply-To: References: Message-ID: On Tue, 27 Feb 2024 08:07:38 GMT, Daniel Jeli?ski wrote: > can we get rid of LDCXX? On my system LDCXX is mapped to `g++` and LD is `gcc`; I searched for the differences, and the only thing I could find is that `g++` implicitly adds `-lstdc++ -shared-libgcc`; I suppose we could explicitly add these options, and use gcc everywhere. > > See: https://stackoverflow.com/a/172592 https://gcc.gnu.org/onlinedocs/gcc/Link-Options.html I don't think that's a good idea, the differences between the gcc and g++ drivers are supposed to be (opaque) implementation details. Doing so would make us dependent on internal mechanisms of gcc subject to change between versions and would make bugfixing hard to do if such a change really happened and the linker command line got messed up as a result (This likely would impact clang too, unless I am mistaken?) ------------- PR Comment: https://git.openjdk.org/jdk/pull/17986#issuecomment-1966002485 From jwaters at openjdk.org Tue Feb 27 08:32:45 2024 From: jwaters at openjdk.org (Julian Waters) Date: Tue, 27 Feb 2024 08:32:45 GMT Subject: RFR: 8326583: Remove over-generalized DefineNativeToolchain solution [v3] In-Reply-To: References: Message-ID: On Mon, 26 Feb 2024 20:21:55 GMT, Magnus Ihse Bursie wrote: >> The idea of setting up general "toolchains" in the native build was good, but it turned out that we really only need a single toolchain, with a single twist: if it should use CC or CPP to link. This is better described by a specific argument to SetupNativeCompilation, LANG := C++ or LANG := C (the default). >> >> There is a single exception to this rule, and that is if we want to compile for the build platform rather than the target platform. (This is only done for adlc) To keep expressing this difference, introduce TARGET_TYPE := BUILD (or TARGET_TYPE := TARGET, the default). >> >> The final odd-case was the hack for building hsdis/bin on mingw. This can be resolved using direct variables to SetupNativeCompilation, instead of first creating a toolchain. >> >> Doing this refactoring will simplify the SetupNativeCompilation code, and make it much clearer if we use the C or C++ linker. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Rename LANG to LINK_TYPE Just a small question by the way: All those new parameters to SetupNativeCompilation, were they always there and the comments about them were just missing from the documentation about the function? ------------- PR Comment: https://git.openjdk.org/jdk/pull/17986#issuecomment-1966025499 From alanb at openjdk.org Tue Feb 27 08:47:51 2024 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 27 Feb 2024 08:47:51 GMT Subject: RFR: 8326096: Deprecate getTotalIn, getTotalOut methods of java.util.zip.Inflater, java.util.zip.Deflater [v9] In-Reply-To: References: Message-ID: On Mon, 26 Feb 2024 20:46:01 GMT, Eirik Bj?rsn?s wrote: >> Please review this PR which proposes that we officially deprecate the following four methods in the `java.util.zip` package: >> >> * `Inflater.getTotalIn()` >> * `Inflater.getTotalOut()` >> * `Deflater.getTotalIn()` >> * `Deflater.getTotalOut()` >> >> Since these legacy methods return `int`, they cannot safely return the number of bytes processed without the risk of losing information about the magnitude or even sign of the returned value. >> >> The corresponding methods `getBytesRead()` and `getBytesWritten()` methods introduced in Java 5 return `long`, and should be used instead when obtaining this information. >> >> Unrelated to the deprecation itself, the documentation currently does not specify what these methods are expected to return when the number of processed bytes is higher than `Integer.MAX_VALUE`. This PR aims to clarify this in the API specification. >> >> Initally, this PR handles only `Inflater.getTotalIn()`. The other three methods will be updated once the wordsmithing for this method stabilizes. > > Eirik Bj?rsn?s has updated the pull request with a new target base 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: > > - Use "value" instead of "number of compressed bytes input so far" > - Merge branch 'master' into deprecate-total-in-out > - Reduce new method description text to one sentence > - To align with the Java Language Specification, use "all but the 32 lowest order bits" > - Use "highest order bits" instead of "highest bits" > - Remove empty line > - Add back a note to specify the long-standing behavior of discarding the highest 32 bits of the return value > - Use "greater than" instead of "larger than" > - Leave first sentence as-is. Simplify the deprecation notice. > - Add since="23" to @Deprecated > - ... and 2 more: https://git.openjdk.org/jdk/compare/285554fe...8d80c776 The change in [8d80c776] looks fine. If Lance is okay with it then I think go ahead and update the other methods too. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17919#issuecomment-1966049658 From asotona at openjdk.org Tue Feb 27 08:50:05 2024 From: asotona at openjdk.org (Adam Sotona) Date: Tue, 27 Feb 2024 08:50:05 GMT Subject: RFR: 8326744: Class-File API transition to Second Preview Message-ID: Task providing Class-File API transition to Second Preview. ------------- Commit messages: - 8326744: Class-File API transition to Second Preview Changes: https://git.openjdk.org/jdk/pull/18021/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18021&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8326744 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/18021.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18021/head:pull/18021 PR: https://git.openjdk.org/jdk/pull/18021 From vklang at openjdk.org Tue Feb 27 10:36:27 2024 From: vklang at openjdk.org (Viktor Klang) Date: Tue, 27 Feb 2024 10:36:27 GMT Subject: RFR: 8269428: java/util/concurrent/ConcurrentHashMap/ToArray.java timed out Message-ID: As an intermediate fix to the test, switching to explicit usage of an ExecutorService seems to do the trick to make this test reliably pass. With that said, this test (CHM::ToArray.java) seems to trigger an issue in ForkJoinPool, so that would need to be fixed separately. Tagging @DougLea as an FYI. :) ------------- Commit messages: - Switching CHM.ToArray test to use a dedicated thread pool Changes: https://git.openjdk.org/jdk/pull/18023/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18023&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8269428 Stats: 49 lines in 1 file changed: 3 ins; 0 del; 46 mod Patch: https://git.openjdk.org/jdk/pull/18023.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18023/head:pull/18023 PR: https://git.openjdk.org/jdk/pull/18023 From vklang at openjdk.org Tue Feb 27 10:41:47 2024 From: vklang at openjdk.org (Viktor Klang) Date: Tue, 27 Feb 2024 10:41:47 GMT Subject: Integrated: 8325754: Dead AbstractQueuedSynchronizer$ConditionNodes survive minor garbage collections In-Reply-To: References: Message-ID: On Wed, 21 Feb 2024 15:01:15 GMT, Viktor Klang wrote: > More aggressively breaking chains in order to prevent nodes promoted to older generations standing in the way for collecting younger nodes. I decided that it was most efficient to add this logic to the else-branch of updating the firstWaiter and lastWaiter. > > There's a race with unlinkCancelledWaiters() but according to @DougLea it should be a benign one. > > There's a performance impact of this, but as it is a plain write, and one to null at that, it should be acceptable. This pull request has now been integrated. Changeset: 60cbf292 Author: Viktor Klang URL: https://git.openjdk.org/jdk/commit/60cbf2925024b1c2253256688ae41741fff0a860 Stats: 10 lines in 2 files changed: 10 ins; 0 del; 0 mod 8325754: Dead AbstractQueuedSynchronizer$ConditionNodes survive minor garbage collections Reviewed-by: alanb ------------- PR: https://git.openjdk.org/jdk/pull/17950 From epeter at openjdk.org Tue Feb 27 10:48:06 2024 From: epeter at openjdk.org (Emanuel Peter) Date: Tue, 27 Feb 2024 10:48:06 GMT Subject: RFR: 8318650: Optimized subword gather for x86 targets. [v16] In-Reply-To: <74IG9XcR_mSgCl2273SIFL2GLxC8QwRCMc64cwdUFLc=.6e247bc1-51c7-4747-8735-f45aa5307c61@github.com> References: <74IG9XcR_mSgCl2273SIFL2GLxC8QwRCMc64cwdUFLc=.6e247bc1-51c7-4747-8735-f45aa5307c61@github.com> Message-ID: On Tue, 27 Feb 2024 10:25:19 GMT, Emanuel Peter wrote: >> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: >> >> Review comment resolutions. > > src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 1672: > >> 1670: Label GATHER8_LOOP; >> 1671: XMMRegister iota = xtmp1; >> 1672: XMMRegister two_vec = xtmp2; > > I'm sorry to bother you so much with this. I think adding aliases that don't mention what register they alias to makes things worse. Now I can't even see if two names might alias to the same register. As I said: you can also comment / document the use of registers. You don't have to use better names if that is problematic. > src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 1681: > >> 1679: vpsubd(xtmp2, xtmp1, xtmp2, vlen_enc); >> 1680: vpslld(two_vec, xtmp2, 1, vlen_enc); >> 1681: load_iota_indices(iota, vector_len * type2aelembytes(elem_ty), T_INT); > > Suggestion: > > vpxor(xtmp1, xtmp1, xtmp1, vlen_enc); // xtmp1 = {0, ...} > vpxor(dst, dst, dst, vlen_enc); // dst = {0, ...} > vallones(xtmp2, vlen_enc); > vpsubd(xtmp2, xtmp1, xtmp2, vlen_enc); > vpslld(xtmp2, xtmp2, 1, vlen_enc); // xtmp2 = {2, 2, ...} > load_iota_indices(xtmp1, vector_len * type2aelembytes(elem_ty), T_INT); // xtmp1 = {0, 1, 2, ...} vallones(xtmp2, vlen_enc); vpsubd(xtmp2, xtmp1, xtmp2, vlen_enc); vpslld(xtmp2, xtmp2, 1, vlen_enc); This is all to set up `xtmp2 = {2, 2, ...}` ? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16354#discussion_r1504000796 PR Review Comment: https://git.openjdk.org/jdk/pull/16354#discussion_r1504022599 From epeter at openjdk.org Tue Feb 27 10:48:05 2024 From: epeter at openjdk.org (Emanuel Peter) Date: Tue, 27 Feb 2024 10:48:05 GMT Subject: RFR: 8318650: Optimized subword gather for x86 targets. [v16] In-Reply-To: References: Message-ID: <74IG9XcR_mSgCl2273SIFL2GLxC8QwRCMc64cwdUFLc=.6e247bc1-51c7-4747-8735-f45aa5307c61@github.com> On Tue, 27 Feb 2024 02:47:13 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 using 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.5-10x 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. >> >> 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 comment resolutions. I sent the patch for testing. And added some suggestions for comments in `C2_MacroAssembler::vgather_subword`. I hope I have not been annoying you too much ? src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 1672: > 1670: Label GATHER8_LOOP; > 1671: XMMRegister iota = xtmp1; > 1672: XMMRegister two_vec = xtmp2; I'm sorry to bother you so much with this. I think adding aliases that don't mention what register they alias to makes things worse. Now I can't even see if two names might alias to the same register. src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 1672: > 1670: Label GATHER8_LOOP; > 1671: XMMRegister iota = xtmp1; > 1672: XMMRegister two_vec = xtmp2; Suggestion: src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 1681: > 1679: vpsubd(xtmp2, xtmp1, xtmp2, vlen_enc); > 1680: vpslld(two_vec, xtmp2, 1, vlen_enc); > 1681: load_iota_indices(iota, vector_len * type2aelembytes(elem_ty), T_INT); Suggestion: vpxor(xtmp1, xtmp1, xtmp1, vlen_enc); // xtmp1 = {0, ...} vpxor(dst, dst, dst, vlen_enc); // dst = {0, ...} vallones(xtmp2, vlen_enc); vpsubd(xtmp2, xtmp1, xtmp2, vlen_enc); vpslld(xtmp2, xtmp2, 1, vlen_enc); // xtmp2 = {2, 2, ...} load_iota_indices(xtmp1, vector_len * type2aelembytes(elem_ty), T_INT); // xtmp1 = {0, 1, 2, ...} src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 1688: > 1686: } else { > 1687: LP64_ONLY(vgather8b_masked_offset(elem_ty, temp_dst, base, idx_base, offset, mask, mask_idx, rtmp, vlen_enc)); > 1688: } Suggestion: // TMP_VEC_64(temp_dst) = PICK_SUB_WORDS_FROM_GATHER_INDICES if (mask == noreg) { vgather8b_offset(elem_ty, temp_dst, base, idx_base, offset, rtmp, vlen_enc); } else { LP64_ONLY(vgather8b_masked_offset(elem_ty, temp_dst, base, idx_base, offset, mask, mask_idx, rtmp, vlen_enc)); } src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 1694: > 1692: addptr(idx_base, 32 >> (type2aelembytes(elem_ty) - 1)); > 1693: subl(length, 8 >> (type2aelembytes(elem_ty) - 1)); > 1694: jcc(Assembler::notEqual, GATHER8_LOOP); Suggestion: // TEMP_PERM_VEC(temp_dst) = PERMUTE TMP_VEC_64(temp_dst) PERM_INDEX(xtmp1) vpermd(temp_dst, xtmp1, temp_dst, vlen_enc == Assembler::AVX_512bit ? vlen_enc : Assembler::AVX_256bit); // PERM_INDEX(xtmp1) = PERM_INDEX(xtmp1) - TWO_VEC(xtmp2) vpsubd(xtmp1, xtmp1, xtmp2, vlen_enc); // DST_VEC = DST_VEC OR TEMP_PERM_VEC vpor(dst, dst, temp_dst, vlen_enc); addptr(idx_base, 32 >> (type2aelembytes(elem_ty) - 1)); subl(length, 8 >> (type2aelembytes(elem_ty) - 1)); jcc(Assembler::notEqual, GATHER8_LOOP); ------------- Changes requested by epeter (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16354#pullrequestreview-1903117002 PR Review Comment: https://git.openjdk.org/jdk/pull/16354#discussion_r1503996753 PR Review Comment: https://git.openjdk.org/jdk/pull/16354#discussion_r1504001356 PR Review Comment: https://git.openjdk.org/jdk/pull/16354#discussion_r1504007501 PR Review Comment: https://git.openjdk.org/jdk/pull/16354#discussion_r1504019352 PR Review Comment: https://git.openjdk.org/jdk/pull/16354#discussion_r1504017498 From ihse at openjdk.org Tue Feb 27 11:19:59 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 27 Feb 2024 11:19:59 GMT Subject: RFR: 8326583: Remove over-generalized DefineNativeToolchain solution [v4] In-Reply-To: References: Message-ID: > The idea of setting up general "toolchains" in the native build was good, but it turned out that we really only need a single toolchain, with a single twist: if it should use CC or CPP to link. This is better described by a specific argument to SetupNativeCompilation, LANG := C++ or LANG := C (the default). > > There is a single exception to this rule, and that is if we want to compile for the build platform rather than the target platform. (This is only done for adlc) To keep expressing this difference, introduce TARGET_TYPE := BUILD (or TARGET_TYPE := TARGET, the default). > > The final odd-case was the hack for building hsdis/bin on mingw. This can be resolved using direct variables to SetupNativeCompilation, instead of first creating a toolchain. > > Doing this refactoring will simplify the SetupNativeCompilation code, and make it much clearer if we use the C or C++ linker. Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits: - Merge branch 'master' into remove-toolchain-define - Rename LANG to LINK_TYPE - Reword "lib" comment to fit in better - Merge branch 'master' into remove-toolchain-define - 8326583: Remove over-generalized DefineNativeToolchain solution ------------- Changes: https://git.openjdk.org/jdk/pull/17986/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17986&range=03 Stats: 231 lines in 14 files changed: 58 ins; 142 del; 31 mod Patch: https://git.openjdk.org/jdk/pull/17986.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17986/head:pull/17986 PR: https://git.openjdk.org/jdk/pull/17986 From ihse at openjdk.org Tue Feb 27 11:19:59 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 27 Feb 2024 11:19:59 GMT Subject: RFR: 8326583: Remove over-generalized DefineNativeToolchain solution [v3] In-Reply-To: References: Message-ID: On Tue, 27 Feb 2024 08:14:56 GMT, Julian Waters wrote: > can we get rid of LDCXX? Yeah, that is something I plan to look into. Linking C++ object files with gcc will fail; and it might be that linking pure C with g++ might be problematic. If this is the case, I hope we can at least determine this automatically which linker frontend to use, i.e. selecting g++ as linker frontend if there is at least one .cpp file in the set of sources. This PR is actually a kind of prerequisite for that kind of work. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17986#issuecomment-1966312751 From ihse at openjdk.org Tue Feb 27 11:19:59 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 27 Feb 2024 11:19:59 GMT Subject: Integrated: 8326583: Remove over-generalized DefineNativeToolchain solution In-Reply-To: References: Message-ID: On Fri, 23 Feb 2024 16:23:43 GMT, Magnus Ihse Bursie wrote: > The idea of setting up general "toolchains" in the native build was good, but it turned out that we really only need a single toolchain, with a single twist: if it should use CC or CPP to link. This is better described by a specific argument to SetupNativeCompilation, LANG := C++ or LANG := C (the default). > > There is a single exception to this rule, and that is if we want to compile for the build platform rather than the target platform. (This is only done for adlc) To keep expressing this difference, introduce TARGET_TYPE := BUILD (or TARGET_TYPE := TARGET, the default). > > The final odd-case was the hack for building hsdis/bin on mingw. This can be resolved using direct variables to SetupNativeCompilation, instead of first creating a toolchain. > > Doing this refactoring will simplify the SetupNativeCompilation code, and make it much clearer if we use the C or C++ linker. This pull request has now been integrated. Changeset: ac3ce2aa Author: Magnus Ihse Bursie URL: https://git.openjdk.org/jdk/commit/ac3ce2aa156332fc4e6f33018ff669657ab4b797 Stats: 231 lines in 14 files changed: 58 ins; 142 del; 31 mod 8326583: Remove over-generalized DefineNativeToolchain solution Reviewed-by: erikj ------------- PR: https://git.openjdk.org/jdk/pull/17986 From ihse at openjdk.org Tue Feb 27 11:19:59 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 27 Feb 2024 11:19:59 GMT Subject: RFR: 8326583: Remove over-generalized DefineNativeToolchain solution [v3] In-Reply-To: References: Message-ID: <84uF4N9DtS5RqXpGr2X8x-QZkztakWV8XYlq1aGP6Ac=.0d0ea683-75c0-4e97-97bf-e30eefe1e170@github.com> On Tue, 27 Feb 2024 08:29:44 GMT, Julian Waters wrote: > All those new parameters to SetupNativeCompilation, were they always there and the comments about them were just missing from the documentation about the function? Yep. The toolchain definition was a way to "package" multiple arguments to SetupNativeCompilation, so you did not have to specify them individually in each call. But in the end they just turned into "normal" arguments to SetupNativeCompilation (but undocumented...). ------------- PR Comment: https://git.openjdk.org/jdk/pull/17986#issuecomment-1966314926 From rgiulietti at openjdk.org Tue Feb 27 11:22:53 2024 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Tue, 27 Feb 2024 11:22:53 GMT Subject: RFR: JDK-8316708: Augment WorstCaseTests with more cases [v7] In-Reply-To: <-AJofvZBHcqti2QDKRqA6BTxKBEPkOsgA_YjZ3wtFpI=.4b1d3a4d-d39e-4e80-bd41-a975817e0a9c@github.com> References: <-AJofvZBHcqti2QDKRqA6BTxKBEPkOsgA_YjZ3wtFpI=.4b1d3a4d-d39e-4e80-bd41-a975817e0a9c@github.com> Message-ID: On Tue, 27 Feb 2024 06:13:08 GMT, Joe Darcy wrote: >> A new paper >> >> "Accuracy of Mathematical Functions in Single, Double, Double Extended, and Quadruple Precision" >> by Brian Gladman, Vincenzo Innocente and Paul Zimmermann >> https://members.loria.fr/PZimmermann/papers/accuracy.pdf >> >> details the inputs with generate the worst-case observed errors in different math library implementations. The FDLIBM-related worst cases should be added to the test suite. > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > Appease jcheck. test/jdk/java/lang/StrictMath/HypotTests.java line 711: > 709: // Empirical worst-case points in other libraries with > 710: // larger worst-case errors than FDLIBM > 711: {0x0.00000000039a2p-1022, 0x0.0000000000001p-1022, 0x0.00000000039a2p-1022}, I can't find this one on the paper. Suggestion: {-0x0.fffffffffffffp-1022, 0x0.0000000000001p-1022, 0x0.fffffffffffffp-1022}, test/jdk/java/lang/StrictMath/Log1pTests.java line 220: > 218: {-0x1.2e496d25897ecp-2, -0x1.663d81cb08f56p-2}, > 219: {-0x1.ffffffbaefe27p-2, -0x1.62e42faa93817p-1}, > 220: }; I think there's another case Suggestion: {-0x1.5efad5491a79bp-1022, -0x1.5efad5491a79bp-1022}, }; test/jdk/java/lang/StrictMath/LogTests.java line 74: > 72: {0x1.0ffea3878db6bp+0, 0x1.f07a0cca521fp-5}, > 73: {0x1.490af72a25a81p-1, -0x1.c4bf7ae48f078p-2}, > 74: {0x1.69e7aa6da2df5p-1, -0x1.634508c9adfp-2}, There are no libraries that have worse errors than OpenLibm, so I'm wondering what these values are good for? test/jdk/java/lang/StrictMath/TrigTests.java line 171: > 169: {-0x1.0e16eb809a35dp+944, 0x1.b5e361ed01dadp-2}, > 170: {-0x1.842d8ec8f752fp+21, -0x1.6ce864edeaffep-1}, > 171: {-0x1.1c49ad613ff3bp+19, -0x1.fffe203cfabe1p-2}, Some of these cases are for libraries that have _better_ worst case errors than OpenLibm. Are they needed here? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15879#discussion_r1504067869 PR Review Comment: https://git.openjdk.org/jdk/pull/15879#discussion_r1504067977 PR Review Comment: https://git.openjdk.org/jdk/pull/15879#discussion_r1504068053 PR Review Comment: https://git.openjdk.org/jdk/pull/15879#discussion_r1504068092 From ihse at openjdk.org Tue Feb 27 11:26:53 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 27 Feb 2024 11:26:53 GMT Subject: RFR: 8174269: Remove COMPAT locale data provider from JDK [v5] In-Reply-To: <5oS5x968YgpeRo6Bf6SQGnPvgLONaDi5hl7fRkeqYbg=.7f120d7c-6719-4a0e-97b8-823eccd0f809@github.com> References: <5oS5x968YgpeRo6Bf6SQGnPvgLONaDi5hl7fRkeqYbg=.7f120d7c-6719-4a0e-97b8-823eccd0f809@github.com> Message-ID: <43IaJIrElCQ3VrWzD3pXNJVvTv39T24dtC46t5yAY0A=.c6ee8393-954d-4e67-bb8c-ddb97518dfd5@github.com> On Tue, 27 Feb 2024 00:24:08 GMT, Naoto Sato wrote: >> This PR intends to remove the legacy `COMPAT` locale data from the JDK. The `COMPAT` locale data was introduced for applications' migratory purposes transitioning to `CLDR`. It is becoming a technical debt and now is the time to remove it (we've been emitting a warning at JVM startup since JDK21, if the app is using `COMPAT`). A corresponding CSR has also been drafted. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Addressing review comments This looks good from a build perspective. Actually, it looks great! :) I'm happy to get rid of this old strange construct. ------------- Marked as reviewed by ihse (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17991#pullrequestreview-1903238470 From jwaters at openjdk.org Tue Feb 27 11:29:47 2024 From: jwaters at openjdk.org (Julian Waters) Date: Tue, 27 Feb 2024 11:29:47 GMT Subject: RFR: 8326583: Remove over-generalized DefineNativeToolchain solution [v3] In-Reply-To: References: Message-ID: On Tue, 27 Feb 2024 11:09:26 GMT, Magnus Ihse Bursie wrote: > > can we get rid of LDCXX? > > Yeah, that is something I plan to look into. Linking C++ object files with gcc will fail; and it might be that linking pure C with g++ might be problematic. If this is the case, I hope we can at least determine this automatically which linker frontend to use, i.e. selecting g++ as linker frontend if there is at least one .cpp file in the set of sources. > > This PR is actually a kind of prerequisite for that kind of work. I'd certainly opt for selecting which linker driver to use automatically than using one for both; According to some discussions with several gcc maintainers (https://web.libera.chat/) they really aren't meant to be intermingled Also was fine with LANG; There wasn't a need to change it to LINK_TYPE, but oh well ------------- PR Comment: https://git.openjdk.org/jdk/pull/17986#issuecomment-1966341897 From djelinski at openjdk.org Tue Feb 27 11:46:48 2024 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Tue, 27 Feb 2024 11:46:48 GMT Subject: RFR: 8326583: Remove over-generalized DefineNativeToolchain solution [v4] In-Reply-To: References: Message-ID: On Tue, 27 Feb 2024 11:19:59 GMT, Magnus Ihse Bursie wrote: >> The idea of setting up general "toolchains" in the native build was good, but it turned out that we really only need a single toolchain, with a single twist: if it should use CC or CPP to link. This is better described by a specific argument to SetupNativeCompilation, LANG := C++ or LANG := C (the default). >> >> There is a single exception to this rule, and that is if we want to compile for the build platform rather than the target platform. (This is only done for adlc) To keep expressing this difference, introduce TARGET_TYPE := BUILD (or TARGET_TYPE := TARGET, the default). >> >> The final odd-case was the hack for building hsdis/bin on mingw. This can be resolved using direct variables to SetupNativeCompilation, instead of first creating a toolchain. >> >> Doing this refactoring will simplify the SetupNativeCompilation code, and make it much clearer if we use the C or C++ linker. > > Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits: > > - Merge branch 'master' into remove-toolchain-define > - Rename LANG to LINK_TYPE > - Reword "lib" comment to fit in better > - Merge branch 'master' into remove-toolchain-define > - 8326583: Remove over-generalized DefineNativeToolchain solution FWIW, when I added `-lstdc++` before both `-static-libstdc++` and replaced LDCXX with LD, the code compiled and linked just fine. Both GCC and G++ call the same linker, and the parameter differences are well documented. It's only a matter of deciding if we want to keep the complexity of selecting the executable to use or not. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17986#issuecomment-1966368056 From ihse at openjdk.org Tue Feb 27 12:01:53 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 27 Feb 2024 12:01:53 GMT Subject: RFR: 8326583: Remove over-generalized DefineNativeToolchain solution [v4] In-Reply-To: References: Message-ID: On Tue, 27 Feb 2024 11:44:31 GMT, Daniel Jeli?ski wrote: > FWIW, when I added -lstdc++ before both -static-libstdc++ and replaced LDCXX with LD, the code compiled and linked just fine. Both GCC and G++ call the same linker, and the parameter differences are well documented. It's only a matter of deciding if we want to keep the complexity of selecting the executable to use or not. My thinking matches yours. It would be nice to get rid of LDCXX. I'll look into it as a follow-up project. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17986#issuecomment-1966390350 From dl at openjdk.org Tue Feb 27 12:24:53 2024 From: dl at openjdk.org (Doug Lea) Date: Tue, 27 Feb 2024 12:24:53 GMT Subject: RFR: 8269428: java/util/concurrent/ConcurrentHashMap/ToArray.java timed out In-Reply-To: References: Message-ID: <0baSYoJj_bZOnOy5Id3x6YJh9SMhgyu3la-6hhcwPH4=.1281b0b1-94bc-40c2-a272-7616e17a986d@github.com> On Tue, 27 Feb 2024 10:30:44 GMT, Viktor Klang wrote: > As an intermediate fix to the test, switching to explicit usage of an ExecutorService seems to do the trick to make this test reliably pass. > > With that said, this test (CHM::ToArray.java) seems to trigger an issue in ForkJoinPool, so that would need to be fixed separately. > > Tagging @DougLea as an FYI. :) This change seems OK in terms of avoiding failures due to unrelated FJP and/or GC issues (for which it may be better to develop a separate test). ------------- PR Comment: https://git.openjdk.org/jdk/pull/18023#issuecomment-1966429236 From dfuchs at openjdk.org Tue Feb 27 12:45:50 2024 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Tue, 27 Feb 2024 12:45:50 GMT Subject: RFR: 8326687: Inconsistent use of "ZIP", "Zip" and "zip" in java.util.zip/jar zipfs javadoc In-Reply-To: References: Message-ID: On Mon, 26 Feb 2024 19:55:47 GMT, Lance Andersen wrote: > This PR updates the javadoc and comments within java.util.zip/jar and zipfs module summary so that it is consistent with the use of "ZIP". > > In addition, open/src/java.base/share/classes/java/util/zip/package-info.java has been updated to point to the higher level location of the PKWARE APPNOTE.TXT has PKWare recently changed the direct path the the latest version of the spec. > > It is also worth noting that error messages were not updated as part of the PR and will be updated separately to keep the javadoc changes separate I am not a usual Reviewer for this area but the changes LGTM Lance. I haven't seen anything unexpected given the description of the changes. ------------- Marked as reviewed by dfuchs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/18011#pullrequestreview-1903392981 From jwaters at openjdk.org Tue Feb 27 12:50:48 2024 From: jwaters at openjdk.org (Julian Waters) Date: Tue, 27 Feb 2024 12:50:48 GMT Subject: RFR: 8326583: Remove over-generalized DefineNativeToolchain solution [v4] In-Reply-To: References: Message-ID: On Tue, 27 Feb 2024 11:19:59 GMT, Magnus Ihse Bursie wrote: >> The idea of setting up general "toolchains" in the native build was good, but it turned out that we really only need a single toolchain, with a single twist: if it should use CC or CPP to link. This is better described by a specific argument to SetupNativeCompilation, LANG := C++ or LANG := C (the default). >> >> There is a single exception to this rule, and that is if we want to compile for the build platform rather than the target platform. (This is only done for adlc) To keep expressing this difference, introduce TARGET_TYPE := BUILD (or TARGET_TYPE := TARGET, the default). >> >> The final odd-case was the hack for building hsdis/bin on mingw. This can be resolved using direct variables to SetupNativeCompilation, instead of first creating a toolchain. >> >> Doing this refactoring will simplify the SetupNativeCompilation code, and make it much clearer if we use the C or C++ linker. > > Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits: > > - Merge branch 'master' into remove-toolchain-define > - Rename LANG to LINK_TYPE > - Reword "lib" comment to fit in better > - Merge branch 'master' into remove-toolchain-define > - 8326583: Remove over-generalized DefineNativeToolchain solution I can't really say I agree, but I guess we'll see where this goes from here first ------------- PR Comment: https://git.openjdk.org/jdk/pull/17986#issuecomment-1966471047 From mdonovan at openjdk.org Tue Feb 27 13:29:07 2024 From: mdonovan at openjdk.org (Matthew Donovan) Date: Tue, 27 Feb 2024 13:29:07 GMT Subject: RFR: 8319648: java/lang/SecurityManager tests ignore vm flags [v2] In-Reply-To: <8QF-ychCHq3eRcsTlZqFqP68z2NApgazCTWyaDaP2iY=.e261430a-7cff-425a-ba7d-26b7f44fd0bc@github.com> References: <8QF-ychCHq3eRcsTlZqFqP68z2NApgazCTWyaDaP2iY=.e261430a-7cff-425a-ba7d-26b7f44fd0bc@github.com> Message-ID: > In this PR I updated the tests to use the newer ProcessTools.createTestJavaProcessBuilder methods to pass VM options to child processes. Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision: removed unused import statement ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17878/files - new: https://git.openjdk.org/jdk/pull/17878/files/458ac07a..5e5261bf Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17878&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17878&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/17878.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17878/head:pull/17878 PR: https://git.openjdk.org/jdk/pull/17878 From eirbjo at openjdk.org Tue Feb 27 14:47:51 2024 From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=) Date: Tue, 27 Feb 2024 14:47:51 GMT Subject: RFR: 8326687: Inconsistent use of "ZIP", "Zip" and "zip" in java.util.zip/jar zipfs javadoc In-Reply-To: References: Message-ID: On Mon, 26 Feb 2024 19:55:47 GMT, Lance Andersen wrote: > This PR updates the javadoc and comments within java.util.zip/jar and zipfs module summary so that it is consistent with the use of "ZIP". > > In addition, open/src/java.base/share/classes/java/util/zip/package-info.java has been updated to point to the higher level location of the PKWARE APPNOTE.TXT has PKWare recently changed the direct path the the latest version of the spec. > > It is also worth noting that error messages were not updated as part of the PR and will be updated separately to keep the javadoc changes separate The class javadocs for `java.util.zip.ZipCoder` uses "zipfile" which is probably a reference to the `ZipFile` class. `jdk.nio.zipfs.ZipCoder` seems to have borrowed the class javadocs, but here `ZipFile` does not make sense. Perhaps `ZipFileSystem` would be better? Would you consider fixing this to CamelCase in this PR (although it is maybe not directly the same inconsistency the PR aims to fix)? https://github.com/openjdk/jdk/blob/c5c866aafe76f51cd5386bf5052c06691c1a0e8c/src/java.base/share/classes/java/util/zip/ZipCoder.java#L41 https://github.com/openjdk/jdk/blob/c5c866aafe76f51cd5386bf5052c06691c1a0e8c/src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipCoder.java#L41 ------------- PR Comment: https://git.openjdk.org/jdk/pull/18011#issuecomment-1966701666 From rriggs at openjdk.org Tue Feb 27 14:51:53 2024 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 27 Feb 2024 14:51:53 GMT Subject: RFR: 8326714: Make file-local functions static in src/java.base/unix/native/libjava/childproc.c In-Reply-To: References: Message-ID: On Tue, 27 Feb 2024 03:11:37 GMT, Jiangli Zhou wrote: > Please help review this trivial change. This was branched from https://github.com/openjdk/jdk/pull/18013, based on discussion with @plummercj in https://github.com/openjdk/jdk/pull/18013 comments. Thanks Marked as reviewed by rriggs (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/18019#pullrequestreview-1903727632 From eirbjo at openjdk.org Tue Feb 27 15:14:45 2024 From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=) Date: Tue, 27 Feb 2024 15:14:45 GMT Subject: RFR: 8326687: Inconsistent use of "ZIP", "Zip" and "zip" in java.util.zip/jar zipfs javadoc In-Reply-To: References: Message-ID: On Mon, 26 Feb 2024 19:55:47 GMT, Lance Andersen wrote: > This PR updates the javadoc and comments within java.util.zip/jar and zipfs module summary so that it is consistent with the use of "ZIP". > > In addition, open/src/java.base/share/classes/java/util/zip/package-info.java has been updated to point to the higher level location of the PKWARE APPNOTE.TXT has PKWare recently changed the direct path the the latest version of the spec. > > It is also worth noting that error messages were not updated as part of the PR and will be updated separately to keep the javadoc changes separate Can you confirm that "zip" in `java.util.zip.ZipUtils.loadLibrary()` was intentionally left lowercase? (Presumably the native library should be referred to by lowercase "zip"): https://github.com/openjdk/jdk/blob/c5c866aafe76f51cd5386bf5052c06691c1a0e8c/src/java.base/share/classes/java/util/zip/ZipUtils.java#L290 See separate feedback about the `ZipOutputStream.inhibitZip64` comment. src/java.base/share/classes/java/util/zip/ZipOutputStream.java line 54: > 52: * Whether to use ZIP64 for zip files with more than 64k entries. > 53: * Until ZIP64 support in zip implementations is ubiquitous, this > 54: * system property allows the creation of zip files which can be Suggestion: * Whether to use ZIP64 for ZIP files with more than 64k entries. * Until ZIP64 support in ZIP implementations is ubiquitous, this * system property allows the creation of ZIP files which can be ------------- PR Review: https://git.openjdk.org/jdk/pull/18011#pullrequestreview-1903793561 PR Review Comment: https://git.openjdk.org/jdk/pull/18011#discussion_r1504401597 From sgehwolf at openjdk.org Tue Feb 27 15:23:09 2024 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Tue, 27 Feb 2024 15:23:09 GMT Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged modules being present [v18] In-Reply-To: References: Message-ID: > Please review this patch which adds a jlink mode to the JDK which doesn't need the packaged modules being present. A.k.a run-time image based jlink. 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 b eing 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 `JRTArchive` 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 jdk.jlink) <(../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.manage... Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision: Only show runtime image suffix for JDK modules ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14787/files - new: https://git.openjdk.org/jdk/pull/14787/files/00caf77c..b034cce2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14787&range=17 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14787&range=16-17 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 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 jiangli at openjdk.org Tue Feb 27 16:08:53 2024 From: jiangli at openjdk.org (Jiangli Zhou) Date: Tue, 27 Feb 2024 16:08:53 GMT Subject: RFR: 8326714: Make file-local functions static in src/java.base/unix/native/libjava/childproc.c In-Reply-To: <9SdW0ASi8yNVMu3f4IEP9Y1vKFxFXVOBD0Js0BbXnuI=.1f36c0af-2a1b-47ae-92d1-13d612a36ebc@github.com> References: <9SdW0ASi8yNVMu3f4IEP9Y1vKFxFXVOBD0Js0BbXnuI=.1f36c0af-2a1b-47ae-92d1-13d612a36ebc@github.com> Message-ID: On Tue, 27 Feb 2024 07:29:46 GMT, Daniel Jeli?ski wrote: >> Please help review this trivial change. This was branched from https://github.com/openjdk/jdk/pull/18013, based on discussion with @plummercj in https://github.com/openjdk/jdk/pull/18013 comments. Thanks > > LGTM @djelinski @RogerRiggs Thanks for the reviews. ------------- PR Comment: https://git.openjdk.org/jdk/pull/18019#issuecomment-1966903722 From lancea at openjdk.org Tue Feb 27 16:15:06 2024 From: lancea at openjdk.org (Lance Andersen) Date: Tue, 27 Feb 2024 16:15:06 GMT Subject: RFR: 8326687: Inconsistent use of "ZIP", "Zip" and "zip" in java.util.zip/jar zipfs javadoc [v2] In-Reply-To: References: Message-ID: On Tue, 27 Feb 2024 16:12:03 GMT, Lance Andersen wrote: >> This PR updates the javadoc and comments within java.util.zip/jar and zipfs module summary so that it is consistent with the use of "ZIP". >> >> In addition, open/src/java.base/share/classes/java/util/zip/package-info.java has been updated to point to the higher level location of the PKWARE APPNOTE.TXT has PKWare recently changed the direct path the the latest version of the spec. >> >> It is also worth noting that error messages were not updated as part of the PR and will be updated separately to keep the javadoc changes separate > > Lance Andersen has updated the pull request incrementally with one additional commit since the last revision: > > Address initial feedback for JDK-8326687 Updated ZipOutputStream.java and the other file you mentioned. I intentionally did not update any files which were not generating javadoc. We can certainly address any additional files and tests not related to javadoc via a separate issue. Thank you Eirik and Daniel for the review ------------- PR Review: https://git.openjdk.org/jdk/pull/18011#pullrequestreview-1903973731 From lancea at openjdk.org Tue Feb 27 16:15:06 2024 From: lancea at openjdk.org (Lance Andersen) Date: Tue, 27 Feb 2024 16:15:06 GMT Subject: RFR: 8326687: Inconsistent use of "ZIP", "Zip" and "zip" in java.util.zip/jar zipfs javadoc [v2] In-Reply-To: References: Message-ID: > This PR updates the javadoc and comments within java.util.zip/jar and zipfs module summary so that it is consistent with the use of "ZIP". > > In addition, open/src/java.base/share/classes/java/util/zip/package-info.java has been updated to point to the higher level location of the PKWARE APPNOTE.TXT has PKWare recently changed the direct path the the latest version of the spec. > > It is also worth noting that error messages were not updated as part of the PR and will be updated separately to keep the javadoc changes separate Lance Andersen has updated the pull request incrementally with one additional commit since the last revision: Address initial feedback for JDK-8326687 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/18011/files - new: https://git.openjdk.org/jdk/pull/18011/files/0208b860..baa67f11 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=18011&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18011&range=00-01 Stats: 10 lines in 4 files changed: 0 ins; 0 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/18011.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18011/head:pull/18011 PR: https://git.openjdk.org/jdk/pull/18011 From lancea at openjdk.org Tue Feb 27 16:15:06 2024 From: lancea at openjdk.org (Lance Andersen) Date: Tue, 27 Feb 2024 16:15:06 GMT Subject: RFR: 8326687: Inconsistent use of "ZIP", "Zip" and "zip" in java.util.zip/jar zipfs javadoc [v2] In-Reply-To: References: Message-ID: <-AFPx8rmcTtpgwzP8GpRi4wvjbMHxPiXtAfVRWNjpIY=.04064385-f142-4429-9aca-fa37e20e25be@github.com> On Tue, 27 Feb 2024 15:08:11 GMT, Eirik Bj?rsn?s wrote: >> Lance Andersen has updated the pull request incrementally with one additional commit since the last revision: >> >> Address initial feedback for JDK-8326687 > > src/java.base/share/classes/java/util/zip/ZipOutputStream.java line 54: > >> 52: * Whether to use ZIP64 for zip files with more than 64k entries. >> 53: * Until ZIP64 support in zip implementations is ubiquitous, this >> 54: * system property allows the creation of zip files which can be > > Suggestion: > > * Whether to use ZIP64 for ZIP files with more than 64k entries. > * Until ZIP64 support in ZIP implementations is ubiquitous, this > * system property allows the creation of ZIP files which can be Fixed not sure how Missed this when updating ZipOutputStream ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18011#discussion_r1504509576 From jiangli at openjdk.org Tue Feb 27 16:46:58 2024 From: jiangli at openjdk.org (Jiangli Zhou) Date: Tue, 27 Feb 2024 16:46:58 GMT Subject: Integrated: 8326714: Make file-local functions static in src/java.base/unix/native/libjava/childproc.c In-Reply-To: References: Message-ID: On Tue, 27 Feb 2024 03:11:37 GMT, Jiangli Zhou wrote: > Please help review this trivial change. This was branched from https://github.com/openjdk/jdk/pull/18013, based on discussion with @plummercj in https://github.com/openjdk/jdk/pull/18013 comments. Thanks This pull request has now been integrated. Changeset: 81b065a9 Author: Jiangli Zhou URL: https://git.openjdk.org/jdk/commit/81b065a95d670ef357c36239d8c408cd72a5c48c Stats: 20 lines in 2 files changed: 0 ins; 13 del; 7 mod 8326714: Make file-local functions static in src/java.base/unix/native/libjava/childproc.c Reviewed-by: djelinski, rriggs ------------- PR: https://git.openjdk.org/jdk/pull/18019 From mbaesken at openjdk.org Tue Feb 27 16:48:05 2024 From: mbaesken at openjdk.org (Matthias Baesken) Date: Tue, 27 Feb 2024 16:48:05 GMT Subject: RFR: JDK-8326389: [test] improve assertEquals failure output [v4] In-Reply-To: References: Message-ID: > Currently assertEquals has in the failure case sometimes confusing output like : > > java.lang.RuntimeException: VM output should contain exactly one RTM locking statistics entry for method compiler.rtm.locking.TestRTMTotalCountIncrRate$Test:? expected 0 to equal 1 > at jdk.test.lib.Asserts.fail(Asserts.java:634) > at jdk.test.lib.Asserts.assertEquals(Asserts.java:205) > > (I don't think we really expected that for some reason 0 equals 1) > This should be improved. Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: adjust ms ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17952/files - new: https://git.openjdk.org/jdk/pull/17952/files/03cf3a82..a89742ff Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17952&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17952&range=02-03 Stats: 4 lines in 1 file changed: 0 ins; 3 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/17952.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17952/head:pull/17952 PR: https://git.openjdk.org/jdk/pull/17952 From mbaesken at openjdk.org Tue Feb 27 16:48:05 2024 From: mbaesken at openjdk.org (Matthias Baesken) Date: Tue, 27 Feb 2024 16:48:05 GMT Subject: RFR: JDK-8326389: [test] improve assertEquals failure output [v3] In-Reply-To: References: <7xPPisT1fNEHqXyPQVJX8gAYu2i7HCV1PNPDlxNVfJw=.3aa0924c-583f-405c-9c0b-61ff292d6d6d@github.com> Message-ID: On Mon, 26 Feb 2024 01:17:23 GMT, Jaikiran Pai wrote: > Hello Christoph, yes that looks fine to me. I adjusted it to the given suggestion. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17952#issuecomment-1967070481 From jpai at openjdk.org Tue Feb 27 16:52:44 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 27 Feb 2024 16:52:44 GMT Subject: RFR: JDK-8326389: [test] improve assertEquals failure output [v4] In-Reply-To: References: Message-ID: On Tue, 27 Feb 2024 16:48:05 GMT, Matthias Baesken wrote: >> Currently assertEquals has in the failure case sometimes confusing output like : >> >> java.lang.RuntimeException: VM output should contain exactly one RTM locking statistics entry for method compiler.rtm.locking.TestRTMTotalCountIncrRate$Test:? expected 0 to equal 1 >> at jdk.test.lib.Asserts.fail(Asserts.java:634) >> at jdk.test.lib.Asserts.assertEquals(Asserts.java:205) >> >> (I don't think we really expected that for some reason 0 equals 1) >> This should be improved. > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > adjust ms Thank you Matthias. This looks good to me. I haven't checked references for this internal `Asserts` class. Before integrating, please run relevant tests that use this class just to be sure no test relies (and now fails) on the message being printed by the failing assertion. ------------- Marked as reviewed by jpai (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17952#pullrequestreview-1904154276 From naoto at openjdk.org Tue Feb 27 17:00:48 2024 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 27 Feb 2024 17:00:48 GMT Subject: RFR: 8174269: Remove COMPAT locale data provider from JDK [v5] In-Reply-To: <43IaJIrElCQ3VrWzD3pXNJVvTv39T24dtC46t5yAY0A=.c6ee8393-954d-4e67-bb8c-ddb97518dfd5@github.com> References: <5oS5x968YgpeRo6Bf6SQGnPvgLONaDi5hl7fRkeqYbg=.7f120d7c-6719-4a0e-97b8-823eccd0f809@github.com> <43IaJIrElCQ3VrWzD3pXNJVvTv39T24dtC46t5yAY0A=.c6ee8393-954d-4e67-bb8c-ddb97518dfd5@github.com> Message-ID: On Tue, 27 Feb 2024 11:24:08 GMT, Magnus Ihse Bursie wrote: >> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: >> >> Addressing review comments > > This looks good from a build perspective. Actually, it looks great! :) I'm happy to get rid of this old strange construct. Thanks, @magicus > to get rid of this old strange construct. Removing legacy clutter is exactly the purpose of this exercise! ------------- PR Comment: https://git.openjdk.org/jdk/pull/17991#issuecomment-1967125233 From duke at openjdk.org Tue Feb 27 17:29:15 2024 From: duke at openjdk.org (Chad Rakoczy) Date: Tue, 27 Feb 2024 17:29:15 GMT Subject: RFR: 8326718: Test java/util/Formatter/Padding.java does not timeout on large inputs before JDK-8299677 Message-ID: [JDK-8299677](https://bugs.openjdk.java.net/browse/JDK-8299677) fixes a bug with Formatter.format taking a long time when there is a lot of padding. This test runs Formatter.format with very large padding. Test fails before [JDK-8299677](https://bugs.openjdk.java.net/browse/JDK-8299677) and passes after. Timeout for the test was set to 10 seconds. Test passes locally with as low as 1 (after [JDK-8299677](https://bugs.openjdk.java.net/browse/JDK-8299677)) and fails as high as 120 (before [JDK-8299677](https://bugs.openjdk.java.net/browse/JDK-8299677)) so it should be consistent. ------------- Commit messages: - 8326718: Test java/util/Formatter/Padding.java does not timeout on large inputs before JDK-8299677 Changes: https://git.openjdk.org/jdk/pull/18033/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18033&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8326718 Stats: 41 lines in 1 file changed: 39 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/18033.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18033/head:pull/18033 PR: https://git.openjdk.org/jdk/pull/18033 From rgiulietti at openjdk.org Tue Feb 27 19:07:54 2024 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Tue, 27 Feb 2024 19:07:54 GMT Subject: RFR: 8326718: Test java/util/Formatter/Padding.java does not timeout on large inputs before JDK-8299677 In-Reply-To: References: Message-ID: On Tue, 27 Feb 2024 17:24:03 GMT, Chad Rakoczy wrote: > [JDK-8299677](https://bugs.openjdk.java.net/browse/JDK-8299677) fixes a bug with Formatter.format taking a long time when there is a lot of padding. This test runs Formatter.format with very large padding. Test fails before [JDK-8299677](https://bugs.openjdk.java.net/browse/JDK-8299677) and passes after. > > Timeout for the test was set to 10 seconds. Test passes locally with as low as 1 (after [JDK-8299677](https://bugs.openjdk.java.net/browse/JDK-8299677)) and fails as high as 120 (before [JDK-8299677](https://bugs.openjdk.java.net/browse/JDK-8299677)) so it should be consistent. test/jdk/java/util/Formatter/Padding.java line 26: > 24: /* > 25: * @test > 26: * @bug 4906370 Suggestion: * @bug 4906370 8299677 8326718 or maybe just Suggestion: * @bug 4906370 8326718 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18033#discussion_r1504795257 From alanb at openjdk.org Tue Feb 27 19:15:52 2024 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 27 Feb 2024 19:15:52 GMT Subject: RFR: 8326718: Test java/util/Formatter/Padding.java does not timeout on large inputs before JDK-8299677 In-Reply-To: References: Message-ID: On Tue, 27 Feb 2024 17:24:03 GMT, Chad Rakoczy wrote: > [JDK-8299677](https://bugs.openjdk.java.net/browse/JDK-8299677) fixes a bug with Formatter.format taking a long time when there is a lot of padding. This test runs Formatter.format with very large padding. Test fails before [JDK-8299677](https://bugs.openjdk.java.net/browse/JDK-8299677) and passes after. > > Timeout for the test was set to 10 seconds. Test passes locally with as low as 1 (after [JDK-8299677](https://bugs.openjdk.java.net/browse/JDK-8299677)) and fails as high as 120 (before [JDK-8299677](https://bugs.openjdk.java.net/browse/JDK-8299677)) so it should be consistent. test/jdk/java/util/Formatter/Padding.java line 29: > 27: * @summary Tests to excercise padding on int and double values, > 28: * with various flag combinations. > 29: * @run junit/timeout=10 Padding /timeout=10 looks problematic, I don't think you want that. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18033#discussion_r1504811214 From rgiulietti at openjdk.org Tue Feb 27 19:23:51 2024 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Tue, 27 Feb 2024 19:23:51 GMT Subject: RFR: 8326718: Test java/util/Formatter/Padding.java does not timeout on large inputs before JDK-8299677 In-Reply-To: References: Message-ID: On Tue, 27 Feb 2024 17:24:03 GMT, Chad Rakoczy wrote: > [JDK-8299677](https://bugs.openjdk.java.net/browse/JDK-8299677) fixes a bug with Formatter.format taking a long time when there is a lot of padding. This test runs Formatter.format with very large padding. Test fails before [JDK-8299677](https://bugs.openjdk.java.net/browse/JDK-8299677) and passes after. > > Timeout for the test was set to 10 seconds. Test passes locally with as low as 1 (after [JDK-8299677](https://bugs.openjdk.java.net/browse/JDK-8299677)) and fails as high as 120 (before [JDK-8299677](https://bugs.openjdk.java.net/browse/JDK-8299677)) so it should be consistent. I guess the title should read "8326718: Test java/util/Formatter/Padding.java does not timeout on large inputs _after_ JDK-8299677" ------------- PR Comment: https://git.openjdk.org/jdk/pull/18033#issuecomment-1967437224 From duke at openjdk.org Tue Feb 27 19:23:52 2024 From: duke at openjdk.org (Chad Rakoczy) Date: Tue, 27 Feb 2024 19:23:52 GMT Subject: RFR: 8326718: Test java/util/Formatter/Padding.java does not timeout on large inputs before JDK-8299677 In-Reply-To: References: Message-ID: On Tue, 27 Feb 2024 19:13:10 GMT, Alan Bateman wrote: >> [JDK-8299677](https://bugs.openjdk.java.net/browse/JDK-8299677) fixes a bug with Formatter.format taking a long time when there is a lot of padding. This test runs Formatter.format with very large padding. Test fails before [JDK-8299677](https://bugs.openjdk.java.net/browse/JDK-8299677) and passes after. >> >> Timeout for the test was set to 10 seconds. Test passes locally with as low as 1 (after [JDK-8299677](https://bugs.openjdk.java.net/browse/JDK-8299677)) and fails as high as 120 (before [JDK-8299677](https://bugs.openjdk.java.net/browse/JDK-8299677)) so it should be consistent. > > test/jdk/java/util/Formatter/Padding.java line 29: > >> 27: * @summary Tests to excercise padding on int and double values, >> 28: * with various flag combinations. >> 29: * @run junit/timeout=10 Padding > > /timeout=10 looks problematic, I don't think you want that. What is the issue with this? Is there a different way to set a timeout? The test tests that format does not take a long time to run so I would like to have a timeout ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18033#discussion_r1504833617 From duke at openjdk.org Tue Feb 27 19:27:53 2024 From: duke at openjdk.org (Chad Rakoczy) Date: Tue, 27 Feb 2024 19:27:53 GMT Subject: RFR: 8326718: Test java/util/Formatter/Padding.java does not timeout on large inputs before JDK-8299677 In-Reply-To: References: Message-ID: On Tue, 27 Feb 2024 19:20:36 GMT, Raffaello Giulietti wrote: > I guess the title should read "8326718: Test java/util/Formatter/Padding.java does not timeout on large inputs _after_ JDK-8299677" The test should timeout/fail before the fix in JDK-8299677 and pass after ------------- PR Comment: https://git.openjdk.org/jdk/pull/18033#issuecomment-1967444745 From rgiulietti at openjdk.org Tue Feb 27 19:35:53 2024 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Tue, 27 Feb 2024 19:35:53 GMT Subject: RFR: 8326718: Test java/util/Formatter/Padding.java does not timeout on large inputs before JDK-8299677 In-Reply-To: References: Message-ID: <44lxAqayio0VB5iAzuSMxuMMgmsoGmxuXhA717HzXtQ=.2ff65283-c104-42fd-8995-ef0818b06590@github.com> On Tue, 27 Feb 2024 17:24:03 GMT, Chad Rakoczy wrote: > [JDK-8299677](https://bugs.openjdk.java.net/browse/JDK-8299677) fixes a bug with Formatter.format taking a long time when there is a lot of padding. This test runs Formatter.format with very large padding. Test fails before [JDK-8299677](https://bugs.openjdk.java.net/browse/JDK-8299677) and passes after. > > Timeout for the test was set to 10 seconds. Test passes locally with as low as 1 (after [JDK-8299677](https://bugs.openjdk.java.net/browse/JDK-8299677)) and fails as high as 120 (before [JDK-8299677](https://bugs.openjdk.java.net/browse/JDK-8299677)) so it should be consistent. "8326718: Test java/util/Formatter/Padding.java _does_ timeout on large inputs _before_ fix in JDK-8299677" or "8326718: Test java/util/Formatter/Padding.java _does not_ timeout on large inputs _after_ JDK-8299677" To me, "8326718: Test java/util/Formatter/Padding.java does not timeout on large inputs before fix in JDK-8299677" as you propose, sounds like the fix JDK-8299677 didn't serve its intended purpose. ------------- PR Comment: https://git.openjdk.org/jdk/pull/18033#issuecomment-1967456018 From duke at openjdk.org Tue Feb 27 19:48:43 2024 From: duke at openjdk.org (Chad Rakoczy) Date: Tue, 27 Feb 2024 19:48:43 GMT Subject: RFR: 8326718: Test java/util/Formatter/Padding.java does not timeout on large inputs before JDK-8299677 In-Reply-To: References: Message-ID: On Tue, 27 Feb 2024 17:24:03 GMT, Chad Rakoczy wrote: > [JDK-8299677](https://bugs.openjdk.java.net/browse/JDK-8299677) fixes a bug with Formatter.format taking a long time when there is a lot of padding. This test runs Formatter.format with very large padding. Test fails before [JDK-8299677](https://bugs.openjdk.java.net/browse/JDK-8299677) and passes after. > > Timeout for the test was set to 10 seconds. Test passes locally with as low as 1 (after [JDK-8299677](https://bugs.openjdk.java.net/browse/JDK-8299677)) and fails as high as 120 (before [JDK-8299677](https://bugs.openjdk.java.net/browse/JDK-8299677)) so it should be consistent. The fix in JDK-8299677 serves it's intended purpose but the test added with it does not test that. The original test does not timeout before or after the fix which is the issue. "8326718: Test java/util/Formatter/Padding.java does not timeout on large inputs after JDK-8299677" This is the expected case. Should the title be what the issue is or what the fix is? To me this sounds like the test should be timing out or was timing out after JDK-8299677 Maybe a better title is "8326718: Test java/util/Formatter/Padding.java should timeout on large inputs before fix in JDK-8299677" ------------- PR Comment: https://git.openjdk.org/jdk/pull/18033#issuecomment-1967475911 From darcy at openjdk.org Tue Feb 27 19:55:51 2024 From: darcy at openjdk.org (Joe Darcy) Date: Tue, 27 Feb 2024 19:55:51 GMT Subject: RFR: 8326718: Test java/util/Formatter/Padding.java does not timeout on large inputs before JDK-8299677 In-Reply-To: References: Message-ID: On Tue, 27 Feb 2024 17:24:03 GMT, Chad Rakoczy wrote: > [JDK-8299677](https://bugs.openjdk.java.net/browse/JDK-8299677) fixes a bug with Formatter.format taking a long time when there is a lot of padding. This test runs Formatter.format with very large padding. Test fails before [JDK-8299677](https://bugs.openjdk.java.net/browse/JDK-8299677) and passes after. > > Timeout for the test was set to 10 seconds. Test passes locally with as low as 1 (after [JDK-8299677](https://bugs.openjdk.java.net/browse/JDK-8299677)) and fails as high as 120 (before [JDK-8299677](https://bugs.openjdk.java.net/browse/JDK-8299677)) so it should be consistent. test/jdk/java/util/Formatter/Padding.java line 2: > 1: /* > 2: * Copyright (c) 2024, Oracle and/or its affiliates. All rights reserved. Copyright nit: per OpenJDK conventions, the new copyright for the updated file should be "2023, 2024" not just "2024". ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18033#discussion_r1504884833 From eirbjo at openjdk.org Tue Feb 27 19:59:08 2024 From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=) Date: Tue, 27 Feb 2024 19:59:08 GMT Subject: RFR: 8326096: Deprecate getTotalIn, getTotalOut methods of java.util.zip.Inflater, java.util.zip.Deflater [v10] In-Reply-To: References: Message-ID: > Please review this PR which proposes that we officially deprecate the following four methods in the `java.util.zip` package: > > * `Inflater.getTotalIn()` > * `Inflater.getTotalOut()` > * `Deflater.getTotalIn()` > * `Deflater.getTotalOut()` > > Since these legacy methods return `int`, they cannot safely return the number of bytes processed without the risk of losing information about the magnitude or even sign of the returned value. > > The corresponding methods `getBytesRead()` and `getBytesWritten()` methods introduced in Java 5 return `long`, and should be used instead when obtaining this information. > > Unrelated to the deprecation itself, the documentation currently does not specify what these methods are expected to return when the number of processed bytes is higher than `Integer.MAX_VALUE`. This PR aims to clarify this in the API specification. > > Initally, this PR handles only `Inflater.getTotalIn()`. The other three methods will be updated once the wordsmithing for this method stabilizes. Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision: Reduce the deprecation note to "Use {@link #getBytesRead()} instead" ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17919/files - new: https://git.openjdk.org/jdk/pull/17919/files/8d80c776..4eadbf86 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17919&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17919&range=08-09 Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/17919.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17919/head:pull/17919 PR: https://git.openjdk.org/jdk/pull/17919 From eirbjo at openjdk.org Tue Feb 27 20:03:52 2024 From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=) Date: Tue, 27 Feb 2024 20:03:52 GMT Subject: RFR: 8326096: Deprecate getTotalIn, getTotalOut methods of java.util.zip.Inflater, java.util.zip.Deflater [v10] In-Reply-To: References: Message-ID: On Tue, 27 Feb 2024 19:59:08 GMT, Eirik Bj?rsn?s wrote: >> Please review this PR which proposes that we officially deprecate the following four methods in the `java.util.zip` package: >> >> * `Inflater.getTotalIn()` >> * `Inflater.getTotalOut()` >> * `Deflater.getTotalIn()` >> * `Deflater.getTotalOut()` >> >> Since these legacy methods return `int`, they cannot safely return the number of bytes processed without the risk of losing information about the magnitude or even sign of the returned value. >> >> The corresponding methods `getBytesRead()` and `getBytesWritten()` methods introduced in Java 5 return `long`, and should be used instead when obtaining this information. >> >> Unrelated to the deprecation itself, the documentation currently does not specify what these methods are expected to return when the number of processed bytes is higher than `Integer.MAX_VALUE`. This PR aims to clarify this in the API specification. >> >> Initally, this PR handles only `Inflater.getTotalIn()`. The other three methods will be updated once the wordsmithing for this method stabilizes. > > Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision: > > Reduce the deprecation note to "Use {@link #getBytesRead()} instead" After some offline discussion about the redundant text, we decided to keep to the new method description text, but reduce the `@deprecated` note to simply refer to the replacement method: /** * Returns the total number of compressed bytes input so far. *

    * This method returns the equivalent of {@code (int) getBytesRead()} * and therefore cannot return the correct value when it is greater * than {@link Integer#MAX_VALUE}. * * @deprecated Use {@link #getBytesRead()} instead * * @return the total number of compressed bytes input so far */ Barring any objections, I'll to go ahead with the update of the rest of the methods and update the CSR draft tomorrow. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17919#issuecomment-1967498161 From rgiulietti at openjdk.org Tue Feb 27 20:03:52 2024 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Tue, 27 Feb 2024 20:03:52 GMT Subject: RFR: 8326718: Test java/util/Formatter/Padding.java does not timeout on large inputs before JDK-8299677 In-Reply-To: References: Message-ID: On Tue, 27 Feb 2024 19:46:27 GMT, Chad Rakoczy wrote: >> [JDK-8299677](https://bugs.openjdk.java.net/browse/JDK-8299677) fixes a bug with Formatter.format taking a long time when there is a lot of padding. This test runs Formatter.format with very large padding. Test fails before [JDK-8299677](https://bugs.openjdk.java.net/browse/JDK-8299677) and passes after. >> >> Timeout for the test was set to 10 seconds. Test passes locally with as low as 1 (after [JDK-8299677](https://bugs.openjdk.java.net/browse/JDK-8299677)) and fails as high as 120 (before [JDK-8299677](https://bugs.openjdk.java.net/browse/JDK-8299677)) so it should be consistent. > > The fix in JDK-8299677 serves it's intended purpose but the test added with it does not test that. The original test does not timeout before or after the fix which is the issue. > > "8326718: Test java/util/Formatter/Padding.java does not timeout on large inputs after JDK-8299677" > This is the expected case. Should the title be what the issue is or what the fix is? To me this sounds like the test should be timing out or was timing out after JDK-8299677 > > Maybe a better title is > "8326718: Test java/util/Formatter/Padding.java should timeout on large inputs before fix in JDK-8299677" @chadrako The title of the issue should succinctly describe the problem at the time it is filed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/18033#issuecomment-1967496584 From darcy at openjdk.org Tue Feb 27 20:03:53 2024 From: darcy at openjdk.org (Joe Darcy) Date: Tue, 27 Feb 2024 20:03:53 GMT Subject: RFR: 8326718: Test java/util/Formatter/Padding.java does not timeout on large inputs before JDK-8299677 In-Reply-To: References: Message-ID: On Tue, 27 Feb 2024 19:21:13 GMT, Chad Rakoczy wrote: > What is the issue with this? Is there a different way to set a timeout? The test tests that format does not take a long time to run so I would like to have a timeout Hard-coded timeout in a test are generally considered harmful as the test suite is run on a wide variety of systems, a single value could be too large for fast systems and too small for slow ones. The jtreg harness has an overall `-timeout:N` factor which can scale up or down all the timeouts of individual tests. I don't know offhand if there is an existing idiom to do this with junit tests from within jtreg. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18033#discussion_r1504897104 From rgiulietti at openjdk.org Tue Feb 27 20:06:52 2024 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Tue, 27 Feb 2024 20:06:52 GMT Subject: RFR: 8326718: Test java/util/Formatter/Padding.java does not timeout on large inputs before JDK-8299677 In-Reply-To: References: Message-ID: On Tue, 27 Feb 2024 19:53:23 GMT, Joe Darcy wrote: >> [JDK-8299677](https://bugs.openjdk.java.net/browse/JDK-8299677) fixes a bug with Formatter.format taking a long time when there is a lot of padding. This test runs Formatter.format with very large padding. Test fails before [JDK-8299677](https://bugs.openjdk.java.net/browse/JDK-8299677) and passes after. >> >> Timeout for the test was set to 10 seconds. Test passes locally with as low as 1 (after [JDK-8299677](https://bugs.openjdk.java.net/browse/JDK-8299677)) and fails as high as 120 (before [JDK-8299677](https://bugs.openjdk.java.net/browse/JDK-8299677)) so it should be consistent. > > test/jdk/java/util/Formatter/Padding.java line 2: > >> 1: /* >> 2: * Copyright (c) 2024, Oracle and/or its affiliates. All rights reserved. > > Copyright nit: per OpenJDK conventions, the new copyright for the updated file should be "2023, 2024," not just "2024". Suggestion: * Copyright (c) 2023, 2024, Oracle and/or its affiliates. All rights reserved. with a `,` after the 2nd year as well. Otherwise a check will fail, as I learned the hard-way ;-) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18033#discussion_r1504901855 From lancea at openjdk.org Tue Feb 27 20:16:45 2024 From: lancea at openjdk.org (Lance Andersen) Date: Tue, 27 Feb 2024 20:16:45 GMT Subject: RFR: 8326096: Deprecate getTotalIn, getTotalOut methods of java.util.zip.Inflater, java.util.zip.Deflater [v10] In-Reply-To: References: Message-ID: On Tue, 27 Feb 2024 20:01:30 GMT, Eirik Bj?rsn?s wrote: > After some offline discussion about the redundant text, we decided to keep to the new method description text, but reduce the `@deprecated` note to simply refer to the replacement method: > > ``` > /** > * Returns the total number of compressed bytes input so far. > *

    > * This method returns the equivalent of {@code (int) getBytesRead()} > * and therefore cannot return the correct value when it is greater > * than {@link Integer#MAX_VALUE}. > * > * @deprecated Use {@link #getBytesRead()} instead > * > * @return the total number of compressed bytes input so far > */ > ``` > > Barring any objections, I'll to go ahead with the update of the rest of the methods and update the CSR draft tomorrow. Yes please move forward and thank you ------------- PR Comment: https://git.openjdk.org/jdk/pull/17919#issuecomment-1967517931 From duke at openjdk.org Tue Feb 27 20:39:51 2024 From: duke at openjdk.org (Chad Rakoczy) Date: Tue, 27 Feb 2024 20:39:51 GMT Subject: RFR: 8326718: Test java/util/Formatter/Padding.java does not timeout on large inputs before JDK-8299677 In-Reply-To: References: Message-ID: <9W2VJhGtXz4ZJvYJl08lDr-YR5SSFTRTYgcORV1qVR4=.2a9a77c5-373d-4ddb-9d7b-a19c38559e78@github.com> On Tue, 27 Feb 2024 19:46:27 GMT, Chad Rakoczy wrote: >> [JDK-8299677](https://bugs.openjdk.java.net/browse/JDK-8299677) fixes a bug with Formatter.format taking a long time when there is a lot of padding. This test runs Formatter.format with very large padding. Test fails before [JDK-8299677](https://bugs.openjdk.java.net/browse/JDK-8299677) and passes after. >> >> Timeout for the test was set to 10 seconds. Test passes locally with as low as 1 (after [JDK-8299677](https://bugs.openjdk.java.net/browse/JDK-8299677)) and fails as high as 120 (before [JDK-8299677](https://bugs.openjdk.java.net/browse/JDK-8299677)) so it should be consistent. > > The fix in JDK-8299677 serves it's intended purpose but the test added with it does not test that. The original test does not timeout before or after the fix which is the issue. > > "8326718: Test java/util/Formatter/Padding.java does not timeout on large inputs after JDK-8299677" > This is the expected case. Should the title be what the issue is or what the fix is? To me this sounds like the test should be timing out or was timing out after JDK-8299677 > > Maybe a better title is > "8326718: Test java/util/Formatter/Padding.java should timeout on large inputs before fix in JDK-8299677" > @chadrako The title of the issue should succinctly describe the problem at the time it is filed. Then I feel like the current title is correct. The issue at the time of filing is that `Padding.java` does not timeout on large inputs before the fix (which is should but doesn't) that was implemented in JDK-8299677 I'm open to other's opinions on this as well ------------- PR Comment: https://git.openjdk.org/jdk/pull/18033#issuecomment-1967548391 From duke at openjdk.org Tue Feb 27 20:56:59 2024 From: duke at openjdk.org (Vladimir Yaroslavskiy) Date: Tue, 27 Feb 2024 20:56:59 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> <-bYhysKjQVb_ZS0I0YutJZ7umfYwbs74rtK6-d2qL9U=.f9981e59-f0c4-48f3-ad7e-5627aad00919@github.com> <91Zv361kqKOjCSJPu20-yhKOb4lBIZVyVTm9f79dkcQ=.745c271d-3cb1-4ff3-9d71-5cad85ff4f14@github.com> <9q8Gg6DQnrf0HLW3oxwfpoUP9639drr1BIQMc1rxDFo=.eb4ea73c-b632-446a-8d50-b51838f67f69@github.com> <0OkFUL1UCNcLRNh4P2ZdKvMENJgFy8Tz2BA5l2QgDXE=.77152fca-3c03-46a0-9855-bcf1c9b8d152@github.com> Message-ID: On Fri, 16 Feb 2024 23:43:15 GMT, Srinivas Vamsi Parasa wrote: >> Hi Vamsi (@vamsi-parasa), >> >> My fault, there was an incorrect version of ArraysSortNew.java. Methods, of course, should be >> >> @Benchmark >> public void sort() { >> Arrays.sort(b); >> } >> >> @Benchmark >> public void p_sort() { >> Arrays.parallelSort(b); >> } >> >> I uploaded correct version, see >> https://github.com/iaroslavski/sorting/blob/master/radixsort/ArraysSortNew.java >> >> I also comment that pom.xml contains additional options (I guess you have the same) >> --add-exports=java.base/jdk.internal.misc=ALL-UNNAMED >> --add-exports=java.base/jdk.internal.vm.annotation=ALL-UNNAMED >> full text is there https://github.com/iaroslavski/sorting/blob/master/radixsort/pom.xml >> >> and command to run test is >> java --add-exports=java.base/jdk.internal.vm.annotation=ALL-UNNAMED --add-exports=java.base/jdk.internal.misc=ALL-UNNAMED -jar target/benchmarks.jar >> >> I assume that each variant of DPQS (DualPivotQuicksort_jdk, DualPivotQuicksort_r20p, DualPivotQuicksort_r20s, DualPivotQuicksort_r25p, DualPivotQuicksort_r25s) is renamed to DualPivotQuicksort and put into >> package java.util. Then benchmarking for a given variant with patched JDK is executed. >> >> Thank you, >> Vladimir > > Hello Vladimir (@iaroslavski), > > Please see the data below. Each DPQS class was copied to java.util and the JDK was recompiled. > > Thanks, > Vamsi > > 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 | (builder) | (size) | Stock JDK | r20p | r20s | r25p | r25s > -- | -- | -- | -- | -- | -- | -- | -- > ArraysSort.Int.p_sort | RANDOM | 600 | 1.618 | 2.601 | 2.966 | 2.898 | 3.269 > ArraysSort.Int.p_sort | RANDOM | 2000 | 7.433 | 8.438 | 8.463 | 8.414 | 8.65 > ArraysSort.Int.p_sort | RANDOM | 90000 | 258.853 | 355.261 | 326.378 | 347.65 | 321.894 > ArraysSort.Int.p_sort | RANDOM | 400000 | 842.085 | 1225.929 | 899.852 | 1278.681 | 932.627 > ArraysSort.Int.p_sort | RANDOM | 3000000 | 5723.659 | 8711.108 | 6086.974 | 8948.101 | 6122.612 > ArraysSort.Int.p_sort | REPEATED | 600 | 0.52 | 0.585 | 0.629 | 0.586 | 0.579 > ArraysSort.Int.p_sort | REPEATED | 2000 | 1.18 | 1.225 | 1.21 | 1.225 | 1.238 > ArraysSort.Int.p_sort | REPEATED | 90000 | 102.142 | 85.79 | 86.131 | 87.954 | 86.036 > ArraysSort.Int.p_sort | REPEATED | 400000 | 244.508 | 229.142 | 227.613 | 228.608 | 228.367 > ArraysSort.Int.p_sort | REPEATED | 3000000 | 2752.745 | 2584.103 | 2544.192 | 2576.803 | 2609.833 > ArraysSort.Int.p_sort | STAGGER | 600 | 1.146 | 0.894 | 0.898 | 0.904 | 0.912 > ArraysSort.Int.p_sort | STAGGER | 2000 | 3.712 | 3.096 | 3.121 | 3.03 | 3.049 > ArraysSort.Int.p_sort | STAGGER | 90000 | 72.763 | 77.575 | 78.366 | 79.158 | 77.199 > ArraysSort.Int.p_sort | STAGGER | 400000 | 212.455 | 228.331 | 225.888 | 224.686 | 225.728 > ArraysSort.Int.p_sort | STAGGER | 3000000 | 2290.327 | 2216.741 | 2196.138 | 2236.658 | 2262.472 > ArraysSort.Int.p_sort | SHUFFLE | 600 | 2.01 | 2.92 | 2.907 | 2.91 | 2.926 > ArraysSort.Int.p_sort | SHUFFLE | 2000 | 7.06 | 7.759 | 7.776 | 7.688 | 8.062 > ArraysSort.Int.p_sort | SHUFFLE | 90000 | 157.728 | 151.871 | 151.101 | 154.03 | 151.2 > ArraysSort.Int.p_sort | SHUFFLE | 400000 | 441.166 | 715.243 | 449.698 | 699.75 | 447.069 > ArraysSort.Int.p_sort | SHUFFLE | 3000000 | 4326.88 | 7133.045 | 4205.47 |... Hello Vamsi (@vamsi-parasa), Could you please run benchmarking of 4 cases with **updated** test class **ArraysSortNew2**? https://github.com/iaroslavski/sorting/blob/master/radixsort/ArraysSortNew2.java Put each DPQS class in java.util package and recompiling the JDK for each case as you did before, and run new class **ArraysSortNew2**. Find the sources there: https://github.com/iaroslavski/sorting/blob/master/radixsort/ArraysSortNew2.java https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_b01.java https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_r27b.java https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_r27p.java https://github.com/iaroslavski/sorting/blob/master/radixsort/DualPivotQuicksort_r27s.java Thank you, Vladimir ------------- PR Comment: https://git.openjdk.org/jdk/pull/13568#issuecomment-1967570922 From darcy at openjdk.org Tue Feb 27 21:11:44 2024 From: darcy at openjdk.org (Joe Darcy) Date: Tue, 27 Feb 2024 21:11:44 GMT Subject: RFR: JDK-8316708: Augment WorstCaseTests with more cases [v7] In-Reply-To: References: <-AJofvZBHcqti2QDKRqA6BTxKBEPkOsgA_YjZ3wtFpI=.4b1d3a4d-d39e-4e80-bd41-a975817e0a9c@github.com> Message-ID: On Tue, 27 Feb 2024 11:20:01 GMT, Raffaello Giulietti wrote: > I can't find this one on the paper. Good catch; must have been a cut and paste error on my part. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15879#discussion_r1504993038 From darcy at openjdk.org Tue Feb 27 21:14:54 2024 From: darcy at openjdk.org (Joe Darcy) Date: Tue, 27 Feb 2024 21:14:54 GMT Subject: RFR: JDK-8316708: Augment WorstCaseTests with more cases [v7] In-Reply-To: References: <-AJofvZBHcqti2QDKRqA6BTxKBEPkOsgA_YjZ3wtFpI=.4b1d3a4d-d39e-4e80-bd41-a975817e0a9c@github.com> Message-ID: On Tue, 27 Feb 2024 11:20:11 GMT, Raffaello Giulietti wrote: > There are no libraries that have worse errors than OpenLibm, so I'm wondering what these values are good for? When I was working on updating the worst-case tests for Math, I would check the input values in Math.foo() and StrictMath.foo() and if they differed pick the smaller one as the reference value. The those inputs that differ, the input is a fingerprint marker for FDLIBM and I added cases to the corresponding StrictMath test. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15879#discussion_r1504998720 From erikj at openjdk.org Tue Feb 27 22:14:55 2024 From: erikj at openjdk.org (Erik Joelsson) Date: Tue, 27 Feb 2024 22:14:55 GMT Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged modules being present [v18] In-Reply-To: References: Message-ID: On Tue, 27 Feb 2024 15:23:09 GMT, Severin Gehwolf wrote: >> Please review this patch which adds a jlink mode to the JDK which doesn't need the packaged modules being present. A.k.a run-time image based jlink. 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 `JRTArchive` 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 jdk.jlink) <(../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.i... > > Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision: > > Only show runtime image suffix for JDK modules >From a build point of view, I don't have much to complain about. See inline comments for some nits. make/autoconf/jdk-options.m4 line 596: > 594: ################################################################################ > 595: # > 596: # jlink related. This part of the comment seems a bit redundant. make/autoconf/spec.gmk.template line 904: > 902: RL_INTERMEDIATE_IMAGE_SUBDIR := runtime-link-initial-jdk > 903: RL_INTERMEDIATE_IMAGE_DIR := $(IMAGES_OUTPUTDIR)/$(RL_INTERMEDIATE_IMAGE_SUBDIR) > 904: This intermediate directory is only used inside the Images.gmk. I don't think we need to define it in spec. It can be a local variable in Images.gmk. Also, unless you really want this intermediate image in "images" as some kind of deliverable I would prefer to put it somewhere under `$(SUPPORT_OUTPUTDIR)/images`. ------------- PR Review: https://git.openjdk.org/jdk/pull/14787#pullrequestreview-1904905122 PR Review Comment: https://git.openjdk.org/jdk/pull/14787#discussion_r1505071076 PR Review Comment: https://git.openjdk.org/jdk/pull/14787#discussion_r1505072553 From psandoz at openjdk.org Tue Feb 27 22:28:51 2024 From: psandoz at openjdk.org (Paul Sandoz) Date: Tue, 27 Feb 2024 22:28:51 GMT Subject: RFR: 8318650: Optimized subword gather for x86 targets. [v16] In-Reply-To: References: Message-ID: On Tue, 27 Feb 2024 02:47:13 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 using 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.5-10x 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. >> >> 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 comment resolutions. The Java code looks correct. It would be nice to common the non-mask and mask variants to reduce the code duplication. Perhaps even common to all element types if the loop check is efficient? src/jdk.incubator.vector/share/classes/jdk/incubator/vector/X-Vector.java.template line 3637: > 3635: } else { > 3636: lsp = isp; > 3637: } No need to initialize `lsp` to null, since it will be definitely assigned after the if/else statement. Suggestion: // Constant folding should sweep out following conditonal logic. VectorSpecies lsp; if (isp.length() > IntVector.SPECIES_PREFERRED.length()) { lsp = IntVector.SPECIES_PREFERRED; } else { lsp = isp; } ------------- PR Review: https://git.openjdk.org/jdk/pull/16354#pullrequestreview-1904909095 PR Review Comment: https://git.openjdk.org/jdk/pull/16354#discussion_r1505073358 From duke at openjdk.org Wed Feb 28 00:00:01 2024 From: duke at openjdk.org (Chad Rakoczy) Date: Wed, 28 Feb 2024 00:00:01 GMT Subject: RFR: 8326718: Test java/util/Formatter/Padding.java does not timeout on large inputs before JDK-8299677 [v2] In-Reply-To: References: Message-ID: > [JDK-8299677](https://bugs.openjdk.java.net/browse/JDK-8299677) fixes a bug with Formatter.format taking a long time when there is a lot of padding. This test runs Formatter.format with very large padding. Test fails before [JDK-8299677](https://bugs.openjdk.java.net/browse/JDK-8299677) and passes after. > > Timeout for the test was set to 10 seconds. Test passes locally with as low as 1 (after [JDK-8299677](https://bugs.openjdk.java.net/browse/JDK-8299677)) and fails as high as 120 (before [JDK-8299677](https://bugs.openjdk.java.net/browse/JDK-8299677)) so it should be consistent. Chad Rakoczy has updated the pull request incrementally with one additional commit since the last revision: Test updates ------------- Changes: - all: https://git.openjdk.org/jdk/pull/18033/files - new: https://git.openjdk.org/jdk/pull/18033/files/b3050e16..45d0acdd Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=18033&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18033&range=00-01 Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/18033.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18033/head:pull/18033 PR: https://git.openjdk.org/jdk/pull/18033 From duke at openjdk.org Wed Feb 28 00:00:01 2024 From: duke at openjdk.org (Chad Rakoczy) Date: Wed, 28 Feb 2024 00:00:01 GMT Subject: RFR: 8326718: Test java/util/Formatter/Padding.java does not timeout on large inputs before JDK-8299677 [v2] In-Reply-To: References: Message-ID: On Tue, 27 Feb 2024 20:01:20 GMT, Joe Darcy wrote: >> What is the issue with this? Is there a different way to set a timeout? The test tests that format does not take a long time to run so I would like to have a timeout > >> What is the issue with this? Is there a different way to set a timeout? The test tests that format does not take a long time to run so I would like to have a timeout > > Hard-coded timeout in a test are generally considered harmful as the test suite is run on a wide variety of systems, a single value could be too large for fast systems and too small for slow ones. The jtreg harness has an overall `-timeout:N` factor which can scale up or down all the timeouts of individual tests. I don't know offhand if there is an existing idiom to do this with junit tests from within jtreg. Removed that timeout. Test fails before patch even when timeout factor is 10. Passes after patch within seconds. Default timeout should be good ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18033#discussion_r1505158893 From kbarrett at openjdk.org Wed Feb 28 01:24:41 2024 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 28 Feb 2024 01:24:41 GMT Subject: RFR: 8324799: Use correct extension for C++ test headers Message-ID: Please review this change that renames some test .h files to .hpp. These files contain C++ code and should be named accordingly. Some of them contain uses of NULL, which we change to nullptr. The renamed files are: test/hotspot/jtreg/vmTestbase/nsk/share/aod/aod.h test/hotspot/jtreg/vmTestbase/nsk/share/jni/jni_tools.h test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/jvmti_tools.h test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/JVMTITools.h test/hotspot/jtreg/vmTestbase/nsk/share/native/nsk_tools.h test/lib/jdk/test/lib/jvmti/jvmti_thread.h test/lib/jdk/test/lib/jvmti/jvmti_common.h test/lib/native/testlib_threads.h The #include updates were performed mostly mechanically, and builds would fail if there were mistakes. The exception is test test/hotspot/jtreg/serviceability/jvmti/FollowReferences/FieldIndices/libFieldIndicesTest.cpp, which was added after I'd done the mechanical update, so was updated by hand. The copyright updates were similarly performed mechanically. All but a handful of the including files have already had their copyrights updated recently, likely as part of JDK-8324681. Thus, the only "interesting" changes are to the renamed files. Testing: mach5 tier1 ------------- Commit messages: - update new test - update copyrights - fix jvmti README - rename NULLs in jvmti_common.hpp - rename jvmti_common.h - rename NULLs in jvmti_thread.hpp - rename jvmti_thread.h - rename NULLs in testlib_threads.hpp - rename testlib_threads.h -- no copyright - rename nsk_tools.h -- no copyright - ... and 5 more: https://git.openjdk.org/jdk/compare/16d917a8...4154005e Changes: https://git.openjdk.org/jdk/pull/18035/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18035&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8324799 Stats: 1535 lines in 731 files changed: 133 ins; 133 del; 1269 mod Patch: https://git.openjdk.org/jdk/pull/18035.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18035/head:pull/18035 PR: https://git.openjdk.org/jdk/pull/18035 From liach at openjdk.org Wed Feb 28 02:05:48 2024 From: liach at openjdk.org (Chen Liang) Date: Wed, 28 Feb 2024 02:05:48 GMT Subject: RFR: 8319386: Migrate Class::getEnclosingMethod/Constructor away from old generic utilities In-Reply-To: References: Message-ID: On Fri, 3 Nov 2023 14:03:02 GMT, Chen Liang wrote: > 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 Please review this patch that migrated descriptor parsing from old, complex Java 5 signature parsing system to the java.lang.invoke's descriptor parsing utilities. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16496#issuecomment-1968053393 From jwaters at openjdk.org Wed Feb 28 05:30:51 2024 From: jwaters at openjdk.org (Julian Waters) Date: Wed, 28 Feb 2024 05:30:51 GMT Subject: RFR: 8324799: Use correct extension for C++ test headers In-Reply-To: References: Message-ID: On Wed, 28 Feb 2024 01:18:50 GMT, Kim Barrett wrote: > Please review this change that renames some test .h files to .hpp. These > files contain C++ code and should be named accordingly. Some of them contain > uses of NULL, which we change to nullptr. > > The renamed files are: > > test/hotspot/jtreg/vmTestbase/nsk/share/aod/aod.h > test/hotspot/jtreg/vmTestbase/nsk/share/jni/jni_tools.h > test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/jvmti_tools.h > test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/JVMTITools.h > test/hotspot/jtreg/vmTestbase/nsk/share/native/nsk_tools.h > > test/lib/jdk/test/lib/jvmti/jvmti_thread.h > test/lib/jdk/test/lib/jvmti/jvmti_common.h > test/lib/native/testlib_threads.h > > The #include updates were performed mostly mechanically, and builds would fail > if there were mistakes. The exception is test > test/hotspot/jtreg/serviceability/jvmti/FollowReferences/FieldIndices/libFieldIndicesTest.cpp, > which was added after I'd done the mechanical update, so was updated by hand. > > The copyright updates were similarly performed mechanically. All but a handful > of the including files have already had their copyrights updated recently, > likely as part of JDK-8324681. > > Thus, the only "interesting" changes are to the renamed files. > > Testing: mach5 tier1 Was a blast looking through all 729 files, but have a +1 ------------- Marked as reviewed by jwaters (Committer). PR Review: https://git.openjdk.org/jdk/pull/18035#pullrequestreview-1905352841 From darcy at openjdk.org Wed Feb 28 06:08:18 2024 From: darcy at openjdk.org (Joe Darcy) Date: Wed, 28 Feb 2024 06:08:18 GMT Subject: RFR: JDK-8316708: Augment WorstCaseTests with more cases [v8] In-Reply-To: References: Message-ID: > A new paper > > "Accuracy of Mathematical Functions in Single, Double, Double Extended, and Quadruple Precision" > by Brian Gladman, Vincenzo Innocente and Paul Zimmermann > https://members.loria.fr/PZimmermann/papers/accuracy.pdf > > details the inputs with generate the worst-case observed errors in different math library implementations. The FDLIBM-related worst cases should be added to the test suite. Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Respond to review feedback, adjust worst-case bounds. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15879/files - new: https://git.openjdk.org/jdk/pull/15879/files/de217d77..98c8e69f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15879&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15879&range=06-07 Stats: 39 lines in 3 files changed: 1 ins; 0 del; 38 mod Patch: https://git.openjdk.org/jdk/pull/15879.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15879/head:pull/15879 PR: https://git.openjdk.org/jdk/pull/15879 From gli at openjdk.org Wed Feb 28 06:17:53 2024 From: gli at openjdk.org (Guoxiong Li) Date: Wed, 28 Feb 2024 06:17:53 GMT Subject: RFR: 8324799: Use correct extension for C++ test headers In-Reply-To: References: Message-ID: On Wed, 28 Feb 2024 01:18:50 GMT, Kim Barrett wrote: > Please review this change that renames some test .h files to .hpp. These > files contain C++ code and should be named accordingly. Some of them contain > uses of NULL, which we change to nullptr. > > The renamed files are: > > test/hotspot/jtreg/vmTestbase/nsk/share/aod/aod.h > test/hotspot/jtreg/vmTestbase/nsk/share/jni/jni_tools.h > test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/jvmti_tools.h > test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/JVMTITools.h > test/hotspot/jtreg/vmTestbase/nsk/share/native/nsk_tools.h > > test/lib/jdk/test/lib/jvmti/jvmti_thread.h > test/lib/jdk/test/lib/jvmti/jvmti_common.h > test/lib/native/testlib_threads.h > > The #include updates were performed mostly mechanically, and builds would fail > if there were mistakes. The exception is test > test/hotspot/jtreg/serviceability/jvmti/FollowReferences/FieldIndices/libFieldIndicesTest.cpp, > which was added after I'd done the mechanical update, so was updated by hand. > > The copyright updates were similarly performed mechanically. All but a handful > of the including files have already had their copyrights updated recently, > likely as part of JDK-8324681. > > Thus, the only "interesting" changes are to the renamed files. > > Testing: mach5 tier1 So large patch. In order to easy to review, it is good to separate such large patch into several patches in the future. Two trivial places need to be adjusted. test/hotspot/jtreg/serviceability/jvmti/events/SingleStep/singlestep01/libsinglestep01.cpp line 28: > 26: #include > 27: #include > 28: #include "jvmti_common.hpp" The copyright of this file is wrong. > * Copyright (c) 200 > * git 3, 2022, Oracle and/or its affiliates. All rights reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. test/hotspot/jtreg/serviceability/jvmti/thread/GetStackTrace/GetStackTraceAndRetransformTest/libGetStackTraceAndRetransformTest.cpp line 27: > 25: #include > 26: #include "jvmti.h" > 27: #include "jvmti_common.hpp" The oracle copyright needs to be added in this file? > * Copyright (c) 2023, Datadog, Inc. All rights reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. ------------- Changes requested by gli (Committer). PR Review: https://git.openjdk.org/jdk/pull/18035#pullrequestreview-1905259144 PR Review Comment: https://git.openjdk.org/jdk/pull/18035#discussion_r1505322535 PR Review Comment: https://git.openjdk.org/jdk/pull/18035#discussion_r1505326445 From clanger at openjdk.org Wed Feb 28 06:37:55 2024 From: clanger at openjdk.org (Christoph Langer) Date: Wed, 28 Feb 2024 06:37:55 GMT Subject: RFR: JDK-8326389: [test] improve assertEquals failure output [v4] In-Reply-To: References: Message-ID: On Tue, 27 Feb 2024 16:48:05 GMT, Matthias Baesken wrote: >> Currently assertEquals has in the failure case sometimes confusing output like : >> >> java.lang.RuntimeException: VM output should contain exactly one RTM locking statistics entry for method compiler.rtm.locking.TestRTMTotalCountIncrRate$Test:? expected 0 to equal 1 >> at jdk.test.lib.Asserts.fail(Asserts.java:634) >> at jdk.test.lib.Asserts.assertEquals(Asserts.java:205) >> >> (I don't think we really expected that for some reason 0 equals 1) >> This should be improved. > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > adjust ms Marked as reviewed by clanger (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/17952#pullrequestreview-1905420462 From clanger at openjdk.org Wed Feb 28 06:58:51 2024 From: clanger at openjdk.org (Christoph Langer) Date: Wed, 28 Feb 2024 06:58:51 GMT Subject: RFR: 8326591: New test JmodExcludedFiles.java fails on Windows when --with-external-symbols-in-bundles=public is used In-Reply-To: <9RR45_rKFq7Syr1gB7zEPqOBgmPf-TeGPOo62M6aFtc=.fff7854c-7c8b-4c97-acbb-8ec6bce5c8d1@github.com> References: <9RR45_rKFq7Syr1gB7zEPqOBgmPf-TeGPOo62M6aFtc=.fff7854c-7c8b-4c97-acbb-8ec6bce5c8d1@github.com> Message-ID: <5cz-G96IGdA_Wt2ovM1icXFURRTV6AjosXTM1XrRyi8=.5bca8095-3059-49a7-80fe-74c562f825f0@github.com> On Fri, 23 Feb 2024 19:18:46 GMT, Christoph Langer wrote: > The new test JmodExcludedFiles.java checks that no debug symbol files are contained in the jmod files. It does not take into account that with configure option --with-external-symbols-in-bundles=public we want to have stripped pdb files, also in jmods, to get native callstacks with line number. > > This modifies the test and checks if equivalent *stripped.pdb files exist when .pdb files are encountered inside jmods. In that case one can assume that --with-external-symbols-in-bundles=public was chosen as configure option. @mlchung, mind to have a look here? Thanks ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/17990#issuecomment-1968346603 From kbarrett at openjdk.org Wed Feb 28 07:06:57 2024 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 28 Feb 2024 07:06:57 GMT Subject: RFR: 8324799: Use correct extension for C++ test headers In-Reply-To: References: Message-ID: <6HffreZJ4swcv8-9QavfrV6On578RKqBPK1Ci9DK91g=.13a46a7c-90af-4b27-b150-5f4dc9731b0d@github.com> On Wed, 28 Feb 2024 06:12:17 GMT, Guoxiong Li wrote: > So large patch. In order to easy to review, it is good to separate such large patch into several patches in the future. I was doing that in prior related changes (see the subtasks of JDK-8324799). But reviewers requested I batch up the remainder, hence this PR. ------------- PR Comment: https://git.openjdk.org/jdk/pull/18035#issuecomment-1968355666 From jpai at openjdk.org Wed Feb 28 07:14:59 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 28 Feb 2024 07:14:59 GMT Subject: RFR: 7036144: GZIPInputStream readTrailer uses faulty available() test for end-of-stream [v6] In-Reply-To: <7eCX4Yx0qM7Ipug5NI-A8I10-22Iyyk-eMh6ELcHV2c=.bd909779-025d-4e71-816d-e4d6539e85ed@github.com> References: <7eCX4Yx0qM7Ipug5NI-A8I10-22Iyyk-eMh6ELcHV2c=.bd909779-025d-4e71-816d-e4d6539e85ed@github.com> Message-ID: On Mon, 5 Feb 2024 23:53:06 GMT, Archie Cobbs wrote: >> `GZIPInputStream`, when looking for a concatenated stream, relies on what the underlying `InputStream` says is how many bytes are `available()`. But this is inappropriate because `InputStream.available()` is just an estimate and is allowed (for example) to always return zero. >> >> The fix is to ignore what's `available()` and just proceed and see what happens. If fewer bytes are available than required, the attempt to extend to another stream is canceled just as it was before, e.g., when the next stream header couldn't be read. > > Archie Cobbs has updated the pull request with a new target base 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-7036144 > - Merge branch 'master' into JDK-7036144 > - Address third round of review comments. > - Address second round of review comments. > - Address review comments. > - Fix bug in GZIPInputStream when underlying available() returns short. Hello Archie, > Edited to add: I said "already a problem in the current code" but should clarify: what I mean is, suppose some clever InputStream were never letting available() return more than the number of compressed bytes remaining. That strategy would not be reliable, because not all reads from the underlying stream are gated with a check of what's available() (for example, see InflaterInputStream.fill()). So I don't think we need to worry about breaking such a case because it's already broken for other reasons. I think what you note is reasonable and accurate. I'll run some experiments against existing corpus of artifacts to see if this proposed change could cause more issues than the current state of GZIPInputStream. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17113#issuecomment-1968364298 From jpai at openjdk.org Wed Feb 28 07:20:53 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 28 Feb 2024 07:20:53 GMT Subject: RFR: 8310837: Use ByteArrayLittleEndian in java.util.zip [v7] In-Reply-To: References: Message-ID: On Tue, 16 Jan 2024 16:38:34 GMT, Glavo wrote: >> 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 incrementally with one additional commit since the last revision: > > Add tests Hello Glavo, I'll need some more time on this to review this. In the meantime, could you update the micro benchmark latest numbers with this latest state? ------------- PR Comment: https://git.openjdk.org/jdk/pull/14632#issuecomment-1968371386 From mbaesken at openjdk.org Wed Feb 28 08:39:54 2024 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 28 Feb 2024 08:39:54 GMT Subject: RFR: JDK-8326389: [test] improve assertEquals failure output [v4] In-Reply-To: References: Message-ID: <8-ph24LaZjnYfmwSXwF6YmDNNx1GRoMPVaP2CpA2wX4=.aa49d10f-ca4f-472c-9703-602166e0f5fc@github.com> On Tue, 27 Feb 2024 16:48:05 GMT, Matthias Baesken wrote: >> Currently assertEquals has in the failure case sometimes confusing output like : >> >> java.lang.RuntimeException: VM output should contain exactly one RTM locking statistics entry for method compiler.rtm.locking.TestRTMTotalCountIncrRate$Test:? expected 0 to equal 1 >> at jdk.test.lib.Asserts.fail(Asserts.java:634) >> at jdk.test.lib.Asserts.assertEquals(Asserts.java:205) >> >> (I don't think we really expected that for some reason 0 equals 1) >> This should be improved. > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > adjust ms Thanks for the reviews ! ------------- PR Comment: https://git.openjdk.org/jdk/pull/17952#issuecomment-1968478987 From mbaesken at openjdk.org Wed Feb 28 08:39:54 2024 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 28 Feb 2024 08:39:54 GMT Subject: Integrated: JDK-8326389: [test] improve assertEquals failure output In-Reply-To: References: Message-ID: On Wed, 21 Feb 2024 15:25:36 GMT, Matthias Baesken wrote: > Currently assertEquals has in the failure case sometimes confusing output like : > > java.lang.RuntimeException: VM output should contain exactly one RTM locking statistics entry for method compiler.rtm.locking.TestRTMTotalCountIncrRate$Test:? expected 0 to equal 1 > at jdk.test.lib.Asserts.fail(Asserts.java:634) > at jdk.test.lib.Asserts.assertEquals(Asserts.java:205) > > (I don't think we really expected that for some reason 0 equals 1) > This should be improved. This pull request has now been integrated. Changeset: 9b1f1e52 Author: Matthias Baesken URL: https://git.openjdk.org/jdk/commit/9b1f1e5294e130ec444b08af1f73d08e86fd91ee Stats: 4 lines in 1 file changed: 0 ins; 3 del; 1 mod 8326389: [test] improve assertEquals failure output Reviewed-by: clanger, jpai ------------- PR: https://git.openjdk.org/jdk/pull/17952 From djelinski at openjdk.org Wed Feb 28 08:57:49 2024 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Wed, 28 Feb 2024 08:57:49 GMT Subject: RFR: JDK-8323186: A faster algorithm for MutablebigInteger.divWord(long, int) [v3] In-Reply-To: References: Message-ID: On Mon, 22 Jan 2024 18:52:32 GMT, fabioromano1 wrote: >> As you note, that would probably require two divisions. I don't know if the JIT compiler can detect that the arguments are the same and emit just one division instead. >> I think your code is good enough for the purpose of [Mutable]BigInteger, and better than the current one. > > @rgiulietti I've added a method to check the results of tests. Hi @fabioromano1, MutableBigInteger.divWord is not a part of the public JDK interface. If you're trying to optimize a method that's publicly available, please add a benchmark for that method. You can find the instructions for running benchmarks [here](https://github.com/openjdk/jdk/blob/master/doc/testing.md#microbenchmarks). You will need to tell configure where it can find JMH, instructions [here](https://github.com/openjdk/jdk/blob/master/doc/testing.md#configuration). If you aren't familiar with JMH, you can find some examples [here](https://github.com/openjdk/jdk/tree/master/test/micro/org/openjdk/bench/java/math). If you check the context where `divWord` is called, you'll notice that it's only used when the dividend is a negative long. If you dig deeper, you'll also notice that dividend is only negative if the divisor is a negative int. With these constraints on the input arguments, the worst-case approximation error is much lower than what you presented in your earlier comment. The `divWord` method might not be worth optimizing. If you take another look at the context where `divWord` is called, you'll probably also notice that the surrounding code can be simplified to `Long.divideUnsigned` and `Long.remainderUnsigned`. These methods are usually optimized by the CPU, so this change might actually improve the performance of some BigInteger operations. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17291#issuecomment-1968511350 From pminborg at openjdk.org Wed Feb 28 09:02:59 2024 From: pminborg at openjdk.org (Per Minborg) Date: Wed, 28 Feb 2024 09:02:59 GMT Subject: RFR: 8310837: Use ByteArrayLittleEndian in java.util.zip [v7] In-Reply-To: References: Message-ID: <7mthJdrNlrn_Xjq3G2a1fZFzUDtaR2Xh2uMxgxpi19g=.df527d1d-7b8f-4dd0-8434-7145dd53eee4@github.com> On Tue, 16 Jan 2024 16:38:34 GMT, Glavo wrote: >> 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 incrementally with one additional commit since the last revision: > > Add tests Nice with better testing for the utility classes. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14632#issuecomment-1968519863 From eirbjo at openjdk.org Wed Feb 28 09:19:20 2024 From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=) Date: Wed, 28 Feb 2024 09:19:20 GMT Subject: RFR: 8326096: Deprecate getTotalIn, getTotalOut methods of java.util.zip.Inflater, java.util.zip.Deflater [v11] In-Reply-To: References: Message-ID: > Please review this PR which proposes that we officially deprecate the following four methods in the `java.util.zip` package: > > * `Inflater.getTotalIn()` > * `Inflater.getTotalOut()` > * `Deflater.getTotalIn()` > * `Deflater.getTotalOut()` > > Since these legacy methods return `int`, they cannot safely return the number of bytes processed without the risk of losing information about the magnitude or even sign of the returned value. > > The corresponding methods `getBytesRead()` and `getBytesWritten()` methods introduced in Java 5 return `long`, and should be used instead when obtaining this information. > > Unrelated to the deprecation itself, the documentation currently does not specify what these methods are expected to return when the number of processed bytes is higher than `Integer.MAX_VALUE`. This PR aims to clarify this in the API specification. > > Initally, this PR handles only `Inflater.getTotalIn()`. The other three methods will be updated once the wordsmithing for this method stabilizes. Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision: Update method description and deprecation note for the three remaining methods ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17919/files - new: https://git.openjdk.org/jdk/pull/17919/files/4eadbf86..b51ff1dc Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17919&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17919&range=09-10 Stats: 24 lines in 2 files changed: 15 ins; 6 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/17919.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17919/head:pull/17919 PR: https://git.openjdk.org/jdk/pull/17919 From eirbjo at openjdk.org Wed Feb 28 09:19:20 2024 From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=) Date: Wed, 28 Feb 2024 09:19:20 GMT Subject: RFR: 8326096: Deprecate getTotalIn, getTotalOut methods of java.util.zip.Inflater, java.util.zip.Deflater [v10] In-Reply-To: References: Message-ID: On Tue, 27 Feb 2024 20:14:27 GMT, Lance Andersen wrote: > Yes please move forward and thank you I have updated javadocs for the remaining methods. The CSR has been proposed and is ready for the initial round of review: https://bugs.openjdk.org/browse/JDK-8326326 ------------- PR Comment: https://git.openjdk.org/jdk/pull/17919#issuecomment-1968547203 From alanb at openjdk.org Wed Feb 28 10:53:53 2024 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 28 Feb 2024 10:53:53 GMT Subject: RFR: 8326096: Deprecate getTotalIn, getTotalOut methods of java.util.zip.Inflater, java.util.zip.Deflater [v11] In-Reply-To: References: Message-ID: On Wed, 28 Feb 2024 09:19:20 GMT, Eirik Bj?rsn?s wrote: >> Please review this PR which proposes that we officially deprecate the following four methods in the `java.util.zip` package: >> >> * `Inflater.getTotalIn()` >> * `Inflater.getTotalOut()` >> * `Deflater.getTotalIn()` >> * `Deflater.getTotalOut()` >> >> Since these legacy methods return `int`, they cannot safely return the number of bytes processed without the risk of losing information about the magnitude or even sign of the returned value. >> >> The corresponding methods `getBytesRead()` and `getBytesWritten()` methods introduced in Java 5 return `long`, and should be used instead when obtaining this information. >> >> Unrelated to the deprecation itself, the documentation currently does not specify what these methods are expected to return when the number of processed bytes is higher than `Integer.MAX_VALUE`. This PR aims to clarify this in the API specification. >> >> Initally, this PR handles only `Inflater.getTotalIn()`. The other three methods will be updated once the wordsmithing for this method stabilizes. > > Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision: > > Update method description and deprecation note for the three remaining methods Thanks for persevering this, looks okay now. ------------- Marked as reviewed by alanb (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17919#pullrequestreview-1905931883 From ihse at openjdk.org Wed Feb 28 11:32:07 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 28 Feb 2024 11:32:07 GMT Subject: RFR: 8326947: Minimize MakeBase.gmk Message-ID: This is part of a general "spring cleaning" of the build system, addressing old code that has bit-rotted, been subject to lava flow, or just had bad or smelly code that we've never gotten around to fix. This particular patch tries to make MakeBase truly minimal; only including the core parts of the build system that all makefiles will need. This is now limited to essential functionality for named parameter functions, variable dependency, tool execution, logging and fixpath functionality. MakeBase still includes Utils.gmk and FileUtils.gmk, and thus "provides" this functionality as well. Separating these out as well will be the subject of a future patch. ------------- Commit messages: - Whitespace fix - MakeBase.gmk should not include MakeIO.gmk anymore - MakeBase.gmk should not include CopyFiles.gmk anymore - Reorder BaseUtils.gmk to make more sense - Move some more functionality to BaseUtils.gmk - Create BaseUtils.gmk with the most basic stuff - Move all file stuff from Utils.gmk to FileUtils.gmk - Document the purpose of MakeBase - Move SOURCE_REVISION_TRACKER to where it is used. - Move timers to InitSupport where they are used - ... and 3 more: https://git.openjdk.org/jdk/compare/1ab6bd43...3c86bcfe Changes: https://git.openjdk.org/jdk/pull/18041/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18041&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8326947 Stats: 1099 lines in 43 files changed: 607 ins; 480 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/18041.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18041/head:pull/18041 PR: https://git.openjdk.org/jdk/pull/18041 From ihse at openjdk.org Wed Feb 28 11:32:07 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 28 Feb 2024 11:32:07 GMT Subject: RFR: 8326947: Minimize MakeBase.gmk In-Reply-To: References: Message-ID: On Wed, 28 Feb 2024 11:24:06 GMT, Magnus Ihse Bursie wrote: > This is part of a general "spring cleaning" of the build system, addressing old code that has bit-rotted, been subject to lava flow, or just had bad or smelly code that we've never gotten around to fix. > > This particular patch tries to make MakeBase truly minimal; only including the core parts of the build system that all makefiles will need. This is now limited to essential functionality for named parameter functions, variable dependency, tool execution, logging and fixpath functionality. MakeBase still includes Utils.gmk and FileUtils.gmk, and thus "provides" this functionality as well. Separating these out as well will be the subject of a future patch. I have verified using `COMPARE_BUILD` on windows-x64, linux-x64, linux-aarch64, macosx-x64 and macosx-aarch64 that there are no differences in the resulting build. ------------- PR Comment: https://git.openjdk.org/jdk/pull/18041#issuecomment-1968778732 From mbaesken at openjdk.org Wed Feb 28 12:34:53 2024 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 28 Feb 2024 12:34:53 GMT Subject: RFR: 8326591: New test JmodExcludedFiles.java fails on Windows when --with-external-symbols-in-bundles=public is used In-Reply-To: <9RR45_rKFq7Syr1gB7zEPqOBgmPf-TeGPOo62M6aFtc=.fff7854c-7c8b-4c97-acbb-8ec6bce5c8d1@github.com> References: <9RR45_rKFq7Syr1gB7zEPqOBgmPf-TeGPOo62M6aFtc=.fff7854c-7c8b-4c97-acbb-8ec6bce5c8d1@github.com> Message-ID: On Fri, 23 Feb 2024 19:18:46 GMT, Christoph Langer wrote: > The new test JmodExcludedFiles.java checks that no debug symbol files are contained in the jmod files. It does not take into account that with configure option --with-external-symbols-in-bundles=public we want to have stripped pdb files, also in jmods, to get native callstacks with line number. > > This modifies the test and checks if equivalent *stripped.pdb files exist when .pdb files are encountered inside jmods. In that case one can assume that --with-external-symbols-in-bundles=public was chosen as configure option. Looks okay to me, but could we print here `RuntimeException(jmodFile + " is expected not to include native debug symbols` not only the jmod but also the unwanted file(s) ? ------------- PR Review: https://git.openjdk.org/jdk/pull/17990#pullrequestreview-1906139346 From lancea at openjdk.org Wed Feb 28 12:36:54 2024 From: lancea at openjdk.org (Lance Andersen) Date: Wed, 28 Feb 2024 12:36:54 GMT Subject: RFR: 8326096: Deprecate getTotalIn, getTotalOut methods of java.util.zip.Inflater, java.util.zip.Deflater [v11] In-Reply-To: References: Message-ID: On Wed, 28 Feb 2024 09:19:20 GMT, Eirik Bj?rsn?s wrote: >> Please review this PR which proposes that we officially deprecate the following four methods in the `java.util.zip` package: >> >> * `Inflater.getTotalIn()` >> * `Inflater.getTotalOut()` >> * `Deflater.getTotalIn()` >> * `Deflater.getTotalOut()` >> >> Since these legacy methods return `int`, they cannot safely return the number of bytes processed without the risk of losing information about the magnitude or even sign of the returned value. >> >> The corresponding methods `getBytesRead()` and `getBytesWritten()` methods introduced in Java 5 return `long`, and should be used instead when obtaining this information. >> >> Unrelated to the deprecation itself, the documentation currently does not specify what these methods are expected to return when the number of processed bytes is greater than `Integer.MAX_VALUE`. This PR aims to clarify this in the API specification. > > Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision: > > Update method description and deprecation note for the three remaining methods Looks good Eirik, thank you for your efforts on the doc updates ------------- Marked as reviewed by lancea (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17919#pullrequestreview-1906144415 From lancea at openjdk.org Wed Feb 28 13:11:54 2024 From: lancea at openjdk.org (Lance Andersen) Date: Wed, 28 Feb 2024 13:11:54 GMT Subject: RFR: 8310837: Use ByteArrayLittleEndian in java.util.zip [v7] In-Reply-To: References: Message-ID: On Tue, 16 Jan 2024 16:38:34 GMT, Glavo wrote: >> 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 incrementally with one additional commit since the last revision: > > Add tests As mentioned earlier, it would be beneficial to measure the potential benefit of this proposed change with ZipFS which has similar albeit slightly different approach to the macros and include as part of this PR of a follow-on PR ------------- PR Comment: https://git.openjdk.org/jdk/pull/14632#issuecomment-1968951462 From jpai at openjdk.org Wed Feb 28 14:00:53 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 28 Feb 2024 14:00:53 GMT Subject: RFR: 8326687: Inconsistent use of "ZIP", "Zip" and "zip" in java.util.zip/jar zipfs javadoc [v2] In-Reply-To: References: Message-ID: On Tue, 27 Feb 2024 16:15:06 GMT, Lance Andersen wrote: >> This PR updates the javadoc and comments within java.util.zip/jar and zipfs module summary so that it is consistent with the use of "ZIP". >> >> In addition, open/src/java.base/share/classes/java/util/zip/package-info.java has been updated to point to the higher level location of the PKWARE APPNOTE.TXT has PKWare recently changed the direct path the the latest version of the spec. >> >> It is also worth noting that error messages were not updated as part of the PR and will be updated separately to keep the javadoc changes separate > > Lance Andersen has updated the pull request incrementally with one additional commit since the last revision: > > Address initial feedback for JDK-8326687 Hello Lance, this doc-only change looks good to me. These changes are merely changing the case of `zip` and aren't changing any specification of the APIs and that looks fine to me. I had imagined that we would be changing only the public API documentations but I suspect you decided to update even code comments and internal class comments to keep everything consistent. I am not opposing it and I ask this so that I can use this decision in future when adding anything in this area or reviewing code. ------------- Marked as reviewed by jpai (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/18011#pullrequestreview-1906340184 From jpai at openjdk.org Wed Feb 28 14:06:57 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 28 Feb 2024 14:06:57 GMT Subject: RFR: 8326687: Inconsistent use of "ZIP", "Zip" and "zip" in java.util.zip/jar zipfs javadoc [v2] In-Reply-To: References: Message-ID: On Tue, 27 Feb 2024 16:15:06 GMT, Lance Andersen wrote: >> This PR updates the javadoc and comments within java.util.zip/jar and zipfs module summary so that it is consistent with the use of "ZIP". >> >> In addition, open/src/java.base/share/classes/java/util/zip/package-info.java has been updated to point to the higher level location of the PKWARE APPNOTE.TXT has PKWare recently changed the direct path the the latest version of the spec. >> >> It is also worth noting that error messages were not updated as part of the PR and will be updated separately to keep the javadoc changes separate > > Lance Andersen has updated the pull request incrementally with one additional commit since the last revision: > > Address initial feedback for JDK-8326687 GitHub doesn't allow me to comment on unchanged lines in the PR, but while reviewing this I noticed 2 things: - It looks like http://www.pkware.com/documents/casestudies/APPNOTE.TXT is now auto redirecting to https://pkware.cachefly.net/webdocs/APPNOTE/APPNOTE-6.3.9.TXT. I'm not sure if its temporary or a permanent thing. - The other thing is we don't seem to have a `@spec` entry in `src/java.base/share/classes/java/util/zip/package-info.java` pointing to http://www.pkware.com/documents/casestudies/APPNOTE.TXT. We are pointing to ZLIB RFC 1950. Do you think we should add a `@spec` entry to point to http://www.pkware.com/documents/casestudies/APPNOTE.TXT? Of course as a separate PR. ------------- PR Comment: https://git.openjdk.org/jdk/pull/18011#issuecomment-1969053529 From gli at openjdk.org Wed Feb 28 14:16:44 2024 From: gli at openjdk.org (Guoxiong Li) Date: Wed, 28 Feb 2024 14:16:44 GMT Subject: RFR: 8326687: Inconsistent use of "ZIP", "Zip" and "zip" in java.util.zip/jar zipfs javadoc [v2] In-Reply-To: References: Message-ID: On Tue, 27 Feb 2024 16:15:06 GMT, Lance Andersen wrote: >> This PR updates the javadoc and comments within java.util.zip/jar and zipfs module summary so that it is consistent with the use of "ZIP". >> >> In addition, open/src/java.base/share/classes/java/util/zip/package-info.java has been updated to point to the higher level location of the PKWARE APPNOTE.TXT has PKWare recently changed the direct path the the latest version of the spec. >> >> It is also worth noting that error messages were not updated as part of the PR and will be updated separately to keep the javadoc changes separate > > Lance Andersen has updated the pull request incrementally with one additional commit since the last revision: > > Address initial feedback for JDK-8326687 I search the package `java.util.zip` and find several `zip64` in the file [ZipConstants64.java](https://github.com/openjdk/jdk/blob/baa67f1130947c7204fc12018d25bfb48528784c/src/java.base/share/classes/java/util/zip/ZipConstants64.java#L51). It seems you didn't fix all the files in the package `java.util.zip/jar`. Is it your intent? Or you miss some files? ------------- PR Review: https://git.openjdk.org/jdk/pull/18011#pullrequestreview-1906378373 From duke at openjdk.org Wed Feb 28 14:21:16 2024 From: duke at openjdk.org (Glavo) Date: Wed, 28 Feb 2024 14:21:16 GMT Subject: RFR: 8310837: Use ByteArrayLittleEndian in java.util.zip [v8] In-Reply-To: References: Message-ID: > Using `ByteArrayLittleEndian` is simpler and faster. > > `make test TEST="micro:java.util.zip.ZipFileOpen"`: > > > Benchmark (size) Mode Cnt Score Error Units > - ZipFileOpen.openCloseZipFile 512 avgt 15 39052.832 ? 107.496 ns/op > + ZipFileOpen.openCloseZipFile 512 avgt 15 36275.539 ? 663.193 ns/op > - ZipFileOpen.openCloseZipFile 1024 avgt 15 77106.494 ? 4159.300 ns/op > + ZipFileOpen.openCloseZipFile 1024 avgt 15 71955.013 ? 2296.050 ns/op Glavo has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision: - Merge branch 'openjdk:master' into zip-utils - Add tests - 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/a9b6b78e..95c29249 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14632&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14632&range=06-07 Stats: 283781 lines in 6242 files changed: 153845 ins; 93433 del; 36503 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 coleenp at openjdk.org Wed Feb 28 14:29:54 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 28 Feb 2024 14:29:54 GMT Subject: RFR: 8324799: Use correct extension for C++ test headers In-Reply-To: References: Message-ID: On Wed, 28 Feb 2024 01:18:50 GMT, Kim Barrett wrote: > Please review this change that renames some test .h files to .hpp. These > files contain C++ code and should be named accordingly. Some of them contain > uses of NULL, which we change to nullptr. > > The renamed files are: > > test/hotspot/jtreg/vmTestbase/nsk/share/aod/aod.h > test/hotspot/jtreg/vmTestbase/nsk/share/jni/jni_tools.h > test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/jvmti_tools.h > test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/JVMTITools.h > test/hotspot/jtreg/vmTestbase/nsk/share/native/nsk_tools.h > > test/lib/jdk/test/lib/jvmti/jvmti_thread.h > test/lib/jdk/test/lib/jvmti/jvmti_common.h > test/lib/native/testlib_threads.h > > The #include updates were performed mostly mechanically, and builds would fail > if there were mistakes. The exception is test > test/hotspot/jtreg/serviceability/jvmti/FollowReferences/FieldIndices/libFieldIndicesTest.cpp, > which was added after I'd done the mechanical update, so was updated by hand. > > The copyright updates were similarly performed mechanically. All but a handful > of the including files have already had their copyrights updated recently, > likely as part of JDK-8324681. > > Thus, the only "interesting" changes are to the renamed files. > > Testing: mach5 tier1 I asked for these to be done together since it's the same scrolling for each of these. I added suggestions, but please feel free to ignore them since it would be prudent pull down and to rebuild after making them and it's not worth it. test/hotspot/jtreg/serviceability/jvmti/DynamicCodeGenerated/libDynamicCodeGenerated.cpp line 25: > 23: > 24: #include > 25: #include Is jvmti.h a C file? Sometimes it has <> sometimes it's included with "". I don't expect to see a change. I was just curious. test/hotspot/jtreg/serviceability/jvmti/vthread/FollowReferences/libVThreadStackRefTest.cpp line 26: > 24: #include > 25: #include > 26: #include Should this be in quotes rather than <> ? test/hotspot/jtreg/serviceability/jvmti/vthread/GetThreadStateMountedTest/libGetThreadStateMountedTest.cpp line 26: > 24: #include > 25: #include > 26: #include Another. test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetClassStatus/getclstat007/getclstat007.cpp line 28: > 26: #include "jvmti.h" > 27: #include "agent_common.hpp" > 28: #include "JVMTITools.hpp" There's a lower case jvmti_tools.hpp and an uppercase JVMTITools.hpp now. Maybe someone could do a cleanup of these tests (please!) test/hotspot/jtreg/vmTestbase/nsk/jvmti/RetransformClasses/retransform004/retransform004.cpp line 29: > 27: #include > 28: #include "agent_common.hpp" > 29: #include Suggestion: #include "jvmti_tools.hpp" ------------- Marked as reviewed by coleenp (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/18035#pullrequestreview-1906370538 PR Review Comment: https://git.openjdk.org/jdk/pull/18035#discussion_r1506026145 PR Review Comment: https://git.openjdk.org/jdk/pull/18035#discussion_r1506031049 PR Review Comment: https://git.openjdk.org/jdk/pull/18035#discussion_r1506031853 PR Review Comment: https://git.openjdk.org/jdk/pull/18035#discussion_r1506038573 PR Review Comment: https://git.openjdk.org/jdk/pull/18035#discussion_r1506045478 From coleenp at openjdk.org Wed Feb 28 14:29:55 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 28 Feb 2024 14:29:55 GMT Subject: RFR: 8324799: Use correct extension for C++ test headers In-Reply-To: References: Message-ID: On Wed, 28 Feb 2024 14:13:58 GMT, Coleen Phillimore wrote: >> Please review this change that renames some test .h files to .hpp. These >> files contain C++ code and should be named accordingly. Some of them contain >> uses of NULL, which we change to nullptr. >> >> The renamed files are: >> >> test/hotspot/jtreg/vmTestbase/nsk/share/aod/aod.h >> test/hotspot/jtreg/vmTestbase/nsk/share/jni/jni_tools.h >> test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/jvmti_tools.h >> test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/JVMTITools.h >> test/hotspot/jtreg/vmTestbase/nsk/share/native/nsk_tools.h >> >> test/lib/jdk/test/lib/jvmti/jvmti_thread.h >> test/lib/jdk/test/lib/jvmti/jvmti_common.h >> test/lib/native/testlib_threads.h >> >> The #include updates were performed mostly mechanically, and builds would fail >> if there were mistakes. The exception is test >> test/hotspot/jtreg/serviceability/jvmti/FollowReferences/FieldIndices/libFieldIndicesTest.cpp, >> which was added after I'd done the mechanical update, so was updated by hand. >> >> The copyright updates were similarly performed mechanically. All but a handful >> of the including files have already had their copyrights updated recently, >> likely as part of JDK-8324681. >> >> Thus, the only "interesting" changes are to the renamed files. >> >> Testing: mach5 tier1 > > test/hotspot/jtreg/serviceability/jvmti/vthread/FollowReferences/libVThreadStackRefTest.cpp line 26: > >> 24: #include >> 25: #include >> 26: #include > > Should this be in quotes rather than <> ? Suggestion: #include "jvmti_common.hpp" > test/hotspot/jtreg/serviceability/jvmti/vthread/GetThreadStateMountedTest/libGetThreadStateMountedTest.cpp line 26: > >> 24: #include >> 25: #include >> 26: #include > > Another. Suggestion: #include "jvmti_common.hpp" ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18035#discussion_r1506033122 PR Review Comment: https://git.openjdk.org/jdk/pull/18035#discussion_r1506033741 From coleenp at openjdk.org Wed Feb 28 14:29:55 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 28 Feb 2024 14:29:55 GMT Subject: RFR: 8324799: Use correct extension for C++ test headers In-Reply-To: References: Message-ID: On Wed, 28 Feb 2024 03:58:39 GMT, Guoxiong Li wrote: >> Please review this change that renames some test .h files to .hpp. These >> files contain C++ code and should be named accordingly. Some of them contain >> uses of NULL, which we change to nullptr. >> >> The renamed files are: >> >> test/hotspot/jtreg/vmTestbase/nsk/share/aod/aod.h >> test/hotspot/jtreg/vmTestbase/nsk/share/jni/jni_tools.h >> test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/jvmti_tools.h >> test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/JVMTITools.h >> test/hotspot/jtreg/vmTestbase/nsk/share/native/nsk_tools.h >> >> test/lib/jdk/test/lib/jvmti/jvmti_thread.h >> test/lib/jdk/test/lib/jvmti/jvmti_common.h >> test/lib/native/testlib_threads.h >> >> The #include updates were performed mostly mechanically, and builds would fail >> if there were mistakes. The exception is test >> test/hotspot/jtreg/serviceability/jvmti/FollowReferences/FieldIndices/libFieldIndicesTest.cpp, >> which was added after I'd done the mechanical update, so was updated by hand. >> >> The copyright updates were similarly performed mechanically. All but a handful >> of the including files have already had their copyrights updated recently, >> likely as part of JDK-8324681. >> >> Thus, the only "interesting" changes are to the renamed files. >> >> Testing: mach5 tier1 > > test/hotspot/jtreg/serviceability/jvmti/events/SingleStep/singlestep01/libsinglestep01.cpp line 28: > >> 26: #include >> 27: #include >> 28: #include "jvmti_common.hpp" > > The copyright of this file is wrong. > >> * Copyright (c) 200 >> * git 3, 2022, Oracle and/or its affiliates. All rights reserved. >> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. It's weird that our jcheck tools didn't find the broken copyright. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18035#discussion_r1506027798 From lancea at openjdk.org Wed Feb 28 14:35:53 2024 From: lancea at openjdk.org (Lance Andersen) Date: Wed, 28 Feb 2024 14:35:53 GMT Subject: RFR: 8326687: Inconsistent use of "ZIP", "Zip" and "zip" in java.util.zip/jar zipfs javadoc [v2] In-Reply-To: References: Message-ID: <6zOtUk9RRjyRQolkPdX-33nBCrH8hCk7TaGsGA92Rds=.96ed98fb-6b44-4ef7-b64e-519d102a2d02@github.com> On Wed, 28 Feb 2024 14:13:57 GMT, Guoxiong Li wrote: > I search the package `java.util.zip` and find several `zip64` in the file [ZipConstants64.java](https://github.com/openjdk/jdk/blob/baa67f1130947c7204fc12018d25bfb48528784c/src/java.base/share/classes/java/util/zip/ZipConstants64.java#L51). It seems you didn't fix all the files in the package `java.util.zip/jar`. Is it your intent? Or you miss some files? The intent of the change is to make the javadoc consistent. There were a couple of files that Eirik mentioned that I addressed but as I indicated in my reply, unless there is a missing javadoc update, I do not plan to address other areas with this PR but can/will in a following ------------- PR Comment: https://git.openjdk.org/jdk/pull/18011#issuecomment-1969116524 From gli at openjdk.org Wed Feb 28 14:40:54 2024 From: gli at openjdk.org (Guoxiong Li) Date: Wed, 28 Feb 2024 14:40:54 GMT Subject: RFR: 8326687: Inconsistent use of "ZIP", "Zip" and "zip" in java.util.zip/jar zipfs javadoc [v2] In-Reply-To: References: Message-ID: On Tue, 27 Feb 2024 16:15:06 GMT, Lance Andersen wrote: >> This PR updates the javadoc and comments within java.util.zip/jar and zipfs module summary so that it is consistent with the use of "ZIP". >> >> In addition, open/src/java.base/share/classes/java/util/zip/package-info.java has been updated to point to the higher level location of the PKWARE APPNOTE.TXT has PKWare recently changed the direct path the the latest version of the spec. >> >> It is also worth noting that error messages were not updated as part of the PR and will be updated separately to keep the javadoc changes separate > > Lance Andersen has updated the pull request incrementally with one additional commit since the last revision: > > Address initial feedback for JDK-8326687 > I do not plan to address other areas with this PR but can/will in a following OK. Looks good. ------------- Marked as reviewed by gli (Committer). PR Review: https://git.openjdk.org/jdk/pull/18011#pullrequestreview-1906443439 From lancea at openjdk.org Wed Feb 28 14:40:54 2024 From: lancea at openjdk.org (Lance Andersen) Date: Wed, 28 Feb 2024 14:40:54 GMT Subject: RFR: 8326687: Inconsistent use of "ZIP", "Zip" and "zip" in java.util.zip/jar zipfs javadoc [v2] In-Reply-To: References: Message-ID: <_bJl32Vu-yAE9gVidjNGnqnw00Obc23KUt6Y4_yp7Og=.17f190aa-490d-4e95-9586-efc8a6724053@github.com> On Wed, 28 Feb 2024 13:58:01 GMT, Jaikiran Pai wrote: > Hello Lance, this doc-only change looks good to me. > > These changes are merely changing the case of `zip` and aren't changing any specification of the APIs and that looks fine to me. > > I had imagined that we would be changing only the public API documentations but I suspect you decided to update even code comments and internal class comments to keep everything consistent. I am not opposing it and I ask this so that I can use this decision in future when adding anything in this area or reviewing code. Hi Jai, thank you. As part of updating the relevant class which contained public facing javadoc, I also updated the casing for comments as you point out for consistency. I did not want to go through all of the tests and non-public facing classes as part of this PR. ------------- PR Comment: https://git.openjdk.org/jdk/pull/18011#issuecomment-1969122748 From duke at openjdk.org Wed Feb 28 14:45:44 2024 From: duke at openjdk.org (Glavo) Date: Wed, 28 Feb 2024 14:45:44 GMT Subject: RFR: 8310837: Use ByteArrayLittleEndian in java.util.zip [v7] In-Reply-To: References: Message-ID: On Wed, 28 Feb 2024 07:17:42 GMT, Jaikiran Pai wrote: > Hello Glavo, I'll need some more time on this to review this. In the meantime, could you update the micro benchmark latest numbers with this latest state? Latest results: Benchmark (size) Mode Cnt Score Error Units - ZipFileOpen.openCloseZipFile 512 avgt 15 55411.637 ? 2010.322 ns/op + ZipFileOpen.openCloseZipFile 512 avgt 15 53247.244 ? 602.826 ns/op - ZipFileOpen.openCloseZipFile 1024 avgt 15 99983.208 ? 374.463 ns/op + ZipFileOpen.openCloseZipFile 1024 avgt 15 96463.939 ? 273.324 ns/op - ZipFileOpen.openCloseZipFilex2 512 avgt 15 57308.739 ? 1627.708 ns/op + ZipFileOpen.openCloseZipFilex2 512 avgt 15 54735.296 ? 241.473 ns/op - ZipFileOpen.openCloseZipFilex2 1024 avgt 15 102068.887 ? 318.778 ns/op + ZipFileOpen.openCloseZipFilex2 1024 avgt 15 98095.240 ? 319.524 ns/op ------------- PR Comment: https://git.openjdk.org/jdk/pull/14632#issuecomment-1969134039 From rgiulietti at openjdk.org Wed Feb 28 14:46:58 2024 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Wed, 28 Feb 2024 14:46:58 GMT Subject: RFR: 8326718: Test java/util/Formatter/Padding.java does not timeout on large inputs before JDK-8299677 In-Reply-To: <9W2VJhGtXz4ZJvYJl08lDr-YR5SSFTRTYgcORV1qVR4=.2a9a77c5-373d-4ddb-9d7b-a19c38559e78@github.com> References: <9W2VJhGtXz4ZJvYJl08lDr-YR5SSFTRTYgcORV1qVR4=.2a9a77c5-373d-4ddb-9d7b-a19c38559e78@github.com> Message-ID: On Tue, 27 Feb 2024 20:37:03 GMT, Chad Rakoczy wrote: >> The fix in JDK-8299677 serves it's intended purpose but the test added with it does not test that. The original test does not timeout before or after the fix which is the issue. >> >> "8326718: Test java/util/Formatter/Padding.java does not timeout on large inputs after JDK-8299677" >> This is the expected case. Should the title be what the issue is or what the fix is? To me this sounds like the test should be timing out or was timing out after JDK-8299677 >> >> Maybe a better title is >> "8326718: Test java/util/Formatter/Padding.java should timeout on large inputs before fix in JDK-8299677" > >> @chadrako The title of the issue should succinctly describe the problem at the time it is filed. > > Then I feel like the current title is correct. The issue at the time of filing is that `Padding.java` does not timeout on large inputs before the fix (which is should but doesn't) that was implemented in JDK-8299677 > > I'm open to other's opinions on this as well @chadrako OK, I now get what you mean with the description in the title. Although it should be noted that the tests were introduced with JDK-8299677 and didn't exercise the large widths in the format specifications, so they could not timeout neither before nor after the fix as they were not tested. So maybe yes, your second proposal > Maybe a better title is > "8326718: Test java/util/Formatter/Padding.java should timeout on large inputs before fix in JDK-8299677" > sounds better. ------------- PR Comment: https://git.openjdk.org/jdk/pull/18033#issuecomment-1969138311 From lancea at openjdk.org Wed Feb 28 14:53:44 2024 From: lancea at openjdk.org (Lance Andersen) Date: Wed, 28 Feb 2024 14:53:44 GMT Subject: RFR: 8326687: Inconsistent use of "ZIP", "Zip" and "zip" in java.util.zip/jar zipfs javadoc [v2] In-Reply-To: References: Message-ID: On Wed, 28 Feb 2024 14:03:58 GMT, Jaikiran Pai wrote: > GitHub doesn't allow me to comment on unchanged lines in the PR, but while reviewing this I noticed 2 things: > > * It looks like http://www.pkware.com/documents/casestudies/APPNOTE.TXT is now auto redirecting to https://pkware.cachefly.net/webdocs/APPNOTE/APPNOTE-6.3.9.TXT. I'm not sure if it's temporary or a permanent thing. I cannot answer that specifically but we need to rely on PKWARE to keep this as accurate as possible. The link has been broken several times by PKWare so I think the best that we can do is keep checking. > * The other thing is we don't seem to have a `@spec` entry in `src/java.base/share/classes/java/util/zip/package-info.java` pointing to http://www.pkware.com/documents/casestudies/APPNOTE.TXT. We are pointing to ZLIB RFC 1950. Do you think we should add a `@spec` entry to point to http://www.pkware.com/documents/casestudies/APPNOTE.TXT? Of course as a separate PR. Good Question, let's discuss and handle separately as I don't know the history of why it was not included ------------- PR Comment: https://git.openjdk.org/jdk/pull/18011#issuecomment-1969151426 From gli at openjdk.org Wed Feb 28 14:58:54 2024 From: gli at openjdk.org (Guoxiong Li) Date: Wed, 28 Feb 2024 14:58:54 GMT Subject: RFR: 8326172: Dubious claim on long[]/double[] alignment in MemorySegment javadoc [v3] In-Reply-To: <9WTuz_2iRFHMBacK8ajMsC3wuyNl2IXFV1ihsfPDjaU=.46032b20-f8b3-496f-b766-48cb1ddc66ce@github.com> References: <9WTuz_2iRFHMBacK8ajMsC3wuyNl2IXFV1ihsfPDjaU=.46032b20-f8b3-496f-b766-48cb1ddc66ce@github.com> Message-ID: <5VF0aYo6wbgKhYwW7wQt1rVTbqVT3J56vyW4Hw9IaxI=.313fd87f-c610-4f9f-9120-e20d48d07533@github.com> On Mon, 26 Feb 2024 15:10:55 GMT, Maurizio Cimadamore wrote: >> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: >> >> re-widen test > > src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 328: > >> 326: * physical address 1010.

    • >> 327: *
  • The starting physical address of a {@code long[]} array will be 8-byte aligned >> 328: * (e.g. 1000), so that successive long elements occur at 8-byte aligned addresses > > I believe there might be other changes required. I see the following sentences in the javadoc: > > > * In other words, heap segments feature a (platform-dependent) maximum > * alignment which is derived from the size of the elements of the Java array backing the > * segment, as shown in the following table: > ``` > > > * In such circumstances, clients have two options. They can use a heap segment backed > * by a different array type (e.g. {@code long[]}), capable of supporting greater maximum > * alignment. More specifically, the maximum alignment associated with {@code long[]} is > * set to {@code ValueLayout.JAVA_LONG.byteAlignment()} which is a platform-dependent > * value (set to {@code ValueLayout.ADDRESS.byteSize()}). That is, {@code long[]}) is > * guaranteed to provide at least 8-byte alignment in 64-bit platforms, but only 4-byte > * alignment in 32-bit platforms: > ``` > > ``` > * In practice, the Java runtime lays out arrays in memory so that each n-byte element > * occurs at an n-byte aligned physical address (except for {@code long[]} and > * {@code double[]}, where alignment is platform-dependent, as explained below). > ``` > Hi @mcimadamore, thanks for making a comment in an OpenJDK project! > > All comments and discussions in the OpenJDK Community must be made available under the OpenJDK [Terms of Use](https://openjdk.java.net/legal/tou/). If you already are an OpenJDK [Author](https://openjdk.java.net/bylaws#author), [Committer](https://openjdk.java.net/bylaws#committer) or [Reviewer](https://openjdk.java.net/bylaws#reviewer), please click [here](https://bugs.openjdk.java.net/secure/CreateIssue.jspa?pid=11300&issuetype=1) to open a new issue so that we can record that fact. Please Use "Add GitHub user mcimadamore" for the summary. > > If you are not an OpenJDK Author, Committer or Reviewer, simply check the box below to accept the OpenJDK Terms of Use for your comments. > > * [ ] I agree to the [OpenJDK Terms of Use](https://openjdk.java.net/legal/tou/) for all comments I make in a project in the [OpenJDK GitHub organization](https://github.com/openjdk). > > Your comment will be automatically restored once you have accepted the OpenJDK [Terms of Use](https://openjdk.java.net/legal/tou/). It is strange to see this comment because @mcimadamore had already been a member in OpenJDK. The SKARA bot may meet a bug. CC'ing @erikj79 and @zhaosongzs . ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18007#discussion_r1506099034 From lancea at openjdk.org Wed Feb 28 17:16:57 2024 From: lancea at openjdk.org (Lance Andersen) Date: Wed, 28 Feb 2024 17:16:57 GMT Subject: Integrated: 8326687: Inconsistent use of "ZIP", "Zip" and "zip" in java.util.zip/jar zipfs javadoc In-Reply-To: References: Message-ID: <_4PZwtidigoz0Ekk-XjBeseIPbvB2pD9Y3xwHPY8pH8=.a634b673-1bbd-4815-8978-2db1ead406bc@github.com> On Mon, 26 Feb 2024 19:55:47 GMT, Lance Andersen wrote: > This PR updates the javadoc and comments within java.util.zip/jar and zipfs module summary so that it is consistent with the use of "ZIP". > > In addition, open/src/java.base/share/classes/java/util/zip/package-info.java has been updated to point to the higher level location of the PKWARE APPNOTE.TXT has PKWare recently changed the direct path the the latest version of the spec. > > It is also worth noting that error messages were not updated as part of the PR and will be updated separately to keep the javadoc changes separate This pull request has now been integrated. Changeset: 38ad5145 Author: Lance Andersen URL: https://git.openjdk.org/jdk/commit/38ad514589764d16b312152474e2446c3339da39 Stats: 123 lines in 12 files changed: 0 ins; 0 del; 123 mod 8326687: Inconsistent use of "ZIP", "Zip" and "zip" in java.util.zip/jar zipfs javadoc Reviewed-by: dfuchs, jpai, gli ------------- PR: https://git.openjdk.org/jdk/pull/18011 From darcy at openjdk.org Wed Feb 28 18:59:55 2024 From: darcy at openjdk.org (Joe Darcy) Date: Wed, 28 Feb 2024 18:59:55 GMT Subject: RFR: JDK-8316708: Augment WorstCaseTests with more cases [v8] In-Reply-To: References: Message-ID: On Wed, 28 Feb 2024 06:08:18 GMT, Joe Darcy wrote: >> A new paper >> >> "Accuracy of Mathematical Functions in Single, Double, Double Extended, and Quadruple Precision" >> by Brian Gladman, Vincenzo Innocente and Paul Zimmermann >> https://members.loria.fr/PZimmermann/papers/accuracy.pdf >> >> details the inputs with generate the worst-case observed errors in different math library implementations. The FDLIBM-related worst cases should be added to the test suite. > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > Respond to review feedback, adjust worst-case bounds. Using high-precision results from http://www.apfloat.org/calculator/, bounds in the worst-case test adjusted to the bracketing floating-point value closer to zero. Updated tests run successfully on Oracle cross-platform build and test system. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15879#issuecomment-1969641261 From brian.burkhalter at oracle.com Wed Feb 28 19:24:04 2024 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 28 Feb 2024 19:24:04 +0000 Subject: Result: New Core Libraries Group Member: Raffaello Giulietti Message-ID: <99DFD921-F883-4C45-A906-7C5A18B0D815@oracle.com> The vote for Raffaello Giulietti [1] is now closed. Yes: 14 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. Brian Burkhalter [1] https://mail.openjdk.org/pipermail/core-libs-dev/2024-February/119208.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From erikj at openjdk.org Wed Feb 28 19:34:01 2024 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 28 Feb 2024 19:34:01 GMT Subject: RFR: 8326891: Prefer RPATH over RUNPATH for $ORIGIN rpaths in internal JDK binaries Message-ID: Executables and dynamic libraries on Linux can encode a search path that the dynamic linker will use when looking up library dependencies, generally referred to as an "rpath". In the JDK we use this with the $ORIGIN feature to set search paths relative to the location of the binary itself. Typically executables in the bin/ directory have the rpath "$ORIGIN/../lib" to find libjli.so. Most of the libraries in lib/ have rpath set to just "$ORIGIN" to find each other. There are two different types of such rpaths, RPATH and RUNPATH. The former is the earlier incantation but RUNPATH has been around since about 2003 and has been default in prominent Linux distros for a long time, and now also seems to be default in the linker directly from binutils. The toolchain used by Oracle defaulted to RPATH until at least JDK 11, but since then with some toolchain upgrade, the default was flipped to RUNPATH. The main (relevant in this case) difference between the two is that RPATH is considered before the LD_LIBRARY_PATH environment variable, while RUNPATH is only considered after LD_LIBRARY_PATH. For libraries that are part of a Linux distribution, letting users, or the system, control and override builtin rpaths with LD_LIBRARY_PATH seems like a reasonable thing to prefer. However, for the JDK, there really is no usecase for having an externally configured LD_LIBRARY_PATH potentially getting in the way of the JDK libraries finding each other correctly. If a user environment sets LD_LIBRARY_PATH, and there is a library in that path with the same name as a JDK library (e.g. libnet.so or some other generically named library) that external library will be loaded instead of the JDK internal library and that is basically guaranteed to break the JDK. There is no supported usecase that I can think of for injecting other versions of such libraries in a JDK distribution. I propose that we explicitly configure the JDK build to set RPATH instead of RUNPATH for Linux binaries. This is done with the linker flag "--disable-new-dtags". ------------- Commit messages: - JDK-8326891 Changes: https://git.openjdk.org/jdk/pull/18050/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18050&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8326891 Stats: 9 lines in 2 files changed: 3 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/18050.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18050/head:pull/18050 PR: https://git.openjdk.org/jdk/pull/18050 From lmesnik at openjdk.org Wed Feb 28 19:50:43 2024 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Wed, 28 Feb 2024 19:50:43 GMT Subject: RFR: 8324799: Use correct extension for C++ test headers In-Reply-To: References: Message-ID: On Wed, 28 Feb 2024 01:18:50 GMT, Kim Barrett wrote: > Please review this change that renames some test .h files to .hpp. These > files contain C++ code and should be named accordingly. Some of them contain > uses of NULL, which we change to nullptr. > > The renamed files are: > > test/hotspot/jtreg/vmTestbase/nsk/share/aod/aod.h > test/hotspot/jtreg/vmTestbase/nsk/share/jni/jni_tools.h > test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/jvmti_tools.h > test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/JVMTITools.h > test/hotspot/jtreg/vmTestbase/nsk/share/native/nsk_tools.h > > test/lib/jdk/test/lib/jvmti/jvmti_thread.h > test/lib/jdk/test/lib/jvmti/jvmti_common.h > test/lib/native/testlib_threads.h > > The #include updates were performed mostly mechanically, and builds would fail > if there were mistakes. The exception is test > test/hotspot/jtreg/serviceability/jvmti/FollowReferences/FieldIndices/libFieldIndicesTest.cpp, > which was added after I'd done the mechanical update, so was updated by hand. > > The copyright updates were similarly performed mechanically. All but a handful > of the including files have already had their copyrights updated recently, > likely as part of JDK-8324681. > > Thus, the only "interesting" changes are to the renamed files. > > Testing: mach5 tier1 Marked as reviewed by lmesnik (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/18035#pullrequestreview-1907166501 From eirbjo at gmail.com Wed Feb 28 21:39:08 2024 From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=) Date: Wed, 28 Feb 2024 22:39:08 +0100 Subject: RFD: java.util.jar.Manifest.make72Safe has an invalid @deprecation tag Message-ID: Hi, The non-public method java.util.jar.Manifest.make72Safe is marked @Deprecated(since="13"). However, the Javadoc comment has a '@deprecation' tag which presumably should have been `@deprecated`. I first thought of proposing a PR to fix the invalid tag, but then I noticed that the method is non-public and has no callers in OpenJDK. Not sure I understand why this internal method was marked deprecated in the first place and not simply removed? Are we worried about people calling this reflectively? What would be the best way to go about this? (a) Do nothing (b) Just fix the tag @deprecation -> @deprecated (c) Fix the tag, add forRemoval=true (d) Just delete the method altogether (it's internal after all). Cheers, Eirik. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbarrett at openjdk.org Thu Feb 29 00:16:28 2024 From: kbarrett at openjdk.org (Kim Barrett) Date: Thu, 29 Feb 2024 00:16:28 GMT Subject: RFR: 8324799: Use correct extension for C++ test headers [v2] In-Reply-To: References: Message-ID: > Please review this change that renames some test .h files to .hpp. These > files contain C++ code and should be named accordingly. Some of them contain > uses of NULL, which we change to nullptr. > > The renamed files are: > > test/hotspot/jtreg/vmTestbase/nsk/share/aod/aod.h > test/hotspot/jtreg/vmTestbase/nsk/share/jni/jni_tools.h > test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/jvmti_tools.h > test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/JVMTITools.h > test/hotspot/jtreg/vmTestbase/nsk/share/native/nsk_tools.h > > test/lib/jdk/test/lib/jvmti/jvmti_thread.h > test/lib/jdk/test/lib/jvmti/jvmti_common.h > test/lib/native/testlib_threads.h > > The #include updates were performed mostly mechanically, and builds would fail > if there were mistakes. The exception is test > test/hotspot/jtreg/serviceability/jvmti/FollowReferences/FieldIndices/libFieldIndicesTest.cpp, > which was added after I'd done the mechanical update, so was updated by hand. > > The copyright updates were similarly performed mechanically. All but a handful > of the including files have already had their copyrights updated recently, > likely as part of JDK-8324681. > > Thus, the only "interesting" changes are to the renamed files. > > Testing: mach5 tier1 Kim Barrett has updated the pull request incrementally with two additional commits since the last revision: - add Oracle copyright - fix busted copyright text ------------- Changes: - all: https://git.openjdk.org/jdk/pull/18035/files - new: https://git.openjdk.org/jdk/pull/18035/files/4154005e..53f93950 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=18035&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18035&range=00-01 Stats: 3 lines in 2 files changed: 1 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/18035.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18035/head:pull/18035 PR: https://git.openjdk.org/jdk/pull/18035 From kbarrett at openjdk.org Thu Feb 29 00:16:29 2024 From: kbarrett at openjdk.org (Kim Barrett) Date: Thu, 29 Feb 2024 00:16:29 GMT Subject: RFR: 8324799: Use correct extension for C++ test headers [v2] In-Reply-To: References: Message-ID: On Wed, 28 Feb 2024 14:11:49 GMT, Coleen Phillimore wrote: >> test/hotspot/jtreg/serviceability/jvmti/events/SingleStep/singlestep01/libsinglestep01.cpp line 28: >> >>> 26: #include >>> 27: #include >>> 28: #include "jvmti_common.hpp" >> >> The copyright of this file is wrong. >> >>> * Copyright (c) 200 >>> * git 3, 2022, Oracle and/or its affiliates. All rights reserved. >>> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > > It's weird that our jcheck tools didn't find the broken copyright. I thought it was odd too, so started a discussion on an internal slack channel about copyright checking. It turns out there are a number that need some work. I'm fixing this one, removing the newline and "git " and updating the second year. The starting year of 2003 seems odd, since this file seems to be fairly new (from Virtual Threads), but 2003 is also what's in the adjacent .java file. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18035#discussion_r1506813867 From kbarrett at openjdk.org Thu Feb 29 00:16:29 2024 From: kbarrett at openjdk.org (Kim Barrett) Date: Thu, 29 Feb 2024 00:16:29 GMT Subject: RFR: 8324799: Use correct extension for C++ test headers [v2] In-Reply-To: References: Message-ID: On Wed, 28 Feb 2024 04:06:08 GMT, Guoxiong Li wrote: >> Kim Barrett has updated the pull request incrementally with two additional commits since the last revision: >> >> - add Oracle copyright >> - fix busted copyright text > > test/hotspot/jtreg/serviceability/jvmti/thread/GetStackTrace/GetStackTraceAndRetransformTest/libGetStackTraceAndRetransformTest.cpp line 27: > >> 25: #include >> 26: #include "jvmti.h" >> 27: #include "jvmti_common.hpp" > > The oracle copyright needs to be added in this file? > >> * Copyright (c) 2023, Datadog, Inc. All rights reserved. >> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. We've touched this a couple times recently. Updating. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18035#discussion_r1506814342 From kbarrett at openjdk.org Thu Feb 29 00:16:29 2024 From: kbarrett at openjdk.org (Kim Barrett) Date: Thu, 29 Feb 2024 00:16:29 GMT Subject: RFR: 8324799: Use correct extension for C++ test headers [v2] In-Reply-To: References: Message-ID: On Wed, 28 Feb 2024 14:15:25 GMT, Coleen Phillimore wrote: >> test/hotspot/jtreg/serviceability/jvmti/vthread/FollowReferences/libVThreadStackRefTest.cpp line 26: >> >>> 24: #include >>> 25: #include >>> 26: #include >> >> Should this be in quotes rather than <> ? > > Suggestion: > > #include "jvmti_common.hpp" Not making those kinds of changes in this PR. Also surprised this is using ``. It seems there are a number of tests doing that. I'll file a bug for that. https://bugs.openjdk.org/browse/JDK-8326999 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18035#discussion_r1506821728 From kbarrett at openjdk.org Thu Feb 29 00:16:29 2024 From: kbarrett at openjdk.org (Kim Barrett) Date: Thu, 29 Feb 2024 00:16:29 GMT Subject: RFR: 8324799: Use correct extension for C++ test headers [v2] In-Reply-To: References: Message-ID: On Wed, 28 Feb 2024 14:18:58 GMT, Coleen Phillimore wrote: >> Kim Barrett has updated the pull request incrementally with two additional commits since the last revision: >> >> - add Oracle copyright >> - fix busted copyright text > > test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetClassStatus/getclstat007/getclstat007.cpp line 28: > >> 26: #include "jvmti.h" >> 27: #include "agent_common.hpp" >> 28: #include "JVMTITools.hpp" > > There's a lower case jvmti_tools.hpp and an uppercase JVMTITools.hpp now. Maybe someone could do a cleanup of these tests (please!) Agreed that's kind of odd, though not new (they were both previously .h files). There are lots of odd things in vmTestbase tests - recall what the README.md in that directory says. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18035#discussion_r1506824801 From duke at openjdk.org Thu Feb 29 01:57:52 2024 From: duke at openjdk.org (Chris Hennick) Date: Thu, 29 Feb 2024 01:57:52 GMT Subject: RFR: 8326227: Rounding error that may distort computeNextGaussian results [v3] In-Reply-To: References: Message-ID: <8rFBTqGfnBjAfEKhwpUbRwIZyksWI0a1iCor7zARM3Y=.732a7a06-0cba-461f-861d-f36a65f29e7a@github.com> On Wed, 21 Feb 2024 02:18:08 GMT, Chris Hennick wrote: >> This provides a slightly more accurate bounding limit for `computeNextExponentialSoftCapped` when the computed bound is greater than `(1.0p53 - 1.0) * DoubleZigguratTables.exponentialX0`. This could cause the `while (computeNextExponentialSoftCapped(rng, limit) < limit)` check in `computeNextGaussian` on line 1402 to always be true, making the `nextGaussian` runtime unbounded in the worst case. >> >> This change is being tested prior to submission to OpenJDK by https://github.com/openjdk/jdk/pull/17703/commits/b8be051cbf40a6a05fafc6a2c76942e9e0b11fdf. > > Chris Hennick has updated the pull request incrementally with one additional commit since the last revision: > > Bug fix: add-exports was for wrong package @turbanoff @rgiulietti This is a follow-up to my previously merged #8131. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17703#issuecomment-1970255590 From gli at openjdk.org Thu Feb 29 02:22:52 2024 From: gli at openjdk.org (Guoxiong Li) Date: Thu, 29 Feb 2024 02:22:52 GMT Subject: RFR: 8324799: Use correct extension for C++ test headers [v2] In-Reply-To: References: Message-ID: On Thu, 29 Feb 2024 00:16:28 GMT, Kim Barrett wrote: >> Please review this change that renames some test .h files to .hpp. These >> files contain C++ code and should be named accordingly. Some of them contain >> uses of NULL, which we change to nullptr. >> >> The renamed files are: >> >> test/hotspot/jtreg/vmTestbase/nsk/share/aod/aod.h >> test/hotspot/jtreg/vmTestbase/nsk/share/jni/jni_tools.h >> test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/jvmti_tools.h >> test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/JVMTITools.h >> test/hotspot/jtreg/vmTestbase/nsk/share/native/nsk_tools.h >> >> test/lib/jdk/test/lib/jvmti/jvmti_thread.h >> test/lib/jdk/test/lib/jvmti/jvmti_common.h >> test/lib/native/testlib_threads.h >> >> The #include updates were performed mostly mechanically, and builds would fail >> if there were mistakes. The exception is test >> test/hotspot/jtreg/serviceability/jvmti/FollowReferences/FieldIndices/libFieldIndicesTest.cpp, >> which was added after I'd done the mechanical update, so was updated by hand. >> >> The copyright updates were similarly performed mechanically. All but a handful >> of the including files have already had their copyrights updated recently, >> likely as part of JDK-8324681. >> >> Thus, the only "interesting" changes are to the renamed files. >> >> Testing: mach5 tier1 > > Kim Barrett has updated the pull request incrementally with two additional commits since the last revision: > > - add Oracle copyright > - fix busted copyright text Looks good. ------------- Marked as reviewed by gli (Committer). PR Review: https://git.openjdk.org/jdk/pull/18035#pullrequestreview-1907811813 From kbarrett at openjdk.org Thu Feb 29 06:24:44 2024 From: kbarrett at openjdk.org (Kim Barrett) Date: Thu, 29 Feb 2024 06:24:44 GMT Subject: RFR: 8324799: Use correct extension for C++ test headers [v2] In-Reply-To: References: Message-ID: On Thu, 29 Feb 2024 00:16:28 GMT, Kim Barrett wrote: >> Please review this change that renames some test .h files to .hpp. These >> files contain C++ code and should be named accordingly. Some of them contain >> uses of NULL, which we change to nullptr. >> >> The renamed files are: >> >> test/hotspot/jtreg/vmTestbase/nsk/share/aod/aod.h >> test/hotspot/jtreg/vmTestbase/nsk/share/jni/jni_tools.h >> test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/jvmti_tools.h >> test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/JVMTITools.h >> test/hotspot/jtreg/vmTestbase/nsk/share/native/nsk_tools.h >> >> test/lib/jdk/test/lib/jvmti/jvmti_thread.h >> test/lib/jdk/test/lib/jvmti/jvmti_common.h >> test/lib/native/testlib_threads.h >> >> The #include updates were performed mostly mechanically, and builds would fail >> if there were mistakes. The exception is test >> test/hotspot/jtreg/serviceability/jvmti/FollowReferences/FieldIndices/libFieldIndicesTest.cpp, >> which was added after I'd done the mechanical update, so was updated by hand. >> >> The copyright updates were similarly performed mechanically. All but a handful >> of the including files have already had their copyrights updated recently, >> likely as part of JDK-8324681. >> >> Thus, the only "interesting" changes are to the renamed files. >> >> Testing: mach5 tier1 > > Kim Barrett has updated the pull request incrementally with two additional commits since the last revision: > > - add Oracle copyright > - fix busted copyright text Thanks for all the reviews. ------------- PR Comment: https://git.openjdk.org/jdk/pull/18035#issuecomment-1970485416 From kbarrett at openjdk.org Thu Feb 29 06:28:01 2024 From: kbarrett at openjdk.org (Kim Barrett) Date: Thu, 29 Feb 2024 06:28:01 GMT Subject: Integrated: 8324799: Use correct extension for C++ test headers In-Reply-To: References: Message-ID: On Wed, 28 Feb 2024 01:18:50 GMT, Kim Barrett wrote: > Please review this change that renames some test .h files to .hpp. These > files contain C++ code and should be named accordingly. Some of them contain > uses of NULL, which we change to nullptr. > > The renamed files are: > > test/hotspot/jtreg/vmTestbase/nsk/share/aod/aod.h > test/hotspot/jtreg/vmTestbase/nsk/share/jni/jni_tools.h > test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/jvmti_tools.h > test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/JVMTITools.h > test/hotspot/jtreg/vmTestbase/nsk/share/native/nsk_tools.h > > test/lib/jdk/test/lib/jvmti/jvmti_thread.h > test/lib/jdk/test/lib/jvmti/jvmti_common.h > test/lib/native/testlib_threads.h > > The #include updates were performed mostly mechanically, and builds would fail > if there were mistakes. The exception is test > test/hotspot/jtreg/serviceability/jvmti/FollowReferences/FieldIndices/libFieldIndicesTest.cpp, > which was added after I'd done the mechanical update, so was updated by hand. > > The copyright updates were similarly performed mechanically. All but a handful > of the including files have already had their copyrights updated recently, > likely as part of JDK-8324681. > > Thus, the only "interesting" changes are to the renamed files. > > Testing: mach5 tier1 This pull request has now been integrated. Changeset: 998d0baa Author: Kim Barrett URL: https://git.openjdk.org/jdk/commit/998d0baab0fd051c38d9fd6021628eb863b80554 Stats: 1538 lines in 731 files changed: 134 ins; 134 del; 1270 mod 8324799: Use correct extension for C++ test headers Reviewed-by: jwaters, gli, coleenp, lmesnik ------------- PR: https://git.openjdk.org/jdk/pull/18035 From dholmes at openjdk.org Thu Feb 29 06:37:51 2024 From: dholmes at openjdk.org (David Holmes) Date: Thu, 29 Feb 2024 06:37:51 GMT Subject: RFR: 8326891: Prefer RPATH over RUNPATH for $ORIGIN rpaths in internal JDK binaries In-Reply-To: References: Message-ID: On Wed, 28 Feb 2024 19:29:13 GMT, Erik Joelsson wrote: > There is no supported usecase that I can think of for injecting other versions of such libraries in a JDK distribution. I can imagine it could be used to allow "hot patching" of the installed JDK/JRE. Whether anyone has ever needed to do so is another matter. I suggest at least adding a Release Note. ------------- PR Comment: https://git.openjdk.org/jdk/pull/18050#issuecomment-1970497315 From simonis at openjdk.org Thu Feb 29 08:35:46 2024 From: simonis at openjdk.org (Volker Simonis) Date: Thu, 29 Feb 2024 08:35:46 GMT Subject: RFR: 8324573: HashMap::putAll add notes for conservative resizing [v5] In-Reply-To: References: Message-ID: On Fri, 16 Feb 2024 23:30:22 GMT, Joshua Cao wrote: >> Add notes for `HashMap::putAll()` conservative resizing. >> >> Note: everything below this line is from the original change. After discussion, we decided to keep the conservative resizing, but we should add an `@implNote` for the decision. >> >> --- >> >> This change mirrors what we did for ConcurrentHashMap in https://github.com/openjdk/jdk/pull/17116. When we add all entries from one map to anther, we should resize that map to the size of the sum of both maps. >> >> I used the command below to run the benchmarks. I set a high heap to reduce garbage collection noise. >> >> java -Xms25G -jar benchmarks.jar -p size=100000 -p addSize=100000 -gc true org.openjdk.bench.java.util.HashMapBench >> >> >> Before change >> >> >> Benchmark (addSize) (mapType) (size) Mode Cnt Score Error Units >> HashMapBench.putAll 100000 HASH_MAP 100000 avgt 4 22.927 ? 3.170 ms/op >> HashMapBench.putAll 100000 LINKED_HASH_MAP 100000 avgt 4 25.198 ? 2.189 ms/op >> >> >> After change >> >> >> Benchmark (addSize) (mapType) (size) Mode Cnt Score Error Units >> HashMapBench.putAll 100000 HASH_MAP 100000 avgt 4 16.780 ? 0.526 ms/op >> HashMapBench.putAll 100000 LINKED_HASH_MAP 100000 avgt 4 19.721 ? 0.349 ms/op >> >> >> We see about average time improvements of 26% in HashMap and 20% in LinkedHashMap. >> >> --- >> >> In the worse case, we may have two maps with identical keys. In this case, we would aggressively resize when we do not need to. I'm also adding an additional `putAllSameKeys` benchmark. >> >> Before change: >> >> >> Benchmark (addSize) (mapType) (size) Mode Cnt Score Error Units >> HashMapBench.putAllSameKeys 100000 HASH_MAP 100000 avgt 6.956 ms/op >> HashMapBench.putAllSameKeys:gc.alloc.rate 100000 HASH_MAP 100000 avgt 1091.383 MB/sec >> HashMapBench.putAllSameKeys:gc.alloc.rate.norm 100000 HASH_MAP 100000 avgt 7968871.917 B/op >> HashMapBench.putAllSameKeys:gc.count 100000 HASH_MAP 100000 avgt ? 0 counts >> HashMapBench.putAllSameKeys 100000 LINKED_HASH_MAP 100000 avgt 8.417 ms/op >> HashMapBench.putAllSameKeys:gc.alloc.rate 100000 LINKED_HASH_MAP 100000 avgt 992.543 MB/sec >> HashM... > > Joshua Cao has updated the pull request with a new target base 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: > > - Add note about conservative resizing > - Merge branch 'master' into hashmap > - extract msize variable > - Use max of both sizes and other maps size in case of overflow > - Add benchmark with all duplicate keys > - 8324573: HashMap::putAll should resize to sum of both map sizes I don't think we need to document what this method is *not* doing or what it *could* do. We should document what the current implementation *is* doing and give advice how the impact of the current implementation can be mitigated. Something like: > {@code HashMap}'s resize policy is intentionally conservative to avoid an unnecessarily large capacity if {@code m} contains many duplicate keys. This can lead to a potentially expensive, extra resize operation. In order to avoid such an additional resize operation callers of {@code putAll} can either use the {@code HashMap(int initialCapacity)} constructor to ensure that this map has a large enough capacity or they can call {@code newHashMap(int numMappings)} before calling {@code putAll()} to ensure that the map is only resized and copied once. Please fix the tags accordingly, I'm not fluent in JavaDoc :) ------------- Changes requested by simonis (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17544#pullrequestreview-1908264266 From jai.forums2013 at gmail.com Thu Feb 29 12:38:48 2024 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Thu, 29 Feb 2024 18:08:48 +0530 Subject: RFD: java.util.jar.Manifest.make72Safe has an invalid @deprecation tag In-Reply-To: References: Message-ID: Hello Eirik, I think that method (and its references in some test code comments) can be removed. Like you note it's a package private method within the java.util.jar package and I don't see its usage (other than test code comments) anywhere within the JDK repo. That @Deprecated annotation on that method seems to have been introduced as part of https://bugs.openjdk.org/browse/JDK-8066619 (review thread https://mail.openjdk.org/pipermail/core-libs-dev/2018-December/057030.html). I'm guessing it likely was an oversight to have added that annotation to an internal method instead of just removing its usage. -Jaikiran On 29/02/24 3:09 am, Eirik Bj?rsn?s wrote: > Hi, > > The non-public method java.util.jar.Manifest.make72Safe is marked > @Deprecated(since="13"). > > However, the Javadoc comment has a '@deprecation' tag which presumably > should?have been `@deprecated`. > > I first thought of proposing a PR to fix the invalid tag, but then I > noticed that the method is non-public and has no callers in OpenJDK. > > Not sure I understand why this internal?method was marked deprecated > in the first place and not simply removed? Are we worried about people > calling this reflectively? > > What would be the best way to go?about this? > > (a) Do nothing > (b) Just fix the tag @deprecation -> @deprecated > (c) Fix the tag, add forRemoval=true > (d) Just delete the method altogether (it's internal after all). > > Cheers, > Eirik. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rgiulietti at openjdk.org Thu Feb 29 13:17:54 2024 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Thu, 29 Feb 2024 13:17:54 GMT Subject: RFR: 8326227: Rounding error that may distort computeNextGaussian results [v3] In-Reply-To: <8rFBTqGfnBjAfEKhwpUbRwIZyksWI0a1iCor7zARM3Y=.732a7a06-0cba-461f-861d-f36a65f29e7a@github.com> References: <8rFBTqGfnBjAfEKhwpUbRwIZyksWI0a1iCor7zARM3Y=.732a7a06-0cba-461f-861d-f36a65f29e7a@github.com> Message-ID: On Thu, 29 Feb 2024 01:54:54 GMT, Chris Hennick wrote: >> Chris Hennick has updated the pull request incrementally with one additional commit since the last revision: >> >> Bug fix: add-exports was for wrong package > > @turbanoff @rgiulietti This is a follow-up to my previously merged #8131. @Pr0methean I'm not familiar with this code, nor with the underlying theory, so I'm not really able to give a meaningful review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17703#issuecomment-1971114920 From erikj at openjdk.org Thu Feb 29 14:32:52 2024 From: erikj at openjdk.org (Erik Joelsson) Date: Thu, 29 Feb 2024 14:32:52 GMT Subject: RFR: 8326891: Prefer RPATH over RUNPATH for $ORIGIN rpaths in internal JDK binaries In-Reply-To: References: Message-ID: On Thu, 29 Feb 2024 06:34:42 GMT, David Holmes wrote: > I can imagine it could be used to allow "hot patching" of the installed JDK/JRE. Whether anyone has ever needed to do so is another matter. I suggest at least adding a Release Note. Added release note. ------------- PR Comment: https://git.openjdk.org/jdk/pull/18050#issuecomment-1971267771 From mullan at openjdk.org Thu Feb 29 18:49:52 2024 From: mullan at openjdk.org (Sean Mullan) Date: Thu, 29 Feb 2024 18:49:52 GMT Subject: RFR: 8319648: java/lang/SecurityManager tests ignore vm flags [v2] In-Reply-To: References: <8QF-ychCHq3eRcsTlZqFqP68z2NApgazCTWyaDaP2iY=.e261430a-7cff-425a-ba7d-26b7f44fd0bc@github.com> Message-ID: On Tue, 27 Feb 2024 13:29:07 GMT, Matthew Donovan wrote: >> In this PR I updated the tests to use the newer ProcessTools.createTestJavaProcessBuilder methods to pass VM options to child processes. > > Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision: > > removed unused import statement Marked as reviewed by mullan (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/17878#pullrequestreview-1909616438 From javalists at cbfiddle.com Thu Feb 29 19:22:45 2024 From: javalists at cbfiddle.com (Alan Snyder) Date: Thu, 29 Feb 2024 11:22:45 -0800 Subject: creating macOS universal applications Message-ID: For anyone interested in building Java-based macOS universal applications, it is possible to create a bundled application that contains two Java runtimes, one for x86 and one for arm. A custom launcher is required to select the appropriate runtime based on the execution environment. I have created such a launcher; it is a very small modification of the macOS launcher used by jpackage. The custom launcher is available on GitHub: https://github.com/violetlib/mac-universal-java-launcher There is some discussion of this issue in JDK-8266259 [https://bugs.openjdk.org/browse/JDK-8266259]. So far, there does not seem to be much interest in this topic. On a related note, is there a place where developers using Java on macOS who are not associated with OpenJDK can share information? -------------- next part -------------- An HTML attachment was scrubbed... URL: From lance.andersen at oracle.com Thu Feb 29 19:31:50 2024 From: lance.andersen at oracle.com (Lance Andersen) Date: Thu, 29 Feb 2024 19:31:50 +0000 Subject: RFD: java.util.jar.Manifest.make72Safe has an invalid @deprecation tag In-Reply-To: References: Message-ID: <3954D413-314E-42B2-AEF6-6ABC460C8319@oracle.com> Hi Eirik, I also be we should be OK to remove. That being said, as part of the change, we should update open/test/jdk/sun/security/tools/jarsigner/PreserveRawManifestEntryAndDigest.java Best Lance On Feb 29, 2024, at 7:38?AM, Jaikiran Pai wrote: Hello Eirik, I think that method (and its references in some test code comments) can be removed. Like you note it's a package private method within the java.util.jar package and I don't see its usage (other than test code comments) anywhere within the JDK repo. That @Deprecated annotation on that method seems to have been introduced as part of https://bugs.openjdk.org/browse/JDK-8066619 (review thread https://mail.openjdk.org/pipermail/core-libs-dev/2018-December/057030.html). I'm guessing it likely was an oversight to have added that annotation to an internal method instead of just removing its usage. -Jaikiran On 29/02/24 3:09 am, Eirik Bj?rsn?s wrote: Hi, The non-public method java.util.jar.Manifest.make72Safe is marked @Deprecated(since="13"). However, the Javadoc comment has a '@deprecation' tag which presumably should have been `@deprecated`. I first thought of proposing a PR to fix the invalid tag, but then I noticed that the method is non-public and has no callers in OpenJDK. Not sure I understand why this internal method was marked deprecated in the first place and not simply removed? Are we worried about people calling this reflectively? What would be the best way to go about this? (a) Do nothing (b) Just fix the tag @deprecation -> @deprecated (c) Fix the tag, add forRemoval=true (d) Just delete the method altogether (it's internal after all). Cheers, Eirik. [oracle_sig_logo.gif] 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 jlu at openjdk.org Thu Feb 29 20:07:14 2024 From: jlu at openjdk.org (Justin Lu) Date: Thu, 29 Feb 2024 20:07:14 GMT Subject: RFR: JDK-6801704: ChoiceFormat::applyPattern inconsistency for invalid patterns [v5] In-Reply-To: References: Message-ID: > Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8317756) which defines the behavior for creating ChoiceFormats with incorrect patterns. The wording is added to both the ChoiceFormat constructor and ChoiceFormat::applyPattern method. > > While ideally the inconsistent behavior itself could be fixed, this behavior has been long-standing for 20+ years and the benefit of consistent error handling does not outweigh the risk of breaking applications that may be relying on the "expected" incorrect behavior. > > Examples of the range of behavior, (all examples violate the pattern syntax defined in the class description) > > > // no limit -> throws an expected IllegalArgumentException > var a = new ChoiceFormat("#foo"); > // no limit or relation in the last subPattern -> discards the incorrect portion, 'baz' and continues > var b = new ChoiceFormat("0#foo|1#bar|baz"); > b.format(2); // returns 'bar' > // no relation or limit -> discards the incorrect portion, 'foo' and continues > var c = new ChoiceFormat("foo"); > c.format(1); // throws AIOOBE Justin Lu has updated the pull request incrementally with two additional commits since the last revision: - include ascending order stipulation in constuctor as well - include apiSpec wording, move to patterns section ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17856/files - new: https://git.openjdk.org/jdk/pull/17856/files/f1f1dc41..8e5bbe05 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17856&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17856&range=03-04 Stats: 34 lines in 1 file changed: 10 ins; 14 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/17856.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17856/head:pull/17856 PR: https://git.openjdk.org/jdk/pull/17856 From joehw at openjdk.org Thu Feb 29 21:23:05 2024 From: joehw at openjdk.org (Joe Wang) Date: Thu, 29 Feb 2024 21:23:05 GMT Subject: RFR: 8326915: NPE when a validating parser is restricted Message-ID: Fix a NPE when a validating parser is restricted by the JDKCatalog resolve property. Also slightly improved the error msg with the catalog name. Test: new test added existing test CatalogSupport5 would fail without the Null check on ErrorReporter. It's a separate issue not covered by this fix. ------------- Commit messages: - 8326915: NPE when a validating parser is restricted Changes: https://git.openjdk.org/jdk/pull/18071/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18071&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8326915 Stats: 116 lines in 5 files changed: 101 ins; 0 del; 15 mod Patch: https://git.openjdk.org/jdk/pull/18071.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18071/head:pull/18071 PR: https://git.openjdk.org/jdk/pull/18071 From clanger at openjdk.org Thu Feb 29 21:36:43 2024 From: clanger at openjdk.org (Christoph Langer) Date: Thu, 29 Feb 2024 21:36:43 GMT Subject: RFR: 8326591: New test JmodExcludedFiles.java fails on Windows when --with-external-symbols-in-bundles=public is used In-Reply-To: References: <9RR45_rKFq7Syr1gB7zEPqOBgmPf-TeGPOo62M6aFtc=.fff7854c-7c8b-4c97-acbb-8ec6bce5c8d1@github.com> Message-ID: On Wed, 28 Feb 2024 12:32:17 GMT, Matthias Baesken wrote: > Looks okay to me, but could we print here `RuntimeException(jmodFile + " is expected not to include native debug symbols` not only the jmod but also the unwanted file(s) ? This information is already printed in isNativeDebugSymbol. So in case of failure, you'll find the culprit in the test output. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17990#issuecomment-1972000461 From naoto at openjdk.org Thu Feb 29 23:57:53 2024 From: naoto at openjdk.org (Naoto Sato) Date: Thu, 29 Feb 2024 23:57:53 GMT Subject: RFR: JDK-6801704: ChoiceFormat::applyPattern inconsistency for invalid patterns [v5] In-Reply-To: References: Message-ID: On Thu, 29 Feb 2024 20:07:14 GMT, Justin Lu wrote: >> Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8317756) which defines the behavior for creating ChoiceFormats with incorrect patterns. The wording is added to both the ChoiceFormat constructor and ChoiceFormat::applyPattern method. >> >> While ideally the inconsistent behavior itself could be fixed, this behavior has been long-standing for 20+ years and the benefit of consistent error handling does not outweigh the risk of breaking applications that may be relying on the "expected" incorrect behavior. >> >> Examples of the range of behavior, (all examples violate the pattern syntax defined in the class description) >> >> >> // no limit -> throws an expected IllegalArgumentException >> var a = new ChoiceFormat("#foo"); >> // no limit or relation in the last subPattern -> discards the incorrect portion, 'baz' and continues >> var b = new ChoiceFormat("0#foo|1#bar|baz"); >> b.format(2); // returns 'bar' >> // no relation or limit -> discards the incorrect portion, 'foo' and continues >> var c = new ChoiceFormat("foo"); >> c.format(1); // throws AIOOBE > > Justin Lu has updated the pull request incrementally with two additional commits since the last revision: > > - include ascending order stipulation in constuctor as well > - include apiSpec wording, move to patterns section LGTM src/java.base/share/classes/java/text/ChoiceFormat.java line 406: > 404: * based on the pattern. The syntax and error related caveats for the > 405: * ChoiceFormat pattern can be found in the {@linkplain ##patterns Patterns} > 406: * section. Unlike {@link #ChoiceFormat(double[], String[])} this method will Nit: `constructor` better suited than `method`. ------------- Marked as reviewed by naoto (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17856#pullrequestreview-1910070004 PR Review Comment: https://git.openjdk.org/jdk/pull/17856#discussion_r1508322149