From swen at openjdk.org Tue Jul 1 00:01:21 2025 From: swen at openjdk.org (Shaojin Wen) Date: Tue, 1 Jul 2025 00:01:21 GMT Subject: RFR: 8361018: Re-examine buffering and encoding conversion in BufferedWriter [v6] In-Reply-To: References: Message-ID: > BufferedWriter -> OutputStreamWriter -> StreamEncoder > > In this call chain, BufferedWriter has a char[] buffer, and StreamEncoder has a ByteBuffer. There are two layers of cache here, or the BufferedWriter layer can be removed. And when charset is UTF8, if the content of write(String) is LATIN1, a conversion from LATIN1 to UTF16 and then to LATIN1 will occur here. > > LATIN1 -> UTF16 -> UTF8 > > We can improve BufferedWriter. When the parameter Writer instanceof OutputStreamWriter is passed in, remove the cache and call it directly. In addition, improve write(String) in StreamEncoder to avoid unnecessary encoding conversion. Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: Revert "BufferedWriter buffer use StringBuilder" This reverts commit da902ca0b0bd6acc003deb8ad1ca0d6485a29a27. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26022/files - new: https://git.openjdk.org/jdk/pull/26022/files/da902ca0..fccd9678 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26022&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26022&range=04-05 Stats: 81 lines in 6 files changed: 31 ins; 32 del; 18 mod Patch: https://git.openjdk.org/jdk/pull/26022.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26022/head:pull/26022 PR: https://git.openjdk.org/jdk/pull/26022 From duke at openjdk.org Tue Jul 1 00:01:21 2025 From: duke at openjdk.org (Brett Okken) Date: Tue, 1 Jul 2025 00:01:21 GMT Subject: RFR: 8361018: Re-examine buffering and encoding conversion in BufferedWriter [v5] In-Reply-To: References: Message-ID: <2UGoXOQvwftFaOWTuopaoo_r6XaIUp2x5SwelfFsgRw=.574d130b-8d0e-4b0b-9a66-749d2ccb00da@github.com> On Mon, 30 Jun 2025 23:56:53 GMT, Shaojin Wen wrote: >> BufferedWriter -> OutputStreamWriter -> StreamEncoder >> >> In this call chain, BufferedWriter has a char[] buffer, and StreamEncoder has a ByteBuffer. There are two layers of cache here, or the BufferedWriter layer can be removed. And when charset is UTF8, if the content of write(String) is LATIN1, a conversion from LATIN1 to UTF16 and then to LATIN1 will occur here. >> >> LATIN1 -> UTF16 -> UTF8 >> >> We can improve BufferedWriter. When the parameter Writer instanceof OutputStreamWriter is passed in, remove the cache and call it directly. In addition, improve write(String) in StreamEncoder to avoid unnecessary encoding conversion. > > Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: > > BufferedWriter buffer use StringBuilder What about a benchmark which exercises the actual benefits of buffering? So many very small writes to a backing OutputStream which is (artificially) slow. Perhaps have an OutputStream which sleeps 1ms on every call. The write out more than 8k of data in chunks of less than 8 chars at a time. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26022#issuecomment-3021204155 From swen at openjdk.org Tue Jul 1 00:12:40 2025 From: swen at openjdk.org (Shaojin Wen) Date: Tue, 1 Jul 2025 00:12:40 GMT Subject: RFR: 8361018: Re-examine buffering and encoding conversion in BufferedWriter [v5] In-Reply-To: <2UGoXOQvwftFaOWTuopaoo_r6XaIUp2x5SwelfFsgRw=.574d130b-8d0e-4b0b-9a66-749d2ccb00da@github.com> References: <2UGoXOQvwftFaOWTuopaoo_r6XaIUp2x5SwelfFsgRw=.574d130b-8d0e-4b0b-9a66-749d2ccb00da@github.com> Message-ID: <4F3WghIFVfxGPb1vRYf8Cdx4n35JwYZwOgfsColqCqQ=.4ae6c24f-3a9f-43a7-9af5-03f074c7d0a5@github.com> On Mon, 30 Jun 2025 23:57:45 GMT, Brett Okken wrote: > What about a benchmark which exercises the actual benefits of buffering? So many very small writes to a backing OutputStream which is (artificially) slow. Perhaps have an OutputStream which sleeps 1ms on every call. The write out more than 8k of data in chunks of less than 8 chars at a time. In fact, StreamEncoder has a ByteBuffer that acts as a buffer, so when BufferedBuffer::out is an OutputStreamWirter encoded as UTF8, there is no need for two layers of buffer. class BufferedWriter { Writer out } class OutputStreamWriter { StreamEncoder se; } class StreamEncoder { ByteBuffer bb; } We often use it like this: new BufferedWriter(new OutputStreamWriter(out, UTF_8))) ------------- PR Comment: https://git.openjdk.org/jdk/pull/26022#issuecomment-3021227716 From sherman at openjdk.org Tue Jul 1 00:45:47 2025 From: sherman at openjdk.org (Xueming Shen) Date: Tue, 1 Jul 2025 00:45:47 GMT Subject: RFR: 8361018: Re-examine buffering and encoding conversion in BufferedWriter [v6] In-Reply-To: References: Message-ID: <6ClkdyctkQbFU6oNWqEWweuKQ9Z2HCjFReka6xpM3R8=.de30d3c6-ce40-418b-be8e-76c930bb1929@github.com> On Tue, 1 Jul 2025 00:01:21 GMT, Shaojin Wen wrote: >> BufferedWriter -> OutputStreamWriter -> StreamEncoder >> >> In this call chain, BufferedWriter has a char[] buffer, and StreamEncoder has a ByteBuffer. There are two layers of cache here, or the BufferedWriter layer can be removed. And when charset is UTF8, if the content of write(String) is LATIN1, a conversion from LATIN1 to UTF16 and then to LATIN1 will occur here. >> >> LATIN1 -> UTF16 -> UTF8 >> >> We can improve BufferedWriter. When the parameter Writer instanceof OutputStreamWriter is passed in, remove the cache and call it directly. In addition, improve write(String) in StreamEncoder to avoid unnecessary encoding conversion. > > Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: > > Revert "BufferedWriter buffer use StringBuilder" > > This reverts commit da902ca0b0bd6acc003deb8ad1ca0d6485a29a27. While I understand the motivation behind the PR, it's a bit challenging (as a reviewer) to agree a change that is essentially to 'break' the abstraction layer by surfacing a lower-level implementation to the top API solely for performance gains. It might be better to separate the 'backdoor UTF-8 path' optimization and the 'skip BufferedWriter' change as a first step to start the discussion? ------------- PR Comment: https://git.openjdk.org/jdk/pull/26022#issuecomment-3021289241 From dholmes at openjdk.org Tue Jul 1 00:53:50 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 1 Jul 2025 00:53:50 GMT Subject: RFR: 8360163: Create annotations to mark dumping method handles and runtime setup required classes [v3] In-Reply-To: References: Message-ID: On Mon, 30 Jun 2025 22:11:57 GMT, Chen Liang wrote: >> I have updated this patch to avoid a redundant `runtimeSetup` annotation - we have agreed that the requirement for setup is a side effect of initialization, and such methods in AOTCI classes must be automatically recognized. This latest revision implements that model. >> >> I intentionally avoided handling Class and ClassLoader `resetArchivedStates` and `MethodType::assemblySetup` - we talked about a generic `assemblyCleanup` method, but I did not find out where is the best place to call such a method in the assembly phase. We cna handle this in a subsequent patch. >> >> In particular, please review the new AOT.md design document - I split it from the AOTCI annotation to prevent jamming; we can put general AOT information there when we have more AOT-specific annotations. >> >> --- >> >> Old description: >> Currently, the list of classes that have interdependencies and those that need runtimeSetup are maintained in a hardcoded list in CDS. This makes it risky for core library developers as they might introduce new interdependencies and observe CDS to fail. By moving the mechanism of these lists to core library annotations as a first step, we can gradually expose the AOT contracts as program semantics described by internal annotations, and also helps us to explore how we can expose these functionalities to the public later. > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > Missed comment updates Just a drive-by comment ... src/hotspot/share/cds/aotClassInitializer.cpp line 247: > 245: > 246: if (CDSConfig::is_dumping_method_handles()) { > 247: // The list of @AOTClassInitializer was created with the help of CDSHeapVerifier. Given there is no longer a list these left over comments seem out of place here. Perhaps the `has_aot_initialization` method should document how it was determined which classes to annotate and what additional constraints there are. Though that could also be left for the documentation in AOT.md, rather than the code. ------------- PR Review: https://git.openjdk.org/jdk/pull/25922#pullrequestreview-2973142829 PR Review Comment: https://git.openjdk.org/jdk/pull/25922#discussion_r2176188797 From sherman at openjdk.org Tue Jul 1 01:03:48 2025 From: sherman at openjdk.org (Xueming Shen) Date: Tue, 1 Jul 2025 01:03:48 GMT Subject: RFR: 8354490: Pattern.CANON_EQ causes a pattern to not match a string with a UNICODE variation In-Reply-To: References: Message-ID: On Wed, 25 Jun 2025 18:51:52 GMT, Xueming Shen wrote: > The root cause is an off-by-one bug introduced in an old change we made years ago for Pattern.CANON_EQ. > See https://cr.openjdk.org/~sherman/regexCE/Note.txt for background info. > > As described in the writeup above the basic logic of the change is to: > > **generate the permutations, create the alternation and then put it appropriately into the character class (logically), we now use a special "Node", the NFCCharProperty to do the matching work. The NFCCharProperty tries to match a grapheme cluster at a time (nfc greedly, then backtrack) against the character class.** > > It appears we have a off-by-one bug in the backtrack boundary condition check, when it backtracking to the position 'after' the base(main) character (in case where the resulting 'nfc' string is not a **single character'** string /not match). In such cases, we still need to match/compare the base character against the _predicate_ to find the potential match. > > For example in the reported scenario, the target string contains the pair of **u+2764** (emoji) + **u+fe0f** (variation selector/emoji_component). The boundary edge j = Grapheme.nextBoundary() starts at **2** (after u+fe0f), then it backtracks to 1. The current boundary check implementation incorrectly exits here because 0 + 1 < 1 fails, which is incorrect. > > This emoji pair should match correctly, s showed below > > > jshell> var p = Pattern.compile("\\p{IsEmoji}\\p{IsEmoji_Component}", Pattern.CANON_EQ); > p ==> \p{IsEmoji}\p{IsEmoji_Component} > > jshell> p.matcher("\u2764\ufe0f").matches(); > $53 ==> true > > > or > > > jshell> var p = Pattern.compile("\\p{IsEmoji}", Pattern.CANON_EQ); > p ==> \p{IsEmoji} > > jshell> p.matcher("\u2764\ufe0f").find(); > $55 ==> true > > > This bug is not limited to the emoji + variation selector pairs (which don't 'nfc' into a single character, even are treated as a single grapheme cluster). It also impacts cases involing dangling or unmatched combining character(s). For example, the following should work/match/find, even in Pattern.CANON_EQ mode. > > > > jshell> p = Pattern.compile("\\p{IsGreek}\\p{IsAlphabetic}", Pattern.CANON_EQ); > p ==> \p{IsGreek}\p{IsAlphabetic} > > jshell> p.matcher("\u1f80\u0345").matches(); > $57 ==> true > > jshell> p = Pattern.compile("[\\p{IsAlphabetic}]*", Pattern.CANON_EQ); > p ==> [\p{IsAlphabetic}]* > > jshell> p.matcher("\u1f80\u0345").matches(); > $59 ==> true > > > **note:** the grapheme boundary is not necessary the same as the resulting nfc boundary. Thanks for the reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/25986#issuecomment-3021316924 From sherman at openjdk.org Tue Jul 1 01:03:49 2025 From: sherman at openjdk.org (Xueming Shen) Date: Tue, 1 Jul 2025 01:03:49 GMT Subject: Integrated: 8354490: Pattern.CANON_EQ causes a pattern to not match a string with a UNICODE variation In-Reply-To: References: Message-ID: On Wed, 25 Jun 2025 18:51:52 GMT, Xueming Shen wrote: > The root cause is an off-by-one bug introduced in an old change we made years ago for Pattern.CANON_EQ. > See https://cr.openjdk.org/~sherman/regexCE/Note.txt for background info. > > As described in the writeup above the basic logic of the change is to: > > **generate the permutations, create the alternation and then put it appropriately into the character class (logically), we now use a special "Node", the NFCCharProperty to do the matching work. The NFCCharProperty tries to match a grapheme cluster at a time (nfc greedly, then backtrack) against the character class.** > > It appears we have a off-by-one bug in the backtrack boundary condition check, when it backtracking to the position 'after' the base(main) character (in case where the resulting 'nfc' string is not a **single character'** string /not match). In such cases, we still need to match/compare the base character against the _predicate_ to find the potential match. > > For example in the reported scenario, the target string contains the pair of **u+2764** (emoji) + **u+fe0f** (variation selector/emoji_component). The boundary edge j = Grapheme.nextBoundary() starts at **2** (after u+fe0f), then it backtracks to 1. The current boundary check implementation incorrectly exits here because 0 + 1 < 1 fails, which is incorrect. > > This emoji pair should match correctly, s showed below > > > jshell> var p = Pattern.compile("\\p{IsEmoji}\\p{IsEmoji_Component}", Pattern.CANON_EQ); > p ==> \p{IsEmoji}\p{IsEmoji_Component} > > jshell> p.matcher("\u2764\ufe0f").matches(); > $53 ==> true > > > or > > > jshell> var p = Pattern.compile("\\p{IsEmoji}", Pattern.CANON_EQ); > p ==> \p{IsEmoji} > > jshell> p.matcher("\u2764\ufe0f").find(); > $55 ==> true > > > This bug is not limited to the emoji + variation selector pairs (which don't 'nfc' into a single character, even are treated as a single grapheme cluster). It also impacts cases involing dangling or unmatched combining character(s). For example, the following should work/match/find, even in Pattern.CANON_EQ mode. > > > > jshell> p = Pattern.compile("\\p{IsGreek}\\p{IsAlphabetic}", Pattern.CANON_EQ); > p ==> \p{IsGreek}\p{IsAlphabetic} > > jshell> p.matcher("\u1f80\u0345").matches(); > $57 ==> true > > jshell> p = Pattern.compile("[\\p{IsAlphabetic}]*", Pattern.CANON_EQ); > p ==> [\p{IsAlphabetic}]* > > jshell> p.matcher("\u1f80\u0345").matches(); > $59 ==> true > > > **note:** the grapheme boundary is not necessary the same as the resulting nfc boundary. This pull request has now been integrated. Changeset: 61a590e9 Author: Xueming Shen URL: https://git.openjdk.org/jdk/commit/61a590e9bea64ddfd465a5e6f224bc2979d841e9 Stats: 19 lines in 2 files changed: 15 ins; 3 del; 1 mod 8354490: Pattern.CANON_EQ causes a pattern to not match a string with a UNICODE variation Reviewed-by: rriggs, naoto ------------- PR: https://git.openjdk.org/jdk/pull/25986 From rriggs at openjdk.org Tue Jul 1 01:39:44 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 1 Jul 2025 01:39:44 GMT Subject: RFR: 8358533: Improve performance of java.io.Reader.readAllLines [v9] In-Reply-To: References: Message-ID: On Mon, 30 Jun 2025 19:38:59 GMT, Brian Burkhalter wrote: >> Replaces the implementation `readAllCharsAsString().lines().toList()` with reading into a temporary `char` array which is then processed to detect line terminators and copy non-terminating characters into strings which are added to the list. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8358533: Sherman's version + decrease initial buffer size src/java.base/share/classes/java/io/Reader.java line 482: > 480: if (pos == limit) { > 481: int len = limit - start; > 482: if (len >= cb.length) { Observation: this algorithm will get less efficient as the line length approaches cb.length. Starting at sb.length/2 It will take 2 reads for every line and will not resize the buffer. I think resizing the buffer when the line length exceeds cb.length/2 will be more efficient (cpu wise). The decoding of the bytes to chars and the setup of the decoder is the expensive part. For most typical line length distributions it would not make a difference but would improve the performance of the outliners. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25863#discussion_r2176233023 From rriggs at openjdk.org Tue Jul 1 01:50:45 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 1 Jul 2025 01:50:45 GMT Subject: RFR: 8358533: Improve performance of java.io.Reader.readAllLines [v9] In-Reply-To: References: Message-ID: On Mon, 30 Jun 2025 19:38:59 GMT, Brian Burkhalter wrote: >> Replaces the implementation `readAllCharsAsString().lines().toList()` with reading into a temporary `char` array which is then processed to detect line terminators and copy non-terminating characters into strings which are added to the list. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8358533: Sherman's version + decrease initial buffer size test/jdk/java/io/Reader/ReadAll.java line 117: > 115: sb.setLength(0); > 116: } > 117: Does one of these cases result in a *very very long line without a terminator"; something that would trigger the limits of ArraySupport.newLength at or near Integer.MAX_VALUE - 8? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25863#discussion_r2176240122 From duke at openjdk.org Tue Jul 1 02:09:43 2025 From: duke at openjdk.org (Brett Okken) Date: Tue, 1 Jul 2025 02:09:43 GMT Subject: RFR: 8361018: Re-examine buffering and encoding conversion in BufferedWriter [v5] In-Reply-To: <4F3WghIFVfxGPb1vRYf8Cdx4n35JwYZwOgfsColqCqQ=.4ae6c24f-3a9f-43a7-9af5-03f074c7d0a5@github.com> References: <2UGoXOQvwftFaOWTuopaoo_r6XaIUp2x5SwelfFsgRw=.574d130b-8d0e-4b0b-9a66-749d2ccb00da@github.com> <4F3WghIFVfxGPb1vRYf8Cdx4n35JwYZwOgfsColqCqQ=.4ae6c24f-3a9f-43a7-9af5-03f074c7d0a5@github.com> Message-ID: On Tue, 1 Jul 2025 00:10:00 GMT, Shaojin Wen wrote: > StreamEncoder has a ByteBuffer that acts as a buffer, At a fixed sized of 512 bytes which cannot be affected by size passed into the BufferedWriter? ------------- PR Comment: https://git.openjdk.org/jdk/pull/26022#issuecomment-3021453158 From swen at openjdk.org Tue Jul 1 02:16:39 2025 From: swen at openjdk.org (Shaojin Wen) Date: Tue, 1 Jul 2025 02:16:39 GMT Subject: RFR: 8361018: Re-examine buffering and encoding conversion in BufferedWriter [v5] In-Reply-To: References: <2UGoXOQvwftFaOWTuopaoo_r6XaIUp2x5SwelfFsgRw=.574d130b-8d0e-4b0b-9a66-749d2ccb00da@github.com> <4F3WghIFVfxGPb1vRYf8Cdx4n35JwYZwOgfsColqCqQ=.4ae6c24f-3a9f-43a7-9af5-03f074c7d0a5@github.com> Message-ID: On Tue, 1 Jul 2025 02:07:07 GMT, Brett Okken wrote: > > StreamEncoder has a ByteBuffer that acts as a buffer, > > At a fixed sized of 512 bytes which cannot be affected by size passed into the BufferedWriter? So I added this method StreamEncoder::growByteBufferIfEmptyNeeded and called it in the BufferedWriter constructor private BufferedWriter(Writer out, int initialSize, int maxSize) { // ... if (out instanceof OutputStreamWriter w && w.se.getCharset() == UTF_8.INSTANCE) { w.se.growByteBufferIfEmptyNeeded(initialSize); this.impl = new OutputStreamWriterImpl(w); } // ... } ------------- PR Comment: https://git.openjdk.org/jdk/pull/26022#issuecomment-3021479496 From liach at openjdk.org Tue Jul 1 02:35:41 2025 From: liach at openjdk.org (Chen Liang) Date: Tue, 1 Jul 2025 02:35:41 GMT Subject: RFR: 8361018: Re-examine buffering and encoding conversion in BufferedWriter [v6] In-Reply-To: References: Message-ID: <8Gw6kEDNuv2UmryKGGqW7QDndJJr29rT6dHKa9pLQLQ=.7d15c0c6-70f2-44e7-a07c-977ec66ed9c7@github.com> On Tue, 1 Jul 2025 00:01:21 GMT, Shaojin Wen wrote: >> BufferedWriter -> OutputStreamWriter -> StreamEncoder >> >> In this call chain, BufferedWriter has a char[] buffer, and StreamEncoder has a ByteBuffer. There are two layers of cache here, or the BufferedWriter layer can be removed. And when charset is UTF8, if the content of write(String) is LATIN1, a conversion from LATIN1 to UTF16 and then to LATIN1 will occur here. >> >> LATIN1 -> UTF16 -> UTF8 >> >> We can improve BufferedWriter. When the parameter Writer instanceof OutputStreamWriter is passed in, remove the cache and call it directly. In addition, improve write(String) in StreamEncoder to avoid unnecessary encoding conversion. > > Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: > > Revert "BufferedWriter buffer use StringBuilder" > > This reverts commit da902ca0b0bd6acc003deb8ad1ca0d6485a29a27. I think we can split this into two parts: 1. Update buffering strategy for BufferedWriter when backing writer is an OutputStreamWriter 2. Use an alternative StreamDecoder impl if the CharsetDecoder is an ArrayDecoder This should make the whole thing more clear. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26022#issuecomment-3021520629 From swen at openjdk.org Tue Jul 1 02:41:37 2025 From: swen at openjdk.org (Shaojin Wen) Date: Tue, 1 Jul 2025 02:41:37 GMT Subject: RFR: 8361018: Re-examine buffering and encoding conversion in BufferedWriter [v6] In-Reply-To: <6ClkdyctkQbFU6oNWqEWweuKQ9Z2HCjFReka6xpM3R8=.de30d3c6-ce40-418b-be8e-76c930bb1929@github.com> References: <6ClkdyctkQbFU6oNWqEWweuKQ9Z2HCjFReka6xpM3R8=.de30d3c6-ce40-418b-be8e-76c930bb1929@github.com> Message-ID: On Tue, 1 Jul 2025 00:41:03 GMT, Xueming Shen wrote: > While I understand the motivation behind the PR, it's a bit challenging, as a reviewer :-) to review a change that is essentially to 'break' the abstraction layer by surfacing a lower-level implementation to the top API solely for performance gains. Maybe it's easier to add an impl note to suggest "it's no longer always a good idea to put a buffered writer on top of an osw", for example. > > It might be better to separate the 'backdoor UTF-8 path' optimization and the 'skip BufferedWriter' change as a first step to start the discussion? After the introduction of JEP 254 Compact Strings, many java.io-related codes need to be optimized for Compact Strings. If we plan to remove the option COMPACT_STRING = off, we should do these optimizations before that. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26022#issuecomment-3021532618 From sherman at openjdk.org Tue Jul 1 04:00:39 2025 From: sherman at openjdk.org (Xueming Shen) Date: Tue, 1 Jul 2025 04:00:39 GMT Subject: RFR: 8361018: Re-examine buffering and encoding conversion in BufferedWriter [v6] In-Reply-To: References: <6ClkdyctkQbFU6oNWqEWweuKQ9Z2HCjFReka6xpM3R8=.de30d3c6-ce40-418b-be8e-76c930bb1929@github.com> Message-ID: <4sIiDHzczQCMWcgdUU-6uSmPgWm-5Xb66JYx-p0TfW0=.e56c5fcd-b182-402e-81b2-8c5094af331b@github.com> On Tue, 1 Jul 2025 02:38:52 GMT, Shaojin Wen wrote: > After the introduction of JEP 254 Compact Strings, many java.io-related codes need to be optimized for Compact Strings. If we plan to remove the option COMPACT_STRING = off, we should do these optimizations before that. now you make me feel guilty :-) ------------- PR Comment: https://git.openjdk.org/jdk/pull/26022#issuecomment-3021665074 From yujige at gmail.com Tue Jul 1 04:55:10 2025 From: yujige at gmail.com (Jige Yu) Date: Mon, 30 Jun 2025 21:55:10 -0700 Subject: [External] : Re: Should mapConcurrent() respect time order instead of input order? In-Reply-To: References: Message-ID: Hi Viktor, Thanks again for encouraging me to give it a try with an alternative mapConcurrently() gatherer. I've completed the experiment and have some interesting results to share. As we discussed earlier, the current mapConcurrent()'s spec to maintain encounter order creates limitations for certain use cases where *optimizing concurrency* is more important. Specifically, for scenarios like a race() operation (taking the first successful result from N candidates) or long-running heartbeat/monitoring tasks with sibling operations, the encounter-order preservation can lead to the gatherer halting or tasks not getting a chance to execute. I've implemented an experimental *mapConcurrently()* gatherer that *drops the requirement of maintaining encounter order*. I then set up a test case involving a simulated heartbeat task, designed to highlight the issue. The results confirmed my hypothesis: ------------------------------ Experiment Findings - The existing *mapConcurrent() indeed halts* when faced with a heartbeat task that doesn't exit (but keeps running until other operations are complete), will halt by operations beyond maxConcurrency from ever being run due to the maxConcurrency limit and the need to preserve order. - The alternative *mapConcurrently() gatherer runs just fine* under the same conditions, demonstrating that removing the encounter-order requirement allows all tasks to execute concurrently and independently, without being blocked by earlier, slower operations, or halt. ------------------------------ This experiment demonstrates the potential benefits of an unordered mapConcurrently() gatherer for specific high-concurrency, non-blocking use cases. It could significantly broaden the applicability of gatherers for scenarios where throughput and responsiveness are prioritized over strict ordering. Best regards, Ben Yu On Mon, Jun 9, 2025 at 1:49?AM Viktor Klang wrote: > Hi Jige, > > Yes, let's see what developers need. ? > > In the meantime, I want to reiterate that it is possible to build what > you're asking for, outside of the JDK. To gather experience, feedback, and > ultimately decide if the feature is worthwhile. > > Cheers, > ? > > > *Viktor Klang* > Software Architect, Java Platform Group > Oracle > ------------------------------ > *From:* Jige Yu > *Sent:* Sunday, 8 June 2025 07:39 > *To:* Viktor Klang > *Cc:* core-libs-dev at openjdk.org > *Subject:* Re: [External] : Re: Should mapConcurrent() respect time order > instead of input order? > > > Hi Viktor, > > Thank you for pointing to the spec. You are absolutely right, that is the > documented behavior. > > My feedback is aimed directly at questioning that specific design choice > within the specification. My perspective is that the benefit of preserving > stream ordering may be outweighed by the significant trade-offs it > introduces?namely, the potential for surprising performance behavior (like > reduced throughput or task starvation) and the loss of flexibility for > implementing common concurrent patterns like race semantics. > > I understand if the design for the current release is finalized, but I > believe this feedback is relevant for the ongoing evolution of the API. > > Best regards, > > On Wed, Jun 4, 2025 at 11:22?AM Viktor Klang > wrote: > > >Ultimately, the question is whether mapConcurrent() should be optimized > primarily for preserving input sequence, or for enabling maximum throughput > and flexibility in concurrent scenarios, including efficient > "first-to-finish" patterns. > > The answer to that is clear in the specification for the operation: > > ?This operation preserves the ordering of the stream.? - > http://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/util/stream/Gatherers.html#mapConcurrent(int,java.util.function.Function) > > Cheers, > ? > > > *Viktor Klang* > Software Architect, Java Platform Group > Oracle > ------------------------------ > *From:* Jige Yu > *Sent:* Wednesday, 4 June 2025 18:18 > *To:* Viktor Klang > *Cc:* core-libs-dev at openjdk.org > *Subject:* Re: [External] : Re: Should mapConcurrent() respect time order > instead of input order? > > Hi Viktor, > > Thank you for the detailed explanation and the links to the Javadoc for > findFirst() and limit(). You're absolutely correct in your > characterization of these operations ? they are indeed concerned with > encounter order, and parallel execution doesn't inherently change that > unless the stream is explicitly unordered. I want to clarify a few of my > points that I didn't explain clearly (see below). > > > On Wed, Jun 4, 2025 at 7:38?AM Viktor Klang > wrote: > > Hi Jige, > > First of all?you're most welcome. Thanks for your insightful questions. > > >*Temptation for Race Semantics:* The beauty of mapConcurrent() integrating > with the Stream API means developers will naturally be drawn to use it for > race-like scenarios. Operations like findFirst() or limit(N) to get the > first few completed results are very intuitive combinations. > > It's important to distinguish between spatial (encounter) order and > temporal (availability) order. > > If we look at `Stream::findFirst()` we see: > > ?Returns an Optional > describing > the first element of this stream, or an empty Optional if the stream is > empty. If the stream has no encounter order, then any element may be > returned.? - > https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/util/stream/Stream.html#findFirst() > > And if we look at `Stream::limit(long)` we see: > > *?While limit() is generally a cheap operation on sequential stream > pipelines, it can be quite expensive on ordered parallel pipelines, > especially for large values of maxSize, since limit(n) is constrained to > return not just any n elements, but **the first n elements in the > encounter order**. ? (emphasis mine) - > https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/util/stream/Stream.html#limit(long) > * > > So, we can conclude that "first" and "limit" are about *encounter order*, > and we can conclude that the presence of parallel does not change that?only > "unorderedness" *may* change that. > > > > My apologies if my previous example using findFirst() wasn't as clear as > it could have been. I'd like to clarify how I see the interaction with > mapConcurrent() playing out: > > 1. > > *mapConcurrent()'s Influence on Encounter Order:* When I mentioned > using findFirst() (or limit()) for race semantics, the implicit > assumption was how mapConcurrent() would feed elements into these > terminal operations. The "encounter order" that findFirst() sees is > precisely what mapConcurrent() emits. If mapConcurrent() emits results > strictly according to input order, then findFirst() will respect that. > However, if an unordered mapConcurrent() were to emit results in their > temporal order of completion, then findFirst() would naturally pick > the first one that *actually finished*, effectively achieving a race. > My point is that mapConcurrent() is in a position to define the > encounter order that downstream operations like findFirst() will act > upon. The surprise isn't with findFirst()'s definition, but with how a > strictly ordered mapConcurrent() might prevent it from being used > effectively for "first-to-finish" logic. > 2. > > *The Role of findAny():* You're right that my example using > findFirst() was more nuanced than I intuitively assumed. A developer > well-versed in the Stream API nuances might indeed opt for findAny() > to implement race semantics, especially given its Javadoc explicitly > mentioning suitability for "maximal performance in parallel operations." > findAny() is designed to return *any* element, which aligns well with > picking the temporally first available result from an unordered concurrent > process. > 3. > > *Aligning Spec with Intuition:* My broader concern is about the > intuitive use of these powerful new tools. If mapConcurrent() > maintains strict input ordering, it's a perfectly valid and understandable > specification by itself. However, the potential for surprise arises when > developers, especially those less acquainted with every fine print of > stream ordering, attempt to combine mapConcurrent() with findFirst() > or findAny() to build common concurrent utilities like a race. They > might intuitively expect that "concurrent mapping" followed by "find > first/any" would yield the result that completes earliest. While developers > *should* read all related documentation, there's also a design ideal > where the API's behavior aligns closely with reasonable developer > intuition, especially for common patterns. An unordered mapConcurrent() > (or an option for it) would, in my view, better support this intuitive use > for race-like patterns. Whereas, I have my doubts that developers commonly > would intuitively assume a concurrent operation to stick to strict ordering > (it's not what we are used to in most concurrent or > multil-threading scenarios) > > Ultimately, the question is whether mapConcurrent() should be optimized > primarily for preserving input sequence, or for enabling maximum throughput > and flexibility in concurrent scenarios, including efficient > "first-to-finish" patterns. > > > > >*Surprise for Race Semantics Users:* Following from the above, it could > be surprising for developers when they realize that the inherent input > ordering of mapConcurrent() means it's not optimized for these race > scenarios. The expectation would be that findFirst() returns as soon as > *any* task completes, but ordering can delay this if an earlier task (in > input order) is slower. > > This should be addressed above. > > >*Ordering Assumption in Concurrency:* My experience is that ordering is > not typically a default assumption when dealing with operations explicitly > marked as "parallel" or "concurrent." For instance, Stream.forEach() on a > parallel stream does not guarantee encounter order, presumably for > performance reasons ? a similar trade-off to what's being discussed for > mapConcurrent(). Developers often consult documentation for ordering > guarantees in concurrent contexts rather than assuming them. > > This should also be addressed above. > > >*Expectation of "True" Concurrency:* When I see an API like mapConcurrent(maxConcurrency, > mapper), my mental model is that if maxConcurrency permits, new tasks > should be initiated as soon as a slot is free. > > This is interesting, because this is how mapConcurrent used to work. It > only placed the limit of *concurrent work in progress* and not *work not > yet possible to propagate downstream*. This was changed, because a > delayed initial (in encounter order) item may let subsequent (completed) > work queue up indefinitely. > > So in conclusion, there's still room for a different take on > "mapConcurrentReorder" (name of course left up to the reader), and the good > news is that such a Gatherer can be implemented, evaluated, hardened, etc > outside of the JDK?and potentially some day something like it ends up in > the JDK. > > > Your mention of a potential mapConcurrentReorder() also brings to mind a > thought about API consistency with existing Stream conventions. We see > patterns like Stream.forEach() (which for parallel streams doesn't > guarantee encounter order, prioritizing performance) versus > Stream.forEachOrdered() (which explicitly enforces it). If mapConcurrent() > were to follow a similar naming convention, it might suggest that the base > mapConcurrent() itself would be the version optimized for throughput (and > thus potentially unordered by default), while a hypothetical > mapConcurrentOrdered() would be the variant explicitly providing the > strict ordering guarantee. This is an observation on how naming might align > with established JDK patterns to intuitively guide user expectations about > the default behavior. > > This naturally leads to the inherent challenge in designing such an API. > It seems we're trying to balance three desirable, but sometimes > conflicting, goals: > > 1. *Strict Encounter Ordering:* Results are emitted in the same order > as the input elements. > 2. *Bounded Memory Buffering:* Avoid out-of-memory errors by not > letting completed but un-emitted results queue up indefinitely. > 3. *Optimized (True) Concurrency:* If maxConcurrency is set (e.g., to N), > the system strives to have N tasks actively running whenever there are > pending input elements and available concurrency slots, rather than being > stalled by a slow-to-complete but earlier-in-sequence task. > > It appears that achieving all three simultaneously is not possible, and a > compromise must be made. > > From my perspective: > > - Goal #2 (Bounded Memory) is non-negotiable; OOM situations are > generally unacceptable. > - Goal #3 (Optimized Concurrency) feels fundamental to an API named > mapConcurrent(). Users will likely expect it to maximize the > concurrent execution of tasks up to the specified limit. Deviations from > this, often necessitated by strict adherence to Goal #1, can lead to > surprises. > - Goal #1 (Strict Ordering), while a "nice-to-have" and sometimes > beneficial, might not always align with common developer intuition for > operations explicitly labeled "concurrent," especially if it compromises > true concurrency. As discussed, ordering can often be reintroduced by the > caller if specifically needed. > > The current implementation understandably prioritizes #1 (Ordering) and #2 > (Bounded Memory). However, this prioritization can lead to situations where > #3 (Optimized Concurrency) is not fully realized, which can be > counter-intuitive. > > I've already mentioned the race scenario. Consider another example where > this becomes particularly evident. Imagine a scenario with a long-running > task (e.g., for periodic monitoring) combined with a stream of other "real" > tasks: > Java > > // Main tasks > List> realTasks = ... ; > // A long-running monitoring task > Callable longRunningMonitoringTask = () -> { > while (!allRealTasksSeemDone()) { // Simplified condition > System.out.println("Monitoring..."); > Thread.sleep(5000); > } > return null; > }; > > Stream> allTasks = Stream.concat( > Stream.of(longRunningMonitoringTask), > realTasks.stream().map(task -> (Callable) task) > ); > > allTasks > .gather(Gatherers.mapConcurrent(MAX_CONCURRENCY, callable -> callable.call())) > .forEach(result -> { /* output results */ }); > > The longRunningMonitoringTask would usually be the first element, with > the current strictly ordered behavior, it would occupy one of the > MAX_CONCURRENCY slots. and as soon as MAX_CONCURRENCY tasks are > executed, completed or not, all subsequent realTasks (beyond the first > one) would be starved, unable to even start until the > longRunningMonitoringTask completes?which is *never*. This creates a > deadlock or significant processing delay that would likely surprise a > developer expecting tasks to proceed concurrently up to the maxConcurrency > limit. An implementation more aligned with the "base name implies > throughput" idea (as per the forEach analogy) would likely handle this > more gracefully by letting tasks run truly concurrently without an implicit > ordering dependency. > > This reinforces my belief that an alternative gatherer, or a default > behavior for mapConcurrent() that prioritizes concurrency (as the name > mapConcurrent might suggest to many, akin to forEach), could be very > valuable. I understand this might be something that evolves outside the JDK > initially, and I appreciate you highlighting that path. > > Thanks again for the continued discussion and the transparency about the > design choices. > > Best regards, > > > > Cheers, > ? > > > *Viktor Klang* > Software Architect, Java Platform Group > Oracle > > ------------------------------ > *From:* Jige Yu > *Sent:* Wednesday, 4 June 2025 16:20 > *To:* Viktor Klang > *Cc:* core-libs-dev at openjdk.org > *Subject:* Re: [External] : Re: Should mapConcurrent() respect time order > instead of input order? > > > Hi Viktor, > > Thank you for sharing that the general feedback on mapConcurrent() has > been positive and for the insights into the ongoing enhancements, > especially around interruption handling and work-in-progress tracking. > > To clarify my own position, I am also extremely enthusiastic about the > mapConcurrent() API overall. It offers an elegant and straightforward way > to manage homogenous, I/O-intensive concurrent tasks within a structured > concurrency model, which is a significant improvement and a much-needed > addition. My feedback on ordering is aimed at maximizing its potential. > > I'd like to elaborate on a few specific scenarios and expectations that > inform my perspective on the ordering: > > 1. > > *Temptation for Race Semantics:* The beauty of mapConcurrent() integrating > with the Stream API means developers will naturally be drawn to use it for > race-like scenarios. Operations like findFirst() or limit(N) to get > the first few completed results are very intuitive combinations. For > example: > Java > > // Hypothetical use case: find the fastest responding service > Optional fastestResult = serviceUrls.stream() > .gather(Gatherers.mapConcurrent(MAX_CONCURRENCY, url -> fetch(url))) > .findFirst(); > > 2. > > *Surprise for Race Semantics Users:* Following from the above, it > could be surprising for developers when they realize that the inherent > input ordering of mapConcurrent() means it's not optimized for these > race scenarios. The expectation would be that findFirst() returns as > soon as *any* task completes, but ordering can delay this if an > earlier task (in input order) is slower. > 3. > > *Ordering Assumption in Concurrency:* My experience is that ordering > is not typically a default assumption when dealing with operations > explicitly marked as "parallel" or "concurrent." For instance, > Stream.forEach() on a parallel stream does not guarantee encounter > order, presumably for performance reasons ? a similar trade-off to what's > being discussed for mapConcurrent(). Developers often consult > documentation for ordering guarantees in concurrent contexts rather than > assuming them. > 4. > > *Expectation of "True" Concurrency:* When I see an API like mapConcurrent(maxConcurrency, > mapper), my mental model is that if maxConcurrency permits, new tasks > should be initiated as soon as a slot is free. For example, with > maxConcurrency=2: > - Task 1 starts. > - Task 2 starts. > - If Task 2 finishes while Task 1 is still running, I would expect > Task 3 to run concurrently alongside task 1, because the max concurrency is > 2, not 1. The current ordered behavior, where Task 3 might have to wait for > Task 1 to complete before its result can be processed (even if Task 3 > itself could have started and finished), can feel a bit counterintuitive to > the notion of maximizing concurrency up to the specified limit. It almost > feels like not a "max concurrency", but "max buffer size". > > These points are offered to highlight potential areas where the current > default could lead to subtle surprises or suboptimal performance for useful > concurrent patterns. > > Thanks again for the open discussion and for your work on these valuable > additions to the JDK. > > Best regards, > > On Tue, Jun 3, 2025 at 2:13?AM Viktor Klang > wrote: > > The general feedback received thus far has been primarily positive. There > have been a few behavior-related enhancements over the previews to better > handle interruption (there's still room to improve there, as per our > concurrent conversation) as well as some improvements to work-in-progress > tracking. > > It will be interesting to see which Gatherer-based operations will be > devised by Java developers in the future. > > Cheers, > ? > > > *Viktor Klang* > Software Architect, Java Platform Group > Oracle > ------------------------------ > *From:* Jige Yu > *Sent:* Monday, 2 June 2025 18:54 > *To:* Viktor Klang > *Cc:* core-libs-dev at openjdk.org > *Subject:* Re: [External] : Re: Should mapConcurrent() respect time order > instead of input order? > > > Hi Viktor, > > Thanks for your reply and for sharing your experience regarding user > preferences. I appreciate that perspective. > > You're right, if an unordered version of mapConcurrent proves to be > widely beneficial and is implemented and adopted by the community, it could > certainly make a strong case for future inclusion in the JDK. > > I wanted to clarify a nuance regarding user preference that I might not > have articulated clearly before. If the question is simply "ordered or > unordered?", in isolation, I can see why many, myself included, might lean > towards "ordered" as a general preference. > > However, the decision becomes more complex when the associated trade-offs > are considered. If the question were phrased more like, "Do you prefer an > ordered mapConcurrent by default, even if it entails potential > performance overhead and limitations for certain use cases like race() operations, > versus an unordered version that offers higher throughput and broader > applicability in such scenarios?" my (and perhaps others') answer might > differ. The perceived cost versus benefit of ordering changes significantly > when these factors are explicit. > > My initial suggestion stemmed from the belief that the performance and > flexibility gains of an unordered approach for I/O-bound tasks would, in > many practical situations, outweigh the convenience of default ordering, > especially since ordering can be reintroduced relatively easily, and > explicitly, when needed. > > Thanks again for the discussion. > > Best regards, > > On Mon, Jun 2, 2025 at 8:51?AM Viktor Klang > wrote: > > >My perspective is that strict adherence to input order for > mapConcurrent() might not be the most common or beneficial default > behavior for users. > > If there is indeed a *majority* who would benefit from an unordered > version of mapConcurrent (my experience is that the majority prefer > ordered) then, since it is possible to implement such a Gatherer outside of > the JDK, this is something which will be constructed, widely used, and > someone will then propose to add something similar to the JDK. > > >While re-implementing the gatherer is a possibility, the existing > implementation is non-trivial, and creating a custom, robust alternative > represents a significant undertaking. > > The existing version needs to maintain order, which adds to the complexity > of the implementation. Implementing an unordered version would likely look > different. > I'd definitely encourage taking the opportunity to attempt to implement it. > > Cheers, > ? > > > *Viktor Klang* > Software Architect, Java Platform Group > Oracle > > ------------------------------ > *From:* Jige Yu > *Sent:* Monday, 2 June 2025 17:05 > *To:* Viktor Klang > *Cc:* core-libs-dev at openjdk.org > *Subject:* Re: [External] : Re: Should mapConcurrent() respect time order > instead of input order? > > > Thank you for your response and for considering my feedback on the > mapConcurrent() gatherer. I understand and respect that the final > decision rests with the JDK maintainers. > > I would like to offer a couple of further points for consideration. My > perspective is that strict adherence to input order for mapConcurrent() might > not be the most common or beneficial default behavior for users. I'd be > very interested to see any research or data that suggests otherwise, as > that would certainly inform my understanding. > > From my experience, a more common need is for higher throughput in > I/O-intensive operations. The ability to support use cases like race()?where > the first successfully completed operation determines the outcome?also > seems like a valuable capability that is currently infeasible due to the > ordering constraint. > > As I see it, if a developer specifically requires the input order to be > preserved, this can be achieved with relative ease by applying a subsequent > sorting operation. For instance: > > .gather(mapConcurrent(...)) > .sorted(Comparator.comparing(Result::getInputSequenceId)) > > The primary challenge in these scenarios is typically the efficient > fan-out and execution of concurrent tasks, not the subsequent sorting of > results. > > Conversely, as you've noted, there isn't a straightforward way to modify > the current default ordered behavior to achieve the higher throughput or > race() semantics that an unordered approach would naturally provide. > > While re-implementing the gatherer is a possibility, the existing > implementation is non-trivial, and creating a custom, robust alternative > represents a significant undertaking. My hope was that an unordered option > could be a valuable addition to the standard library, benefiting a wider > range of developers. > > Thank you again for your time and consideration. > > > On Mon, Jun 2, 2025 at 7:48?AM Viktor Klang > wrote: > > >Even if it by default preserves input order, when I explicitly called > stream.unordered(), could mapConcurrent() respect that and in return > achieve higher throughput with support for race? > > The Gatherer doesn't know whether the Stream is unordered or ordered. The > operation should be semantically equivalent anyway. > > Cheers, > ? > > > *Viktor Klang* > Software Architect, Java Platform Group > Oracle > ------------------------------ > *From:* Jige Yu > *Sent:* Monday, 2 June 2025 16:29 > *To:* Viktor Klang ; core-libs-dev at openjdk.org < > core-libs-dev at openjdk.org> > *Subject:* [External] : Re: Should mapConcurrent() respect time order > instead of input order? > > Sorry. Forgot to copy to the mailing list. > > On Mon, Jun 2, 2025 at 7:27?AM Jige Yu wrote: > > Thanks Viktor! > > I was thinking from my own experience that I wouldn't have automatically > assumed that a concurrent fanout library would by default preserve input > order. > > And I think wanting high throughput with real-life utilities like race > would be more commonly useful. > > But I could be wrong. > > Regardless, mapConcurrent() can do both, no? > > Even if it by default preserves input order, when I explicitly called > stream.unordered(), could mapConcurrent() respect that and in return > achieve higher throughput with support for race? > > > > On Mon, Jun 2, 2025 at 2:33?AM Viktor Klang > wrote: > > Hi! > > In a similar vein to the built-in Collectors, > the built-in Gatherers provide solutions to common stream-related > problems, but also, they also serve as "inspiration" for developers for > what is possible to implement using Gatherers. > > If someone, for performance reasons, and with a use-case which does not > require encounter-order, want to take advantage of that combination of > circumstances, it is definitely possible to implement your own Gatherer > which has that behavior. > > Cheers, > ? > > > *Viktor Klang* > Software Architect, Java Platform Group > Oracle > ------------------------------ > *From:* core-libs-dev on behalf of Jige > Yu > *Sent:* Sunday, 1 June 2025 21:08 > *To:* core-libs-dev at openjdk.org > *Subject:* Should mapConcurrent() respect time order instead of input > order? > > It seems like for most people, input order isn't that important for > concurrent work, and concurrent results being in non-deterministic order is > often expected. > > If mapConcurrent() just respect output encounter order: > > It'll be able to achieve *higher throughput* if an early task is slow, > For example, with concurrency=2, and if the first task takes 10 minutes to > run, mapConcurrent() would only be able to process 2 tasks within the first > 10 minutes; whereas with encounter order, the first task being slow doesn't > block the 3rd - 100th elements from being processed and output. > > mapConcurrent() can be used to implement useful concurrent semantics, for > example to *support race* semantics. Imagine if I need to send request to > 10 candidate backends and take whichever that succeeds first, I'd be able > to do: > > backends.stream() > .gather(mapConcurrent( > backend -> { > try { > return backend.fetchOrder(); > } catch (RpcException e) { > return null; // failed to fetch but not fatal > } > }) > .filter(Objects::notNull) > .findFirst(); // first success then cancel the rest > > Cheers, > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From xgong at openjdk.org Tue Jul 1 06:04:29 2025 From: xgong at openjdk.org (Xiaohong Gong) Date: Tue, 1 Jul 2025 06:04:29 GMT Subject: RFR: 8359419: AArch64: Relax min vector length to 32-bit for short vectors Message-ID: ### Background On AArch64, the minimum vector length supported is 64-bit for basic types, except for `byte` and `boolean` (32-bit and 16-bit respectively to match special Vector API features). This limitation prevents intrinsification of vector type conversions between `short` and wider types (e.g. `long/double`) in Vector API when the entire vector length is within 128 bits, resulting in degraded performance for such conversions. For example, type conversions between `ShortVector.SPECIES_128` and `LongVector.SPECIES_128` are not supported on AArch64 NEON and SVE architectures with 128-bit max vector size. This occurs because the compiler would need to generate a vector with 2 short elements, resulting in a 32-bit vector size. To intrinsify such type conversion APIs, we need to relax the min vector length constraint from 64-bit to 32-bit for short vectors. ### Impact Analysis #### 1. Vector types Vectors only with `short` element types will be affected, as we just supported 32-bit `short` vectors in this change. #### 2. Vector API No impact on Vector API or the vector-specific nodes. The minimum vector shape at API level remains 64-bit. It's not possible to generate a final vector IR with 32-bit vector size. Type conversions may generate intermediate 32-bit vectors, but they will be resized or cast to vectors with at least 64-bit length. #### 3. Auto-vectorization Enables vectorization of cases containing only 2 `short` lanes, with significant performance improvements. Since we have supported 32-bit vectors for `byte` type for a long time, extending this to `short` did not introduce additional risks. #### 4. Codegen of vector nodes NEON doesn't support 32-bit SIMD instructions, so we use 64-bit instructions instead. For lanewise operations, this is safe because the higher half bits can be ignored. Details: - Lanewise vector operations are unaffected as explained above. - NEON supports vector load/store instructions with 32-bit vector size, which we already use in relevant IRs (shared by SVE). - Cross-lane operations like reduction may be affected, potentially causing incorrect results for `min/max/mul/and` reductions. The min vector size for such operations should remain 64-bit. We've added assertions in match rules. Since it's currently not possible to generate such reductions (Vector API minimum is 64-bit, and SLP doesn't support subword type reductions), we maintain the status quo. However, adding an explicit vector size check in `match_rule_supported_vector()` would be beneficial. - Missing codegen support for type conversions with 32-bit input or output vector size should be added. ### Main changes: - Support 2 shorts vector types. The supported min vector element count for each basic type is: - `T_BOOLEAN`: 2 - `T_BYTE`: 4 - `T_CHAR`: 4 - `T_SHORT`: 2 (new supported) - `T_INT`/`T_FLOAT`/`T_LONG`/`T_DOUBLE`: 2 - Add codegen support for `Vector[U]Cast` with 32-bit input or output vector size. `VectorReinterpret` has already considered the 32-bit vector size cases. - Unsupport reductions with less than 8 bytes vector size explicitly. - Add additional IR tests for Vector API type conversions. - Add JMH benchmark for auto-vectorization with two 16-bit lanes. ### Test Tested hotspot/jdk/langtools - all tests passed. ### Performance Following shows the performance improvement of relative VectorAPI JMHs on a NVIDIA Grace (128-bit SVE2) machine: Benchmark SIZE Mode Unit Before After Gain VectorFPtoIntCastOperations.microDouble128ToShort128 512 thrpt ops/ms 731.529 26278.599 35.92 VectorFPtoIntCastOperations.microDouble128ToShort128 1024 thrpt ops/ms 366.461 10595.767 28.91 VectorFPtoIntCastOperations.microFloat64ToShort64 512 thrpt ops/ms 315.791 14327.682 45.37 VectorFPtoIntCastOperations.microFloat64ToShort64 1024 thrpt ops/ms 158.485 7261.847 45.82 VectorZeroExtend.short2Long 128 thrpt ops/ms 1447.243 898666.972 620.95 And here is the performance improvement of the added JMH on Grace: Benchmark LEN Mode Unit Before After Gain VectorTwoShorts.addVec2S 64 avgt ns/op 20.948 12.683 1.65 VectorTwoShorts.addVec2S 128 avgt ns/op 40.073 22.703 1.76 VectorTwoShorts.addVec2S 512 avgt ns/op 157.447 83.691 1.88 VectorTwoShorts.addVec2S 1024 avgt ns/op 313.022 165.085 1.89 VectorTwoShorts.mulVec2S 64 avgt ns/op 20.981 12.647 1.65 VectorTwoShorts.mulVec2S 128 avgt ns/op 40.279 22.637 1.77 VectorTwoShorts.mulVec2S 512 avgt ns/op 158.642 83.371 1.90 VectorTwoShorts.mulVec2S 1024 avgt ns/op 314.788 165.205 1.90 VectorTwoShorts.reverseBytesVec2S 64 avgt ns/op 17.739 9.106 1.94 VectorTwoShorts.reverseBytesVec2S 128 avgt ns/op 32.591 15.632 2.08 VectorTwoShorts.reverseBytesVec2S 512 avgt ns/op 126.154 55.284 2.28 VectorTwoShorts.reverseBytesVec2S 1024 avgt ns/op 254.592 107.457 2.36 We can observe the similar uplift on an AArch64 N1 (NEON) machine. ------------- Commit messages: - 8359419: AArch64: Relax min vector length to 32-bit for short vectors Changes: https://git.openjdk.org/jdk/pull/26057/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26057&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8359419 Stats: 306 lines in 8 files changed: 196 ins; 9 del; 101 mod Patch: https://git.openjdk.org/jdk/pull/26057.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26057/head:pull/26057 PR: https://git.openjdk.org/jdk/pull/26057 From xgong at openjdk.org Tue Jul 1 06:09:44 2025 From: xgong at openjdk.org (Xiaohong Gong) Date: Tue, 1 Jul 2025 06:09:44 GMT Subject: RFR: 8355563: VectorAPI: Refactor current implementation of subword gather load API [v2] In-Reply-To: References: Message-ID: On Wed, 25 Jun 2025 09:16:48 GMT, Xiaohong Gong wrote: >> JDK-8318650 introduced hotspot intrinsification of subword gather load APIs for X86 platforms [1]. However, the current implementation is not optimal for AArch64 SVE platform, which natively supports vector instructions for subword gather load operations using an int vector for indices (see [2][3]). >> >> Two key areas require improvement: >> 1. At the Java level, vector indices generated for range validation could be reused for the subsequent gather load operation on architectures with native vector instructions like AArch64 SVE. However, the current implementation prevents compiler reuse of these index vectors due to divergent control flow, potentially impacting performance. >> 2. At the compiler IR level, the additional `offset` input for `LoadVectorGather`/`LoadVectorGatherMasked` with subword types increases IR complexity and complicates backend implementation. Furthermore, generating `add` instructions before each memory access negatively impacts performance. >> >> This patch refactors the implementation at both the Java level and compiler mid-end to improve efficiency and maintainability across different architectures. >> >> Main changes: >> 1. Java-side API refactoring: >> - Explicitly passes generated index vectors to hotspot, eliminating duplicate index vectors for gather load instructions on >> architectures like AArch64. >> 2. C2 compiler IR refactoring: >> - Refactors `LoadVectorGather`/`LoadVectorGatherMasked` IR for subword types by removing the memory offset input and incorporating it into the memory base `addr` at the IR level. This simplifies backend implementation, reduces add operations, and unifies the IR across all types. >> 3. Backend changes: >> - Streamlines X86 implementation of subword gather operations following the removal of the offset input from the IR level. >> >> Performance: >> The performance of the relative JMH improves up to 27% on a X86 AVX512 system. Please see the data below: >> >> Benchmark Mode Cnt Unit SIZE Before After Gain >> GatherOperationsBenchmark.microByteGather128 thrpt 30 ops/ms 64 53682.012 52650.325 0.98 >> GatherOperationsBenchmark.microByteGather128 thrpt 30 ops/ms 256 14484.252 14255.156 0.98 >> GatherOperationsBenchmark.microByteGather128 thrpt 30 ops/ms 1024 3664.900 3595.615 0.98 >> GatherOperationsBenchmark.microByteGather128 thrpt 30 ops/ms 4096 908.31... > > Xiaohong Gong has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: > > - Address review comments > - Merge 'jdk:master' into JDK-8355563 > - 8355563: VectorAPI: Refactor current implementation of subword gather load API Ping again! Thanks in advance! ------------- PR Comment: https://git.openjdk.org/jdk/pull/25138#issuecomment-3021961883 From ihse at openjdk.org Tue Jul 1 06:22:46 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 1 Jul 2025 06:22:46 GMT Subject: RFR: 8361076: Add benchmark for ImageReader in preparation for Valhalla changes [v3] In-Reply-To: References: Message-ID: On Mon, 30 Jun 2025 15:08:25 GMT, David Beaumont wrote: >> Initial benchmark to capture at least some comparative measures of ImageReader performance. >> >> Current results on my laptop: >> >> Benchmark Mode Cnt Score Error Units >> NewImageBenchmark.warmCache_CountAllNodes avgt 5 0.785 ? 0.140 ms/op >> NewImageBenchmark.coldStart_CountOnly ss 5 34.051 ? 17.662 ms/op >> NewImageBenchmark.coldStart_InitAndCount ss 5 31.006 ? 9.674 ms/op >> NewImageBenchmark.coldStart_LoadJavacInitClasses ss 5 3.752 ? 6.873 ms/op >> >> The upcoming changes to ImageReader should show significant improvements to these results. > > David Beaumont has updated the pull request incrementally with one additional commit since the last revision: > > Some tidying up relating to the state objects. Build change trivially fine. ------------- Marked as reviewed by ihse (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26044#pullrequestreview-2973675262 From epeter at openjdk.org Tue Jul 1 06:38:45 2025 From: epeter at openjdk.org (Emanuel Peter) Date: Tue, 1 Jul 2025 06:38:45 GMT Subject: RFR: 8355563: VectorAPI: Refactor current implementation of subword gather load API [v2] In-Reply-To: References: Message-ID: On Tue, 1 Jul 2025 06:07:03 GMT, Xiaohong Gong wrote: >> Xiaohong Gong has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: >> >> - Address review comments >> - Merge 'jdk:master' into JDK-8355563 >> - 8355563: VectorAPI: Refactor current implementation of subword gather load API > > Ping again! Thanks in advance! @XiaohongGong I'm a little busy at the moment, and soon going on a summer vacation, so I cannot promise a full review soon. Feel free to ask someone else to have a look. I quickly looked through your new benchmark results you published after integration of https://github.com/openjdk/jdk/pull/25539. There seem to still be a few cases where `Gain < 1`. Especially: GatherOperationsBenchmark.microShortGather512_MASK 256 thrpt 30 ops/ms 11587.465 10674.598 0.92 GatherOperationsBenchmark.microShortGather512_MASK 1024 thrpt 30 ops/ms 2902.731 2629.739 0.90 GatherOperationsBenchmark.microShortGather512_MASK 4096 thrpt 30 ops/ms 741.546 671.124 0.90 and GatherOperationsBenchmark.microShortGather256_MASK 256 thrpt 30 ops/ms 11339.217 10951.141 0.96 GatherOperationsBenchmark.microShortGather256_MASK 1024 thrpt 30 ops/ms 2840.081 2718.823 0.95 GatherOperationsBenchmark.microShortGather256_MASK 4096 thrpt 30 ops/ms 725.334 696.343 0.96 and GatherOperationsBenchmark.microByteGather512_MASK 64 thrpt 30 ops/ms 50588.210 48220.741 0.95 Do you know what happens in those cases? That said: https://github.com/openjdk/jdk/pull/25539 seems to have been quite the sucess, there are way fewer regressions now than before ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/25138#issuecomment-3022057434 From xgong at openjdk.org Tue Jul 1 06:43:44 2025 From: xgong at openjdk.org (Xiaohong Gong) Date: Tue, 1 Jul 2025 06:43:44 GMT Subject: RFR: 8355563: VectorAPI: Refactor current implementation of subword gather load API [v2] In-Reply-To: References: Message-ID: <7-WqNSzjPLOsHJ4DHogxqbiInl8TIz5sxIEXbIfo2OQ=.912568b8-830d-47cc-a837-46af6be618f3@github.com> On Tue, 1 Jul 2025 06:07:03 GMT, Xiaohong Gong wrote: >> Xiaohong Gong has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: >> >> - Address review comments >> - Merge 'jdk:master' into JDK-8355563 >> - 8355563: VectorAPI: Refactor current implementation of subword gather load API > > Ping again! Thanks in advance! > @XiaohongGong I'm a little busy at the moment, and soon going on a summer vacation, so I cannot promise a full review soon. Feel free to ask someone else to have a look. > > I quickly looked through your new benchmark results you published after integration of #25539. There seem to still be a few cases where `Gain < 1`. Especially: > > ``` > GatherOperationsBenchmark.microShortGather512_MASK 256 thrpt 30 ops/ms 11587.465 10674.598 0.92 > GatherOperationsBenchmark.microShortGather512_MASK 1024 thrpt 30 ops/ms 2902.731 2629.739 0.90 > GatherOperationsBenchmark.microShortGather512_MASK 4096 thrpt 30 ops/ms 741.546 671.124 0.90 > ``` > > and > > ``` > GatherOperationsBenchmark.microShortGather256_MASK 256 thrpt 30 ops/ms 11339.217 10951.141 0.96 > GatherOperationsBenchmark.microShortGather256_MASK 1024 thrpt 30 ops/ms 2840.081 2718.823 0.95 > GatherOperationsBenchmark.microShortGather256_MASK 4096 thrpt 30 ops/ms 725.334 696.343 0.96 > ``` > > and > > ``` > GatherOperationsBenchmark.microByteGather512_MASK 64 thrpt 30 ops/ms 50588.210 48220.741 0.95 > ``` > > Do you know what happens in those cases? Thanks for your input! Yes, I spent some time making an analysis on these little regressions. Seems there are the architecture HW influences like the cache miss or code alignment. I tried with a larger loop alignment like 32, and the performance will be improved and regressions are gone. Since I'm not quite familiar with X86 architectures, I'm not sure of the exact point. Any suggestions on that? ------------- PR Comment: https://git.openjdk.org/jdk/pull/25138#issuecomment-3022088710 From epeter at openjdk.org Tue Jul 1 06:55:41 2025 From: epeter at openjdk.org (Emanuel Peter) Date: Tue, 1 Jul 2025 06:55:41 GMT Subject: RFR: 8355563: VectorAPI: Refactor current implementation of subword gather load API [v2] In-Reply-To: <7-WqNSzjPLOsHJ4DHogxqbiInl8TIz5sxIEXbIfo2OQ=.912568b8-830d-47cc-a837-46af6be618f3@github.com> References: <7-WqNSzjPLOsHJ4DHogxqbiInl8TIz5sxIEXbIfo2OQ=.912568b8-830d-47cc-a837-46af6be618f3@github.com> Message-ID: On Tue, 1 Jul 2025 06:41:32 GMT, Xiaohong Gong wrote: >> Ping again! Thanks in advance! > >> @XiaohongGong I'm a little busy at the moment, and soon going on a summer vacation, so I cannot promise a full review soon. Feel free to ask someone else to have a look. >> >> I quickly looked through your new benchmark results you published after integration of #25539. There seem to still be a few cases where `Gain < 1`. Especially: >> >> ``` >> GatherOperationsBenchmark.microShortGather512_MASK 256 thrpt 30 ops/ms 11587.465 10674.598 0.92 >> GatherOperationsBenchmark.microShortGather512_MASK 1024 thrpt 30 ops/ms 2902.731 2629.739 0.90 >> GatherOperationsBenchmark.microShortGather512_MASK 4096 thrpt 30 ops/ms 741.546 671.124 0.90 >> ``` >> >> and >> >> ``` >> GatherOperationsBenchmark.microShortGather256_MASK 256 thrpt 30 ops/ms 11339.217 10951.141 0.96 >> GatherOperationsBenchmark.microShortGather256_MASK 1024 thrpt 30 ops/ms 2840.081 2718.823 0.95 >> GatherOperationsBenchmark.microShortGather256_MASK 4096 thrpt 30 ops/ms 725.334 696.343 0.96 >> ``` >> >> and >> >> ``` >> GatherOperationsBenchmark.microByteGather512_MASK 64 thrpt 30 ops/ms 50588.210 48220.741 0.95 >> ``` >> >> Do you know what happens in those cases? > > Thanks for your input! Yes, I spent some time making an analysis on these little regressions. Seems there are the architecture HW influences like the cache miss or code alignment. I tried with a larger loop alignment like 32, and the performance will be improved and regressions are gone. Since I'm not quite familiar with X86 architectures, I'm not sure of the exact point. Any suggestions on that? @XiaohongGong Maybe someone from Intel (@jatin-bhateja @sviswa7) can help you with the x86 specific issues. You could always use hardware counters to measure cache misses. Also if the vectors are not cache-line aligned, there may be split loads or stores. Also that can be measured with hardware counters. Maybe the benchmark needs to be improved somehow, to account for issues with alignment. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25138#issuecomment-3022132271 From xgong at openjdk.org Tue Jul 1 07:10:41 2025 From: xgong at openjdk.org (Xiaohong Gong) Date: Tue, 1 Jul 2025 07:10:41 GMT Subject: RFR: 8355563: VectorAPI: Refactor current implementation of subword gather load API [v2] In-Reply-To: <7-WqNSzjPLOsHJ4DHogxqbiInl8TIz5sxIEXbIfo2OQ=.912568b8-830d-47cc-a837-46af6be618f3@github.com> References: <7-WqNSzjPLOsHJ4DHogxqbiInl8TIz5sxIEXbIfo2OQ=.912568b8-830d-47cc-a837-46af6be618f3@github.com> Message-ID: On Tue, 1 Jul 2025 06:41:32 GMT, Xiaohong Gong wrote: >> Ping again! Thanks in advance! > >> @XiaohongGong I'm a little busy at the moment, and soon going on a summer vacation, so I cannot promise a full review soon. Feel free to ask someone else to have a look. >> >> I quickly looked through your new benchmark results you published after integration of #25539. There seem to still be a few cases where `Gain < 1`. Especially: >> >> ``` >> GatherOperationsBenchmark.microShortGather512_MASK 256 thrpt 30 ops/ms 11587.465 10674.598 0.92 >> GatherOperationsBenchmark.microShortGather512_MASK 1024 thrpt 30 ops/ms 2902.731 2629.739 0.90 >> GatherOperationsBenchmark.microShortGather512_MASK 4096 thrpt 30 ops/ms 741.546 671.124 0.90 >> ``` >> >> and >> >> ``` >> GatherOperationsBenchmark.microShortGather256_MASK 256 thrpt 30 ops/ms 11339.217 10951.141 0.96 >> GatherOperationsBenchmark.microShortGather256_MASK 1024 thrpt 30 ops/ms 2840.081 2718.823 0.95 >> GatherOperationsBenchmark.microShortGather256_MASK 4096 thrpt 30 ops/ms 725.334 696.343 0.96 >> ``` >> >> and >> >> ``` >> GatherOperationsBenchmark.microByteGather512_MASK 64 thrpt 30 ops/ms 50588.210 48220.741 0.95 >> ``` >> >> Do you know what happens in those cases? > > Thanks for your input! Yes, I spent some time making an analysis on these little regressions. Seems there are the architecture HW influences like the cache miss or code alignment. I tried with a larger loop alignment like 32, and the performance will be improved and regressions are gone. Since I'm not quite familiar with X86 architectures, I'm not sure of the exact point. Any suggestions on that? > @XiaohongGong Maybe someone from Intel (@jatin-bhateja @sviswa7) can help you with the x86 specific issues. You could always use hardware counters to measure cache misses. Also if the vectors are not cache-line aligned, there may be split loads or stores. Also that can be measured with hardware counters. Maybe the benchmark needs to be improved somehow, to account for issues with alignment. I also tried to measure cache misses with perf on my x86 machine, and I noticed the cache miss is increased. The generated code layout of the test/benchmark is changed with my changes in Java side, so I guess maybe the alignment is different with before. To verify my thought, I used the vm option `-XX:OptoLoopAlignment=32`, and the performance can be improved a lot compared with the version without my change. So I think the patch itself maybe acceptable even we noticed minor regressions. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25138#issuecomment-3022195040 From alanb at openjdk.org Tue Jul 1 07:28:40 2025 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 1 Jul 2025 07:28:40 GMT Subject: RFR: 8361076: Add benchmark for ImageReader in preparation for Valhalla changes [v3] In-Reply-To: References: Message-ID: On Mon, 30 Jun 2025 15:08:25 GMT, David Beaumont wrote: >> Initial benchmark to capture at least some comparative measures of ImageReader performance. >> >> Current results on my laptop: >> >> Benchmark Mode Cnt Score Error Units >> NewImageBenchmark.warmCache_CountAllNodes avgt 5 0.785 ? 0.140 ms/op >> NewImageBenchmark.coldStart_CountOnly ss 5 34.051 ? 17.662 ms/op >> NewImageBenchmark.coldStart_InitAndCount ss 5 31.006 ? 9.674 ms/op >> NewImageBenchmark.coldStart_LoadJavacInitClasses ss 5 3.752 ? 6.873 ms/op >> >> The upcoming changes to ImageReader should show significant improvements to these results. > > David Beaumont has updated the pull request incrementally with one additional commit since the last revision: > > Some tidying up relating to the state objects. test/micro/org/openjdk/bench/jdk/internal/jrtfs/ImageReaderBenchmark.java line 230: > 228: // Created by running "java -verbose:class", throwing away anonymous inner > 229: // classes and anything without a reliable name, and grouping by the stated > 230: // source. It's not perfect, but it's representative. I don't think this is maintainable. How useful (or not) is this benchmark if the names of all the internal classes (that will change from release to release) are dropped from this? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26044#discussion_r2176636106 From djelinski at openjdk.org Tue Jul 1 07:34:06 2025 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Tue, 1 Jul 2025 07:34:06 GMT Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API [v9] In-Reply-To: References: Message-ID: On Thu, 26 Jun 2025 17:34:45 GMT, Daniel Fuchs wrote: >> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 525 commits: >> >> - merge latest changes from master branch >> - http3: run H3StreamLimitReachedTest.java with -Djdk.httpclient.http3.maxStreamLimitTimeout=0 too >> - retry the ResetControlStream test as needed >> - http3: fix pending connection and reconnection on stream limit reached logic >> - http3: pending acknowledgement should be registered before actually sending the packet >> - http3: fix race with ping requests in PacketSpaceManager.java causing intermittent failures in H3ErrorHandlingTest.java >> - http3: improve exceptions in Http3ServerExchange.java >> - http3: fix exception handling in CancelRequestTest.java >> - http3: review feedback - revert HPACK.java >> - Implement X509TrustManagerImpl#checkClientTrusted for QUIC >> - ... and 515 more: https://git.openjdk.org/jdk/compare/5a1301df...0229c215 > > src/java.base/share/classes/sun/security/ssl/KeyShareExtension.java line 49: > >> 47: static final ExtensionConsumer chOnLoadConsumer = >> 48: new CHKeyShareConsumer(); >> 49: static final HandshakeAbsence chOnTradeAbsence = > > Could we fix that one in mainline to remove this file from the PR? [JDK-8361125](https://bugs.openjdk.org/browse/JDK-8361125) > src/java.base/share/classes/sun/security/ssl/PreSharedKeyExtension.java line 61: > >> 59: static final HandshakeConsumer chOnTradeConsumer = >> 60: new CHPreSharedKeyUpdate(); >> 61: static final HandshakeAbsence chOnTradeAbsence = > > Could we bring this change to mainline to remove this file from this PR? [JDK-8361125](https://bugs.openjdk.org/browse/JDK-8361125) > src/java.base/share/classes/sun/security/ssl/SupportedGroupsExtension.java line 50: > >> 48: static final ExtensionConsumer chOnLoadConsumer = >> 49: new CHSupportedGroupsConsumer(); >> 50: static final HandshakeAbsence chOnTradeAbsence = > > Another one that could disappear if we fixed that typo in mainline first. > @djelinski would you be willing to do that? [JDK-8361125](https://bugs.openjdk.org/browse/JDK-8361125) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2176646140 PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2176645611 PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2176645272 From aph at openjdk.org Tue Jul 1 08:13:41 2025 From: aph at openjdk.org (Andrew Haley) Date: Tue, 1 Jul 2025 08:13:41 GMT Subject: RFR: 8359419: AArch64: Relax min vector length to 32-bit for short vectors In-Reply-To: References: Message-ID: On Tue, 1 Jul 2025 05:59:15 GMT, Xiaohong Gong wrote: > ### Background > On AArch64, the minimum vector length supported is 64-bit for basic types, except for `byte` and `boolean` (32-bit and 16-bit respectively to match special Vector API features). This limitation prevents intrinsification of vector type conversions between `short` and wider types (e.g. `long/double`) in Vector API when the entire vector length is within 128 bits, resulting in degraded performance for such conversions. > > For example, type conversions between `ShortVector.SPECIES_128` and `LongVector.SPECIES_128` are not supported on AArch64 NEON and SVE architectures with 128-bit max vector size. This occurs because the compiler would need to generate a vector with 2 short elements, resulting in a 32-bit vector size. > > To intrinsify such type conversion APIs, we need to relax the min vector length constraint from 64-bit to 32-bit for short vectors. > > ### Impact Analysis > #### 1. Vector types > Vectors only with `short` element types will be affected, as we just supported 32-bit `short` vectors in this change. > > #### 2. Vector API > No impact on Vector API or the vector-specific nodes. The minimum vector shape at API level remains 64-bit. It's not possible to generate a final vector IR with 32-bit vector size. Type conversions may generate intermediate 32-bit vectors, but they will be resized or cast to vectors with at least 64-bit length. > > #### 3. Auto-vectorization > Enables vectorization of cases containing only 2 `short` lanes, with significant performance improvements. Since we have supported 32-bit vectors for `byte` type for a long time, extending this to `short` did not introduce additional risks. > > #### 4. Codegen of vector nodes > NEON doesn't support 32-bit SIMD instructions, so we use 64-bit instructions instead. For lanewise operations, this is safe because the higher half bits can be ignored. > > Details: > - Lanewise vector operations are unaffected as explained above. > - NEON supports vector load/store instructions with 32-bit vector size, which we already use in relevant IRs (shared by SVE). > - Cross-lane operations like reduction may be affected, potentially causing incorrect results for `min/max/mul/and` reductions. The min vector size for such operations should remain 64-bit. We've added assertions in match rules. Since it's currently not possible to generate such reductions (Vector API minimum is 64-bit, and SLP doesn't support subword type reductions), we maintain the status quo. However, adding an explicit vector size check in `match_rule_s... src/hotspot/cpu/aarch64/aarch64.ad line 2371: > 2369: switch(bt) { > 2370: case T_BOOLEAN: > 2371: // It needs to load/store a vector mask with only 2 elements Suggestion: // Load/store a vector mask with only 2 elements Same with the other cases. src/hotspot/cpu/aarch64/aarch64.ad line 2386: > 2384: break; > 2385: default: > 2386: // Limit the min vector length to 64-bit normally. Suggestion: // Limit the min vector length to 64-bit. src/hotspot/cpu/aarch64/aarch64_vector.ad line 199: > 197: case Op_MaxReductionV: > 198: // Reductions with less than 8 bytes vector length are > 199: // not supported for now. Suggestion: // not supported. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26057#discussion_r2176759967 PR Review Comment: https://git.openjdk.org/jdk/pull/26057#discussion_r2176761846 PR Review Comment: https://git.openjdk.org/jdk/pull/26057#discussion_r2176762709 From aph at openjdk.org Tue Jul 1 08:23:38 2025 From: aph at openjdk.org (Andrew Haley) Date: Tue, 1 Jul 2025 08:23:38 GMT Subject: RFR: 8360884: Better scoped values [v3] In-Reply-To: References: <8yqi3J3JfLa2NNags9waBIshIMIuOJRjm-rHF--Wjws=.d04990af-5fdb-4218-a8da-60bda679b1d1@github.com> Message-ID: <5n7tsON05k7Ww6Tej-nT3P9A2fRrd76W05XMe0RPaiI=.b4300af0-1919-4b1c-9068-7964911d8133@github.com> On Mon, 30 Jun 2025 15:55:03 GMT, Alan Bateman wrote: > There's something a bit uncomfortable about initializing hashGenerator in ScopedValue's class initializer, then changing it in Constants class initializer. Iimmediately clear what the memory model issues. It doesn't of course matter if the stale value is used but I think confusing on first sight. That's fair. I think it's a benign race, but I guess that's still a race. > Have you tried dropping the initializer from ScopedValue so it hashGenerator is only set by Constants? The ScopedValue constructor can call generateKey if hashGenerator is null, and hashGenerator can become a stable field. That would be more explicit. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26019#discussion_r2176792642 From xgong at openjdk.org Tue Jul 1 08:35:42 2025 From: xgong at openjdk.org (Xiaohong Gong) Date: Tue, 1 Jul 2025 08:35:42 GMT Subject: RFR: 8359419: AArch64: Relax min vector length to 32-bit for short vectors In-Reply-To: References: Message-ID: On Tue, 1 Jul 2025 08:10:16 GMT, Andrew Haley wrote: >> ### Background >> On AArch64, the minimum vector length supported is 64-bit for basic types, except for `byte` and `boolean` (32-bit and 16-bit respectively to match special Vector API features). This limitation prevents intrinsification of vector type conversions between `short` and wider types (e.g. `long/double`) in Vector API when the entire vector length is within 128 bits, resulting in degraded performance for such conversions. >> >> For example, type conversions between `ShortVector.SPECIES_128` and `LongVector.SPECIES_128` are not supported on AArch64 NEON and SVE architectures with 128-bit max vector size. This occurs because the compiler would need to generate a vector with 2 short elements, resulting in a 32-bit vector size. >> >> To intrinsify such type conversion APIs, we need to relax the min vector length constraint from 64-bit to 32-bit for short vectors. >> >> ### Impact Analysis >> #### 1. Vector types >> Vectors only with `short` element types will be affected, as we just supported 32-bit `short` vectors in this change. >> >> #### 2. Vector API >> No impact on Vector API or the vector-specific nodes. The minimum vector shape at API level remains 64-bit. It's not possible to generate a final vector IR with 32-bit vector size. Type conversions may generate intermediate 32-bit vectors, but they will be resized or cast to vectors with at least 64-bit length. >> >> #### 3. Auto-vectorization >> Enables vectorization of cases containing only 2 `short` lanes, with significant performance improvements. Since we have supported 32-bit vectors for `byte` type for a long time, extending this to `short` did not introduce additional risks. >> >> #### 4. Codegen of vector nodes >> NEON doesn't support 32-bit SIMD instructions, so we use 64-bit instructions instead. For lanewise operations, this is safe because the higher half bits can be ignored. >> >> Details: >> - Lanewise vector operations are unaffected as explained above. >> - NEON supports vector load/store instructions with 32-bit vector size, which we already use in relevant IRs (shared by SVE). >> - Cross-lane operations like reduction may be affected, potentially causing incorrect results for `min/max/mul/and` reductions. The min vector size for such operations should remain 64-bit. We've added assertions in match rules. Since it's currently not possible to generate such reductions (Vector API minimum is 64-bit, and SLP doesn't support subword type reductions), we maintain the status quo. However, addin... > > src/hotspot/cpu/aarch64/aarch64.ad line 2371: > >> 2369: switch(bt) { >> 2370: case T_BOOLEAN: >> 2371: // It needs to load/store a vector mask with only 2 elements > > Suggestion: > > // Load/store a vector mask with only 2 elements > > Same with the other cases. Thanks so much for your comment. I will fix them soon. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26057#discussion_r2176831961 From duke at openjdk.org Tue Jul 1 09:07:43 2025 From: duke at openjdk.org (ExE Boss) Date: Tue, 1 Jul 2025 09:07:43 GMT Subject: RFR: 8360884: Better scoped values [v3] In-Reply-To: <5n7tsON05k7Ww6Tej-nT3P9A2fRrd76W05XMe0RPaiI=.b4300af0-1919-4b1c-9068-7964911d8133@github.com> References: <8yqi3J3JfLa2NNags9waBIshIMIuOJRjm-rHF--Wjws=.d04990af-5fdb-4218-a8da-60bda679b1d1@github.com> <5n7tsON05k7Ww6Tej-nT3P9A2fRrd76W05XMe0RPaiI=.b4300af0-1919-4b1c-9068-7964911d8133@github.com> Message-ID: On Tue, 1 Jul 2025 08:21:10 GMT, Andrew Haley wrote: >> src/java.base/share/classes/java/lang/ScopedValue.java line 802: >> >>> 800: return x; >>> 801: } >>> 802: }; >> >> There's something a bit uncomfortable about initializing hashGenerator in ScopedValue's class initializer, then changing it in Constants class initializer. Iimmediately clear what the memory model issues. It doesn't of course matter if the stale value is used but I think confusing on first sight. >> >> Have you tried dropping the initializer from ScopedValue so it hashGenerator is only set by Constants? The ScopedValue constructor can call generateKey if hashGenerator is null, and hashGenerator can become a stable field. > >> There's something a bit uncomfortable about initializing hashGenerator in ScopedValue's class initializer, then changing it in Constants class initializer. Iimmediately clear what the memory model issues. It doesn't of course matter if the stale value is used but I think confusing on first sight. > > That's fair. I think it's a benign race, but I guess that's still a race. > >> Have you tried dropping the initializer from ScopedValue so it hashGenerator is only set by Constants? The ScopedValue constructor can call generateKey if hashGenerator is null, and hashGenerator can become a stable field. > > That would be more explicit. > > Have you tried dropping the initializer from ScopedValue so hashGenerator is only set by Constants? The ScopedValue constructor can call generateKey if hashGenerator is null, and hashGenerator can become a stable field. > > That would be more explicit. A?stable?field would?also be?constant?foldable. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26019#discussion_r2176927586 From swen at openjdk.org Tue Jul 1 09:20:43 2025 From: swen at openjdk.org (Shaojin Wen) Date: Tue, 1 Jul 2025 09:20:43 GMT Subject: RFR: 8361018: Re-examine buffering and encoding conversion in BufferedWriter [v6] In-Reply-To: <8Gw6kEDNuv2UmryKGGqW7QDndJJr29rT6dHKa9pLQLQ=.7d15c0c6-70f2-44e7-a07c-977ec66ed9c7@github.com> References: <8Gw6kEDNuv2UmryKGGqW7QDndJJr29rT6dHKa9pLQLQ=.7d15c0c6-70f2-44e7-a07c-977ec66ed9c7@github.com> Message-ID: On Tue, 1 Jul 2025 02:33:16 GMT, Chen Liang wrote: > I think we can split this into two parts: > > 1. Update buffering strategy for BufferedWriter when backing writer is an OutputStreamWriter > 2. Use an alternative StreamDecoder impl if the CharsetDecoder is an ArrayDecoder > > This should make the whole thing more clear. You are right. The current PR is the fast path optimization of UTF_8 OutputStreamWriter. For UTF_16/UTF_16LE/UTF_16BE, I submitted a draft pr 26034. And for the buffer of BufferedWriter, if char[] is used, the encodeArrayLoop technique can be used in CharsetEncoder for optimization. If the buffer uses StringBuilder wrap as StringCharBuffer, StringCharBuffer cannot use encodeArrayLoop for optimization, which is the key point affecting performance. | buffer type | CharBuffer type | support arrayLoop | | -- | -- | -- | | char[] | HeapCharBuffer | true | | StringBuilder | StringCharBuffer | false | Therefore, I recommend continuing to use char[] as buffer in BufferedWriter non-UTF_8 OutputStreamWriter scenarios. If you are interested, you can take a look at the optimization of these two encodeArrayLoop: * In UTF_8$Encoder public final class UTF_8 extends Unicode { private static final class Encoder extends CharsetEncoder { protected final CoderResult encodeLoop(CharBuffer src, ByteBuffer dst) { if (src.hasArray() && dst.hasArray()) return encodeArrayLoop(src, dst); else return encodeBufferLoop(src, dst); } // ... } } * UnicodeEncoder in PR #26034 public abstract class UnicodeEncoder extends CharsetEncoder { protected CoderResult encodeLoop(CharBuffer src, ByteBuffer dst) { if (src.hasArray() && dst.hasArray()) { return encodeArrayLoop(src, dst); } return encodeBufferLoop(src, dst); } private CoderResult encodeArrayLoop(CharBuffer src, ByteBuffer dst) { char[] sa = src.array(); int soff = src.arrayOffset(); int sp = soff + src.position(); int sl = soff + src.limit(); byte[] da = dst.array(); int doff = dst.arrayOffset(); int dp = doff + dst.position(); int dl = doff + dst.limit(); .... } } ------------- PR Comment: https://git.openjdk.org/jdk/pull/26022#issuecomment-3022903336 From aph at openjdk.org Tue Jul 1 11:15:54 2025 From: aph at openjdk.org (Andrew Haley) Date: Tue, 1 Jul 2025 11:15:54 GMT Subject: RFR: 8360884: Better scoped values [v4] In-Reply-To: <8yqi3J3JfLa2NNags9waBIshIMIuOJRjm-rHF--Wjws=.d04990af-5fdb-4218-a8da-60bda679b1d1@github.com> References: <8yqi3J3JfLa2NNags9waBIshIMIuOJRjm-rHF--Wjws=.d04990af-5fdb-4218-a8da-60bda679b1d1@github.com> Message-ID: > Scoped values cannot be used early in the JDK boot process because of some dependencies on System.getProperty(). This dependency should be removed in a way that allows scoped values to be created (but not necessarily bound) at any stage during boot. > > Also, Scoped Value's constructor has a synchronized block, which limits the use of scoped values at runtime. Constructing a scoped value should be a thread-local operation. Andrew Haley has updated the pull request incrementally with two additional commits since the last revision: - 8360884: Better scoped values - 8360884: Better scoped values ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26019/files - new: https://git.openjdk.org/jdk/pull/26019/files/3f01aad6..f8ff2965 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26019&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26019&range=02-03 Stats: 30 lines in 2 files changed: 9 ins; 13 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/26019.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26019/head:pull/26019 PR: https://git.openjdk.org/jdk/pull/26019 From djelinski at openjdk.org Tue Jul 1 11:16:58 2025 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Tue, 1 Jul 2025 11:16:58 GMT Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API [v9] In-Reply-To: References: Message-ID: <2uIlI67ZuXY_FGElLjUN1wcwoPSdVrQACgyVF7AEbfk=.624e0472-4a35-4c9a-aec8-cc02e28d5632@github.com> On Thu, 26 Jun 2025 16:36:40 GMT, Daniel Fuchs wrote: >> Hi, >> >> Please find here a PR for the implementation of [JEP 517: HTTP/3 for the HTTP Client API](https://openjdk.org/jeps/517). >> >> The CSR can be viewed at [JDK-8350588: Implement JEP 517: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588) >> >> This JEP proposes to enhance the HttpClient implementation to support HTTP/3. >> It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider. > > Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 525 commits: > > - merge latest changes from master branch > - http3: run H3StreamLimitReachedTest.java with -Djdk.httpclient.http3.maxStreamLimitTimeout=0 too > - retry the ResetControlStream test as needed > - http3: fix pending connection and reconnection on stream limit reached logic > - http3: pending acknowledgement should be registered before actually sending the packet > - http3: fix race with ping requests in PacketSpaceManager.java causing intermittent failures in H3ErrorHandlingTest.java > - http3: improve exceptions in Http3ServerExchange.java > - http3: fix exception handling in CancelRequestTest.java > - http3: review feedback - revert HPACK.java > - Implement X509TrustManagerImpl#checkClientTrusted for QUIC > - ... and 515 more: https://git.openjdk.org/jdk/compare/5a1301df...0229c215 src/java.net.http/share/classes/jdk/internal/net/http/http3/frames/FramesDecoder.java line 143: > 141: * This method doesn't try to do any decoding. > 142: */ > 143: public Http3Frame peek() { This method is unused. I'll remove it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2177297533 From nbenalla at openjdk.org Tue Jul 1 11:35:42 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Tue, 1 Jul 2025 11:35:42 GMT Subject: RFR: 8346884: Add since checker test to jdk.editpad In-Reply-To: References: Message-ID: On Tue, 3 Jun 2025 10:09:44 GMT, Nizar Benalla wrote: > Please review this patch to add a new test to check `@since` tags in the `jdk.editpad` module. > > TIA keep alive ------------- PR Comment: https://git.openjdk.org/jdk/pull/25613#issuecomment-3023556036 From jpai at openjdk.org Tue Jul 1 11:42:47 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 1 Jul 2025 11:42:47 GMT Subject: RFR: 8359337: XML/JAXP tests that make network connections should ensure that no proxy is selected [v2] In-Reply-To: <7Y0SnncvGGNUttXuKSc8Htqn_fwu0i9mzZ1loaDJO0w=.96cd29ff-9a3e-44c6-8e00-81e6d6021480@github.com> References: <0ZlZ_gQ5h1iAeWoYi1oFZCdbAnBlLMrwcSxdgR8tT6A=.94b90475-a65e-4bc0-a0af-65833f4cdfad@github.com> <7Y0SnncvGGNUttXuKSc8Htqn_fwu0i9mzZ1loaDJO0w=.96cd29ff-9a3e-44c6-8e00-81e6d6021480@github.com> Message-ID: On Mon, 30 Jun 2025 16:52:55 GMT, Jaikiran Pai wrote: >> Can I please get a review of this test-only change which addresses the issue noted in https://bugs.openjdk.org/browse/JDK-8359337? >> >> On macOS, the JDK by default (without any explicit system properties) picks up the proxy settings configured on the host. These proxy settings then get used by the JVM wide `DefaultProxySelector`. That can then result in some tests, like the ones listed in that issue, to fail. >> >> The commit in this PR updates these tests to disable the proxy when running these tests. I've verified that after these changes, these tests now pass on the host where these tests were failing previously. Additionally I've run tier2 to make sure nothing else is impacted due to this change. > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > Joe's review - add bugid Hello Johannes, > What is the error seen on macOS when the proxy is not disabled? These tests have been written to trigger specific error conditions. Some of them rely on a specific exception being thrown when communicating with an address that is known to be invalid. When a proxy is involved, the communication with the target address happens over the proxy which results in a different error (which depends on the proxy implementation). That causes the assertions in these tests to fail. Thank you all for the reviews. I'll go ahead and integrate this now. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26052#issuecomment-3023572131 PR Comment: https://git.openjdk.org/jdk/pull/26052#issuecomment-3023573558 From jpai at openjdk.org Tue Jul 1 11:42:47 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 1 Jul 2025 11:42:47 GMT Subject: Integrated: 8359337: XML/JAXP tests that make network connections should ensure that no proxy is selected In-Reply-To: <0ZlZ_gQ5h1iAeWoYi1oFZCdbAnBlLMrwcSxdgR8tT6A=.94b90475-a65e-4bc0-a0af-65833f4cdfad@github.com> References: <0ZlZ_gQ5h1iAeWoYi1oFZCdbAnBlLMrwcSxdgR8tT6A=.94b90475-a65e-4bc0-a0af-65833f4cdfad@github.com> Message-ID: On Mon, 30 Jun 2025 16:18:00 GMT, Jaikiran Pai wrote: > Can I please get a review of this test-only change which addresses the issue noted in https://bugs.openjdk.org/browse/JDK-8359337? > > On macOS, the JDK by default (without any explicit system properties) picks up the proxy settings configured on the host. These proxy settings then get used by the JVM wide `DefaultProxySelector`. That can then result in some tests, like the ones listed in that issue, to fail. > > The commit in this PR updates these tests to disable the proxy when running these tests. I've verified that after these changes, these tests now pass on the host where these tests were failing previously. Additionally I've run tier2 to make sure nothing else is impacted due to this change. This pull request has now been integrated. Changeset: 7583a7b8 Author: Jaikiran Pai URL: https://git.openjdk.org/jdk/commit/7583a7b857da053c5e3770b680ab3494f1a6b66a Stats: 128 lines in 5 files changed: 97 ins; 7 del; 24 mod 8359337: XML/JAXP tests that make network connections should ensure that no proxy is selected Reviewed-by: lancea, iris, joehw ------------- PR: https://git.openjdk.org/jdk/pull/26052 From jpai at openjdk.org Tue Jul 1 11:52:49 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 1 Jul 2025 11:52:49 GMT Subject: [jdk25] RFR: 8359337: XML/JAXP tests that make network connections should ensure that no proxy is selected Message-ID: Can I please get a review of this backport of a test-only fix? This backports the fix for https://bugs.openjdk.org/browse/JDK-8359337 into JDK 25. The original fix was integrated into mainline a few minutes back https://github.com/openjdk/jdk/pull/26052. Backporting this fix should help prevent failure of these tests on macOS hosts which have proxies configured. ------------- Commit messages: - Backport 7583a7b857da053c5e3770b680ab3494f1a6b66a Changes: https://git.openjdk.org/jdk/pull/26065/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26065&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8359337 Stats: 128 lines in 5 files changed: 97 ins; 7 del; 24 mod Patch: https://git.openjdk.org/jdk/pull/26065.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26065/head:pull/26065 PR: https://git.openjdk.org/jdk/pull/26065 From rriggs at openjdk.org Tue Jul 1 13:29:44 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 1 Jul 2025 13:29:44 GMT Subject: RFR: 8334015: Add Support for UUID Version 7 (UUIDv7) defined in RFC 9562 [v10] In-Reply-To: <4b4eB1IhNlZXMVqf-aOj-IIp3kwLiqOVfeqioc2dL9Q=.8af3f74b-7b61-424a-b2c6-421fa6e0c0e6@github.com> References: <4b4eB1IhNlZXMVqf-aOj-IIp3kwLiqOVfeqioc2dL9Q=.8af3f74b-7b61-424a-b2c6-421fa6e0c0e6@github.com> Message-ID: On Mon, 30 Jun 2025 18:19:30 GMT, Kieran Farrell wrote: >> With the recent approval of UUIDv7 (https://datatracker.ietf.org/doc/rfc9562/), this PR aims to add a new static method UUID.timestampUUID() which constructs and returns a UUID in support of the new time generated UUID version. >> >> The specification requires embedding the current timestamp in milliseconds into the first bits 0?47. The version number in bits 48?51, bits 52?63 are available for sub-millisecond precision or for pseudorandom data. The variant is set in bits 64?65. The remaining bits 66?127 are free to use for more pseudorandom data or to employ a counter based approach for increased time percision (https://www.rfc-editor.org/rfc/rfc9562.html#name-uuid-version-7). >> >> The choice of implementation comes down to balancing the sensitivity level of being able to distingush UUIDs created below <1ms apart with performance. A test simulating a high-concurrency environment with 4 threads generating 10000 UUIDv7 values in parallel to measure the collision rate of each implementation (the amount of times the time based portion of the UUID was not unique and entries could not distinguished by time) yeilded the following results for each implemtation: >> >> >> - random-byte-only - 99.8% >> - higher-precision - 3.5% >> - counter-based - 0% >> >> >> Performance tests show a decrease in performance as expected with the counter based implementation due to the introduction of synchronization: >> >> - random-byte-only 143.487 ? 10.932 ns/op >> - higher-precision 149.651 ? 8.438 ns/op >> - counter-based 245.036 ? 2.943 ns/op >> >> The best balance here might be to employ a higher-precision implementation as the large increase in time sensitivity comes at a very slight performance cost. > > Kieran Farrell 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: > > update spec Set the CSR state to Proposed to begin the CSR review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25303#issuecomment-3024019886 From rriggs at openjdk.org Tue Jul 1 14:11:45 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 1 Jul 2025 14:11:45 GMT Subject: RFR: 8352016: Improve java/lang/RuntimeTests/RuntimeExitLogTest.java [v3] In-Reply-To: References: Message-ID: On Fri, 4 Apr 2025 10:29:43 GMT, Takuya Kiriyama wrote: >> The current test program for the logging feature added in JDK-8301627 does not fully check some important cases. >> >> Issue Details: >> The test does not properly check cases where logging might not happen due to different logging levels. (e.g. ALL, TRACE, WARNING, etc.) >> The check for the logged stack trace is not enough, as it does not confirm enough details in the output. >> >> Fix Details: >> Added more test cases to check behavior under different logging levels. >> Improved the stack trace check by verifying more details in the logged output. >> These changes make the test more complete and ensure that the logging feature works as expected. >> Also, any existing test cases prior to this pull request are retained. >> >> The test was verified in the following OS environments, and it passed successfully in both environments. >> - Windows Server 2022 Standard 21H2 >> - Red Hat Enterprise Linux release 9.2 (Plow) >> >> Could you please review this fix? > > Takuya Kiriyama has updated the pull request incrementally with one additional commit since the last revision: > > 8352016: Improve java/lang/RuntimeTests/RuntimeExitLogTest.java Looks good, thanks for your patience. ------------- Marked as reviewed by rriggs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24050#pullrequestreview-2975617552 From tkiriyama at openjdk.org Tue Jul 1 14:11:46 2025 From: tkiriyama at openjdk.org (Takuya Kiriyama) Date: Tue, 1 Jul 2025 14:11:46 GMT Subject: RFR: 8352016: Improve java/lang/RuntimeTests/RuntimeExitLogTest.java In-Reply-To: References: Message-ID: On Wed, 19 Mar 2025 20:07:26 GMT, Roger Riggs wrote: >> The current test program for the logging feature added in JDK-8301627 does not fully check some important cases. >> >> Issue Details: >> The test does not properly check cases where logging might not happen due to different logging levels. (e.g. ALL, TRACE, WARNING, etc.) >> The check for the logged stack trace is not enough, as it does not confirm enough details in the output. >> >> Fix Details: >> Added more test cases to check behavior under different logging levels. >> Improved the stack trace check by verifying more details in the logged output. >> These changes make the test more complete and ensure that the logging feature works as expected. >> Also, any existing test cases prior to this pull request are retained. >> >> The test was verified in the following OS environments, and it passed successfully in both environments. >> - Windows Server 2022 Standard 21H2 >> - Red Hat Enterprise Linux release 9.2 (Plow) >> >> Could you please review this fix? > > Out of curiosity, what raised this as an issue that needed more tests? > Was there a failure of some implementation that caused a bug? Hi, @RogerRiggs I'm just following up on this PR. I addressed your comments before. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24050#issuecomment-3023026379 From rriggs at openjdk.org Tue Jul 1 14:13:42 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 1 Jul 2025 14:13:42 GMT Subject: RFR: 8334015: Add Support for UUID Version 7 (UUIDv7) defined in RFC 9562 [v10] In-Reply-To: <4b4eB1IhNlZXMVqf-aOj-IIp3kwLiqOVfeqioc2dL9Q=.8af3f74b-7b61-424a-b2c6-421fa6e0c0e6@github.com> References: <4b4eB1IhNlZXMVqf-aOj-IIp3kwLiqOVfeqioc2dL9Q=.8af3f74b-7b61-424a-b2c6-421fa6e0c0e6@github.com> Message-ID: On Mon, 30 Jun 2025 18:19:30 GMT, Kieran Farrell wrote: >> With the recent approval of UUIDv7 (https://datatracker.ietf.org/doc/rfc9562/), this PR aims to add a new static method UUID.timestampUUID() which constructs and returns a UUID in support of the new time generated UUID version. >> >> The specification requires embedding the current timestamp in milliseconds into the first bits 0?47. The version number in bits 48?51, bits 52?63 are available for sub-millisecond precision or for pseudorandom data. The variant is set in bits 64?65. The remaining bits 66?127 are free to use for more pseudorandom data or to employ a counter based approach for increased time percision (https://www.rfc-editor.org/rfc/rfc9562.html#name-uuid-version-7). >> >> The choice of implementation comes down to balancing the sensitivity level of being able to distingush UUIDs created below <1ms apart with performance. A test simulating a high-concurrency environment with 4 threads generating 10000 UUIDv7 values in parallel to measure the collision rate of each implementation (the amount of times the time based portion of the UUID was not unique and entries could not distinguished by time) yeilded the following results for each implemtation: >> >> >> - random-byte-only - 99.8% >> - higher-precision - 3.5% >> - counter-based - 0% >> >> >> Performance tests show a decrease in performance as expected with the counter based implementation due to the introduction of synchronization: >> >> - random-byte-only 143.487 ? 10.932 ns/op >> - higher-precision 149.651 ? 8.438 ns/op >> - counter-based 245.036 ? 2.943 ns/op >> >> The best balance here might be to employ a higher-precision implementation as the large increase in time sensitivity comes at a very slight performance cost. > > Kieran Farrell 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: > > update spec LGTM ------------- Marked as reviewed by rriggs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25303#pullrequestreview-2975624056 From dfuchs at openjdk.org Tue Jul 1 14:16:44 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Tue, 1 Jul 2025 14:16:44 GMT Subject: [jdk25] RFR: 8359337: XML/JAXP tests that make network connections should ensure that no proxy is selected In-Reply-To: References: Message-ID: <2AwBxckSavQEtCCKD20ckA_RazX5u7YSEVdgGqm8bdM=.ae0d00dd-3106-40b1-8698-abce750cffa1@github.com> On Tue, 1 Jul 2025 11:48:30 GMT, Jaikiran Pai wrote: > Can I please get a review of this backport of a test-only fix? > > This backports the fix for https://bugs.openjdk.org/browse/JDK-8359337 into JDK 25. The original fix was integrated into mainline a few minutes back https://github.com/openjdk/jdk/pull/26052. Backporting this fix should help prevent failure of these tests on macOS hosts which have proxies configured. Look reasonable to me - though strictly speaking tests that fiddle with the global configuration should be run in /othervm. This seems OK without /othervm as long as tests are not run concurrently in the same VM. Maybe wait for @JoeWang-Java to approve before pushing. ------------- PR Review: https://git.openjdk.org/jdk/pull/26065#pullrequestreview-2975637913 Marked as reviewed by dfuchs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26065#pullrequestreview-2975643173 From duke at openjdk.org Tue Jul 1 14:18:20 2025 From: duke at openjdk.org (David Beaumont) Date: Tue, 1 Jul 2025 14:18:20 GMT Subject: RFR: 8360037: Refactor ImageReader in preparation for Valhalla support Message-ID: Refactoring `ImageReader` to make it easy to add preview mode functionality for Valhalla. This PR is a large change to `ImageReader` (effectively a rewrite) but reduces the surface area of the API significantly, reduces code complexity and increases performance/memory efficiency. The need for this sort of change comes from the need to support "preview mode" in Valhalla for classes loaded from core modules. ### Preview Mode In the proposed preview mode support for Valhalla, a resource with the name `/modules//` may come from one of two locations in the underlying jimage file; `//` or `//META-INF/preview/`. Furthermore, directories (represented as directory nodes via the API) will have a potentially different number of child nodes depending on whether preview mode is in effect, and some directories may only exist at all in preview mode. Furthermore, the directories and symbolic link nodes in `/packages/...` will also be affected by the existence of new package directories. To retain consistency and avoid "surprises" later, all of this needs to be taken into account. Below is a summary of the main changes for mainline JDK to better support preview mode later: ### 1: Improved encapsulation for preview mode The current `ImageReader` code exposes the data from the jimage file in several ways; via the `Node` abstraction, but also with methods which return an `ImageLocation` instance directly. In preview mode it would not be acceptable to return the `ImageLocation`, since that would leak the existence of resources in the `META-INF/preview` namespace and lets users see resource nodes with names that don't match the underlying `ImageLocation` from which their contents come. As such, the PR removes all methods which can leak `ImageLocation` or other "underlying" semantics about the jimage file. Luckily most of these are either used minimally and easily migrated to using nodes, or they were not being used at all. This PR also removes any methods which were already unused across the OpenJDK codebase (if I discover any issues with over-trimming of the API during full CI testing, it will be easy to address). ### 2. Simplification of directory child node handling The current `ImageReader` code attempts to create parent directories "on demand" for any child nodes it creates. This results in parent directories having a non-empty but incomplete set of child nodes present. This is referred to as the directory being "incomplete" and requires users of the API to understand this and potentially "complete" these nodes by calling back into the `ImageReader` API. This approach is an attempt to provide lazy node creation (which is a necessary trait since there are ~31,000 nodes in a typical jimage hierarchy) but isn't actually necessary since a child node has no "get parent" functionality and simply not creating parent nodes at the point is functionally equivalent. The partially complete directory nodes also pose an issue for preview mode support, making it more complex to reason about where and when preview child nodes should be applied. This PR simplifies directory node handling in two ways: 1. Directory nodes are either empty (incomplete) or have all child nodes present. 2. Directory nodes no longer have an API to return their (possibly incomplete) child nodes to users. This results in simpler to reason about code for directory management and simpler changes later to support preview mode. Removing the on-demand parent directory creation and the partial child list management also has a noticeable performance improvement (based on the new `ImageReaderBenchmark` in pr/26044). ### 3. More comments and code assertions Since `ImageReader` is a critical bit of internal tooling for OpenJDK, I made sure to add significant comments explaining the behaviour, as well as adding many new in-code assert statements. The version of `ImageReader` in this PR is 70 lines shorter than the current version, but if you account for new comments, it's really a reduction of almost 40% (640 -> 400 lines of code) and has over 200 more comment lines. ### 4. New tests I added a new unit test for `ImageReader` since, until now, its API was not really being tested directly. These tests are useful now, but will really help when preview mode is added in Valhalla, since then there will need to be significant edge-case testing. I'm happy to improve or change tests in this PR, but they definitely cover the main cases. ### 5. Adding TODO comments for review discussion. There are obviously some open questions about the exact design of the APIs, and some questions around behaviour. To make reviewing easier, I've added inline TODOs which are there to illicit feedback. I will account for an remove all of these before the PR is integrated, but I want reviewers to read and comment on them (even if there is no change expected). ### Performance Improvements On my laptop (not objectively interesting, but good for comparison) I am seeing a significant performance improvement over all benchmarks and a reduction in timing variability. These benchmarks are awkward because of the need to test things in a "cold start" state, so timings will have larger variability than expected, but the performance improvements are consistent and non trivial: Run with `make test TEST="micro:jdk.internal.jrtfs.ImageReaderBenchmark"` using the benchmark currently being added in `pr/26044`: Current version: Benchmark Mode Cnt Score Error Units ImageReaderBenchmark.warmCache_CountAllNodes avgt 5 0.784 ? 0.023 ms/op ImageReaderBenchmark.coldStart_CountOnly ss 5 37.910 ? 28.554 ms/op ImageReaderBenchmark.coldStart_InitAndCount ss 5 37.471 ? 18.775 ms/op ImageReaderBenchmark.coldStart_LoadJavacInitClasses ss 5 4.279 ? 7.959 ms/op This PR: Benchmark Mode Cnt Score Error Units ImageReaderBenchmark.warmCache_CountAllNodes avgt 10 0.880 ? 0.086 ms/op ImageReaderBenchmark.coldStart_CountOnly ss 10 14.303 ? 3.975 ms/op ImageReaderBenchmark.coldStart_InitAndCount ss 10 14.032 ? 3.068 ms/op ImageReaderBenchmark.coldStart_LoadJavacInitClasses ss 10 2.530 ? 0.348 ms/op Shows a >2.5x speedup for traversing all nodes in a "cold start" state, and ~1.7x speedup for loading the core set of classes needed to start javac. ------------- Depends on: https://git.openjdk.org/jdk/pull/26044 Commit messages: - Integrating with ImageReaderBenchmark. - Merge branch 'master' into jdk_8355953_reader/squashed - undo dependent changes - syncing to main branch - Newline at EOF. - Pretty much ready for review now. - WIP - more tests needed. - Reapply diffs. Changes: https://git.openjdk.org/jdk/pull/26054/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26054&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8360037 Stats: 2217 lines in 11 files changed: 1613 ins; 342 del; 262 mod Patch: https://git.openjdk.org/jdk/pull/26054.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26054/head:pull/26054 PR: https://git.openjdk.org/jdk/pull/26054 From duke at openjdk.org Tue Jul 1 14:18:21 2025 From: duke at openjdk.org (David Beaumont) Date: Tue, 1 Jul 2025 14:18:21 GMT Subject: RFR: 8360037: Refactor ImageReader in preparation for Valhalla support In-Reply-To: References: Message-ID: <9xh9VZuuTCyFomE_TV9usc_bVDSPz6ssX5HDmj-hhSU=.18a3192c-57b1-4920-b97b-4cfd37c6fea6@github.com> On Mon, 30 Jun 2025 23:27:49 GMT, David Beaumont wrote: > Refactoring `ImageReader` to make it easy to add preview mode functionality for Valhalla. > > This PR is a large change to `ImageReader` (effectively a rewrite) but reduces the surface area of the API significantly, reduces code complexity and increases performance/memory efficiency. The need for this sort of change comes from the need to support "preview mode" in Valhalla for classes loaded from core modules. > > ### Preview Mode > > In the proposed preview mode support for Valhalla, a resource with the name `/modules//` may come from one of two locations in the underlying jimage file; `//` or `//META-INF/preview/`. Furthermore, directories (represented as directory nodes via the API) will have a potentially different number of child nodes depending on whether preview mode is in effect, and some directories may only exist at all in preview mode. > > Furthermore, the directories and symbolic link nodes in `/packages/...` will also be affected by the existence of new package directories. To retain consistency and avoid "surprises" later, all of this needs to be taken into account. > > Below is a summary of the main changes for mainline JDK to better support preview mode later: > > ### 1: Improved encapsulation for preview mode > > The current `ImageReader` code exposes the data from the jimage file in several ways; via the `Node` abstraction, but also with methods which return an `ImageLocation` instance directly. In preview mode it would not be acceptable to return the `ImageLocation`, since that would leak the existence of resources in the `META-INF/preview` namespace and lets users see resource nodes with names that don't match the underlying `ImageLocation` from which their contents come. > > As such, the PR removes all methods which can leak `ImageLocation` or other "underlying" semantics about the jimage file. Luckily most of these are either used minimally and easily migrated to using nodes, or they were not being used at all. This PR also removes any methods which were already unused across the OpenJDK codebase (if I discover any issues with over-trimming of the API during full CI testing, it will be easy to address). > > ### 2. Simplification of directory child node handling > > The current `ImageReader` code attempts to create parent directories "on demand" for any child nodes it creates. This results in parent directories having a non-empty but incomplete set of child nodes present. This is referred to as the directory being "incomple... Anything marked "TODO" is for discussion during the coming review. I don't intend to leave any of these in the code after, but they raise specific issues I'd like address. With these pre-preview comments, I think this is finally ready for review. make/test/BuildMicrobenchmark.gmk line 1: > 1: # Ignore this file, it's part of the PR to add the benchmark. I'll merge and sort everything out once that's in. src/java.base/share/classes/jdk/internal/jimage/ImageReader.java line 1: > 1: /* I think that this class is best reviewed as if it were a new implementation, rather than trying to reason about the specific changes between the versions. Hopefully the comments will make the design clear and the reduced complexity/lines-of-code will help it be understood in a more stand-alone way. src/java.base/share/classes/jdk/internal/jimage/ImageReader.java line 95: > 93: } > 94: > 95: // directory management interface A large number of the methods below were either: 1. Unused or effectively no-ops. 2. Breaking encapsulation and leaking underlying types such as `ImageLocation` (not a big problem now, but prevents cleanly implementing the preview mode logic for Valhalla). The new API has essentially 3 top level methods here: 1. findNode() 2. getResource(Node) 3. getResourceBuffer(Node) Any navigation of the node hierarchy is done via `getChildNames()` and unlike now, no user can obtain a reference to an "incomplete" node. src/java.base/share/classes/jdk/internal/jimage/ImageReader.java line 157: > 155: } > 156: > 157: /** This method and the `getResourceBuffer()` method below are, I think, only called in one place and could, in theory, be factored out of this class altogether. src/java.base/share/classes/jdk/internal/jimage/ImageReader.java line 255: > 253: if (openers.isEmpty()) { > 254: close(); > 255: // TODO (review note): Should this be synchronized by "this" ?? I genuinely this this might be an existing issue. src/java.base/share/classes/jdk/internal/jimage/ImageReader.java line 601: > 599: } > 600: > 601: /** Most of these were either never called or no longer needed in the new implementation. src/java.base/share/classes/jdk/internal/jrtfs/ExplodedImage.java line 122: > 120: > 121: @Override > 122: public List getChildren() { ExplodedImage makes a custom subclass of Node to "fake" the ImageReader behaviour. While this will need to change for preview mode, for now it's enough to just modify the one affected API. src/java.base/share/classes/jdk/internal/jrtfs/JrtFileAttributes.java line 52: > 50: @Override > 51: public FileTime creationTime() { > 52: return node.creationTime(); There's no benefit to having all these one-line getter methods duplicated in `ImageReader` since it already provides the file attributes object directly. src/java.base/share/classes/jdk/internal/jrtfs/JrtFileSystem.java line 228: > 226: } > 227: if (filter == null) { > 228: return node.getChildren() Same logic, just based on the child names instead of the nodes. src/java.base/share/classes/jdk/internal/jrtfs/SystemImage.java line 61: > 59: // open a .jimage and build directory structure > 60: final ImageReader image = ImageReader.open(moduleImageFile); > 61: image.getRootDirectory(); This method no longer serves any purpose (it used to initialize the root directory entries, but it's not needed now. src/java.base/share/classes/jdk/internal/module/SystemModuleFinders.java line 224: > 222: ImageReader reader = SystemImage.reader(); > 223: for (String mn : reader.getModuleNames()) { > 224: ImageLocation loc = reader.findLocation(mn, "module-info.class"); It is unsafe to let users see the underlying `ImageLocation` for a resource in preview mode, so this code had to be migrated to using a `Node` based view of the data. This is probably the most complex change not part of `ImageReader` itself. src/java.base/share/classes/jdk/internal/module/SystemModuleFinders.java line 509: > 507: if (node.isDirectory()) { > 508: // build node > 509: ImageReader.Node dir = SystemImage.reader().findNode(name); This is an example of the fragility of the current "partially complete directory" behaviour. The `node` variable is exactly the same instance as the `dir` variable, and the call to `findNode()` serves only to ensure the directory is "complete" before use. In the new API only the name is available, so `findNode()` *must* be called, ensuring there's no risk of accidentally using an incomplete directory node. test/jdk/jdk/internal/jimage/ImageReaderTest.java line 78: > 76: > 77: @Test > 78: public void testModuleDirectories() throws IOException { I could make these more data driven (i.e. parametrized) if people want. test/jdk/jdk/internal/jimage/ImageReaderTest.java line 217: > 215: > 216: /// Loads and performs actions on classes stored in a given `ImageReader`. > 217: private static class ImageClassLoader extends ClassLoader { Loading and running class bytes to get a `toString()` value will be super important in the preview mode tests to prove that the correct class bytes were used. test/jdk/jdk/internal/jimage/JImageReadTest.java line 28: > 26: * @summary Unit test for libjimage JIMAGE_Open/Read/Close > 27: * @modules java.base/jdk.internal.jimage > 28: * @run testng/othervm JImageReadTest Looking back, I don't recall exactly why this was needed. I will see if it's still necessary, but I think it was. test/jdk/tools/jimage/ImageReaderDuplicateChildNodesTest.java line 1: > 1: /* Just uses child names rather than nodes. ------------- PR Review: https://git.openjdk.org/jdk/pull/26054#pullrequestreview-2973065956 PR Review: https://git.openjdk.org/jdk/pull/26054#pullrequestreview-2975530216 PR Review Comment: https://git.openjdk.org/jdk/pull/26054#discussion_r2177654333 PR Review Comment: https://git.openjdk.org/jdk/pull/26054#discussion_r2177702506 PR Review Comment: https://git.openjdk.org/jdk/pull/26054#discussion_r2176142533 PR Review Comment: https://git.openjdk.org/jdk/pull/26054#discussion_r2177705221 PR Review Comment: https://git.openjdk.org/jdk/pull/26054#discussion_r2177707657 PR Review Comment: https://git.openjdk.org/jdk/pull/26054#discussion_r2177710965 PR Review Comment: https://git.openjdk.org/jdk/pull/26054#discussion_r2177658457 PR Review Comment: https://git.openjdk.org/jdk/pull/26054#discussion_r2177660750 PR Review Comment: https://git.openjdk.org/jdk/pull/26054#discussion_r2177664240 PR Review Comment: https://git.openjdk.org/jdk/pull/26054#discussion_r2177671307 PR Review Comment: https://git.openjdk.org/jdk/pull/26054#discussion_r2177676879 PR Review Comment: https://git.openjdk.org/jdk/pull/26054#discussion_r2177687414 PR Review Comment: https://git.openjdk.org/jdk/pull/26054#discussion_r2177691003 PR Review Comment: https://git.openjdk.org/jdk/pull/26054#discussion_r2177692842 PR Review Comment: https://git.openjdk.org/jdk/pull/26054#discussion_r2177694731 PR Review Comment: https://git.openjdk.org/jdk/pull/26054#discussion_r2177697691 From ihse at openjdk.org Tue Jul 1 14:21:43 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 1 Jul 2025 14:21:43 GMT Subject: RFR: 8346719: Add relaunchers to the static JDK image for missing executables [v3] In-Reply-To: References: Message-ID: On Fri, 27 Jun 2025 16:15:57 GMT, Magnus Ihse Bursie wrote: >> In the static JDK image, a single humongous java executable is generated, and no other launcher, such as javac. This makes it impossible to run our jtreg tests, which assume these are present. >> >> The solution is fortunately simply: we just need to add a bunch of trivial launchers, which are thin wrappers that execute the main java binary, with the proper arguments. This will result in the same behavior as the normal dynamic launchers, only that we will need to take the detour of launching another process instead of calling directly into the JLI library. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Remove problemlisting Any reviewers on this? ------------- PR Comment: https://git.openjdk.org/jdk/pull/24380#issuecomment-3024250322 From jpai at openjdk.org Tue Jul 1 14:29:43 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 1 Jul 2025 14:29:43 GMT Subject: [jdk25] RFR: 8359337: XML/JAXP tests that make network connections should ensure that no proxy is selected In-Reply-To: <2AwBxckSavQEtCCKD20ckA_RazX5u7YSEVdgGqm8bdM=.ae0d00dd-3106-40b1-8698-abce750cffa1@github.com> References: <2AwBxckSavQEtCCKD20ckA_RazX5u7YSEVdgGqm8bdM=.ae0d00dd-3106-40b1-8698-abce750cffa1@github.com> Message-ID: On Tue, 1 Jul 2025 14:13:08 GMT, Daniel Fuchs wrote: > This seems OK without /othervm as long as tests are not run concurrently in the same VM. jtreg guarantees that a agentvm is only used for one single action. So the same JVM will never run more than one test concurrently. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26065#issuecomment-3024283597 From jpai at openjdk.org Tue Jul 1 14:32:41 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 1 Jul 2025 14:32:41 GMT Subject: [jdk25] RFR: 8359337: XML/JAXP tests that make network connections should ensure that no proxy is selected In-Reply-To: References: <2AwBxckSavQEtCCKD20ckA_RazX5u7YSEVdgGqm8bdM=.ae0d00dd-3106-40b1-8698-abce750cffa1@github.com> Message-ID: On Tue, 1 Jul 2025 14:26:44 GMT, Jaikiran Pai wrote: > So the same JVM will never run more than one test concurrently. Just for my own peace of mind I looked up the jtreg FAQ to be sure it specifies this behaviour. The FAQ here says https://openjdk.org/jtreg/faq.html#how-do-i-specify-whether-to-run-tests-concurrently > (jtreg never runs multiple tests at the same time in any one JVM.) ------------- PR Comment: https://git.openjdk.org/jdk/pull/26065#issuecomment-3024297073 From alanb at openjdk.org Tue Jul 1 14:35:45 2025 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 1 Jul 2025 14:35:45 GMT Subject: RFR: 8360037: Refactor ImageReader in preparation for Valhalla support In-Reply-To: References: Message-ID: On Mon, 30 Jun 2025 23:27:49 GMT, David Beaumont wrote: > Refactoring `ImageReader` to make it easy to add preview mode functionality for Valhalla. > > This PR is a large change to `ImageReader` (effectively a rewrite) but reduces the surface area of the API significantly, reduces code complexity and increases performance/memory efficiency. The need for this sort of change comes from the need to support "preview mode" in Valhalla for classes loaded from core modules. > > ### Preview Mode > > In the proposed preview mode support for Valhalla, a resource with the name `/modules//` may come from one of two locations in the underlying jimage file; `//` or `//META-INF/preview/`. Furthermore, directories (represented as directory nodes via the API) will have a potentially different number of child nodes depending on whether preview mode is in effect, and some directories may only exist at all in preview mode. > > Furthermore, the directories and symbolic link nodes in `/packages/...` will also be affected by the existence of new package directories. To retain consistency and avoid "surprises" later, all of this needs to be taken into account. > > Below is a summary of the main changes for mainline JDK to better support preview mode later: > > ### 1: Improved encapsulation for preview mode > > The current `ImageReader` code exposes the data from the jimage file in several ways; via the `Node` abstraction, but also with methods which return an `ImageLocation` instance directly. In preview mode it would not be acceptable to return the `ImageLocation`, since that would leak the existence of resources in the `META-INF/preview` namespace and lets users see resource nodes with names that don't match the underlying `ImageLocation` from which their contents come. > > As such, the PR removes all methods which can leak `ImageLocation` or other "underlying" semantics about the jimage file. Luckily most of these are either used minimally and easily migrated to using nodes, or they were not being used at all. This PR also removes any methods which were already unused across the OpenJDK codebase (if I discover any issues with over-trimming of the API during full CI testing, it will be easy to address). > > ### 2. Simplification of directory child node handling > > The current `ImageReader` code attempts to create parent directories "on demand" for any child nodes it creates. This results in parent directories having a non-empty but incomplete set of child nodes present. This is referred to as the directory being "incomple... src/java.base/share/classes/jdk/internal/module/SystemModuleFinders.java line 62: > 60: import jdk.internal.module.ModuleHashes.HashSupplier; > 61: > 62: import static java.util.Objects.requireNonNull; The existing Objects.requireNonNull are okay, no need to change them all as it is nothing to do with the changes. src/java.base/share/classes/jdk/internal/module/SystemModuleFinders.java line 251: > 249: } > 250: > 251: private static Stream getModuleAttributes() { Can you rename this to allModuleAttributes and add a method description to match the other methods. src/java.base/share/classes/jdk/internal/module/SystemModuleFinders.java line 257: > 255: .getChildNames() > 256: .map(mn -> getNode(reader, mn + "/module-info.class")) > 257: // This fails with ISE if the node isn't a resource (corrupt JImage). Can you drop this comment and check getNode to thrown an Error (ISE isn't right when we have a broken image). test/micro/org/openjdk/bench/jdk/internal/jrtfs/ImageReaderBenchmark.java line 60: > 58: @OutputTimeUnit(TimeUnit.MILLISECONDS) > 59: @Fork(value = 1, jvmArgs = {"--add-exports", "java.base/jdk.internal.jimage=ALL-UNNAMED"}) > 60: public class ImageReaderBenchmark { This is the benchmark from the other PR, did you mean to include it? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26054#discussion_r2177761299 PR Review Comment: https://git.openjdk.org/jdk/pull/26054#discussion_r2177768203 PR Review Comment: https://git.openjdk.org/jdk/pull/26054#discussion_r2177772042 PR Review Comment: https://git.openjdk.org/jdk/pull/26054#discussion_r2177762265 From duke at openjdk.org Tue Jul 1 14:36:39 2025 From: duke at openjdk.org (Brett Okken) Date: Tue, 1 Jul 2025 14:36:39 GMT Subject: RFR: 8361018: Re-examine buffering and encoding conversion in BufferedWriter [v6] In-Reply-To: References: Message-ID: On Tue, 1 Jul 2025 00:01:21 GMT, Shaojin Wen wrote: >> BufferedWriter -> OutputStreamWriter -> StreamEncoder >> >> In this call chain, BufferedWriter has a char[] buffer, and StreamEncoder has a ByteBuffer. There are two layers of cache here, or the BufferedWriter layer can be removed. And when charset is UTF8, if the content of write(String) is LATIN1, a conversion from LATIN1 to UTF16 and then to LATIN1 will occur here. >> >> LATIN1 -> UTF16 -> UTF8 >> >> We can improve BufferedWriter. When the parameter Writer instanceof OutputStreamWriter is passed in, remove the cache and call it directly. In addition, improve write(String) in StreamEncoder to avoid unnecessary encoding conversion. > > Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: > > Revert "BufferedWriter buffer use StringBuilder" > > This reverts commit da902ca0b0bd6acc003deb8ad1ca0d6485a29a27. My initial impression was that the point of this PR was that the BufferedWriter was forcing the conversion to utf-16 and bypassing that would avoid a conversion. However, it seems that it is actually the StreamEncoder/CharsetEncoder that is really forcing that - and the conversion to utf-16 is required for optimal encoder performance. The result (of this PR), then, seems to be that for OutputStreamWriter as a target (and maybe for specific character encodings) BufferedWriter no long buffers, but delegates that responsibility to the OutputStreamWriter (and its StreamEncoder). Are there any scenarios where wrapping an OutputStreamWriter with a BufferedWriter makes sense? Is it only to control the buffer size? If so, should OutputStreamWriter itself just allow consumers to control the buffer size? (And then just change the doc of OutputStreamWriter to discourage the use of BufferedWriter - and change PrintWriter to not [create this combo](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/io/PrintWriter.java#L167).) Should the various encoders be optimized to work with a StringCharBuffer? Perhaps only if backed by a String or AbstractStringBuilder? It seems that there could be more target character encodings beyond utf-8 and utf-16 (i.e ascii, iso-8859-1, cp1252, etc.) which could benefit from the source already known whether it is latin 1. It feels strange to place the optimizations for specific character encodings directly in StreamEncoder. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26022#issuecomment-3024309269 From duke at openjdk.org Tue Jul 1 14:39:47 2025 From: duke at openjdk.org (simon) Date: Tue, 1 Jul 2025 14:39:47 GMT Subject: RFR: 8360122: Fix java.sql\Connection.java indentation [v2] In-Reply-To: References: Message-ID: On Mon, 23 Jun 2025 17:45:02 GMT, Lance Andersen wrote: >> simon has updated the pull request incrementally with one additional commit since the last revision: >> >> 8360122: refactor code formatting to enforce 100 chars line length limit for improved readability > > I might not have time this week to look at this as I have some other commitments. I do think we will want to narrow the changes being proposed @LanceAndersen Hope you're doing well! Could you review the change so that I can apply the necessary improvements and proceed with the integration? ------------- PR Comment: https://git.openjdk.org/jdk/pull/25925#issuecomment-3024321438 From duke at openjdk.org Tue Jul 1 14:40:44 2025 From: duke at openjdk.org (ExE Boss) Date: Tue, 1 Jul 2025 14:40:44 GMT Subject: RFR: 8360037: Refactor ImageReader in preparation for Valhalla support In-Reply-To: References: Message-ID: On Mon, 30 Jun 2025 23:27:49 GMT, David Beaumont wrote: > Refactoring `ImageReader` to make it easy to add preview mode functionality for Valhalla. > > This PR is a large change to `ImageReader` (effectively a rewrite) but reduces the surface area of the API significantly, reduces code complexity and increases performance/memory efficiency. The need for this sort of change comes from the need to support "preview mode" in Valhalla for classes loaded from core modules. > > ### Preview Mode > > In the proposed preview mode support for Valhalla, a resource with the name `/modules//` may come from one of two locations in the underlying jimage file; `//` or `//META-INF/preview/`. Furthermore, directories (represented as directory nodes via the API) will have a potentially different number of child nodes depending on whether preview mode is in effect, and some directories may only exist at all in preview mode. > > Furthermore, the directories and symbolic link nodes in `/packages/...` will also be affected by the existence of new package directories. To retain consistency and avoid "surprises" later, all of this needs to be taken into account. > > Below is a summary of the main changes for mainline JDK to better support preview mode later: > > ### 1: Improved encapsulation for preview mode > > The current `ImageReader` code exposes the data from the jimage file in several ways; via the `Node` abstraction, but also with methods which return an `ImageLocation` instance directly. In preview mode it would not be acceptable to return the `ImageLocation`, since that would leak the existence of resources in the `META-INF/preview` namespace and lets users see resource nodes with names that don't match the underlying `ImageLocation` from which their contents come. > > As such, the PR removes all methods which can leak `ImageLocation` or other "underlying" semantics about the jimage file. Luckily most of these are either used minimally and easily migrated to using nodes, or they were not being used at all. This PR also removes any methods which were already unused across the OpenJDK codebase (if I discover any issues with over-trimming of the API during full CI testing, it will be easy to address). > > ### 2. Simplification of directory child node handling > > The current `ImageReader` code attempts to create parent directories "on demand" for any child nodes it creates. This results in parent directories having a non-empty but incomplete set of child nodes present. This is referred to as the directory being "incomple... src/java.base/share/classes/jdk/internal/jimage/ImageReader.java line 207: > 205: this.nodes = new HashMap<>(); > 206: // TODO (review note): These should exist under all circumstances, but there's > 207: // probably a more robust way of getting it these offsets. Suggestion: // probably a more robust way of getting these offsets. src/java.base/share/classes/jdk/internal/jimage/ImageReader.java line 211: > 209: this.packagesStringOffset = findLocation("/packages/java.lang").getModuleOffset(); > 210: > 211: // Node creation is very lazy, se can just make the top-level directories Typo: Suggestion: // Node creation is very lazy, so can just make the top-level directories src/java.base/share/classes/jdk/internal/jimage/ImageReader.java line 544: > 542: > 543: // A node is completed when all its direct children have been built. As > 544: // such, non-directory nodes are always complete. I?think this?might flow?better: Suggestion: // A node is completed when all its direct children have been built. // As such, non-directory nodes are always complete. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26054#discussion_r2177769091 PR Review Comment: https://git.openjdk.org/jdk/pull/26054#discussion_r2177768332 PR Review Comment: https://git.openjdk.org/jdk/pull/26054#discussion_r2177779216 From alanb at openjdk.org Tue Jul 1 14:40:45 2025 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 1 Jul 2025 14:40:45 GMT Subject: RFR: 8360037: Refactor ImageReader in preparation for Valhalla support In-Reply-To: References: Message-ID: On Mon, 30 Jun 2025 23:27:49 GMT, David Beaumont wrote: > Refactoring `ImageReader` to make it easy to add preview mode functionality for Valhalla. > > This PR is a large change to `ImageReader` (effectively a rewrite) but reduces the surface area of the API significantly, reduces code complexity and increases performance/memory efficiency. The need for this sort of change comes from the need to support "preview mode" in Valhalla for classes loaded from core modules. > > ### Preview Mode > > In the proposed preview mode support for Valhalla, a resource with the name `/modules//` may come from one of two locations in the underlying jimage file; `//` or `//META-INF/preview/`. Furthermore, directories (represented as directory nodes via the API) will have a potentially different number of child nodes depending on whether preview mode is in effect, and some directories may only exist at all in preview mode. > > Furthermore, the directories and symbolic link nodes in `/packages/...` will also be affected by the existence of new package directories. To retain consistency and avoid "surprises" later, all of this needs to be taken into account. > > Below is a summary of the main changes for mainline JDK to better support preview mode later: > > ### 1: Improved encapsulation for preview mode > > The current `ImageReader` code exposes the data from the jimage file in several ways; via the `Node` abstraction, but also with methods which return an `ImageLocation` instance directly. In preview mode it would not be acceptable to return the `ImageLocation`, since that would leak the existence of resources in the `META-INF/preview` namespace and lets users see resource nodes with names that don't match the underlying `ImageLocation` from which their contents come. > > As such, the PR removes all methods which can leak `ImageLocation` or other "underlying" semantics about the jimage file. Luckily most of these are either used minimally and easily migrated to using nodes, or they were not being used at all. This PR also removes any methods which were already unused across the OpenJDK codebase (if I discover any issues with over-trimming of the API during full CI testing, it will be easy to address). > > ### 2. Simplification of directory child node handling > > The current `ImageReader` code attempts to create parent directories "on demand" for any child nodes it creates. This results in parent directories having a non-empty but incomplete set of child nodes present. This is referred to as the directory being "incomple... src/java.base/share/classes/jdk/internal/module/SystemModuleFinders.java line 456: > 454: Optional node = Optional.ofNullable(reader.findNode(nodeName)); > 455: if (node.isPresent() && !node.get().isResource()) { > 456: throw new IllegalStateException("Not a resource node: " + node.get()); The IllegalStateException is problematic here, maybe you mean to add an assert? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26054#discussion_r2177784419 From jpai at openjdk.org Tue Jul 1 14:41:42 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 1 Jul 2025 14:41:42 GMT Subject: RFR: 8334015: Add Support for UUID Version 7 (UUIDv7) defined in RFC 9562 [v10] In-Reply-To: <4b4eB1IhNlZXMVqf-aOj-IIp3kwLiqOVfeqioc2dL9Q=.8af3f74b-7b61-424a-b2c6-421fa6e0c0e6@github.com> References: <4b4eB1IhNlZXMVqf-aOj-IIp3kwLiqOVfeqioc2dL9Q=.8af3f74b-7b61-424a-b2c6-421fa6e0c0e6@github.com> Message-ID: On Mon, 30 Jun 2025 18:19:30 GMT, Kieran Farrell wrote: >> With the recent approval of UUIDv7 (https://datatracker.ietf.org/doc/rfc9562/), this PR aims to add a new static method UUID.timestampUUID() which constructs and returns a UUID in support of the new time generated UUID version. >> >> The specification requires embedding the current timestamp in milliseconds into the first bits 0?47. The version number in bits 48?51, bits 52?63 are available for sub-millisecond precision or for pseudorandom data. The variant is set in bits 64?65. The remaining bits 66?127 are free to use for more pseudorandom data or to employ a counter based approach for increased time percision (https://www.rfc-editor.org/rfc/rfc9562.html#name-uuid-version-7). >> >> The choice of implementation comes down to balancing the sensitivity level of being able to distingush UUIDs created below <1ms apart with performance. A test simulating a high-concurrency environment with 4 threads generating 10000 UUIDv7 values in parallel to measure the collision rate of each implementation (the amount of times the time based portion of the UUID was not unique and entries could not distinguished by time) yeilded the following results for each implemtation: >> >> >> - random-byte-only - 99.8% >> - higher-precision - 3.5% >> - counter-based - 0% >> >> >> Performance tests show a decrease in performance as expected with the counter based implementation due to the introduction of synchronization: >> >> - random-byte-only 143.487 ? 10.932 ns/op >> - higher-precision 149.651 ? 8.438 ns/op >> - counter-based 245.036 ? 2.943 ns/op >> >> The best balance here might be to employ a higher-precision implementation as the large increase in time sensitivity comes at a very slight performance cost. > > Kieran Farrell 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: > > update spec src/java.base/share/classes/java/util/UUID.java line 107: > 105: > 106: private static long monotonicMS() { > 107: return ORIGIN_MS + (System.nanoTime() - ORIGIN_NS) / 1_000_000; Hello Kieran, the `System.nanoTime()` specifies: > This method provides nanosecond precision, but not necessarily nanosecond resolution (that is, how frequently the value changes) - no guarantees are made except that the resolution is at least as good as that of {@link #currentTimeMillis()}. Then `System.currentTimeMillis()` specifies: > Note that while the unit of time of the return value is a millisecond, the granularity of the value depends on the underlying operating system and may be larger. For example, many operating systems measure time in units of tens of milliseconds. Would that then mean that there's no guarantee here on this line that multiple sequential calls to `System.nanoTime()` will not return the same value and thus the breaking the monotic guarantee of this method? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25303#discussion_r2177788923 From rriggs at openjdk.org Tue Jul 1 14:51:42 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 1 Jul 2025 14:51:42 GMT Subject: RFR: 8334015: Add Support for UUID Version 7 (UUIDv7) defined in RFC 9562 [v10] In-Reply-To: References: <4b4eB1IhNlZXMVqf-aOj-IIp3kwLiqOVfeqioc2dL9Q=.8af3f74b-7b61-424a-b2c6-421fa6e0c0e6@github.com> Message-ID: On Tue, 1 Jul 2025 14:39:11 GMT, Jaikiran Pai wrote: >> Kieran Farrell 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: >> >> update spec > > src/java.base/share/classes/java/util/UUID.java line 107: > >> 105: >> 106: private static long monotonicMS() { >> 107: return ORIGIN_MS + (System.nanoTime() - ORIGIN_NS) / 1_000_000; > > Hello Kieran, the `System.nanoTime()` specifies: > >> This method provides nanosecond precision, but not necessarily > nanosecond resolution (that is, how frequently the value changes) - no > guarantees are made except that the resolution is at least as > good as that of {@link #currentTimeMillis()}. > > Then `System.currentTimeMillis()` specifies: > >> Note that while the unit of time of the return value is a millisecond, > the granularity of the value depends on the underlying > operating system and may be larger. For example, many > operating systems measure time in units of tens of > milliseconds. > > Would that then mean that there's no guarantee here on this line that multiple sequential calls to `System.nanoTime()` will not return the same value and thus the breaking the monotonic guarantee of this method? The uniqueness comes not just from the timestamp but also from the random data in the other bytes that are generated for each new UUID. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25303#discussion_r2177815716 From brett.okken.os at gmail.com Tue Jul 1 14:57:43 2025 From: brett.okken.os at gmail.com (Brett Okken) Date: Tue, 1 Jul 2025 09:57:43 -0500 Subject: StringCharBuffer and bulk get Message-ID: jdk 25 introduced[1] a bulk getChars method to CharSequence[2]. Should StringCharBuffer be updated to utilize that new method to implement the bulk get method[3]? That would presumably require changes to the private getArray[4]. I think there could also be changes to putBuffer[5] for when the target has an array. That array could be used for the getChars call. [1] - https://github.com/openjdk/jdk/commit/7642556a5a131e9104033ad7d7abfdb4be5012cf [2] - https://download.java.net/java/early_access/jdk25/docs/api/java.base/java/lang/CharSequence.html#getChars(int,int,char%5B%5D,int) [3] - https://download.java.net/java/early_access/jdk25/docs/api/java.base/java/nio/CharBuffer.html#get(int,char%5B%5D,int,int) [4] - https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/nio/X-Buffer.java.template#L953-L985 [5] - https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/nio/X-Buffer.java.template#L1152-L1156 From bpb at openjdk.org Tue Jul 1 15:13:41 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 1 Jul 2025 15:13:41 GMT Subject: RFR: 8358533: Improve performance of java.io.Reader.readAllLines [v9] In-Reply-To: References: Message-ID: <3StfS2-72iIkuHlf9HpzfC-BNoD4kDEjHY2esUnPKEM=.f7ae323f-5313-445b-bd7d-89f6743974f3@github.com> On Tue, 1 Jul 2025 01:37:27 GMT, Roger Riggs wrote: > I think resizing the buffer when the line length exceeds cb.length/2 will be more efficient (cpu wise). I concur. I missed that this had been changed in the most recent commit. > test/jdk/java/io/Reader/ReadAll.java line 117: > >> 115: sb.setLength(0); >> 116: } >> 117: > > Does one of these cases result in a *very very long line without a terminator"; something that would trigger the limits of ArraySupport.newLength at or near Integer.MAX_VALUE - 8? I don't know, but I doubt it. I will look into adding something. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25863#discussion_r2177863145 PR Review Comment: https://git.openjdk.org/jdk/pull/25863#discussion_r2177863858 From jpai at openjdk.org Tue Jul 1 15:23:41 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 1 Jul 2025 15:23:41 GMT Subject: RFR: 8334015: Add Support for UUID Version 7 (UUIDv7) defined in RFC 9562 [v10] In-Reply-To: References: <4b4eB1IhNlZXMVqf-aOj-IIp3kwLiqOVfeqioc2dL9Q=.8af3f74b-7b61-424a-b2c6-421fa6e0c0e6@github.com> Message-ID: On Tue, 1 Jul 2025 14:48:50 GMT, Roger Riggs wrote: >> src/java.base/share/classes/java/util/UUID.java line 107: >> >>> 105: >>> 106: private static long monotonicMS() { >>> 107: return ORIGIN_MS + (System.nanoTime() - ORIGIN_NS) / 1_000_000; >> >> Hello Kieran, the `System.nanoTime()` specifies: >> >>> This method provides nanosecond precision, but not necessarily >> nanosecond resolution (that is, how frequently the value changes) - no >> guarantees are made except that the resolution is at least as >> good as that of {@link #currentTimeMillis()}. >> >> Then `System.currentTimeMillis()` specifies: >> >>> Note that while the unit of time of the return value is a millisecond, >> the granularity of the value depends on the underlying >> operating system and may be larger. For example, many >> operating systems measure time in units of tens of >> milliseconds. >> >> Would that then mean that there's no guarantee here on this line that multiple sequential calls to `System.nanoTime()` will not return the same value and thus the breaking the monotonic guarantee of this method? > > The uniqueness comes not just from the timestamp but also from the random data in the other bytes that are generated for each new UUID. Hello Roger, that's true about the uniqueness semantics. However, from what I understand of RFC-9562, on which this new API is based, it has much stricter expectations about monotonocity (the first 48 bits) too. For example, the following sections: https://www.rfc-editor.org/rfc/rfc9562.html#name-timestamp-considerations https://www.rfc-editor.org/rfc/rfc9562.html#name-monotonicity-and-counters ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25303#discussion_r2177888554 From dfuchs at openjdk.org Tue Jul 1 15:23:41 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Tue, 1 Jul 2025 15:23:41 GMT Subject: RFR: 8334015: Add Support for UUID Version 7 (UUIDv7) defined in RFC 9562 [v10] In-Reply-To: References: <4b4eB1IhNlZXMVqf-aOj-IIp3kwLiqOVfeqioc2dL9Q=.8af3f74b-7b61-424a-b2c6-421fa6e0c0e6@github.com> Message-ID: On Tue, 1 Jul 2025 15:20:07 GMT, Jaikiran Pai wrote: >> The uniqueness comes not just from the timestamp but also from the random data in the other bytes that are generated for each new UUID. > > Hello Roger, that's true about the uniqueness semantics. However, from what I understand of RFC-9562, on which this new API is based, it has much stricter expectations about monotonocity (the first 48 bits) too. For example, the following sections: > > https://www.rfc-editor.org/rfc/rfc9562.html#name-timestamp-considerations > https://www.rfc-editor.org/rfc/rfc9562.html#name-monotonicity-and-counters This method ensures monotonicity, at the cost of potentially returning a time stamp in the future if the system clock has been moved back by NTP. Not sure if that's an issue or not - but it's certainly a tradeoff. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25303#discussion_r2177889997 From alanb at openjdk.org Tue Jul 1 15:44:40 2025 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 1 Jul 2025 15:44:40 GMT Subject: RFR: 8360884: Better scoped values [v4] In-Reply-To: References: <8yqi3J3JfLa2NNags9waBIshIMIuOJRjm-rHF--Wjws=.d04990af-5fdb-4218-a8da-60bda679b1d1@github.com> Message-ID: On Tue, 1 Jul 2025 11:15:54 GMT, Andrew Haley wrote: >> Scoped values cannot be used early in the JDK boot process because of some dependencies on System.getProperty(). This dependency should be removed in a way that allows scoped values to be created (but not necessarily bound) at any stage during boot. >> >> Also, Scoped Value's constructor has a synchronized block, which limits the use of scoped values at runtime. Constructing a scoped value should be a thread-local operation. > > Andrew Haley has updated the pull request incrementally with two additional commits since the last revision: > > - 8360884: Better scoped values > - 8360884: Better scoped values src/java.base/share/classes/java/lang/ScopedValue.java line 534: > 532: > 533: private ScopedValue() { > 534: this.hash = hashGenerator != null ? hashGenerator.getAsInt() : generateKey(); The updated version looks much better. It might just a bit clearer to read hashGenerator once here (it doesn't matter of course but stable fields tend to attract a lot of questions). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26019#discussion_r2177930532 From iris at openjdk.org Tue Jul 1 16:09:44 2025 From: iris at openjdk.org (Iris Clark) Date: Tue, 1 Jul 2025 16:09:44 GMT Subject: [jdk25] RFR: 8359337: XML/JAXP tests that make network connections should ensure that no proxy is selected In-Reply-To: References: Message-ID: <4sQm6D6icSMukjKohgjcevtNiAbEB1k0NmgtKFmDrdo=.8cb7b3d8-742b-4f1d-ad4b-dfa610e5b1f7@github.com> On Tue, 1 Jul 2025 11:48:30 GMT, Jaikiran Pai wrote: > Can I please get a review of this backport of a test-only fix? > > This backports the fix for https://bugs.openjdk.org/browse/JDK-8359337 into JDK 25. The original fix was integrated into mainline a few minutes back https://github.com/openjdk/jdk/pull/26052. Backporting this fix should help prevent failure of these tests on macOS hosts which have proxies configured. Confirmed changes are the same of those already pushed to the `master` branch. ------------- Marked as reviewed by iris (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26065#pullrequestreview-2976102094 From openjdk at icemanx.nl Tue Jul 1 16:15:21 2025 From: openjdk at icemanx.nl (Rob Spoor) Date: Tue, 1 Jul 2025 18:15:21 +0200 Subject: Could ByteOrder be turned into an enum? Message-ID: <2493cf38-5324-408e-9912-202277c64b59@icemanx.nl> Hi all, I've been using ByteOrder quite a bit, but something that's always annoyed me is that it's not an enum (because it predates them), and therefore cannot be easily used in switch expressions or statements. For instance, the closest I get is this, which still requires a default statement: var i = switch (ByteOrder.nativeOrder()) { case ByteOrder b when b.equals(ByteOrder.LITTLE_ENDIAN) -> 1; case ByteOrder b when b.equals(ByteOrder.BIG_ENDIAN) -> 2; default -> throw new IllegalStateException("not supported"); }; I know that it's also possible to use a ternary expression, but that depends on there never being a third value: var i = ByteOrder.nativeOrder().equals(ByteOrder.LITTLE_ENDIAN) ? 1 : 2 As a little proof-of-concept I created the enum below and checked the signatures with javap. Apart from a different super class (Object -> Enum) and the extra values() and valueOf(String) methods, the two have the same fields, constructors and methods with the same signatures. And it would allow us to use this shorter switch expression: var i = switch (ByteOrder.nativeOrder()) { case LITTLE_ENDIAN -> 1; case BIG_ENDIAN -> 2; }; So my question is: are there technical limitations that would prevent this change? The enum I created: public enum ByteOrder { BIG_ENDIAN("BIG_ENDIAN"), LITTLE_ENDIAN("LITTLE_ENDIAN"), ; private final String name; ByteOrder(String name) { this.name = name; } private static final ByteOrder NATIVE_ORDER = Unsafe.getUnsafe().isBigEndian() ? ByteOrder.BIG_ENDIAN : ByteOrder.LITTLE_ENDIAN; public static ByteOrder nativeOrder() { return NATIVE_ORDER; } public String toString() { return name; } } From chen.l.liang at oracle.com Tue Jul 1 16:29:23 2025 From: chen.l.liang at oracle.com (Chen Liang) Date: Tue, 1 Jul 2025 16:29:23 +0000 Subject: StringCharBuffer and bulk get In-Reply-To: References: Message-ID: Hi Brett, I think your suggestion makes sense. I have created https://bugs.openjdk.org/browse/JDK-8361209 to track this RFE. Feel free to contribute a patch to implement this enhancement. ________________________________ From: core-libs-dev on behalf of Brett Okken Sent: Tuesday, July 1, 2025 9:57 AM To: core-libs-dev Subject: StringCharBuffer and bulk get jdk 25 introduced[1] a bulk getChars method to CharSequence[2]. Should StringCharBuffer be updated to utilize that new method to implement the bulk get method[3]? That would presumably require changes to the private getArray[4]. I think there could also be changes to putBuffer[5] for when the target has an array. That array could be used for the getChars call. [1] - https://github.com/openjdk/jdk/commit/7642556a5a131e9104033ad7d7abfdb4be5012cf [2] - https://download.java.net/java/early_access/jdk25/docs/api/java.base/java/lang/CharSequence.html#getChars(int,int,char%5B%5D,int) [3] - https://download.java.net/java/early_access/jdk25/docs/api/java.base/java/nio/CharBuffer.html#get(int,char%5B%5D,int,int) [4] - https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/nio/X-Buffer.java.template#L953-L985 [5] - https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/nio/X-Buffer.java.template#L1152-L1156 -------------- next part -------------- An HTML attachment was scrubbed... URL: From bpb at openjdk.org Tue Jul 1 16:37:45 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 1 Jul 2025 16:37:45 GMT Subject: RFR: 8358533: Improve performance of java.io.Reader.readAllLines [v9] In-Reply-To: <3StfS2-72iIkuHlf9HpzfC-BNoD4kDEjHY2esUnPKEM=.f7ae323f-5313-445b-bd7d-89f6743974f3@github.com> References: <3StfS2-72iIkuHlf9HpzfC-BNoD4kDEjHY2esUnPKEM=.f7ae323f-5313-445b-bd7d-89f6743974f3@github.com> Message-ID: On Tue, 1 Jul 2025 15:10:33 GMT, Brian Burkhalter wrote: >> test/jdk/java/io/Reader/ReadAll.java line 117: >> >>> 115: sb.setLength(0); >>> 116: } >>> 117: >> >> Does one of these cases result in a *very very long line without a terminator"; something that would trigger the limits of ArraySupport.newLength at or near Integer.MAX_VALUE - 8? > > I don't know, but I doubt it. I will look into adding something. With this change --- a/test/jdk/java/io/Reader/ReadAll.java +++ b/test/jdk/java/io/Reader/ReadAll.java @@ -115,6 +115,8 @@ public static void setup() throws IOException { sb.setLength(0); } + strings.add(" ".repeat(Integer.MAX_VALUE/2)); + the limit is reached but it doubles the test run time, at least on an M4 Max. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25863#discussion_r2178054383 From joehw at openjdk.org Tue Jul 1 16:44:39 2025 From: joehw at openjdk.org (Joe Wang) Date: Tue, 1 Jul 2025 16:44:39 GMT Subject: [jdk25] RFR: 8359337: XML/JAXP tests that make network connections should ensure that no proxy is selected In-Reply-To: References: Message-ID: On Tue, 1 Jul 2025 11:48:30 GMT, Jaikiran Pai wrote: > Can I please get a review of this backport of a test-only fix? > > This backports the fix for https://bugs.openjdk.org/browse/JDK-8359337 into JDK 25. The original fix was integrated into mainline a few minutes back https://github.com/openjdk/jdk/pull/26052. Backporting this fix should help prevent failure of these tests on macOS hosts which have proxies configured. Thanks Jaikiran. ------------- Marked as reviewed by joehw (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26065#pullrequestreview-2976191016 From duke at openjdk.org Tue Jul 1 16:52:40 2025 From: duke at openjdk.org (David Beaumont) Date: Tue, 1 Jul 2025 16:52:40 GMT Subject: RFR: 8361076: Add benchmark for ImageReader in preparation for Valhalla changes [v3] In-Reply-To: References: Message-ID: On Tue, 1 Jul 2025 07:25:35 GMT, Alan Bateman wrote: >> David Beaumont has updated the pull request incrementally with one additional commit since the last revision: >> >> Some tidying up relating to the state objects. > > test/micro/org/openjdk/bench/jdk/internal/jrtfs/ImageReaderBenchmark.java line 230: > >> 228: // Created by running "java -verbose:class", throwing away anonymous inner >> 229: // classes and anything without a reliable name, and grouping by the stated >> 230: // source. It's not perfect, but it's representative. > > I don't think this is maintainable. How useful (or not) is this benchmark if the names of all the internal classes (that will change from release to release) are dropped from this? Debatable. It's obviously going to scale any results somewhat based on the size of the resources and number of classes. It's kind nice to see "this change removes at least N micro/milli seconds of time spent" since that's a minimum set of classes we expect to always be needed, so any time saved is a lower bound. I'd say maybe leave it as is for now with a note saying "if this keeps breaking, make the list less fragile". I'm also assuming this is only run manually, and not a part of any CI pipeline ... so please let me know if I'm wrong about that. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26044#discussion_r2178080151 From duke at openjdk.org Tue Jul 1 17:02:27 2025 From: duke at openjdk.org (David Beaumont) Date: Tue, 1 Jul 2025 17:02:27 GMT Subject: RFR: 8361076: Add benchmark for ImageReader in preparation for Valhalla changes [v4] In-Reply-To: References: Message-ID: > Initial benchmark to capture at least some comparative measures of ImageReader performance. > > Current results on my laptop: > > Benchmark Mode Cnt Score Error Units > NewImageBenchmark.warmCache_CountAllNodes avgt 5 0.785 ? 0.140 ms/op > NewImageBenchmark.coldStart_CountOnly ss 5 34.051 ? 17.662 ms/op > NewImageBenchmark.coldStart_InitAndCount ss 5 31.006 ? 9.674 ms/op > NewImageBenchmark.coldStart_LoadJavacInitClasses ss 5 3.752 ? 6.873 ms/op > > The upcoming changes to ImageReader should show significant improvements to these results. David Beaumont has updated the pull request incrementally with one additional commit since the last revision: Adding comment about maintainability. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26044/files - new: https://git.openjdk.org/jdk/pull/26044/files/089b68e2..965abec0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26044&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26044&range=02-03 Stats: 7 lines in 1 file changed: 7 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/26044.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26044/head:pull/26044 PR: https://git.openjdk.org/jdk/pull/26044 From jpai at openjdk.org Tue Jul 1 17:13:46 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 1 Jul 2025 17:13:46 GMT Subject: RFR: 8334015: Add Support for UUID Version 7 (UUIDv7) defined in RFC 9562 [v10] In-Reply-To: <4b4eB1IhNlZXMVqf-aOj-IIp3kwLiqOVfeqioc2dL9Q=.8af3f74b-7b61-424a-b2c6-421fa6e0c0e6@github.com> References: <4b4eB1IhNlZXMVqf-aOj-IIp3kwLiqOVfeqioc2dL9Q=.8af3f74b-7b61-424a-b2c6-421fa6e0c0e6@github.com> Message-ID: On Mon, 30 Jun 2025 18:19:30 GMT, Kieran Farrell wrote: >> With the recent approval of UUIDv7 (https://datatracker.ietf.org/doc/rfc9562/), this PR aims to add a new static method UUID.timestampUUID() which constructs and returns a UUID in support of the new time generated UUID version. >> >> The specification requires embedding the current timestamp in milliseconds into the first bits 0?47. The version number in bits 48?51, bits 52?63 are available for sub-millisecond precision or for pseudorandom data. The variant is set in bits 64?65. The remaining bits 66?127 are free to use for more pseudorandom data or to employ a counter based approach for increased time percision (https://www.rfc-editor.org/rfc/rfc9562.html#name-uuid-version-7). >> >> The choice of implementation comes down to balancing the sensitivity level of being able to distingush UUIDs created below <1ms apart with performance. A test simulating a high-concurrency environment with 4 threads generating 10000 UUIDv7 values in parallel to measure the collision rate of each implementation (the amount of times the time based portion of the UUID was not unique and entries could not distinguished by time) yeilded the following results for each implemtation: >> >> >> - random-byte-only - 99.8% >> - higher-precision - 3.5% >> - counter-based - 0% >> >> >> Performance tests show a decrease in performance as expected with the counter based implementation due to the introduction of synchronization: >> >> - random-byte-only 143.487 ? 10.932 ns/op >> - higher-precision 149.651 ? 8.438 ns/op >> - counter-based 245.036 ? 2.943 ns/op >> >> The best balance here might be to employ a higher-precision implementation as the large increase in time sensitivity comes at a very slight performance cost. > > Kieran Farrell 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: > > update spec src/java.base/share/classes/java/util/UUID.java line 407: > 405: *
  • 3 Name-based UUID > 406: *
  • 4 Randomly generated UUID > 407: *
  • 7 Unix timestamp-based UUID Would it better to reword this to "Unix Epoch time-based UUID" to match what we call it in the rest of the changes and the RFC's Table-2 https://www.rfc-editor.org/rfc/rfc9562.html#table2? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25303#discussion_r2178136046 From jpai at openjdk.org Tue Jul 1 17:16:42 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 1 Jul 2025 17:16:42 GMT Subject: RFR: 8334015: Add Support for UUID Version 7 (UUIDv7) defined in RFC 9562 [v10] In-Reply-To: <4b4eB1IhNlZXMVqf-aOj-IIp3kwLiqOVfeqioc2dL9Q=.8af3f74b-7b61-424a-b2c6-421fa6e0c0e6@github.com> References: <4b4eB1IhNlZXMVqf-aOj-IIp3kwLiqOVfeqioc2dL9Q=.8af3f74b-7b61-424a-b2c6-421fa6e0c0e6@github.com> Message-ID: <9mGzVTRxB12O9EMkOCehJPzLTQuOFJ8-lcYQY08Fir8=.d50b112b-bfa7-4ca7-a4f9-2b78216d9c39@github.com> On Mon, 30 Jun 2025 18:19:30 GMT, Kieran Farrell wrote: >> With the recent approval of UUIDv7 (https://datatracker.ietf.org/doc/rfc9562/), this PR aims to add a new static method UUID.timestampUUID() which constructs and returns a UUID in support of the new time generated UUID version. >> >> The specification requires embedding the current timestamp in milliseconds into the first bits 0?47. The version number in bits 48?51, bits 52?63 are available for sub-millisecond precision or for pseudorandom data. The variant is set in bits 64?65. The remaining bits 66?127 are free to use for more pseudorandom data or to employ a counter based approach for increased time percision (https://www.rfc-editor.org/rfc/rfc9562.html#name-uuid-version-7). >> >> The choice of implementation comes down to balancing the sensitivity level of being able to distingush UUIDs created below <1ms apart with performance. A test simulating a high-concurrency environment with 4 threads generating 10000 UUIDv7 values in parallel to measure the collision rate of each implementation (the amount of times the time based portion of the UUID was not unique and entries could not distinguished by time) yeilded the following results for each implemtation: >> >> >> - random-byte-only - 99.8% >> - higher-precision - 3.5% >> - counter-based - 0% >> >> >> Performance tests show a decrease in performance as expected with the counter based implementation due to the introduction of synchronization: >> >> - random-byte-only 143.487 ? 10.932 ns/op >> - higher-precision 149.651 ? 8.438 ns/op >> - counter-based 245.036 ? 2.943 ns/op >> >> The best balance here might be to employ a higher-precision implementation as the large increase in time sensitivity comes at a very slight performance cost. > > Kieran Farrell 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: > > update spec src/java.base/share/classes/java/util/UUID.java line 237: > 235: * RFC 9562 Universally Unique IDentifiers (UUIDs) > 236: */ > 237: public static UUID unixEpochTimeMillis(long timestamp) { This new method is missing a `@since` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25303#discussion_r2178144835 From psandoz at openjdk.org Tue Jul 1 18:06:45 2025 From: psandoz at openjdk.org (Paul Sandoz) Date: Tue, 1 Jul 2025 18:06:45 GMT Subject: RFR: 8355563: VectorAPI: Refactor current implementation of subword gather load API [v2] In-Reply-To: References: Message-ID: On Wed, 25 Jun 2025 09:16:48 GMT, Xiaohong Gong wrote: >> JDK-8318650 introduced hotspot intrinsification of subword gather load APIs for X86 platforms [1]. However, the current implementation is not optimal for AArch64 SVE platform, which natively supports vector instructions for subword gather load operations using an int vector for indices (see [2][3]). >> >> Two key areas require improvement: >> 1. At the Java level, vector indices generated for range validation could be reused for the subsequent gather load operation on architectures with native vector instructions like AArch64 SVE. However, the current implementation prevents compiler reuse of these index vectors due to divergent control flow, potentially impacting performance. >> 2. At the compiler IR level, the additional `offset` input for `LoadVectorGather`/`LoadVectorGatherMasked` with subword types increases IR complexity and complicates backend implementation. Furthermore, generating `add` instructions before each memory access negatively impacts performance. >> >> This patch refactors the implementation at both the Java level and compiler mid-end to improve efficiency and maintainability across different architectures. >> >> Main changes: >> 1. Java-side API refactoring: >> - Explicitly passes generated index vectors to hotspot, eliminating duplicate index vectors for gather load instructions on >> architectures like AArch64. >> 2. C2 compiler IR refactoring: >> - Refactors `LoadVectorGather`/`LoadVectorGatherMasked` IR for subword types by removing the memory offset input and incorporating it into the memory base `addr` at the IR level. This simplifies backend implementation, reduces add operations, and unifies the IR across all types. >> 3. Backend changes: >> - Streamlines X86 implementation of subword gather operations following the removal of the offset input from the IR level. >> >> Performance: >> The performance of the relative JMH improves up to 27% on a X86 AVX512 system. Please see the data below: >> >> Benchmark Mode Cnt Unit SIZE Before After Gain >> GatherOperationsBenchmark.microByteGather128 thrpt 30 ops/ms 64 53682.012 52650.325 0.98 >> GatherOperationsBenchmark.microByteGather128 thrpt 30 ops/ms 256 14484.252 14255.156 0.98 >> GatherOperationsBenchmark.microByteGather128 thrpt 30 ops/ms 1024 3664.900 3595.615 0.98 >> GatherOperationsBenchmark.microByteGather128 thrpt 30 ops/ms 4096 908.31... > > Xiaohong Gong has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: > > - Address review comments > - Merge 'jdk:master' into JDK-8355563 > - 8355563: VectorAPI: Refactor current implementation of subword gather load API Marked as reviewed by psandoz (Reviewer). This is a nice simplification, Java changes look good. I'll let the Intel folks sign-off related to regressions. IMO minor regressions like this are acceptable if the generated code quality is good, and if the benchmark reports higher variance and averaging results from multiple forks close the gap. (In this case i don't understand how the Java changes impacts alignment). ------------- PR Review: https://git.openjdk.org/jdk/pull/25138#pullrequestreview-2976493924 PR Comment: https://git.openjdk.org/jdk/pull/25138#issuecomment-3025029477 From armin.schrenk at skymatic.de Tue Jul 1 18:46:12 2025 From: armin.schrenk at skymatic.de (Armin Schrenk) Date: Tue, 01 Jul 2025 20:46:12 +0200 Subject: =?utf-8?q?Re=3A?= [External] =?utf-8?q?=3A?==?utf-8?q?_Re=3A?= =?utf-8?q?_jpackage=3A?= Support building native Windows MSIs In-Reply-To: References: <13a-68629a80-9-779b3d00@72416994> <36a66421-240e-49a4-94f5-f89467eab56d@oracle.com> <13e-6862d180-11-2f7cd380@124222359> Message-ID: <13f-68642d00-3-69f4458@20238135> Great, thank you. I created a ticket in the issue tracker, see https://bugs.openjdk.org/browse/JDK-8361207 . ?The sanity checks already finished with success. Are there more steps needed/any requirements or can i create the PR now (after a rebase (-;) ? Best regards, Armin Am Montag, Juni 30, 2025 20:22 CEST, schrieb Alexey Semenyuk : ? Armin, I will sponsor your patch. - Alexey On 6/30/2025 2:04 PM, Armin Schrenk wrote: > > Cool. The changes can be found in? > https://github.com/infeo/jdk/commit/77c50367e3fd7d677bfe2e805be2feafa30b0a37. > > Basically, the command line builder for wix3/wix4 is adjusted to set? > the arch flag to x64, x86 or arm64 depending on return values of some? > jdk.internal.util.Architecture::is[Architecture] methods. If the? > architecture is not supported by the wix Version, an? > IOException("Unsupported architecture") is thrown. I defined an? > package private enum to filter out already unsupported architectures. > > @"Alexey Semenyuk" I've read the contribution guide. So, the next step? > would be finding a Sponsor? > > Best regards, > > Armin > > Am Montag, Juni 30, 2025 17:59 CEST, schrieb Alexey Semenyuk? > : > >> Hi Armin, >> >> Your ARM64 MSI contribution/enhancement for the jpackage will be much >> appreciated. >> >> - Alexey >> >> On 6/30/2025 10:09 AM, Armin Schrenk wrote: >> > >> > Hello everyone, >> > >> > does jpackage support building native ARM64 MSI packages? Building an >> > jpackage MSI on Windows ARM64, the resulting package contains x64 DLLs. >> > >> > I looked further into the JDK code and apparently, the wix Command >> > builder (WixPipeline.java) only supports x86 or x64 ?(see >> >? >> https://github.com/openjdk/jdk/blob/a84946dde4283fd423ef00ce3176bbe1985d7046/src/jdk.jpackage/windows/classes/jdk/jpackage/internal/WixPipeline.java#L211). >> > According to the wix docs, aarch64 is supported since version 4.0: >> > https://docs.firegiant.com/wix/tools/wixexe/#build >> > >> > I already created a patched JDK locally, but maybe this can be a >> > contribution/enhancement for the JDK in general. >> > >> > Best regards, >> > >> > Armin Schrenk >> > >> > > > ? ? -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2759 bytes Desc: not available URL: From rriggs at openjdk.org Tue Jul 1 18:57:44 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 1 Jul 2025 18:57:44 GMT Subject: RFR: 8360037: Refactor ImageReader in preparation for Valhalla support In-Reply-To: References: Message-ID: On Mon, 30 Jun 2025 23:27:49 GMT, David Beaumont wrote: > Refactoring `ImageReader` to make it easy to add preview mode functionality for Valhalla. > > This PR is a large change to `ImageReader` (effectively a rewrite) but reduces the surface area of the API significantly, reduces code complexity and increases performance/memory efficiency. The need for this sort of change comes from the need to support "preview mode" in Valhalla for classes loaded from core modules. > > ### Preview Mode > > In the proposed preview mode support for Valhalla, a resource with the name `/modules//` may come from one of two locations in the underlying jimage file; `//` or `//META-INF/preview/`. Furthermore, directories (represented as directory nodes via the API) will have a potentially different number of child nodes depending on whether preview mode is in effect, and some directories may only exist at all in preview mode. > > Furthermore, the directories and symbolic link nodes in `/packages/...` will also be affected by the existence of new package directories. To retain consistency and avoid "surprises" later, all of this needs to be taken into account. > > Below is a summary of the main changes for mainline JDK to better support preview mode later: > > ### 1: Improved encapsulation for preview mode > > The current `ImageReader` code exposes the data from the jimage file in several ways; via the `Node` abstraction, but also with methods which return an `ImageLocation` instance directly. In preview mode it would not be acceptable to return the `ImageLocation`, since that would leak the existence of resources in the `META-INF/preview` namespace and lets users see resource nodes with names that don't match the underlying `ImageLocation` from which their contents come. > > As such, the PR removes all methods which can leak `ImageLocation` or other "underlying" semantics about the jimage file. Luckily most of these are either used minimally and easily migrated to using nodes, or they were not being used at all. This PR also removes any methods which were already unused across the OpenJDK codebase (if I discover any issues with over-trimming of the API during full CI testing, it will be easy to address). > > ### 2. Simplification of directory child node handling > > The current `ImageReader` code attempts to create parent directories "on demand" for any child nodes it creates. This results in parent directories having a non-empty but incomplete set of child nodes present. This is referred to as the directory being "incomple... src/java.base/share/classes/jdk/internal/jimage/ImageReader.java line 555: > 553: > 554: /** > 555: * Returns the JRY file system compatible name of this node (e.g. Typo: "JRY" src/java.base/share/classes/jdk/internal/module/SystemModuleFinders.java line 292: > 290: @Override > 291: public Optional find(String name) { > 292: requireNonNull(name); Personal preference is avoid static imports making the code readable by retaining the "Objects." qualifier otherwise the non-local method call appears out of thin air. YMMV. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26054#discussion_r2178300589 PR Review Comment: https://git.openjdk.org/jdk/pull/26054#discussion_r2178311050 From rriggs at openjdk.org Tue Jul 1 18:57:45 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 1 Jul 2025 18:57:45 GMT Subject: RFR: 8360037: Refactor ImageReader in preparation for Valhalla support In-Reply-To: <9xh9VZuuTCyFomE_TV9usc_bVDSPz6ssX5HDmj-hhSU=.18a3192c-57b1-4920-b97b-4cfd37c6fea6@github.com> References: <9xh9VZuuTCyFomE_TV9usc_bVDSPz6ssX5HDmj-hhSU=.18a3192c-57b1-4920-b97b-4cfd37c6fea6@github.com> Message-ID: <7jq-fF6TKn2LVG7na2cKpZ_uR-c-bSZe1xhqt3vaXa4=.397585d5-c923-42de-9431-8a23645df224@github.com> On Tue, 1 Jul 2025 14:02:11 GMT, David Beaumont wrote: >> Refactoring `ImageReader` to make it easy to add preview mode functionality for Valhalla. >> >> This PR is a large change to `ImageReader` (effectively a rewrite) but reduces the surface area of the API significantly, reduces code complexity and increases performance/memory efficiency. The need for this sort of change comes from the need to support "preview mode" in Valhalla for classes loaded from core modules. >> >> ### Preview Mode >> >> In the proposed preview mode support for Valhalla, a resource with the name `/modules//` may come from one of two locations in the underlying jimage file; `//` or `//META-INF/preview/`. Furthermore, directories (represented as directory nodes via the API) will have a potentially different number of child nodes depending on whether preview mode is in effect, and some directories may only exist at all in preview mode. >> >> Furthermore, the directories and symbolic link nodes in `/packages/...` will also be affected by the existence of new package directories. To retain consistency and avoid "surprises" later, all of this needs to be taken into account. >> >> Below is a summary of the main changes for mainline JDK to better support preview mode later: >> >> ### 1: Improved encapsulation for preview mode >> >> The current `ImageReader` code exposes the data from the jimage file in several ways; via the `Node` abstraction, but also with methods which return an `ImageLocation` instance directly. In preview mode it would not be acceptable to return the `ImageLocation`, since that would leak the existence of resources in the `META-INF/preview` namespace and lets users see resource nodes with names that don't match the underlying `ImageLocation` from which their contents come. >> >> As such, the PR removes all methods which can leak `ImageLocation` or other "underlying" semantics about the jimage file. Luckily most of these are either used minimally and easily migrated to using nodes, or they were not being used at all. This PR also removes any methods which were already unused across the OpenJDK codebase (if I discover any issues with over-trimming of the API during full CI testing, it will be easy to address). >> >> ### 2. Simplification of directory child node handling >> >> The current `ImageReader` code attempts to create parent directories "on demand" for any child nodes it creates. This results in parent directories having a non-empty but incomplete set of child nodes present. This is re... > > test/jdk/jdk/internal/jimage/ImageReaderTest.java line 78: > >> 76: >> 77: @Test >> 78: public void testModuleDirectories() throws IOException { > > I could make these more data driven (i.e. parametrized) if people want. yes, please, it will make failures easier to identity. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26054#discussion_r2178321323 From alexey.semenyuk at oracle.com Tue Jul 1 19:10:21 2025 From: alexey.semenyuk at oracle.com (Alexey Semenyuk) Date: Tue, 1 Jul 2025 15:10:21 -0400 Subject: [External] : Re: jpackage: Support building native Windows MSIs In-Reply-To: <13f-68642d00-3-69f4458@20238135> References: <13a-68629a80-9-779b3d00@72416994> <36a66421-240e-49a4-94f5-f89467eab56d@oracle.com> <13e-6862d180-11-2f7cd380@124222359> <13f-68642d00-3-69f4458@20238135> Message-ID: Hi Armin, Create a PR. If you haven't signed the OCA yet, it will ask you to do so. After that, we will proceed with the review. - Alexey On 7/1/2025 2:46 PM, Armin Schrenk wrote: > > Great, thank you. I created a ticket in the issue tracker, see > https://bugs.openjdk.org/browse/JDK-8361207 > . ?The sanity checks > already finished with success. Are there more steps needed/any > requirements or can i create the PR now (after a rebase (-;) ? > > Best regards, > > Armin > > Am Montag, Juni 30, 2025 20:22 CEST, schrieb Alexey Semenyuk > : > >> Armin, >> >> I will sponsor your patch. >> >> - Alexey >> >> On 6/30/2025 2:04 PM, Armin Schrenk wrote: >> > >> > Cool. The changes can be found in >> > >> https://github.com/infeo/jdk/commit/77c50367e3fd7d677bfe2e805be2feafa30b0a37. >> > >> > Basically, the command line builder for wix3/wix4 is adjusted to set >> > the arch flag to x64, x86 or arm64 depending on return values of some >> > jdk.internal.util.Architecture::is[Architecture] methods. If the >> > architecture is not supported by the wix Version, an >> > IOException("Unsupported architecture") is thrown. I defined an >> > package private enum to filter out already unsupported architectures. >> > >> > @"Alexey Semenyuk" I've read the contribution guide. So, the next step >> > would be finding a Sponsor? >> > >> > Best regards, >> > >> > Armin >> > >> > Am Montag, Juni 30, 2025 17:59 CEST, schrieb Alexey Semenyuk >> > : >> > >> >> Hi Armin, >> >> >> >> Your ARM64 MSI contribution/enhancement for the jpackage will be much >> >> appreciated. >> >> >> >> - Alexey >> >> >> >> On 6/30/2025 10:09 AM, Armin Schrenk wrote: >> >> > >> >> > Hello everyone, >> >> > >> >> > does jpackage support building native ARM64 MSI packages? >> Building an >> >> > jpackage MSI on Windows ARM64, the resulting package contains >> x64 DLLs. >> >> > >> >> > I looked further into the JDK code and apparently, the wix Command >> >> > builder (WixPipeline.java) only supports x86 or x64 ?(see >> >> > >> >> >> https://github.com/openjdk/jdk/blob/a84946dde4283fd423ef00ce3176bbe1985d7046/src/jdk.jpackage/windows/classes/jdk/jpackage/internal/WixPipeline.java#L211). >> >> > According to the wix docs, aarch64 is supported since version 4.0: >> >> > https://docs.firegiant.com/wix/tools/wixexe/#build >> >> > >> >> > I already created a patched JDK locally, but maybe this can be a >> >> > contribution/enhancement for the JDK in general. >> >> > >> >> > Best regards, >> >> > >> >> > Armin Schrenk >> >> > >> >> >> > >> > >> > >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rriggs at openjdk.org Tue Jul 1 19:19:40 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 1 Jul 2025 19:19:40 GMT Subject: RFR: 8358533: Improve performance of java.io.Reader.readAllLines [v9] In-Reply-To: References: <3StfS2-72iIkuHlf9HpzfC-BNoD4kDEjHY2esUnPKEM=.f7ae323f-5313-445b-bd7d-89f6743974f3@github.com> Message-ID: On Tue, 1 Jul 2025 16:34:51 GMT, Brian Burkhalter wrote: >> I don't know, but I doubt it. I will look into adding something. > > With this change > > --- a/test/jdk/java/io/Reader/ReadAll.java > +++ b/test/jdk/java/io/Reader/ReadAll.java > @@ -115,6 +115,8 @@ public static void setup() throws IOException { > sb.setLength(0); > } > > + strings.add(" ".repeat(Integer.MAX_VALUE/2)); > + > > the limit is reached but it doubles the test run time, at least on an M4 Max. Yea, seems a waste to run it every time. I don't think we run any tests statistically *some of the time". Maybe if it was limited to run only in *big* configurations, maybe a separate @run with: `@requires os.maxMemory >= 6g` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25863#discussion_r2178365431 From sherman at openjdk.org Tue Jul 1 19:20:40 2025 From: sherman at openjdk.org (Xueming Shen) Date: Tue, 1 Jul 2025 19:20:40 GMT Subject: RFR: 8361018: Re-examine buffering and encoding conversion in BufferedWriter [v6] In-Reply-To: References: Message-ID: On Tue, 1 Jul 2025 14:33:34 GMT, Brett Okken wrote: > StreamEncoder/CharsetEncoder that is really forcing that - and the conversion to utf-16 is required for optimal encoder performance. It might be worth exploring the idea of using string-buffer as the buffer to carry the byte[] + coder (delaying the byte[] ? char[] conversion) to the StreamEncoder, and then wrapping it as a StringCharBuffer all the way down to the charset/encoder layer. This could enable potential optimizations at individual charset encoder level. It's unclear how significant the cost would be for the additional asb + scb wrapping and the access. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26022#issuecomment-3025232418 From djelinski at openjdk.org Tue Jul 1 19:53:57 2025 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Tue, 1 Jul 2025 19:53:57 GMT Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API [v9] In-Reply-To: References: Message-ID: <3UR7O_cfQFPcsz5GseXURHT9KVC6pUFSxa_KsNLtYNY=.d579b776-0eee-467b-b993-c1341b2dcb19@github.com> On Thu, 26 Jun 2025 16:36:40 GMT, Daniel Fuchs wrote: >> Hi, >> >> Please find here a PR for the implementation of [JEP 517: HTTP/3 for the HTTP Client API](https://openjdk.org/jeps/517). >> >> The CSR can be viewed at [JDK-8350588: Implement JEP 517: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588) >> >> This JEP proposes to enhance the HttpClient implementation to support HTTP/3. >> It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider. > > Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 525 commits: > > - merge latest changes from master branch > - http3: run H3StreamLimitReachedTest.java with -Djdk.httpclient.http3.maxStreamLimitTimeout=0 too > - retry the ResetControlStream test as needed > - http3: fix pending connection and reconnection on stream limit reached logic > - http3: pending acknowledgement should be registered before actually sending the packet > - http3: fix race with ping requests in PacketSpaceManager.java causing intermittent failures in H3ErrorHandlingTest.java > - http3: improve exceptions in Http3ServerExchange.java > - http3: fix exception handling in CancelRequestTest.java > - http3: review feedback - revert HPACK.java > - Implement X509TrustManagerImpl#checkClientTrusted for QUIC > - ... and 515 more: https://git.openjdk.org/jdk/compare/5a1301df...0229c215 src/java.net.http/share/classes/jdk/internal/net/http/http3/streams/UniStreamPair.java line 87: > 85: private final CompletableFuture streamWriterCF; > 86: // a queue of ByteBuffers submitted for writing. > 87: // might be null if not used. Only used in QueuingStreamPair. It seems to be true. I'll see if I can move it to QueuingStreamPair. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2178413151 From rriggs at openjdk.org Tue Jul 1 19:57:42 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 1 Jul 2025 19:57:42 GMT Subject: RFR: 8344332: (bf) Migrate DirectByteBuffer away from jdk.internal.ref.Cleaner [v7] In-Reply-To: References: Message-ID: On Sun, 29 Jun 2025 20:43:56 GMT, Kim Barrett wrote: >> This change makes java.nio no longer use jdk.internal.ref.Cleaner to manage >> native memory for Direct-X-Buffers. Instead it uses bespoke PhantomReferences >> and a dedicated ReferenceQueue. This differs from PR 22165, which proposed to >> use java.lang.ref.Cleaner. >> >> This change is algorithmically similar to the two previous versions: >> JDK-6857566 and JDK-8156500 (current mainline). The critical function is >> Bits::reserveMemory(). For both of those versions and this change, a thread >> calls that function and tries to reserve some space. If it fails, then it >> keeps trying until all cleaners deactivated (cleared) by prior GCs have been >> cleaned. If reservation still fails, then it invokes the GC to try to >> deactivate more cleaners for cleaning. After that GC it keeps trying the >> reservation and waiting for cleaning, with sleeps to avoid a spin loop, >> eventually either succeeding or giving up and throwing OOME. >> >> Retaining that algorithmic approach is one of the goals of this change, since >> it has been successfully in use since JDK 9 (and was originally developed and >> extensively tested in JDK 8). >> >> The key to this approach is having a way to determine that deactivated >> cleaners have been cleaned. JDK-6857566 accomplished this by having waiting >> threads help the reference processor until there was no available work. >> JDK-8156500 waits for the reference processor to quiesce, relying on its >> immediate processing of cleaners. java.lang.ref.Cleaner doesn't provide a way >> to do this, which is why this change rolls its own Cleaner-like mechanism from >> the underlying primitives. Like JDK-6857566, this change has waiting threads >> help with cleaning references. This was a potentially undesirable feature of >> JDK-6857566, as arbitrary allocating threads were invoking arbitrary cleaners. >> (Though by the time of JDK-6857566 the cleaners were only used by DBB, and >> became internal-only somewhere around that time as well.) That's not a concern >> here, as the cleaners involved are only from DBB, and we know what they look >> like. >> >> As noted in the discussion of JDK-6857566, it's good to have DBB cleaning >> being done off the reference processing thread, as it may be expensive and >> slow down enqueuing other pending references. JDK-6857566 only did some of >> that, and JDK-8156500 lost that feature. This change moves all of the DBB >> cleaning off of the reference processing thread. (So does PR 22165.) >> >> Neither JDK-6857566 nor this change are... > > Kim Barrett has updated the pull request incrementally with two additional commits since the last revision: > > - add @Override for clean() method > - more commentary for reserveMemory Looks fine ------------- PR Review: https://git.openjdk.org/jdk/pull/25289#pullrequestreview-2976779477 From duke at openjdk.org Tue Jul 1 19:57:45 2025 From: duke at openjdk.org (David Beaumont) Date: Tue, 1 Jul 2025 19:57:45 GMT Subject: RFR: 8360037: Refactor ImageReader in preparation for Valhalla support In-Reply-To: References: Message-ID: On Tue, 1 Jul 2025 14:37:50 GMT, Alan Bateman wrote: >> Refactoring `ImageReader` to make it easy to add preview mode functionality for Valhalla. >> >> This PR is a large change to `ImageReader` (effectively a rewrite) but reduces the surface area of the API significantly, reduces code complexity and increases performance/memory efficiency. The need for this sort of change comes from the need to support "preview mode" in Valhalla for classes loaded from core modules. >> >> ### Preview Mode >> >> In the proposed preview mode support for Valhalla, a resource with the name `/modules//` may come from one of two locations in the underlying jimage file; `//` or `//META-INF/preview/`. Furthermore, directories (represented as directory nodes via the API) will have a potentially different number of child nodes depending on whether preview mode is in effect, and some directories may only exist at all in preview mode. >> >> Furthermore, the directories and symbolic link nodes in `/packages/...` will also be affected by the existence of new package directories. To retain consistency and avoid "surprises" later, all of this needs to be taken into account. >> >> Below is a summary of the main changes for mainline JDK to better support preview mode later: >> >> ### 1: Improved encapsulation for preview mode >> >> The current `ImageReader` code exposes the data from the jimage file in several ways; via the `Node` abstraction, but also with methods which return an `ImageLocation` instance directly. In preview mode it would not be acceptable to return the `ImageLocation`, since that would leak the existence of resources in the `META-INF/preview` namespace and lets users see resource nodes with names that don't match the underlying `ImageLocation` from which their contents come. >> >> As such, the PR removes all methods which can leak `ImageLocation` or other "underlying" semantics about the jimage file. Luckily most of these are either used minimally and easily migrated to using nodes, or they were not being used at all. This PR also removes any methods which were already unused across the OpenJDK codebase (if I discover any issues with over-trimming of the API during full CI testing, it will be easy to address). >> >> ### 2. Simplification of directory child node handling >> >> The current `ImageReader` code attempts to create parent directories "on demand" for any child nodes it creates. This results in parent directories having a non-empty but incomplete set of child nodes present. This is re... > > src/java.base/share/classes/jdk/internal/module/SystemModuleFinders.java line 456: > >> 454: Optional node = Optional.ofNullable(reader.findNode(nodeName)); >> 455: if (node.isPresent() && !node.get().isResource()) { >> 456: throw new IllegalStateException("Not a resource node: " + node.get()); > > The IllegalStateException is problematic here, maybe you mean to add an assert? This is called externally so cannot trust the given name really references a resource. I can't therefore make it an assertion, but I can just return empty if it didn't point at a resource (even if it did point at a directory etc.). Or I can make it an Error. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26054#discussion_r2178417095 From duke at openjdk.org Tue Jul 1 20:01:48 2025 From: duke at openjdk.org (David Beaumont) Date: Tue, 1 Jul 2025 20:01:48 GMT Subject: RFR: 8360037: Refactor ImageReader in preparation for Valhalla support In-Reply-To: References: Message-ID: On Tue, 1 Jul 2025 18:38:26 GMT, Roger Riggs wrote: >> Refactoring `ImageReader` to make it easy to add preview mode functionality for Valhalla. >> >> This PR is a large change to `ImageReader` (effectively a rewrite) but reduces the surface area of the API significantly, reduces code complexity and increases performance/memory efficiency. The need for this sort of change comes from the need to support "preview mode" in Valhalla for classes loaded from core modules. >> >> ### Preview Mode >> >> In the proposed preview mode support for Valhalla, a resource with the name `/modules//` may come from one of two locations in the underlying jimage file; `//` or `//META-INF/preview/`. Furthermore, directories (represented as directory nodes via the API) will have a potentially different number of child nodes depending on whether preview mode is in effect, and some directories may only exist at all in preview mode. >> >> Furthermore, the directories and symbolic link nodes in `/packages/...` will also be affected by the existence of new package directories. To retain consistency and avoid "surprises" later, all of this needs to be taken into account. >> >> Below is a summary of the main changes for mainline JDK to better support preview mode later: >> >> ### 1: Improved encapsulation for preview mode >> >> The current `ImageReader` code exposes the data from the jimage file in several ways; via the `Node` abstraction, but also with methods which return an `ImageLocation` instance directly. In preview mode it would not be acceptable to return the `ImageLocation`, since that would leak the existence of resources in the `META-INF/preview` namespace and lets users see resource nodes with names that don't match the underlying `ImageLocation` from which their contents come. >> >> As such, the PR removes all methods which can leak `ImageLocation` or other "underlying" semantics about the jimage file. Luckily most of these are either used minimally and easily migrated to using nodes, or they were not being used at all. This PR also removes any methods which were already unused across the OpenJDK codebase (if I discover any issues with over-trimming of the API during full CI testing, it will be easy to address). >> >> ### 2. Simplification of directory child node handling >> >> The current `ImageReader` code attempts to create parent directories "on demand" for any child nodes it creates. This results in parent directories having a non-empty but incomplete set of child nodes present. This is re... > > src/java.base/share/classes/jdk/internal/module/SystemModuleFinders.java line 292: > >> 290: @Override >> 291: public Optional find(String name) { >> 292: requireNonNull(name); > > Personal preference is avoid static imports making the code readable by retaining the "Objects." qualifier otherwise the non-local method call appears out of thin air. YMMV. Yeah, given a couple of qualified ones existed here I'll qualify them all. Personally I've evolved my opinion on this from preferring qualified use to thinking that the static import is more concise (and no less clear given the very unambiguous name). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26054#discussion_r2178423993 From djelinski at openjdk.org Tue Jul 1 20:09:55 2025 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Tue, 1 Jul 2025 20:09:55 GMT Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API [v9] In-Reply-To: References: Message-ID: <3lbVW_vZLe7AqGQprT2k4Xa0gOwgsxzBfGmlwcPHtsQ=.abb14e6f-d7ef-4f36-a420-219dde365b52@github.com> On Thu, 26 Jun 2025 16:36:40 GMT, Daniel Fuchs wrote: >> Hi, >> >> Please find here a PR for the implementation of [JEP 517: HTTP/3 for the HTTP Client API](https://openjdk.org/jeps/517). >> >> The CSR can be viewed at [JDK-8350588: Implement JEP 517: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588) >> >> This JEP proposes to enhance the HttpClient implementation to support HTTP/3. >> It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider. > > Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 525 commits: > > - merge latest changes from master branch > - http3: run H3StreamLimitReachedTest.java with -Djdk.httpclient.http3.maxStreamLimitTimeout=0 too > - retry the ResetControlStream test as needed > - http3: fix pending connection and reconnection on stream limit reached logic > - http3: pending acknowledgement should be registered before actually sending the packet > - http3: fix race with ping requests in PacketSpaceManager.java causing intermittent failures in H3ErrorHandlingTest.java > - http3: improve exceptions in Http3ServerExchange.java > - http3: fix exception handling in CancelRequestTest.java > - http3: review feedback - revert HPACK.java > - Implement X509TrustManagerImpl#checkClientTrusted for QUIC > - ... and 515 more: https://git.openjdk.org/jdk/compare/5a1301df...0229c215 src/java.net.http/share/classes/jdk/internal/net/http/http3/streams/UniStreamPair.java line 99: > 97: // The QuicStreamReader for the peer control stream > 98: volatile QuicStreamReader peerReader; > 99: private final CompletableFuture streamReaderCF; Unused src/java.net.http/share/classes/jdk/internal/net/http/http3/streams/UniStreamPair.java line 246: > 244: * type has been read off the remote initiated stream} > 245: */ > 246: public final CompletableFuture futureReceiverStreamReader() { Unused ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2178431502 PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2178432294 From duke at openjdk.org Tue Jul 1 20:37:06 2025 From: duke at openjdk.org (David Beaumont) Date: Tue, 1 Jul 2025 20:37:06 GMT Subject: RFR: 8360037: Refactor ImageReader in preparation for Valhalla support [v2] In-Reply-To: References: Message-ID: > Refactoring `ImageReader` to make it easy to add preview mode functionality for Valhalla. > > This PR is a large change to `ImageReader` (effectively a rewrite) but reduces the surface area of the API significantly, reduces code complexity and increases performance/memory efficiency. The need for this sort of change comes from the need to support "preview mode" in Valhalla for classes loaded from core modules. > > ### Preview Mode > > In the proposed preview mode support for Valhalla, a resource with the name `/modules//` may come from one of two locations in the underlying jimage file; `//` or `//META-INF/preview/`. Furthermore, directories (represented as directory nodes via the API) will have a potentially different number of child nodes depending on whether preview mode is in effect, and some directories may only exist at all in preview mode. > > Furthermore, the directories and symbolic link nodes in `/packages/...` will also be affected by the existence of new package directories. To retain consistency and avoid "surprises" later, all of this needs to be taken into account. > > Below is a summary of the main changes for mainline JDK to better support preview mode later: > > ### 1: Improved encapsulation for preview mode > > The current `ImageReader` code exposes the data from the jimage file in several ways; via the `Node` abstraction, but also with methods which return an `ImageLocation` instance directly. In preview mode it would not be acceptable to return the `ImageLocation`, since that would leak the existence of resources in the `META-INF/preview` namespace and lets users see resource nodes with names that don't match the underlying `ImageLocation` from which their contents come. > > As such, the PR removes all methods which can leak `ImageLocation` or other "underlying" semantics about the jimage file. Luckily most of these are either used minimally and easily migrated to using nodes, or they were not being used at all. This PR also removes any methods which were already unused across the OpenJDK codebase (if I discover any issues with over-trimming of the API during full CI testing, it will be easy to address). > > ### 2. Simplification of directory child node handling > > The current `ImageReader` code attempts to create parent directories "on demand" for any child nodes it creates. This results in parent directories having a non-empty but incomplete set of child nodes present. This is referred to as the directory being "incomple... David Beaumont has updated the pull request incrementally with one additional commit since the last revision: Updates based on feedback. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26054/files - new: https://git.openjdk.org/jdk/pull/26054/files/d8efaa09..29633a12 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26054&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26054&range=00-01 Stats: 39 lines in 2 files changed: 13 ins; 6 del; 20 mod Patch: https://git.openjdk.org/jdk/pull/26054.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26054/head:pull/26054 PR: https://git.openjdk.org/jdk/pull/26054 From duke at openjdk.org Tue Jul 1 20:37:06 2025 From: duke at openjdk.org (David Beaumont) Date: Tue, 1 Jul 2025 20:37:06 GMT Subject: RFR: 8360037: Refactor ImageReader in preparation for Valhalla support [v2] In-Reply-To: References: Message-ID: On Tue, 1 Jul 2025 14:29:28 GMT, Alan Bateman wrote: >> David Beaumont has updated the pull request incrementally with one additional commit since the last revision: >> >> Updates based on feedback. > > src/java.base/share/classes/jdk/internal/module/SystemModuleFinders.java line 62: > >> 60: import jdk.internal.module.ModuleHashes.HashSupplier; >> 61: >> 62: import static java.util.Objects.requireNonNull; > > The existing Objects.requireNonNull are okay, no need to change them all as it is nothing to do with the changes. Done. > src/java.base/share/classes/jdk/internal/module/SystemModuleFinders.java line 251: > >> 249: } >> 250: >> 251: private static Stream getModuleAttributes() { > > Can you rename this to allModuleAttributes and add a method description to match the other methods. Done. > src/java.base/share/classes/jdk/internal/module/SystemModuleFinders.java line 257: > >> 255: .getChildNames() >> 256: .map(mn -> getNode(reader, mn + "/module-info.class")) >> 257: // This fails with ISE if the node isn't a resource (corrupt JImage). > > Can you drop this comment and check getNode to thrown an Error (ISE isn't right when we have a broken image). `getNode()` is called twice and while it can throw the error, there's no nice way for `getResourceBuffer()` to be that strict (it's a separate API). After fiddling a bit I reworked the module attribute loading into a separate helper and caught & escalated any exceptions relating to that into `Error`. The only question now is that `ModuleInfo.read()` has at least one other runtime exception (`InvalidModuleDescriptorException`) it can throw which we could catch here. Should I add that to the list? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26054#discussion_r2178463701 PR Review Comment: https://git.openjdk.org/jdk/pull/26054#discussion_r2178463291 PR Review Comment: https://git.openjdk.org/jdk/pull/26054#discussion_r2178462973 From duke at openjdk.org Tue Jul 1 20:37:06 2025 From: duke at openjdk.org (David Beaumont) Date: Tue, 1 Jul 2025 20:37:06 GMT Subject: RFR: 8360037: Refactor ImageReader in preparation for Valhalla support [v2] In-Reply-To: References: Message-ID: On Tue, 1 Jul 2025 19:54:10 GMT, David Beaumont wrote: >> src/java.base/share/classes/jdk/internal/module/SystemModuleFinders.java line 456: >> >>> 454: Optional node = Optional.ofNullable(reader.findNode(nodeName)); >>> 455: if (node.isPresent() && !node.get().isResource()) { >>> 456: throw new IllegalStateException("Not a resource node: " + node.get()); >> >> The IllegalStateException is problematic here, maybe you mean to add an assert? > > This is called externally so cannot trust the given name really references a resource. > I can't therefore make it an assertion, but I can just return empty if it didn't point at a resource (even if it did point at a directory etc.). Or I can make it an Error. I made it return empty for now and documented it as such. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26054#discussion_r2178467594 From duke at openjdk.org Tue Jul 1 20:39:43 2025 From: duke at openjdk.org (David Beaumont) Date: Tue, 1 Jul 2025 20:39:43 GMT Subject: RFR: 8360037: Refactor ImageReader in preparation for Valhalla support [v2] In-Reply-To: <7jq-fF6TKn2LVG7na2cKpZ_uR-c-bSZe1xhqt3vaXa4=.397585d5-c923-42de-9431-8a23645df224@github.com> References: <9xh9VZuuTCyFomE_TV9usc_bVDSPz6ssX5HDmj-hhSU=.18a3192c-57b1-4920-b97b-4cfd37c6fea6@github.com> <7jq-fF6TKn2LVG7na2cKpZ_uR-c-bSZe1xhqt3vaXa4=.397585d5-c923-42de-9431-8a23645df224@github.com> Message-ID: On Tue, 1 Jul 2025 18:45:49 GMT, Roger Riggs wrote: >> test/jdk/jdk/internal/jimage/ImageReaderTest.java line 78: >> >>> 76: >>> 77: @Test >>> 78: public void testModuleDirectories() throws IOException { >> >> I could make these more data driven (i.e. parametrized) if people want. > > yes, please, it will make failures easier to identity. I may not get to this before taking leave, but I will do it. It doesn't make sense to parameterise all tests, but I'll do the basic ones like this. Not having it spin up a new jimage for each obviously helps :) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26054#discussion_r2178471074 From sviswanathan at openjdk.org Tue Jul 1 21:33:44 2025 From: sviswanathan at openjdk.org (Sandhya Viswanathan) Date: Tue, 1 Jul 2025 21:33:44 GMT Subject: RFR: 8355563: VectorAPI: Refactor current implementation of subword gather load API [v2] In-Reply-To: References: Message-ID: On Wed, 25 Jun 2025 09:16:48 GMT, Xiaohong Gong wrote: >> JDK-8318650 introduced hotspot intrinsification of subword gather load APIs for X86 platforms [1]. However, the current implementation is not optimal for AArch64 SVE platform, which natively supports vector instructions for subword gather load operations using an int vector for indices (see [2][3]). >> >> Two key areas require improvement: >> 1. At the Java level, vector indices generated for range validation could be reused for the subsequent gather load operation on architectures with native vector instructions like AArch64 SVE. However, the current implementation prevents compiler reuse of these index vectors due to divergent control flow, potentially impacting performance. >> 2. At the compiler IR level, the additional `offset` input for `LoadVectorGather`/`LoadVectorGatherMasked` with subword types increases IR complexity and complicates backend implementation. Furthermore, generating `add` instructions before each memory access negatively impacts performance. >> >> This patch refactors the implementation at both the Java level and compiler mid-end to improve efficiency and maintainability across different architectures. >> >> Main changes: >> 1. Java-side API refactoring: >> - Explicitly passes generated index vectors to hotspot, eliminating duplicate index vectors for gather load instructions on >> architectures like AArch64. >> 2. C2 compiler IR refactoring: >> - Refactors `LoadVectorGather`/`LoadVectorGatherMasked` IR for subword types by removing the memory offset input and incorporating it into the memory base `addr` at the IR level. This simplifies backend implementation, reduces add operations, and unifies the IR across all types. >> 3. Backend changes: >> - Streamlines X86 implementation of subword gather operations following the removal of the offset input from the IR level. >> >> Performance: >> The performance of the relative JMH improves up to 27% on a X86 AVX512 system. Please see the data below: >> >> Benchmark Mode Cnt Unit SIZE Before After Gain >> GatherOperationsBenchmark.microByteGather128 thrpt 30 ops/ms 64 53682.012 52650.325 0.98 >> GatherOperationsBenchmark.microByteGather128 thrpt 30 ops/ms 256 14484.252 14255.156 0.98 >> GatherOperationsBenchmark.microByteGather128 thrpt 30 ops/ms 1024 3664.900 3595.615 0.98 >> GatherOperationsBenchmark.microByteGather128 thrpt 30 ops/ms 4096 908.31... > > Xiaohong Gong has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: > > - Address review comments > - Merge 'jdk:master' into JDK-8355563 > - 8355563: VectorAPI: Refactor current implementation of subword gather load API Marked as reviewed by sviswanathan (Reviewer). Agree with Paul, these are minor regressions. Let us proceed with this patch. ------------- PR Review: https://git.openjdk.org/jdk/pull/25138#pullrequestreview-2977019367 PR Comment: https://git.openjdk.org/jdk/pull/25138#issuecomment-3025596784 From duke at openjdk.org Tue Jul 1 22:12:01 2025 From: duke at openjdk.org (David Beaumont) Date: Tue, 1 Jul 2025 22:12:01 GMT Subject: RFR: 8360037: Refactor ImageReader in preparation for Valhalla support [v3] In-Reply-To: References: Message-ID: > Refactoring `ImageReader` to make it easy to add preview mode functionality for Valhalla. > > This PR is a large change to `ImageReader` (effectively a rewrite) but reduces the surface area of the API significantly, reduces code complexity and increases performance/memory efficiency. The need for this sort of change comes from the need to support "preview mode" in Valhalla for classes loaded from core modules. > > ### Preview Mode > > In the proposed preview mode support for Valhalla, a resource with the name `/modules//` may come from one of two locations in the underlying jimage file; `//` or `//META-INF/preview/`. Furthermore, directories (represented as directory nodes via the API) will have a potentially different number of child nodes depending on whether preview mode is in effect, and some directories may only exist at all in preview mode. > > Furthermore, the directories and symbolic link nodes in `/packages/...` will also be affected by the existence of new package directories. To retain consistency and avoid "surprises" later, all of this needs to be taken into account. > > Below is a summary of the main changes for mainline JDK to better support preview mode later: > > ### 1: Improved encapsulation for preview mode > > The current `ImageReader` code exposes the data from the jimage file in several ways; via the `Node` abstraction, but also with methods which return an `ImageLocation` instance directly. In preview mode it would not be acceptable to return the `ImageLocation`, since that would leak the existence of resources in the `META-INF/preview` namespace and lets users see resource nodes with names that don't match the underlying `ImageLocation` from which their contents come. > > As such, the PR removes all methods which can leak `ImageLocation` or other "underlying" semantics about the jimage file. Luckily most of these are either used minimally and easily migrated to using nodes, or they were not being used at all. This PR also removes any methods which were already unused across the OpenJDK codebase (if I discover any issues with over-trimming of the API during full CI testing, it will be easy to address). > > ### 2. Simplification of directory child node handling > > The current `ImageReader` code attempts to create parent directories "on demand" for any child nodes it creates. This results in parent directories having a non-empty but incomplete set of child nodes present. This is referred to as the directory being "incomple... David Beaumont has updated the pull request incrementally with one additional commit since the last revision: Feedback changes. * Making some simple tests parametrized. * Revert change to JImageReadTest (it passes either way, so keep it simple). ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26054/files - new: https://git.openjdk.org/jdk/pull/26054/files/29633a12..9d9e62ba Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26054&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26054&range=01-02 Stats: 33 lines in 2 files changed: 17 ins; 5 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/26054.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26054/head:pull/26054 PR: https://git.openjdk.org/jdk/pull/26054 From rriggs at openjdk.org Tue Jul 1 22:30:57 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 1 Jul 2025 22:30:57 GMT Subject: RFR: 8354872: Clarify java.lang.Process resource cleanup [v3] In-Reply-To: <39KIPIXZDBI9tpPyXew2Ye-uzPvkLSQnOzGJFuK9E2Y=.dc8df88f-f21a-4dd6-8297-5629098bd408@github.com> References: <39KIPIXZDBI9tpPyXew2Ye-uzPvkLSQnOzGJFuK9E2Y=.dc8df88f-f21a-4dd6-8297-5629098bd408@github.com> Message-ID: > Improve the documentation of Process use of system resources. > > Describe the implementation closing streams when no longer referenced. > Clarify the interactions between inputStream and inputReader and errorStream and errorReader. > Add advice and example using try-with-resources to open and close streams. > Recommend closing streams when no longer in use. Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: javadoc cleanup ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25884/files - new: https://git.openjdk.org/jdk/pull/25884/files/8be5b028..868c93aa Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25884&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25884&range=01-02 Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/25884.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25884/head:pull/25884 PR: https://git.openjdk.org/jdk/pull/25884 From rriggs at openjdk.org Tue Jul 1 22:30:58 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 1 Jul 2025 22:30:58 GMT Subject: RFR: 8354872: Clarify java.lang.Process resource cleanup [v2] In-Reply-To: References: <39KIPIXZDBI9tpPyXew2Ye-uzPvkLSQnOzGJFuK9E2Y=.dc8df88f-f21a-4dd6-8297-5629098bd408@github.com> Message-ID: On Fri, 27 Jun 2025 19:06:22 GMT, Roger Riggs wrote: >> Improve the documentation of Process use of system resources. >> >> Describe the implementation closing streams when no longer referenced. >> Clarify the interactions between inputStream and inputReader and errorStream and errorReader. >> Add advice and example using try-with-resources to open and close streams. >> Recommend closing streams when no longer in use. > > Roger Riggs has updated the pull request incrementally with two additional commits since the last revision: > > - Revised Process and ProcessBuilder doc with reviewer suggestions. > And copyrights. > - Update example to use Reader.allAllLines() and simplify passing args to the ProcessBuilder constructor. > Plus copyright update Please also review the CSR. [JDK-8356311](https://bugs.openjdk.org/browse/JDK-8356311): Clarify java.lang.Process resource use ------------- PR Comment: https://git.openjdk.org/jdk/pull/25884#issuecomment-3025717882 From bpb at openjdk.org Tue Jul 1 23:04:00 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 1 Jul 2025 23:04:00 GMT Subject: RFR: 8358533: Improve performance of java.io.Reader.readAllLines [v10] In-Reply-To: References: Message-ID: <3D0JHwAVVr5O_UpXs3iedgasXzbq2I5n82dh9TyQDVo=.8e031329-6223-4a6f-aea8-ef3b2933cbce@github.com> > Replaces the implementation `readAllCharsAsString().lines().toList()` with reading into a temporary `char` array which is then processed to detect line terminators and copy non-terminating characters into strings which are added to the list. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8358533: Trigger array resize at cb.length/2 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25863/files - new: https://git.openjdk.org/jdk/pull/25863/files/47c8bb97..9eeed767 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25863&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25863&range=08-09 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25863.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25863/head:pull/25863 PR: https://git.openjdk.org/jdk/pull/25863 From bpb at openjdk.org Tue Jul 1 23:04:01 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 1 Jul 2025 23:04:01 GMT Subject: RFR: 8358533: Improve performance of java.io.Reader.readAllLines [v9] In-Reply-To: <3StfS2-72iIkuHlf9HpzfC-BNoD4kDEjHY2esUnPKEM=.f7ae323f-5313-445b-bd7d-89f6743974f3@github.com> References: <3StfS2-72iIkuHlf9HpzfC-BNoD4kDEjHY2esUnPKEM=.f7ae323f-5313-445b-bd7d-89f6743974f3@github.com> Message-ID: On Tue, 1 Jul 2025 15:10:10 GMT, Brian Burkhalter wrote: >> src/java.base/share/classes/java/io/Reader.java line 482: >> >>> 480: if (pos == limit) { >>> 481: int len = limit - start; >>> 482: if (len >= cb.length) { >> >> Observation: this algorithm will get less efficient as the line length approaches cb.length. >> Starting at sb.length/2 It will take 2 reads for every line and will not resize the buffer. >> I think resizing the buffer when the line length exceeds cb.length/2 will be more efficient (cpu wise). >> The decoding of the bytes to chars and the setup of the decoder is the expensive part. >> For most typical line length distributions it would not make a difference but would improve the performance of the outliners. > >> I think resizing the buffer when the line length exceeds cb.length/2 will be more efficient (cpu wise). > > I concur. I missed that this had been changed in the most recent commit. So changed in [9eeed76](https://github.com/openjdk/jdk/pull/25863/commits/9eeed767ced6e7b86ac7c2c73fb2d32063d88a7a). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25863#discussion_r2178698226 From bpb at openjdk.org Tue Jul 1 23:04:01 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 1 Jul 2025 23:04:01 GMT Subject: RFR: 8358533: Improve performance of java.io.Reader.readAllLines [v9] In-Reply-To: References: <3StfS2-72iIkuHlf9HpzfC-BNoD4kDEjHY2esUnPKEM=.f7ae323f-5313-445b-bd7d-89f6743974f3@github.com> Message-ID: On Tue, 1 Jul 2025 19:17:17 GMT, Roger Riggs wrote: >> With this change >> >> --- a/test/jdk/java/io/Reader/ReadAll.java >> +++ b/test/jdk/java/io/Reader/ReadAll.java >> @@ -115,6 +115,8 @@ public static void setup() throws IOException { >> sb.setLength(0); >> } >> >> + strings.add(" ".repeat(Integer.MAX_VALUE/2)); >> + >> >> the limit is reached but it doubles the test run time, at least on an M4 Max. > > Yea, seems a waste to run it every time. I don't think we run any tests statistically *some of the time". > Maybe if it was limited to run only in *big* configurations, maybe a separate @run with: > > `@requires os.maxMemory >= 6g` The test fails with OOME in the CI even with the above `@requires` so I am _not_ changing it for now. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25863#discussion_r2178698828 From liach at openjdk.org Tue Jul 1 23:03:32 2025 From: liach at openjdk.org (Chen Liang) Date: Tue, 1 Jul 2025 23:03:32 GMT Subject: RFR: 8360163: Create annotations to mark dumping method handles and runtime setup required classes [v4] In-Reply-To: References: Message-ID: > I have updated this patch to avoid a redundant `runtimeSetup` annotation - we have agreed that the requirement for setup is a side effect of initialization, and such methods in AOTCI classes must be automatically recognized. This latest revision implements that model. > > I intentionally avoided handling Class and ClassLoader `resetArchivedStates` and `MethodType::assemblySetup` - we talked about a generic `assemblyCleanup` method, but I did not find out where is the best place to call such a method in the assembly phase. We cna handle this in a subsequent patch. > > In particular, please review the new AOT.md design document - I split it from the AOTCI annotation to prevent jamming; we can put general AOT information there when we have more AOT-specific annotations. > > --- > > Old description: > Currently, the list of classes that have interdependencies and those that need runtimeSetup are maintained in a hardcoded list in CDS. This makes it risky for core library developers as they might introduce new interdependencies and observe CDS to fail. By moving the mechanism of these lists to core library annotations as a first step, we can gradually expose the AOT contracts as program semantics described by internal annotations, and also helps us to explore how we can expose these functionalities to the public later. Chen Liang has updated the pull request incrementally with one additional commit since the last revision: Stage ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25922/files - new: https://git.openjdk.org/jdk/pull/25922/files/9ec3d2e3..181c6f27 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25922&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25922&range=02-03 Stats: 341 lines in 41 files changed: 159 ins; 94 del; 88 mod Patch: https://git.openjdk.org/jdk/pull/25922.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25922/head:pull/25922 PR: https://git.openjdk.org/jdk/pull/25922 From liach at openjdk.org Tue Jul 1 23:20:59 2025 From: liach at openjdk.org (Chen Liang) Date: Tue, 1 Jul 2025 23:20:59 GMT Subject: RFR: 8360163: Create annotations to mark dumping method handles and runtime setup required classes [v5] In-Reply-To: References: Message-ID: > I have updated this patch to avoid a redundant `runtimeSetup` annotation - we have agreed that the requirement for setup is a side effect of initialization, and such methods in AOTCI classes must be automatically recognized. This latest revision implements that model. > > I intentionally avoided handling Class and ClassLoader `resetArchivedStates` and `MethodType::assemblySetup` - we talked about a generic `assemblyCleanup` method, but I did not find out where is the best place to call such a method in the assembly phase. We cna handle this in a subsequent patch. > > In particular, please review the new AOT.md design document - I split it from the AOTCI annotation to prevent jamming; we can put general AOT information there when we have more AOT-specific annotations. > > --- > > Old description: > Currently, the list of classes that have interdependencies and those that need runtimeSetup are maintained in a hardcoded list in CDS. This makes it risky for core library developers as they might introduce new interdependencies and observe CDS to fail. By moving the mechanism of these lists to core library annotations as a first step, we can gradually expose the AOT contracts as program semantics described by internal annotations, and also helps us to explore how we can expose these functionalities to the public later. Chen Liang has updated the pull request incrementally with one additional commit since the last revision: Reviewed the diff on github ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25922/files - new: https://git.openjdk.org/jdk/pull/25922/files/181c6f27..d5a54f5b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25922&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25922&range=03-04 Stats: 19 lines in 9 files changed: 9 ins; 4 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/25922.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25922/head:pull/25922 PR: https://git.openjdk.org/jdk/pull/25922 From liach at openjdk.org Tue Jul 1 23:20:59 2025 From: liach at openjdk.org (Chen Liang) Date: Tue, 1 Jul 2025 23:20:59 GMT Subject: RFR: 8360163: Create annotations to mark dumping method handles and runtime setup required classes [v4] In-Reply-To: References: Message-ID: On Tue, 1 Jul 2025 23:03:32 GMT, Chen Liang wrote: >> I have updated this patch to avoid a redundant `runtimeSetup` annotation - we have agreed that the requirement for setup is a side effect of initialization, and such methods in AOTCI classes must be automatically recognized. This latest revision implements that model. >> >> I intentionally avoided handling Class and ClassLoader `resetArchivedStates` and `MethodType::assemblySetup` - we talked about a generic `assemblyCleanup` method, but I did not find out where is the best place to call such a method in the assembly phase. We cna handle this in a subsequent patch. >> >> In particular, please review the new AOT.md design document - I split it from the AOTCI annotation to prevent jamming; we can put general AOT information there when we have more AOT-specific annotations. >> >> --- >> >> Old description: >> Currently, the list of classes that have interdependencies and those that need runtimeSetup are maintained in a hardcoded list in CDS. This makes it risky for core library developers as they might introduce new interdependencies and observe CDS to fail. By moving the mechanism of these lists to core library annotations as a first step, we can gradually expose the AOT contracts as program semantics described by internal annotations, and also helps us to explore how we can expose these functionalities to the public later. > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > Stage Turns out the current class initializer annotation is still quite restricted to MH - this means we will for now not merge this with the runtime setup annotation. I also added verification in classFileParser for runtimeSetup annotated methods. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25922#issuecomment-3025824157 From bpb at openjdk.org Tue Jul 1 23:26:42 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 1 Jul 2025 23:26:42 GMT Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from libnio to libjava [v15] In-Reply-To: References: Message-ID: > This proposed change would move the native objects required for NIO file interaction from the libnio native library to the libjava native library on Linux, macOS, and Windows. Brian Burkhalter 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 - Merge - Merge - Merge - Merge - Merge - Merge - 8337143: Minor makefile tweak - 8337143: Clean up to address reviewer comments - Merge - ... and 5 more: https://git.openjdk.org/jdk/compare/9d518b32...ffa3c469 ------------- Changes: https://git.openjdk.org/jdk/pull/20317/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20317&range=14 Stats: 1539 lines in 93 files changed: 774 ins; 668 del; 97 mod Patch: https://git.openjdk.org/jdk/pull/20317.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20317/head:pull/20317 PR: https://git.openjdk.org/jdk/pull/20317 From iklam at openjdk.org Wed Jul 2 00:22:54 2025 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 2 Jul 2025 00:22:54 GMT Subject: RFR: 8360555: Archive all unnamed modules in CDS full module graph Message-ID: The CDS full module graph is supposed to contain a snapshot of the boot layer, which has 3 unnamed modules for the boot, platform and system class loaders. Each unnamed module is represented by a `java.lang.Module` Java object and a `ModuleEntry` C++ object. Currently, we archive only the `java.lang.Module` for the platform and system loaders. The other 4 objects are dynamically created in the production run while executing Java bytecodes during VM bootstrap. With this PR, we archive all of the above 6 objects when `CDSConfig::is_dumping_full_module_graph()` is true. This is required for [JDK-8350550](https://bugs.openjdk.org/browse/JDK-8350550), as we need the `java.lang.Module` object for archived classes in the unnamed module of the boot loader prior to executing any Java code. We also archive the `ModuleEntry` objects for the 3 unnamed modules for uniformity, as these objects are already archived for named modules. ------------- Commit messages: - 8360555: Archive all unnamed modules in CDS full module graph Changes: https://git.openjdk.org/jdk/pull/26082/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26082&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8360555 Stats: 187 lines in 13 files changed: 140 ins; 17 del; 30 mod Patch: https://git.openjdk.org/jdk/pull/26082.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26082/head:pull/26082 PR: https://git.openjdk.org/jdk/pull/26082 From jpai at openjdk.org Wed Jul 2 01:38:55 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 2 Jul 2025 01:38:55 GMT Subject: [jdk25] RFR: 8359337: XML/JAXP tests that make network connections should ensure that no proxy is selected In-Reply-To: References: Message-ID: On Tue, 1 Jul 2025 11:48:30 GMT, Jaikiran Pai wrote: > Can I please get a review of this backport of a test-only fix? > > This backports the fix for https://bugs.openjdk.org/browse/JDK-8359337 into JDK 25. The original fix was integrated into mainline a few minutes back https://github.com/openjdk/jdk/pull/26052. Backporting this fix should help prevent failure of these tests on macOS hosts which have proxies configured. Thank you all for the reviews. tier1, tier2 and tier3 tests against JDK 25 with this backport went fine. I'll integrate this now. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26065#issuecomment-3026052859 From jpai at openjdk.org Wed Jul 2 01:38:56 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 2 Jul 2025 01:38:56 GMT Subject: [jdk25] Integrated: 8359337: XML/JAXP tests that make network connections should ensure that no proxy is selected In-Reply-To: References: Message-ID: On Tue, 1 Jul 2025 11:48:30 GMT, Jaikiran Pai wrote: > Can I please get a review of this backport of a test-only fix? > > This backports the fix for https://bugs.openjdk.org/browse/JDK-8359337 into JDK 25. The original fix was integrated into mainline a few minutes back https://github.com/openjdk/jdk/pull/26052. Backporting this fix should help prevent failure of these tests on macOS hosts which have proxies configured. This pull request has now been integrated. Changeset: 554e38dd Author: Jaikiran Pai URL: https://git.openjdk.org/jdk/commit/554e38dd5a9f804998021375acb3663ac0bb075d Stats: 128 lines in 5 files changed: 97 ins; 7 del; 24 mod 8359337: XML/JAXP tests that make network connections should ensure that no proxy is selected Reviewed-by: dfuchs, iris, joehw Backport-of: 7583a7b857da053c5e3770b680ab3494f1a6b66a ------------- PR: https://git.openjdk.org/jdk/pull/26065 From xgong at openjdk.org Wed Jul 2 01:54:50 2025 From: xgong at openjdk.org (Xiaohong Gong) Date: Wed, 2 Jul 2025 01:54:50 GMT Subject: RFR: 8355563: VectorAPI: Refactor current implementation of subword gather load API [v2] In-Reply-To: References: Message-ID: On Tue, 1 Jul 2025 18:03:33 GMT, Paul Sandoz wrote: > This is a nice simplification, Java changes look good. I'll let the Intel folks sign-off related to regressions. IMO minor regressions like this are acceptable if the generated code quality is good, and if the benchmark reports higher variance and averaging results from multiple forks close the gap. (In this case i don't understand how the Java changes impacts alignment). Thanks for your review and comments @PaulSandoz ! The java changes in this patch makes the outer loop in test not be peeled as before since all the range checks or branches are hoisted out side of the loop. While it needs one iteration of loop peeling to eliminate branches before. I think this makes the whole generated code's layout changes a lot. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25138#issuecomment-3026080127 From xgong at openjdk.org Wed Jul 2 01:54:51 2025 From: xgong at openjdk.org (Xiaohong Gong) Date: Wed, 2 Jul 2025 01:54:51 GMT Subject: RFR: 8355563: VectorAPI: Refactor current implementation of subword gather load API [v2] In-Reply-To: References: Message-ID: <7GrGfBF_v8F0v02sRHC78ofMZwpMdzQZaHeYlNvi_N0=.93defb9e-ca9b-41b4-8722-1746692e2316@github.com> On Tue, 1 Jul 2025 21:30:20 GMT, Sandhya Viswanathan wrote: > Agree with Paul, these are minor regressions. Let us proceed with this patch. Thanks so much for your review @sviswa7 ! ------------- PR Comment: https://git.openjdk.org/jdk/pull/25138#issuecomment-3026080679 From xgong at openjdk.org Wed Jul 2 02:39:33 2025 From: xgong at openjdk.org (Xiaohong Gong) Date: Wed, 2 Jul 2025 02:39:33 GMT Subject: RFR: 8359419: AArch64: Relax min vector length to 32-bit for short vectors [v2] In-Reply-To: References: Message-ID: > ### Background > On AArch64, the minimum vector length supported is 64-bit for basic types, except for `byte` and `boolean` (32-bit and 16-bit respectively to match special Vector API features). This limitation prevents intrinsification of vector type conversions between `short` and wider types (e.g. `long/double`) in Vector API when the entire vector length is within 128 bits, resulting in degraded performance for such conversions. > > For example, type conversions between `ShortVector.SPECIES_128` and `LongVector.SPECIES_128` are not supported on AArch64 NEON and SVE architectures with 128-bit max vector size. This occurs because the compiler would need to generate a vector with 2 short elements, resulting in a 32-bit vector size. > > To intrinsify such type conversion APIs, we need to relax the min vector length constraint from 64-bit to 32-bit for short vectors. > > ### Impact Analysis > #### 1. Vector types > Vectors only with `short` element types will be affected, as we just supported 32-bit `short` vectors in this change. > > #### 2. Vector API > No impact on Vector API or the vector-specific nodes. The minimum vector shape at API level remains 64-bit. It's not possible to generate a final vector IR with 32-bit vector size. Type conversions may generate intermediate 32-bit vectors, but they will be resized or cast to vectors with at least 64-bit length. > > #### 3. Auto-vectorization > Enables vectorization of cases containing only 2 `short` lanes, with significant performance improvements. Since we have supported 32-bit vectors for `byte` type for a long time, extending this to `short` did not introduce additional risks. > > #### 4. Codegen of vector nodes > NEON doesn't support 32-bit SIMD instructions, so we use 64-bit instructions instead. For lanewise operations, this is safe because the higher half bits can be ignored. > > Details: > - Lanewise vector operations are unaffected as explained above. > - NEON supports vector load/store instructions with 32-bit vector size, which we already use in relevant IRs (shared by SVE). > - Cross-lane operations like reduction may be affected, potentially causing incorrect results for `min/max/mul/and` reductions. The min vector size for such operations should remain 64-bit. We've added assertions in match rules. Since it's currently not possible to generate such reductions (Vector API minimum is 64-bit, and SLP doesn't support subword type reductions), we maintain the status quo. However, adding an explicit vector size check in `match_rule_s... Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision: Refine comments based on review suggestion ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26057/files - new: https://git.openjdk.org/jdk/pull/26057/files/5af5bd49..4e15e588 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26057&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26057&range=00-01 Stats: 9 lines in 3 files changed: 0 ins; 0 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/26057.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26057/head:pull/26057 PR: https://git.openjdk.org/jdk/pull/26057 From xgong at openjdk.org Wed Jul 2 02:39:34 2025 From: xgong at openjdk.org (Xiaohong Gong) Date: Wed, 2 Jul 2025 02:39:34 GMT Subject: RFR: 8359419: AArch64: Relax min vector length to 32-bit for short vectors In-Reply-To: References: Message-ID: <0PdYt-pCobM5mAb4q3nDcR9PKz89QVFCsZF-jnMAv4Q=.6a5d9f1f-8b68-448c-ab72-2f7f4a12322e@github.com> On Tue, 1 Jul 2025 05:59:15 GMT, Xiaohong Gong wrote: > ### Background > On AArch64, the minimum vector length supported is 64-bit for basic types, except for `byte` and `boolean` (32-bit and 16-bit respectively to match special Vector API features). This limitation prevents intrinsification of vector type conversions between `short` and wider types (e.g. `long/double`) in Vector API when the entire vector length is within 128 bits, resulting in degraded performance for such conversions. > > For example, type conversions between `ShortVector.SPECIES_128` and `LongVector.SPECIES_128` are not supported on AArch64 NEON and SVE architectures with 128-bit max vector size. This occurs because the compiler would need to generate a vector with 2 short elements, resulting in a 32-bit vector size. > > To intrinsify such type conversion APIs, we need to relax the min vector length constraint from 64-bit to 32-bit for short vectors. > > ### Impact Analysis > #### 1. Vector types > Vectors only with `short` element types will be affected, as we just supported 32-bit `short` vectors in this change. > > #### 2. Vector API > No impact on Vector API or the vector-specific nodes. The minimum vector shape at API level remains 64-bit. It's not possible to generate a final vector IR with 32-bit vector size. Type conversions may generate intermediate 32-bit vectors, but they will be resized or cast to vectors with at least 64-bit length. > > #### 3. Auto-vectorization > Enables vectorization of cases containing only 2 `short` lanes, with significant performance improvements. Since we have supported 32-bit vectors for `byte` type for a long time, extending this to `short` did not introduce additional risks. > > #### 4. Codegen of vector nodes > NEON doesn't support 32-bit SIMD instructions, so we use 64-bit instructions instead. For lanewise operations, this is safe because the higher half bits can be ignored. > > Details: > - Lanewise vector operations are unaffected as explained above. > - NEON supports vector load/store instructions with 32-bit vector size, which we already use in relevant IRs (shared by SVE). > - Cross-lane operations like reduction may be affected, potentially causing incorrect results for `min/max/mul/and` reductions. The min vector size for such operations should remain 64-bit. We've added assertions in match rules. Since it's currently not possible to generate such reductions (Vector API minimum is 64-bit, and SLP doesn't support subword type reductions), we maintain the status quo. However, adding an explicit vector size check in `match_rule_s... Hi @theRealAph , I'v updated the patch by fixing the comment issues. Could you please take a look at it again? Thanks a lot! ------------- PR Comment: https://git.openjdk.org/jdk/pull/26057#issuecomment-3026147575 From liangchenblue at gmail.com Wed Jul 2 02:49:44 2025 From: liangchenblue at gmail.com (Chen Liang) Date: Tue, 1 Jul 2025 21:49:44 -0500 Subject: Could ByteOrder be turned into an enum? In-Reply-To: <2493cf38-5324-408e-9912-202277c64b59@icemanx.nl> References: <2493cf38-5324-408e-9912-202277c64b59@icemanx.nl> Message-ID: Indeed, given that ByteOrder is more widely used and appears in many other APIs like FFM, it would be quite helpful to modernize it. There are other eligible candidates like CodingErrorAction, but their usages are more restricted to Buffer itself. On Tue, Jul 1, 2025 at 11:15?AM Rob Spoor wrote: > Hi all, > > I've been using ByteOrder quite a bit, but something that's always > annoyed me is that it's not an enum (because it predates them), and > therefore cannot be easily used in switch expressions or statements. For > instance, the closest I get is this, which still requires a default > statement: > > var i = switch (ByteOrder.nativeOrder()) { > case ByteOrder b when b.equals(ByteOrder.LITTLE_ENDIAN) -> 1; > case ByteOrder b when b.equals(ByteOrder.BIG_ENDIAN) -> 2; > default -> throw new IllegalStateException("not supported"); > }; > > I know that it's also possible to use a ternary expression, but that > depends on there never being a third value: > > var i = ByteOrder.nativeOrder().equals(ByteOrder.LITTLE_ENDIAN) > ? 1 : 2 > > > As a little proof-of-concept I created the enum below and checked the > signatures with javap. Apart from a different super class (Object -> > Enum) and the extra values() and valueOf(String) methods, the two have > the same fields, constructors and methods with the same signatures. And > it would allow us to use this shorter switch expression: > > var i = switch (ByteOrder.nativeOrder()) { > case LITTLE_ENDIAN -> 1; > case BIG_ENDIAN -> 2; > }; > > So my question is: are there technical limitations that would prevent > this change? > > > The enum I created: > > public enum ByteOrder { > > BIG_ENDIAN("BIG_ENDIAN"), > LITTLE_ENDIAN("LITTLE_ENDIAN"), > ; > > private final String name; > > ByteOrder(String name) { > this.name = name; > } > > private static final ByteOrder NATIVE_ORDER > = Unsafe.getUnsafe().isBigEndian() > ? ByteOrder.BIG_ENDIAN : ByteOrder.LITTLE_ENDIAN; > > public static ByteOrder nativeOrder() { > return NATIVE_ORDER; > } > > public String toString() { > return name; > } > } > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From iklam at openjdk.org Wed Jul 2 04:49:40 2025 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 2 Jul 2025 04:49:40 GMT Subject: RFR: 8360163: Create annotations to mark dumping method handles and runtime setup required classes [v5] In-Reply-To: References: Message-ID: On Tue, 1 Jul 2025 23:20:59 GMT, Chen Liang wrote: >> I have updated this patch to avoid a redundant `runtimeSetup` annotation - we have agreed that the requirement for setup is a side effect of initialization, and such methods in AOTCI classes must be automatically recognized. This latest revision implements that model. >> >> I intentionally avoided handling Class and ClassLoader `resetArchivedStates` and `MethodType::assemblySetup` - we talked about a generic `assemblyCleanup` method, but I did not find out where is the best place to call such a method in the assembly phase. We cna handle this in a subsequent patch. >> >> In particular, please review the new AOT.md design document - I split it from the AOTCI annotation to prevent jamming; we can put general AOT information there when we have more AOT-specific annotations. >> >> --- >> >> Old description: >> Currently, the list of classes that have interdependencies and those that need runtimeSetup are maintained in a hardcoded list in CDS. This makes it risky for core library developers as they might introduce new interdependencies and observe CDS to fail. By moving the mechanism of these lists to core library annotations as a first step, we can gradually expose the AOT contracts as program semantics described by internal annotations, and also helps us to explore how we can expose these functionalities to the public later. > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > Reviewed the diff on github Changes requested by iklam (Reviewer). src/hotspot/share/cds/aotClassInitializer.cpp line 41: > 39: > 40: // Tell if ik is marked as AOT initialization safe via @jdk.internal.vm.annotation.AOTSafeClassInitializer. > 41: bool AOTClassInitializer::allows_aot_initialization(InstanceKlass* ik) { Instead of doing the asserts here, I think the checks should be done in `ClassFileParser`: if a class is marked `@AOTSafeClassInitializer` annotation, then each of its supertypes must either be marked `@AOTSafeClassInitializer`, or have no ``. Otherwise an exception should be thrown (ClassFileFormatError??). This will be a good reminder that if you mark a class as `@AOTSafeClassInitializer`, you should check the `` of all of its supertypes. Then, this function can be removed, and the caller can call `ik->has_aot_safe_initializer()` directly. src/java.base/share/classes/java/lang/invoke/ClassSpecializer.java line 68: > 66: * @param species data type. > 67: */ > 68: @AOTSafeClassInitializer This should be placed below the `/*non-public*/` comment. src/java.base/share/classes/jdk/internal/vm/annotation/AOT.md line 47: > 45: because the result of loading an AOT cache must look like a valid, > 46: standard-conformant execution of the JVM. But a heap object with an > 47: uninitialized class is an impossibility within the JVMS. We should resolve the differences between this file and AOTSafeClassInitializer.java. The comments in the latter describes the current implementation, whereas this file describes what we want in the future. See https://github.com/openjdk/jdk/blob/7d7e60c8aebc4b4c1e7121be702393e5bc46e9ce/src/hotspot/share/cds/heapShared.cpp#L317-L331 In the current implementation, only the objects in the "special object graph" have their classes marked as "aot-initialized". The "special object graph" is described here: https://github.com/openjdk/jdk/blob/7d7e60c8aebc4b4c1e7121be702393e5bc46e9ce/src/hotspot/share/cds/heapShared.hpp#L274-L279 It essentially corresponds to the "objects directly or indirectly referenced by resolved constant pool entries" by the comments in AOTSafeClassInitializer.java. src/java.base/share/classes/jdk/internal/vm/annotation/AOTSafeClassInitializer.java line 53: > 51: /// entries when it's safe and beneficial to do so. > 52: /// > 53: /// An AOT-resolved constant pool entry for an invokedynamic or invokehandle bytecodes can bytecodes -> bytecode ------------- PR Review: https://git.openjdk.org/jdk/pull/25922#pullrequestreview-2977642139 PR Review Comment: https://git.openjdk.org/jdk/pull/25922#discussion_r2179033016 PR Review Comment: https://git.openjdk.org/jdk/pull/25922#discussion_r2179038052 PR Review Comment: https://git.openjdk.org/jdk/pull/25922#discussion_r2179049071 PR Review Comment: https://git.openjdk.org/jdk/pull/25922#discussion_r2179050047 From duke at openjdk.org Wed Jul 2 06:35:41 2025 From: duke at openjdk.org (ExE Boss) Date: Wed, 2 Jul 2025 06:35:41 GMT Subject: RFR: 8360884: Better scoped values [v4] In-Reply-To: References: <8yqi3J3JfLa2NNags9waBIshIMIuOJRjm-rHF--Wjws=.d04990af-5fdb-4218-a8da-60bda679b1d1@github.com> Message-ID: On Tue, 1 Jul 2025 15:41:45 GMT, Alan Bateman wrote: >> Andrew Haley has updated the pull request incrementally with two additional commits since the last revision: >> >> - 8360884: Better scoped values >> - 8360884: Better scoped values > > src/java.base/share/classes/java/lang/ScopedValue.java line 534: > >> 532: >> 533: private ScopedValue() { >> 534: this.hash = hashGenerator != null ? hashGenerator.getAsInt() : generateKey(); > > The updated version looks much better. It might just a bit clearer to read hashGenerator once here (it doesn't matter of course but stable fields tend to attract a lot of questions). Something like?this? Suggestion: final IntSupplier hashGen = hashGenerator; this.hash = hashGen != null ? hashGen.getAsInt() : generateKey(); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26019#discussion_r2179229055 From djelinski at openjdk.org Wed Jul 2 07:51:01 2025 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Wed, 2 Jul 2025 07:51:01 GMT Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API [v9] In-Reply-To: References: Message-ID: On Fri, 27 Jun 2025 13:21:12 GMT, Daniel Fuchs wrote: >> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 525 commits: >> >> - merge latest changes from master branch >> - http3: run H3StreamLimitReachedTest.java with -Djdk.httpclient.http3.maxStreamLimitTimeout=0 too >> - retry the ResetControlStream test as needed >> - http3: fix pending connection and reconnection on stream limit reached logic >> - http3: pending acknowledgement should be registered before actually sending the packet >> - http3: fix race with ping requests in PacketSpaceManager.java causing intermittent failures in H3ErrorHandlingTest.java >> - http3: improve exceptions in Http3ServerExchange.java >> - http3: fix exception handling in CancelRequestTest.java >> - http3: review feedback - revert HPACK.java >> - Implement X509TrustManagerImpl#checkClientTrusted for QUIC >> - ... and 515 more: https://git.openjdk.org/jdk/compare/5a1301df...0229c215 > > src/java.base/share/classes/sun/security/ssl/X509Authentication.java line 224: > >> 222: // TODO in future, when QuicTLSEngine might become a public exported interface >> 223: // we should have a method on javax.net.ssl.X509ExtendedKeyManager that >> 224: // takes QuicTLSEngine. > > Suggestion: > > // TODO in future, if QuicTLSEngine ever becomes a public exported interface > // we might have a method on javax.net.ssl.X509ExtendedKeyManager that > // takes QuicTLSEngine. Maybe we could stop guessing the future, and use this instead: Suggestion: // TODO add a method on javax.net.ssl.X509ExtendedKeyManager that // takes QuicTLSEngine. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2179367158 From adinn at openjdk.org Wed Jul 2 07:51:39 2025 From: adinn at openjdk.org (Andrew Dinn) Date: Wed, 2 Jul 2025 07:51:39 GMT Subject: RFR: 8360163: Create annotations to mark dumping method handles and runtime setup required classes [v5] In-Reply-To: References: Message-ID: On Wed, 2 Jul 2025 04:38:50 GMT, Ioi Lam wrote: >> Chen Liang has updated the pull request incrementally with one additional commit since the last revision: >> >> Reviewed the diff on github > > src/java.base/share/classes/java/lang/invoke/ClassSpecializer.java line 68: > >> 66: * @param species data type. >> 67: */ >> 68: @AOTSafeClassInitializer > > This should be placed below the `/*non-public*/` comment. Perhaps also the same for BoundMethodHandle? and others? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25922#discussion_r2179368175 From adinn at openjdk.org Wed Jul 2 08:10:46 2025 From: adinn at openjdk.org (Andrew Dinn) Date: Wed, 2 Jul 2025 08:10:46 GMT Subject: RFR: 8360163: Create annotations to mark dumping method handles and runtime setup required classes [v5] In-Reply-To: References: Message-ID: On Tue, 1 Jul 2025 23:20:59 GMT, Chen Liang wrote: >> I have updated this patch to avoid a redundant `runtimeSetup` annotation - we have agreed that the requirement for setup is a side effect of initialization, and such methods in AOTCI classes must be automatically recognized. This latest revision implements that model. >> >> I intentionally avoided handling Class and ClassLoader `resetArchivedStates` and `MethodType::assemblySetup` - we talked about a generic `assemblyCleanup` method, but I did not find out where is the best place to call such a method in the assembly phase. We cna handle this in a subsequent patch. >> >> In particular, please review the new AOT.md design document - I split it from the AOTCI annotation to prevent jamming; we can put general AOT information there when we have more AOT-specific annotations. >> >> --- >> >> Old description: >> Currently, the list of classes that have interdependencies and those that need runtimeSetup are maintained in a hardcoded list in CDS. This makes it risky for core library developers as they might introduce new interdependencies and observe CDS to fail. By moving the mechanism of these lists to core library annotations as a first step, we can gradually expose the AOT contracts as program semantics described by internal annotations, and also helps us to explore how we can expose these functionalities to the public later. > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > Reviewed the diff on github src/java.base/share/classes/jdk/internal/vm/annotation/AOT.md line 67: > 65: only the data images created by such threads. > 66: > 67: Therefore, if a class A is marked `AOTClassInitializer`, and it has This mentions the annotation without saying what it is or how it relates to the preceding discussion. Can we maybe introduce it at this point? Something like this: "Annotation `AOTClassInitializer` is provided to declare that a specific JDK class's metadata, its class mirror and, potentially, its instances can safely be included in an AOT cache. If a class A is marked ..." ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25922#discussion_r2179407537 From aph at openjdk.org Wed Jul 2 08:18:44 2025 From: aph at openjdk.org (Andrew Haley) Date: Wed, 2 Jul 2025 08:18:44 GMT Subject: RFR: 8359419: AArch64: Relax min vector length to 32-bit for short vectors [v2] In-Reply-To: References: Message-ID: On Wed, 2 Jul 2025 02:39:33 GMT, Xiaohong Gong wrote: >> ### Background >> On AArch64, the minimum vector length supported is 64-bit for basic types, except for `byte` and `boolean` (32-bit and 16-bit respectively to match special Vector API features). This limitation prevents intrinsification of vector type conversions between `short` and wider types (e.g. `long/double`) in Vector API when the entire vector length is within 128 bits, resulting in degraded performance for such conversions. >> >> For example, type conversions between `ShortVector.SPECIES_128` and `LongVector.SPECIES_128` are not supported on AArch64 NEON and SVE architectures with 128-bit max vector size. This occurs because the compiler would need to generate a vector with 2 short elements, resulting in a 32-bit vector size. >> >> To intrinsify such type conversion APIs, we need to relax the min vector length constraint from 64-bit to 32-bit for short vectors. >> >> ### Impact Analysis >> #### 1. Vector types >> Vectors only with `short` element types will be affected, as we just supported 32-bit `short` vectors in this change. >> >> #### 2. Vector API >> No impact on Vector API or the vector-specific nodes. The minimum vector shape at API level remains 64-bit. It's not possible to generate a final vector IR with 32-bit vector size. Type conversions may generate intermediate 32-bit vectors, but they will be resized or cast to vectors with at least 64-bit length. >> >> #### 3. Auto-vectorization >> Enables vectorization of cases containing only 2 `short` lanes, with significant performance improvements. Since we have supported 32-bit vectors for `byte` type for a long time, extending this to `short` did not introduce additional risks. >> >> #### 4. Codegen of vector nodes >> NEON doesn't support 32-bit SIMD instructions, so we use 64-bit instructions instead. For lanewise operations, this is safe because the higher half bits can be ignored. >> >> Details: >> - Lanewise vector operations are unaffected as explained above. >> - NEON supports vector load/store instructions with 32-bit vector size, which we already use in relevant IRs (shared by SVE). >> - Cross-lane operations like reduction may be affected, potentially causing incorrect results for `min/max/mul/and` reductions. The min vector size for such operations should remain 64-bit. We've added assertions in match rules. Since it's currently not possible to generate such reductions (Vector API minimum is 64-bit, and SLP doesn't support subword type reductions), we maintain the status quo. However, addin... > > Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision: > > Refine comments based on review suggestion src/hotspot/cpu/aarch64/aarch64.ad line 2367: > 2365: // Theoretically, the minimal vector length supported by AArch64 > 2366: // ISA and Vector API species is 64-bit. However, 32-bit or 16-bit > 2367: // vector length is also allowed for special Vector API usages. Suggestion: // Usually, the shortest vector length supported by AArch64 // ISA and Vector API species is 64 bits. However, we allow // 32-bit or 16-bit vectors in a few special cases. Reason for change: it wasn't clear what "supported" meant. Supported by the hardware, or by HotSpot. And why do we only support it in a few special cases? This comment raises more questions than it answers. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26057#discussion_r2179423549 From epeter at openjdk.org Wed Jul 2 08:26:46 2025 From: epeter at openjdk.org (Emanuel Peter) Date: Wed, 2 Jul 2025 08:26:46 GMT Subject: RFR: 8355563: VectorAPI: Refactor current implementation of subword gather load API [v2] In-Reply-To: <7GrGfBF_v8F0v02sRHC78ofMZwpMdzQZaHeYlNvi_N0=.93defb9e-ca9b-41b4-8722-1746692e2316@github.com> References: <7GrGfBF_v8F0v02sRHC78ofMZwpMdzQZaHeYlNvi_N0=.93defb9e-ca9b-41b4-8722-1746692e2316@github.com> Message-ID: On Wed, 2 Jul 2025 01:52:19 GMT, Xiaohong Gong wrote: >> Agree with Paul, these are minor regressions. Let us proceed with this patch. > >> Agree with Paul, these are minor regressions. Let us proceed with this patch. > > Thanks so much for your review @sviswa7 ! @XiaohongGong I quickly scanned the patch, it looks good to me too. I'm submitting some internal testing now, to make sure our extended testing does not break on integration. Should take about 24h. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25138#issuecomment-3026931008 From duke at openjdk.org Wed Jul 2 08:31:45 2025 From: duke at openjdk.org (David Beaumont) Date: Wed, 2 Jul 2025 08:31:45 GMT Subject: RFR: 8360037: Refactor ImageReader in preparation for Valhalla support [v3] In-Reply-To: References: Message-ID: <_pByqz5D9z7RxpOx3JcGEwMsZ6qbW5BtE7FNb-liazQ=.c8b05e3a-13dd-4af4-9b64-2e9bae1cc40f@github.com> On Tue, 1 Jul 2025 14:29:51 GMT, Alan Bateman wrote: >> David Beaumont has updated the pull request incrementally with one additional commit since the last revision: >> >> Feedback changes. >> >> * Making some simple tests parametrized. >> * Revert change to JImageReadTest (it passes either way, so keep it simple). > > test/micro/org/openjdk/bench/jdk/internal/jrtfs/ImageReaderBenchmark.java line 60: > >> 58: @OutputTimeUnit(TimeUnit.MILLISECONDS) >> 59: @Fork(value = 1, jvmArgs = {"--add-exports", "java.base/jdk.internal.jimage=ALL-UNNAMED"}) >> 60: public class ImageReaderBenchmark { > > This is the benchmark from the other PR, did you mean to include it? Yes, because the API changed. Once the other PR is merged this will just show the diffs (github is refusing to show just the diffs even though I told it to use the other PR). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26054#discussion_r2179452274 From duke at openjdk.org Wed Jul 2 08:38:46 2025 From: duke at openjdk.org (David Beaumont) Date: Wed, 2 Jul 2025 08:38:46 GMT Subject: RFR: 8360037: Refactor ImageReader in preparation for Valhalla support [v4] In-Reply-To: References: Message-ID: On Tue, 1 Jul 2025 18:30:56 GMT, Roger Riggs wrote: >> David Beaumont has updated the pull request incrementally with one additional commit since the last revision: >> >> Small feedback related tweaks. > > src/java.base/share/classes/jdk/internal/jimage/ImageReader.java line 555: > >> 553: >> 554: /** >> 555: * Returns the JRY file system compatible name of this node (e.g. > > Typo: "JRY" Done. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26054#discussion_r2179459480 From duke at openjdk.org Wed Jul 2 08:38:40 2025 From: duke at openjdk.org (David Beaumont) Date: Wed, 2 Jul 2025 08:38:40 GMT Subject: RFR: 8360037: Refactor ImageReader in preparation for Valhalla support [v4] In-Reply-To: References: Message-ID: > Refactoring `ImageReader` to make it easy to add preview mode functionality for Valhalla. > > This PR is a large change to `ImageReader` (effectively a rewrite) but reduces the surface area of the API significantly, reduces code complexity and increases performance/memory efficiency. The need for this sort of change comes from the need to support "preview mode" in Valhalla for classes loaded from core modules. > > ### Preview Mode > > In the proposed preview mode support for Valhalla, a resource with the name `/modules//` may come from one of two locations in the underlying jimage file; `//` or `//META-INF/preview/`. Furthermore, directories (represented as directory nodes via the API) will have a potentially different number of child nodes depending on whether preview mode is in effect, and some directories may only exist at all in preview mode. > > Furthermore, the directories and symbolic link nodes in `/packages/...` will also be affected by the existence of new package directories. To retain consistency and avoid "surprises" later, all of this needs to be taken into account. > > Below is a summary of the main changes for mainline JDK to better support preview mode later: > > ### 1: Improved encapsulation for preview mode > > The current `ImageReader` code exposes the data from the jimage file in several ways; via the `Node` abstraction, but also with methods which return an `ImageLocation` instance directly. In preview mode it would not be acceptable to return the `ImageLocation`, since that would leak the existence of resources in the `META-INF/preview` namespace and lets users see resource nodes with names that don't match the underlying `ImageLocation` from which their contents come. > > As such, the PR removes all methods which can leak `ImageLocation` or other "underlying" semantics about the jimage file. Luckily most of these are either used minimally and easily migrated to using nodes, or they were not being used at all. This PR also removes any methods which were already unused across the OpenJDK codebase (if I discover any issues with over-trimming of the API during full CI testing, it will be easy to address). > > ### 2. Simplification of directory child node handling > > The current `ImageReader` code attempts to create parent directories "on demand" for any child nodes it creates. This results in parent directories having a non-empty but incomplete set of child nodes present. This is referred to as the directory being "incomple... David Beaumont has updated the pull request incrementally with one additional commit since the last revision: Small feedback related tweaks. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26054/files - new: https://git.openjdk.org/jdk/pull/26054/files/9d9e62ba..a8b68c7b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26054&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26054&range=02-03 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/26054.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26054/head:pull/26054 PR: https://git.openjdk.org/jdk/pull/26054 From duke at openjdk.org Wed Jul 2 08:38:43 2025 From: duke at openjdk.org (David Beaumont) Date: Wed, 2 Jul 2025 08:38:43 GMT Subject: RFR: 8360037: Refactor ImageReader in preparation for Valhalla support [v4] In-Reply-To: References: Message-ID: On Tue, 1 Jul 2025 14:32:41 GMT, ExE Boss wrote: >> David Beaumont has updated the pull request incrementally with one additional commit since the last revision: >> >> Small feedback related tweaks. > > src/java.base/share/classes/jdk/internal/jimage/ImageReader.java line 207: > >> 205: this.nodes = new HashMap<>(); >> 206: // TODO (review note): These should exist under all circumstances, but there's >> 207: // probably a more robust way of getting it these offsets. > > Suggestion: > > // probably a more robust way of getting these offsets. Done. > src/java.base/share/classes/jdk/internal/jimage/ImageReader.java line 211: > >> 209: this.packagesStringOffset = findLocation("/packages/java.lang").getModuleOffset(); >> 210: >> 211: // Node creation is very lazy, se can just make the top-level directories > > Typo: > Suggestion: > > // Node creation is very lazy, so can just make the top-level directories Done. > src/java.base/share/classes/jdk/internal/jimage/ImageReader.java line 544: > >> 542: >> 543: // A node is completed when all its direct children have been built. As >> 544: // such, non-directory nodes are always complete. > > I?think this?might flow?better: > Suggestion: > > // A node is completed when all its direct children have been built. > // As such, non-directory nodes are always complete. Done. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26054#discussion_r2179459970 PR Review Comment: https://git.openjdk.org/jdk/pull/26054#discussion_r2179460025 PR Review Comment: https://git.openjdk.org/jdk/pull/26054#discussion_r2179459756 From swen at openjdk.org Wed Jul 2 08:52:43 2025 From: swen at openjdk.org (Shaojin Wen) Date: Wed, 2 Jul 2025 08:52:43 GMT Subject: RFR: 8361018: Re-examine buffering and encoding conversion in BufferedWriter [v6] In-Reply-To: References: Message-ID: On Tue, 1 Jul 2025 00:01:21 GMT, Shaojin Wen wrote: >> BufferedWriter -> OutputStreamWriter -> StreamEncoder >> >> In this call chain, BufferedWriter has a char[] buffer, and StreamEncoder has a ByteBuffer. There are two layers of cache here, or the BufferedWriter layer can be removed. And when charset is UTF8, if the content of write(String) is LATIN1, a conversion from LATIN1 to UTF16 and then to LATIN1 will occur here. >> >> LATIN1 -> UTF16 -> UTF8 >> >> We can improve BufferedWriter. When the parameter Writer instanceof OutputStreamWriter is passed in, remove the cache and call it directly. In addition, improve write(String) in StreamEncoder to avoid unnecessary encoding conversion. > > Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: > > Revert "BufferedWriter buffer use StringBuilder" > > This reverts commit da902ca0b0bd6acc003deb8ad1ca0d6485a29a27. According to the suggestions of liach and xx, I added the improvement research of BufferedWriter using StringBuilder as buffer + ArrayEncoder to the current PR, which can have a good performance improvement in non-UTF8 scenarios. The code is this branch: https://github.com/wenshao/jdk/tree/utf8_writer_202506_x4 There are a lot of code changes, which should be another PR. git remote add wenshao git at github.com:wenshao/jdk.git git fetch wenshao ## Baseline # https://github.com/wenshao/jdk/tree/utf8_writer_202506_test git checkout 2758d6ad7767832db004d28f10cc764f33fa438e make test TEST="micro:java.io.BufferedWriterBench" MICRO="OPTIONS=-p charset=ISO_8859_1,ASCII,UTF8,UTF16,GB18030 # Current (PR 26022 & BufferedWriter use StringBuilder as buffer) # https://github.com/wenshao/jdk/tree/utf8_writer_202506_x4 git checkout 77c5996b6a7b7ea74d03b64c4c8e827a7d76f05a make test TEST="micro:java.io.BufferedWriterBench" MICRO="OPTIONS=-p charset=ISO_8859_1,ASCII,UTF8,UTF16,GB18030 ## Benchmark Numbers on Aliyun ECS c9i (Intel x64 CPU) Benchmark (charType) (charset) Units Base_Score Current_Score Improvement(%) writeCharArray ascii ISO_8859_1 us/op 3.128 3.027 +3.23% writeCharArray ascii ASCII us/op 3.126 3.351 -6.88% writeCharArray ascii UTF8 us/op 3.125 3.716 -18.91% writeCharArray ascii UTF16 us/op 32.469 11.404 +64.87% writeCharArray ascii GB18030 us/op 9.642 7.296 +24.34% writeCharArray utf8_2_bytes ISO_8859_1 us/op 3.137 3.016 +3.86% writeCharArray utf8_2_bytes ASCII us/op 96.779 8.725 +90.99% writeCharArray utf8_2_bytes UTF8 us/op 17.346 12.966 +25.25% writeCharArray utf8_2_bytes UTF16 us/op 32.407 11.267 +65.19% writeCharArray utf8_2_bytes GB18030 us/op 82.994 12.401 +85.14% writeCharArray utf8_3_bytes ISO_8859_1 us/op 100.063 7.486 +92.51% writeCharArray utf8_3_bytes ASCII us/op 96.061 9.236 +90.40% writeCharArray utf8_3_bytes UTF8 us/op 28.340 13.358 +52.86% writeCharArray utf8_3_bytes UTF16 us/op 32.468 11.785 +63.70% writeCharArray utf8_3_bytes GB18030 us/op 40.864 37.012 +9.66% writeCharArray emoji ISO_8859_1 us/op 190.547 10.149 +94.67% writeCharArray emoji ASCII us/op 187.803 12.774 +93.17% writeCharArray emoji UTF8 us/op 41.493 23.473 +43.49% writeCharArray emoji UTF16 us/op 48.248 16.227 +66.36% writeCharArray emoji GB18030 us/op 147.360 63.437 +57.01% writeString ascii ISO_8859_1 us/op 3.340 2.770 +17.09% writeString ascii ASCII us/op 3.340 3.069 +8.11% writeString ascii UTF8 us/op 3.324 2.944 +11.43% writeString ascii UTF16 us/op 32.503 11.214 +65.49% writeString ascii GB18030 us/op 9.023 6.999 +22.43% writeString utf8_2_bytes ISO_8859_1 us/op 3.338 2.827 +15.31% writeString utf8_2_bytes ASCII us/op 95.964 8.542 +91.10% writeString utf8_2_bytes UTF8 us/op 17.660 10.155 +42.44% writeString utf8_2_bytes UTF16 us/op 32.516 11.173 +65.63% writeString utf8_2_bytes GB18030 us/op 82.369 12.231 +85.14% writeString utf8_3_bytes ISO_8859_1 us/op 100.280 7.363 +92.66% writeString utf8_3_bytes ASCII us/op 95.279 9.060 +90.48% writeString utf8_3_bytes UTF8 us/op 28.344 18.366 +35.19% writeString utf8_3_bytes UTF16 us/op 32.672 11.284 +65.43% writeString utf8_3_bytes GB18030 us/op 43.798 37.145 +15.16% writeString emoji ISO_8859_1 us/op 189.574 9.904 +94.75% writeString emoji ASCII us/op 187.021 12.427 +93.35% writeString emoji UTF8 us/op 41.775 25.875 +37.98% writeString emoji UTF16 us/op 48.240 15.696 +67.10% writeString emoji GB18030 us/op 147.097 63.587 +56.78% ## Benchmark Numbers on MacBook M1 Pro (aarch64) Benchmark (charType) (charset) Units Base_Score Current_Score Improvement(%) BufferedWriterBench.writeCharArray ascii ISO_8859_1 us/op 2.815 2.133 +24.20% BufferedWriterBench.writeCharArray ascii ASCII us/op 2.742 2.352 +14.22% BufferedWriterBench.writeCharArray ascii UTF8 us/op 2.704 2.616 +3.25% BufferedWriterBench.writeCharArray ascii UTF16 us/op 31.294 8.489 +72.87% BufferedWriterBench.writeCharArray ascii GB18030 us/op 8.932 3.820 +57.20% BufferedWriterBench.writeCharArray utf8_2_bytes ISO_8859_1 us/op 2.828 2.210 +21.85% BufferedWriterBench.writeCharArray utf8_2_bytes ASCII us/op 109.255 5.669 +94.80% BufferedWriterBench.writeCharArray utf8_2_bytes UTF8 us/op 22.353 14.039 +37.15% BufferedWriterBench.writeCharArray utf8_2_bytes UTF16 us/op 31.268 8.349 +73.28% BufferedWriterBench.writeCharArray utf8_2_bytes GB18030 us/op 90.835 6.816 +92.50% BufferedWriterBench.writeCharArray utf8_3_bytes ISO_8859_1 us/op 109.734 7.834 +92.88% BufferedWriterBench.writeCharArray utf8_3_bytes ASCII us/op 106.981 7.906 +92.60% BufferedWriterBench.writeCharArray utf8_3_bytes UTF8 us/op 21.453 16.076 +25.07% BufferedWriterBench.writeCharArray utf8_3_bytes UTF16 us/op 31.294 6.945 +77.75% BufferedWriterBench.writeCharArray utf8_3_bytes GB18030 us/op 49.007 27.891 +43.02% BufferedWriterBench.writeCharArray emoji ISO_8859_1 us/op 223.538 11.189 +94.54% BufferedWriterBench.writeCharArray emoji ASCII us/op 264.875 11.384 +95.69% BufferedWriterBench.writeCharArray emoji UTF8 us/op 35.704 21.672 +39.29% BufferedWriterBench.writeCharArray emoji UTF16 us/op 45.979 11.255 +75.51% BufferedWriterBench.writeCharArray emoji GB18030 us/op 148.829 57.625 +61.33% BufferedWriterBench.writeString ascii ISO_8859_1 us/op 2.898 2.159 +25.49% BufferedWriterBench.writeString ascii ASCII us/op 2.876 2.591 +9.91% BufferedWriterBench.writeString ascii UTF8 us/op 2.894 2.466 +14.79% BufferedWriterBench.writeString ascii UTF16 us/op 31.236 8.759 +71.82% BufferedWriterBench.writeString ascii GB18030 us/op 9.010 3.899 +56.70% BufferedWriterBench.writeString utf8_2_bytes ISO_8859_1 us/op 2.894 2.178 +24.71% BufferedWriterBench.writeString utf8_2_bytes ASCII us/op 108.426 5.611 +94.82% BufferedWriterBench.writeString utf8_2_bytes UTF8 us/op 22.206 12.225 +44.93% BufferedWriterBench.writeString utf8_2_bytes UTF16 us/op 31.305 8.773 +71.98% BufferedWriterBench.writeString utf8_2_bytes GB18030 us/op 90.820 6.907 +92.40% BufferedWriterBench.writeString utf8_3_bytes ISO_8859_1 us/op 108.983 7.931 +92.66% BufferedWriterBench.writeString utf8_3_bytes ASCII us/op 107.064 7.836 +92.66% BufferedWriterBench.writeString utf8_3_bytes UTF8 us/op 21.664 13.102 +39.47% BufferedWriterBench.writeString utf8_3_bytes UTF16 us/op 31.546 6.930 +78.00% BufferedWriterBench.writeString utf8_3_bytes GB18030 us/op 52.688 27.698 +47.17% BufferedWriterBench.writeString emoji ISO_8859_1 us/op 221.930 11.160 +94.95% BufferedWriterBench.writeString emoji ASCII us/op 236.791 11.116 +95.30% BufferedWriterBench.writeString emoji UTF8 us/op 35.025 23.210 +33.73% BufferedWriterBench.writeString emoji UTF16 us/op 45.988 11.334 +75.32% BufferedWriterBench.writeString emoji GB18030 us/op 148.202 57.472 +61.23% ------------- PR Comment: https://git.openjdk.org/jdk/pull/26022#issuecomment-3027011273 From xgong at openjdk.org Wed Jul 2 08:59:47 2025 From: xgong at openjdk.org (Xiaohong Gong) Date: Wed, 2 Jul 2025 08:59:47 GMT Subject: RFR: 8355563: VectorAPI: Refactor current implementation of subword gather load API [v2] In-Reply-To: <7GrGfBF_v8F0v02sRHC78ofMZwpMdzQZaHeYlNvi_N0=.93defb9e-ca9b-41b4-8722-1746692e2316@github.com> References: <7GrGfBF_v8F0v02sRHC78ofMZwpMdzQZaHeYlNvi_N0=.93defb9e-ca9b-41b4-8722-1746692e2316@github.com> Message-ID: On Wed, 2 Jul 2025 01:52:19 GMT, Xiaohong Gong wrote: >> Agree with Paul, these are minor regressions. Let us proceed with this patch. > >> Agree with Paul, these are minor regressions. Let us proceed with this patch. > > Thanks so much for your review @sviswa7 ! > @XiaohongGong I quickly scanned the patch, it looks good to me too. I'm submitting some internal testing now, to make sure our extended testing does not break on integration. Should take about 24h. Good to know that. Thanks so much for your testing @eme64 ! ------------- PR Comment: https://git.openjdk.org/jdk/pull/25138#issuecomment-3027032342 From xgong at openjdk.org Wed Jul 2 09:02:46 2025 From: xgong at openjdk.org (Xiaohong Gong) Date: Wed, 2 Jul 2025 09:02:46 GMT Subject: RFR: 8359419: AArch64: Relax min vector length to 32-bit for short vectors [v2] In-Reply-To: References: Message-ID: On Wed, 2 Jul 2025 08:15:34 GMT, Andrew Haley wrote: >> Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision: >> >> Refine comments based on review suggestion > > src/hotspot/cpu/aarch64/aarch64.ad line 2367: > >> 2365: // Theoretically, the minimal vector length supported by AArch64 >> 2366: // ISA and Vector API species is 64-bit. However, 32-bit or 16-bit >> 2367: // vector length is also allowed for special Vector API usages. > > Suggestion: > > // Usually, the shortest vector length supported by AArch64 > // ISA and Vector API species is 64 bits. However, we allow > // 32-bit or 16-bit vectors in a few special cases. > > > Reason for change: it wasn't clear what "supported" meant. Supported by the hardware, or by HotSpot. And why do we only support it in a few special cases? This comment raises more questions than it answers. Thanks so much for your suggestion! Looks better to me. I will update soon. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26057#discussion_r2179517582 From kevinw at openjdk.org Wed Jul 2 09:04:51 2025 From: kevinw at openjdk.org (Kevin Walls) Date: Wed, 2 Jul 2025 09:04:51 GMT Subject: [jdk25] RFR: 8359870: JVM crashes in AccessInternal::PostRuntimeDispatch Message-ID: Clean backport to JDK 25. This change recently integrated in JDK 26 and is through tiers 1 - 4 so far. ------------- Commit messages: - Backport 13a3927855da61fe27f3b43e5e4755d0c5ac5a16 Changes: https://git.openjdk.org/jdk/pull/26088/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26088&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8359870 Stats: 32 lines in 5 files changed: 22 ins; 2 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/26088.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26088/head:pull/26088 PR: https://git.openjdk.org/jdk/pull/26088 From rgiulietti at openjdk.org Wed Jul 2 09:55:41 2025 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Wed, 2 Jul 2025 09:55:41 GMT Subject: RFR: 8334015: Add Support for UUID Version 7 (UUIDv7) defined in RFC 9562 [v10] In-Reply-To: References: <4b4eB1IhNlZXMVqf-aOj-IIp3kwLiqOVfeqioc2dL9Q=.8af3f74b-7b61-424a-b2c6-421fa6e0c0e6@github.com> Message-ID: On Tue, 1 Jul 2025 15:20:07 GMT, Jaikiran Pai wrote: >> The uniqueness comes not just from the timestamp but also from the random data in the other bytes that are generated for each new UUID. > > Hello Roger, that's true about the uniqueness semantics. However, from what I understand of RFC-9562, on which this new API is based, I think it has much stricter expectations about monotonocity (the first 48 bits) too. For example, the following sections: > > https://www.rfc-editor.org/rfc/rfc9562.html#name-timestamp-considerations > https://www.rfc-editor.org/rfc/rfc9562.html#name-monotonicity-and-counters Indeed, the sections of the RFC mentioned by @jaikiran do require timestamps to be (strictly) monotonic. The method `monotonicMS()` does not fulfill this requirement. There are some methods described in ?6.2 to help ensuring monotonicity. While it is true that the 74 bits of randomness help in creating unique ID with high probability, the requirements for the timestamp part in UUID Version 7 seem more restrictive than just uniqueness. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25303#discussion_r2179634215 From kfarrell at openjdk.org Wed Jul 2 10:11:39 2025 From: kfarrell at openjdk.org (Kieran Farrell) Date: Wed, 2 Jul 2025 10:11:39 GMT Subject: RFR: 8334015: Add Support for UUID Version 7 (UUIDv7) defined in RFC 9562 [v10] In-Reply-To: References: <4b4eB1IhNlZXMVqf-aOj-IIp3kwLiqOVfeqioc2dL9Q=.8af3f74b-7b61-424a-b2c6-421fa6e0c0e6@github.com> Message-ID: On Wed, 2 Jul 2025 09:52:54 GMT, Raffaello Giulietti wrote: >> Hello Roger, that's true about the uniqueness semantics. However, from what I understand of RFC-9562, on which this new API is based, I think it has much stricter expectations about monotonocity (the first 48 bits) too. For example, the following sections: >> >> https://www.rfc-editor.org/rfc/rfc9562.html#name-timestamp-considerations >> https://www.rfc-editor.org/rfc/rfc9562.html#name-monotonicity-and-counters > > Indeed, the sections of the RFC mentioned by @jaikiran do require timestamps to be (strictly) monotonic. The method `monotonicMS()` does not fulfill this requirement. There are some methods described in ?6.2 to help ensuring monotonicity. > > While it is true that the 74 bits of randomness help in creating unique ID with high probability, the requirements for the timestamp part in UUID Version 7 seem more restrictive than just uniqueness. Hi Jaikiran, You are correct in that the current implementation only supports uniqueness among time clashes and not monotonicity. Although section 5.7 UUID version 7 states that adding monotonic or extra precision bits is optional and that the millisecond portion along with the random bits is sufficient, section 6.2 does state: > Take care to ensure UUIDs generated in batches are also monotonic. That is, if one thousand UUIDs are generated for the same timestamp, there should be sufficient logic for organizing the creation order of those one thousand UUIDs The use of 'should' here makes it seem like this is a strong recommendation rather than a mandate. Regardless, it might be benifical to better satisfy this guidance. Since we don't currently have access to higher precision time, updating the implementation to include a dedicated counter would be the only viable approach, and comes at the cost of performance. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25303#discussion_r2179666440 From duke at openjdk.org Wed Jul 2 10:30:49 2025 From: duke at openjdk.org (David Beaumont) Date: Wed, 2 Jul 2025 10:30:49 GMT Subject: RFR: 8360037: Refactor ImageReader in preparation for Valhalla support [v4] In-Reply-To: References: Message-ID: On Wed, 2 Jul 2025 08:38:40 GMT, David Beaumont wrote: >> Refactoring `ImageReader` to make it easy to add preview mode functionality for Valhalla. >> >> This PR is a large change to `ImageReader` (effectively a rewrite) but reduces the surface area of the API significantly, reduces code complexity and increases performance/memory efficiency. The need for this sort of change comes from the need to support "preview mode" in Valhalla for classes loaded from core modules. >> >> ### Preview Mode >> >> In the proposed preview mode support for Valhalla, a resource with the name `/modules//` may come from one of two locations in the underlying jimage file; `//` or `//META-INF/preview/`. Furthermore, directories (represented as directory nodes via the API) will have a potentially different number of child nodes depending on whether preview mode is in effect, and some directories may only exist at all in preview mode. >> >> Furthermore, the directories and symbolic link nodes in `/packages/...` will also be affected by the existence of new package directories. To retain consistency and avoid "surprises" later, all of this needs to be taken into account. >> >> Below is a summary of the main changes for mainline JDK to better support preview mode later: >> >> ### 1: Improved encapsulation for preview mode >> >> The current `ImageReader` code exposes the data from the jimage file in several ways; via the `Node` abstraction, but also with methods which return an `ImageLocation` instance directly. In preview mode it would not be acceptable to return the `ImageLocation`, since that would leak the existence of resources in the `META-INF/preview` namespace and lets users see resource nodes with names that don't match the underlying `ImageLocation` from which their contents come. >> >> As such, the PR removes all methods which can leak `ImageLocation` or other "underlying" semantics about the jimage file. Luckily most of these are either used minimally and easily migrated to using nodes, or they were not being used at all. This PR also removes any methods which were already unused across the OpenJDK codebase (if I discover any issues with over-trimming of the API during full CI testing, it will be easy to address). >> >> ### 2. Simplification of directory child node handling >> >> The current `ImageReader` code attempts to create parent directories "on demand" for any child nodes it creates. This results in parent directories having a non-empty but incomplete set of child nodes present. This is re... > > David Beaumont has updated the pull request incrementally with one additional commit since the last revision: > > Small feedback related tweaks. Latest changes uploaded. I will be unable to look at this for about a week now, but there are still some "TODO" comments in the ImageReader code which I'd like people's opinions on (esp. the possibly non-thread safe call to close() from SharedImageReader (not locked on the instance). ------------- PR Comment: https://git.openjdk.org/jdk/pull/26054#issuecomment-3027321237 From kfarrell at openjdk.org Wed Jul 2 10:44:21 2025 From: kfarrell at openjdk.org (Kieran Farrell) Date: Wed, 2 Jul 2025 10:44:21 GMT Subject: RFR: 8334015: Add Support for UUID Version 7 (UUIDv7) defined in RFC 9562 [v11] In-Reply-To: References: Message-ID: > With the recent approval of UUIDv7 (https://datatracker.ietf.org/doc/rfc9562/), this PR aims to add a new static method UUID.timestampUUID() which constructs and returns a UUID in support of the new time generated UUID version. > > The specification requires embedding the current timestamp in milliseconds into the first bits 0?47. The version number in bits 48?51, bits 52?63 are available for sub-millisecond precision or for pseudorandom data. The variant is set in bits 64?65. The remaining bits 66?127 are free to use for more pseudorandom data or to employ a counter based approach for increased time percision (https://www.rfc-editor.org/rfc/rfc9562.html#name-uuid-version-7). > > The choice of implementation comes down to balancing the sensitivity level of being able to distingush UUIDs created below <1ms apart with performance. A test simulating a high-concurrency environment with 4 threads generating 10000 UUIDv7 values in parallel to measure the collision rate of each implementation (the amount of times the time based portion of the UUID was not unique and entries could not distinguished by time) yeilded the following results for each implemtation: > > > - random-byte-only - 99.8% > - higher-precision - 3.5% > - counter-based - 0% > > > Performance tests show a decrease in performance as expected with the counter based implementation due to the introduction of synchronization: > > - random-byte-only 143.487 ? 10.932 ns/op > - higher-precision 149.651 ? 8.438 ns/op > - counter-based 245.036 ? 2.943 ns/op > > The best balance here might be to employ a higher-precision implementation as the large increase in time sensitivity comes at a very slight performance cost. Kieran Farrell has updated the pull request incrementally with one additional commit since the last revision: spec updates ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25303/files - new: https://git.openjdk.org/jdk/pull/25303/files/1e730c24..c06474fc Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25303&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25303&range=09-10 Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25303.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25303/head:pull/25303 PR: https://git.openjdk.org/jdk/pull/25303 From kfarrell at openjdk.org Wed Jul 2 10:46:56 2025 From: kfarrell at openjdk.org (Kieran Farrell) Date: Wed, 2 Jul 2025 10:46:56 GMT Subject: RFR: 8334015: Add Support for UUID Version 7 (UUIDv7) defined in RFC 9562 [v12] In-Reply-To: References: Message-ID: > With the recent approval of UUIDv7 (https://datatracker.ietf.org/doc/rfc9562/), this PR aims to add a new static method UUID.timestampUUID() which constructs and returns a UUID in support of the new time generated UUID version. > > The specification requires embedding the current timestamp in milliseconds into the first bits 0?47. The version number in bits 48?51, bits 52?63 are available for sub-millisecond precision or for pseudorandom data. The variant is set in bits 64?65. The remaining bits 66?127 are free to use for more pseudorandom data or to employ a counter based approach for increased time percision (https://www.rfc-editor.org/rfc/rfc9562.html#name-uuid-version-7). > > The choice of implementation comes down to balancing the sensitivity level of being able to distingush UUIDs created below <1ms apart with performance. A test simulating a high-concurrency environment with 4 threads generating 10000 UUIDv7 values in parallel to measure the collision rate of each implementation (the amount of times the time based portion of the UUID was not unique and entries could not distinguished by time) yeilded the following results for each implemtation: > > > - random-byte-only - 99.8% > - higher-precision - 3.5% > - counter-based - 0% > > > Performance tests show a decrease in performance as expected with the counter based implementation due to the introduction of synchronization: > > - random-byte-only 143.487 ? 10.932 ns/op > - higher-precision 149.651 ? 8.438 ns/op > - counter-based 245.036 ? 2.943 ns/op > > The best balance here might be to employ a higher-precision implementation as the large increase in time sensitivity comes at a very slight performance cost. Kieran Farrell has updated the pull request incrementally with one additional commit since the last revision: rm whitespace ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25303/files - new: https://git.openjdk.org/jdk/pull/25303/files/c06474fc..a72f1834 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25303&range=11 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25303&range=10-11 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/25303.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25303/head:pull/25303 PR: https://git.openjdk.org/jdk/pull/25303 From mhaessig at openjdk.org Wed Jul 2 11:37:14 2025 From: mhaessig at openjdk.org (Manuel =?UTF-8?B?SMOkc3NpZw==?=) Date: Wed, 2 Jul 2025 11:37:14 GMT Subject: RFR: 8361253: CommanLineOptionTest library should report observed values on failure Message-ID: When a check in `CommandLineOptionTest` fails, the `AssertionError` message contains the expected value, but not the observed value. To reduce the amount of digging in the logs we have to do when analyzing a failure, this PR adds the observed value to the error messages. So instead of java.lang.AssertionError: Option 'CICompilerCount' is expected to have '12' value a mismatch in the `CICompilerCount` will now print java.lang.AssertionError: Option 'CICompilerCount' is expected to have '12' value, but is 'CICompilerCount = 6'. Testing: - [ ] Github Actions - [ ] tier1 through tier3 plus Oracle internal testing ------------- Commit messages: - Add observed values to CommandLineOptionTest error messages Changes: https://git.openjdk.org/jdk/pull/26092/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26092&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8361253 Stats: 7 lines in 1 file changed: 3 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/26092.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26092/head:pull/26092 PR: https://git.openjdk.org/jdk/pull/26092 From dholmes at openjdk.org Wed Jul 2 12:18:38 2025 From: dholmes at openjdk.org (David Holmes) Date: Wed, 2 Jul 2025 12:18:38 GMT Subject: RFR: 8361253: CommanLineOptionTest library should report observed values on failure In-Reply-To: References: Message-ID: On Wed, 2 Jul 2025 11:00:44 GMT, Manuel H?ssig wrote: > When a check in `CommandLineOptionTest` fails, the `AssertionError` message contains the expected value, but not the observed value. To reduce the amount of digging in the logs we have to do when analyzing a failure, this PR adds the observed value to the error messages. So instead of > > > java.lang.AssertionError: Option 'CICompilerCount' is expected to have '12' value > > > a mismatch in the `CICompilerCount` will now print > > > java.lang.AssertionError: Option 'CICompilerCount' is expected to have '12' value, but is 'CICompilerCount = 6'. > > > Testing: > - [ ] Github Actions > - [ ] tier1 through tier3 plus Oracle internal testing This looks reasonable to me. Thanks for addressing this so promptly! There was a typo in the JBS issue title so you will need to adjust here. ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26092#pullrequestreview-2978917364 From shade at openjdk.org Wed Jul 2 12:41:38 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 2 Jul 2025 12:41:38 GMT Subject: RFR: 8361253: CommandLineOptionTest library should report observed values on failure In-Reply-To: References: Message-ID: <7TBGrTc8gKqAJfXiXhNBhXLFkWVFF0KQkJnMpN7e1Po=.d9ece700-fe5a-4c35-baa5-9ab4e4f586d2@github.com> On Wed, 2 Jul 2025 11:00:44 GMT, Manuel H?ssig wrote: > When a check in `CommandLineOptionTest` fails, the `AssertionError` message contains the expected value, but not the observed value. To reduce the amount of digging in the logs we have to do when analyzing a failure, this PR adds the observed value to the error messages. So instead of > > > java.lang.AssertionError: Option 'CICompilerCount' is expected to have '12' value > > > a mismatch in the `CICompilerCount` will now print > > > java.lang.AssertionError: Option 'CICompilerCount' is expected to have '12' value, but is 'CICompilerCount = 6'. > > > Testing: > - [x] Github Actions > - [ ] tier1 through tier3 plus Oracle internal testing Marked as reviewed by shade (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26092#pullrequestreview-2978987090 From alanb at openjdk.org Wed Jul 2 12:53:46 2025 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 2 Jul 2025 12:53:46 GMT Subject: RFR: 8360037: Refactor ImageReader in preparation for Valhalla support [v4] In-Reply-To: References: Message-ID: On Wed, 2 Jul 2025 08:38:40 GMT, David Beaumont wrote: >> Refactoring `ImageReader` to make it easy to add preview mode functionality for Valhalla. >> >> This PR is a large change to `ImageReader` (effectively a rewrite) but reduces the surface area of the API significantly, reduces code complexity and increases performance/memory efficiency. The need for this sort of change comes from the need to support "preview mode" in Valhalla for classes loaded from core modules. >> >> ### Preview Mode >> >> In the proposed preview mode support for Valhalla, a resource with the name `/modules//` may come from one of two locations in the underlying jimage file; `//` or `//META-INF/preview/`. Furthermore, directories (represented as directory nodes via the API) will have a potentially different number of child nodes depending on whether preview mode is in effect, and some directories may only exist at all in preview mode. >> >> Furthermore, the directories and symbolic link nodes in `/packages/...` will also be affected by the existence of new package directories. To retain consistency and avoid "surprises" later, all of this needs to be taken into account. >> >> Below is a summary of the main changes for mainline JDK to better support preview mode later: >> >> ### 1: Improved encapsulation for preview mode >> >> The current `ImageReader` code exposes the data from the jimage file in several ways; via the `Node` abstraction, but also with methods which return an `ImageLocation` instance directly. In preview mode it would not be acceptable to return the `ImageLocation`, since that would leak the existence of resources in the `META-INF/preview` namespace and lets users see resource nodes with names that don't match the underlying `ImageLocation` from which their contents come. >> >> As such, the PR removes all methods which can leak `ImageLocation` or other "underlying" semantics about the jimage file. Luckily most of these are either used minimally and easily migrated to using nodes, or they were not being used at all. This PR also removes any methods which were already unused across the OpenJDK codebase (if I discover any issues with over-trimming of the API during full CI testing, it will be easy to address). >> >> ### 2. Simplification of directory child node handling >> >> The current `ImageReader` code attempts to create parent directories "on demand" for any child nodes it creates. This results in parent directories having a non-empty but incomplete set of child nodes present. This is re... > > David Beaumont has updated the pull request incrementally with one additional commit since the last revision: > > Small feedback related tweaks. src/java.base/share/classes/jdk/internal/module/SystemModuleFinders.java line 266: > 264: > 265: // The nodes we are processing must exist (every module must have a module-info.class). > 266: private static ModuleInfo.Attributes loadModuleAttributes(ImageReader reader, String moduleName) { Would you mind renaming this to readModuleAttributes as it's confusing to switch to using "load" here. Also can you fix the comment as it is very confusing to to say "The nodes we are processing must exist" when the method is simple called to read and parse a module-info. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26054#discussion_r2179975265 From jpai at openjdk.org Wed Jul 2 12:57:41 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 2 Jul 2025 12:57:41 GMT Subject: RFR: 8354872: Clarify java.lang.Process resource cleanup [v3] In-Reply-To: References: <39KIPIXZDBI9tpPyXew2Ye-uzPvkLSQnOzGJFuK9E2Y=.dc8df88f-f21a-4dd6-8297-5629098bd408@github.com> Message-ID: On Tue, 1 Jul 2025 22:30:57 GMT, Roger Riggs wrote: >> Improve the documentation of Process use of system resources. >> >> Describe the implementation closing streams when no longer referenced. >> Clarify the interactions between inputStream and inputReader and errorStream and errorReader. >> Add advice and example using try-with-resources to open and close streams. >> Recommend closing streams when no longer in use. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > javadoc cleanup src/java.base/share/classes/java/lang/Process.java line 129: > 127: * } > 128: * } > 129: *

    Stream resources (file descriptor or handled) are always paired; one in the invoking process Hello Roger, this looks like a typo. I think it was meant to be "or handle"? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25884#discussion_r2179987213 From alanb at openjdk.org Wed Jul 2 13:02:49 2025 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 2 Jul 2025 13:02:49 GMT Subject: RFR: 8360037: Refactor ImageReader in preparation for Valhalla support [v4] In-Reply-To: References: Message-ID: On Wed, 2 Jul 2025 08:38:40 GMT, David Beaumont wrote: >> Refactoring `ImageReader` to make it easy to add preview mode functionality for Valhalla. >> >> This PR is a large change to `ImageReader` (effectively a rewrite) but reduces the surface area of the API significantly, reduces code complexity and increases performance/memory efficiency. The need for this sort of change comes from the need to support "preview mode" in Valhalla for classes loaded from core modules. >> >> ### Preview Mode >> >> In the proposed preview mode support for Valhalla, a resource with the name `/modules//` may come from one of two locations in the underlying jimage file; `//` or `//META-INF/preview/`. Furthermore, directories (represented as directory nodes via the API) will have a potentially different number of child nodes depending on whether preview mode is in effect, and some directories may only exist at all in preview mode. >> >> Furthermore, the directories and symbolic link nodes in `/packages/...` will also be affected by the existence of new package directories. To retain consistency and avoid "surprises" later, all of this needs to be taken into account. >> >> Below is a summary of the main changes for mainline JDK to better support preview mode later: >> >> ### 1: Improved encapsulation for preview mode >> >> The current `ImageReader` code exposes the data from the jimage file in several ways; via the `Node` abstraction, but also with methods which return an `ImageLocation` instance directly. In preview mode it would not be acceptable to return the `ImageLocation`, since that would leak the existence of resources in the `META-INF/preview` namespace and lets users see resource nodes with names that don't match the underlying `ImageLocation` from which their contents come. >> >> As such, the PR removes all methods which can leak `ImageLocation` or other "underlying" semantics about the jimage file. Luckily most of these are either used minimally and easily migrated to using nodes, or they were not being used at all. This PR also removes any methods which were already unused across the OpenJDK codebase (if I discover any issues with over-trimming of the API during full CI testing, it will be easy to address). >> >> ### 2. Simplification of directory child node handling >> >> The current `ImageReader` code attempts to create parent directories "on demand" for any child nodes it creates. This results in parent directories having a non-empty but incomplete set of child nodes present. This is re... > > David Beaumont has updated the pull request incrementally with one additional commit since the last revision: > > Small feedback related tweaks. src/java.base/share/classes/jdk/internal/module/SystemModuleFinders.java line 458: > 456: * returned even if a non-resource node exists with the given name. > 457: */ > 458: private Optional findResourceNode(ImageReader reader, String name) throws IOException { If you change this method use SystemImage.reader (like containsResource does) then it would be a bit nicer. It's okay to change this method to return null when not found too, the read method can box. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26054#discussion_r2180007050 From jpai at openjdk.org Wed Jul 2 13:05:40 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 2 Jul 2025 13:05:40 GMT Subject: RFR: 8354872: Clarify java.lang.Process resource cleanup [v3] In-Reply-To: References: <39KIPIXZDBI9tpPyXew2Ye-uzPvkLSQnOzGJFuK9E2Y=.dc8df88f-f21a-4dd6-8297-5629098bd408@github.com> Message-ID: On Tue, 1 Jul 2025 22:30:57 GMT, Roger Riggs wrote: >> Improve the documentation of Process use of system resources. >> >> Describe the implementation closing streams when no longer referenced. >> Clarify the interactions between inputStream and inputReader and errorStream and errorReader. >> Add advice and example using try-with-resources to open and close streams. >> Recommend closing streams when no longer in use. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > javadoc cleanup src/java.base/share/classes/java/lang/Process.java line 208: > 206: * > 207: * @apiNote > 208: * Use either this method or an {@linkplain #inputReader(Charset) input reader} I think this should be `{@linkplain #inputReader() input reader}` (i.e. the one that doesn't take a CharSet) to match what was there previously before the changes in this PR. src/java.base/share/classes/java/lang/Process.java line 240: > 238: * > 239: * @apiNote > 240: * Use either this method or an {@linkplain #errorReader(Charset) error reader} Same here - I think it should be `{@linkplain #errorReader() error reader}` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25884#discussion_r2180011109 PR Review Comment: https://git.openjdk.org/jdk/pull/25884#discussion_r2180013254 From jpai at openjdk.org Wed Jul 2 13:08:39 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 2 Jul 2025 13:08:39 GMT Subject: RFR: 8354872: Clarify java.lang.Process resource cleanup [v3] In-Reply-To: References: <39KIPIXZDBI9tpPyXew2Ye-uzPvkLSQnOzGJFuK9E2Y=.dc8df88f-f21a-4dd6-8297-5629098bd408@github.com> Message-ID: On Tue, 1 Jul 2025 22:30:57 GMT, Roger Riggs wrote: >> Improve the documentation of Process use of system resources. >> >> Describe the implementation closing streams when no longer referenced. >> Clarify the interactions between inputStream and inputReader and errorStream and errorReader. >> Add advice and example using try-with-resources to open and close streams. >> Recommend closing streams when no longer in use. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > javadoc cleanup The updated changes look good to me. I just noticed a few typoes which I've reviewed inline. I'll review the CSR now. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25884#issuecomment-3027821492 From jpai at openjdk.org Wed Jul 2 13:28:42 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 2 Jul 2025 13:28:42 GMT Subject: RFR: 8354872: Clarify java.lang.Process resource cleanup [v3] In-Reply-To: References: <39KIPIXZDBI9tpPyXew2Ye-uzPvkLSQnOzGJFuK9E2Y=.dc8df88f-f21a-4dd6-8297-5629098bd408@github.com> Message-ID: <5aV_LR8YAhidGNtBlf5quqj9CoyqPSGg9uzNKy5j8ZQ=.115a3aef-ba2e-4840-bf88-0b45515f6f5f@github.com> On Tue, 1 Jul 2025 22:30:57 GMT, Roger Riggs wrote: >> Improve the documentation of Process use of system resources. >> >> Describe the implementation closing streams when no longer referenced. >> Clarify the interactions between inputStream and inputReader and errorStream and errorReader. >> Add advice and example using try-with-resources to open and close streams. >> Recommend closing streams when no longer in use. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > javadoc cleanup src/java.base/share/classes/java/lang/ProcessBuilder.java line 545: > 543: * {@snippet lang = "java" : > 544: * Redirect.DISCARD.file(); // is the filename appropriate for the operating system > 545: * Redirect.DISCARD.type() == Redirect.Type.WRITE; I built this PR locally to see how this gets rendered. It looks like this: javadoc Should we add a `&&` in there somewhere to match what we do with the other `Redirect` types? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25884#discussion_r2180065549 From rriggs at openjdk.org Wed Jul 2 13:46:39 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 2 Jul 2025 13:46:39 GMT Subject: RFR: 8358533: Improve performance of java.io.Reader.readAllLines [v7] In-Reply-To: <49BAIrPYEOTuF3SDhHxtF3KLg-9N3YmkKp5Z0BGgMmw=.8105cebd-bc10-4de3-b6cb-81b00692fdb6@github.com> References: <49BAIrPYEOTuF3SDhHxtF3KLg-9N3YmkKp5Z0BGgMmw=.8105cebd-bc10-4de3-b6cb-81b00692fdb6@github.com> Message-ID: On Fri, 27 Jun 2025 23:00:04 GMT, Brian Burkhalter wrote: >> src/java.base/share/classes/java/io/Reader.java line 504: >> >>> 502: } >>> 503: if (fragLen >= cb.length/2) { >>> 504: // allocate larger buffer and copy chars to beginning >> >> It might be designed to use a more conservative resizing approach, for example, **cb.length + TRANSFER_BUFFER_SIZE**, rather than exponential doubling, more in line with how resizing is handled in string builder. not a very strong opinion though :-) > >> [...] more in line with how resizing is handled in string builder > > Looks like `StringBuilder` eventually calls `ArraysSupport.newLength(int,int.int)`. This is probably worth checking out. On the call to ArraysSupport.newLength(curr, min, preferred). This will double the size (preferred) until it runs past SOFT_MAX_ARRAY_LENGTH. Then it starts growing by minGrowth, it should probably be smaller; something that will allow it to get pretty close to SOFT_MAX_ARRAY_LENGTH before throwing OOME. But still large enough to allow efficient reads. Maybe 4k, or 8k, or 16k. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25863#discussion_r2180106662 From duke at openjdk.org Wed Jul 2 13:54:02 2025 From: duke at openjdk.org (David Beaumont) Date: Wed, 2 Jul 2025 13:54:02 GMT Subject: RFR: 8360037: Refactor ImageReader in preparation for Valhalla support [v5] In-Reply-To: References: Message-ID: > Refactoring `ImageReader` to make it easy to add preview mode functionality for Valhalla. > > This PR is a large change to `ImageReader` (effectively a rewrite) but reduces the surface area of the API significantly, reduces code complexity and increases performance/memory efficiency. The need for this sort of change comes from the need to support "preview mode" in Valhalla for classes loaded from core modules. > > ### Preview Mode > > In the proposed preview mode support for Valhalla, a resource with the name `/modules//` may come from one of two locations in the underlying jimage file; `//` or `//META-INF/preview/`. Furthermore, directories (represented as directory nodes via the API) will have a potentially different number of child nodes depending on whether preview mode is in effect, and some directories may only exist at all in preview mode. > > Furthermore, the directories and symbolic link nodes in `/packages/...` will also be affected by the existence of new package directories. To retain consistency and avoid "surprises" later, all of this needs to be taken into account. > > Below is a summary of the main changes for mainline JDK to better support preview mode later: > > ### 1: Improved encapsulation for preview mode > > The current `ImageReader` code exposes the data from the jimage file in several ways; via the `Node` abstraction, but also with methods which return an `ImageLocation` instance directly. In preview mode it would not be acceptable to return the `ImageLocation`, since that would leak the existence of resources in the `META-INF/preview` namespace and lets users see resource nodes with names that don't match the underlying `ImageLocation` from which their contents come. > > As such, the PR removes all methods which can leak `ImageLocation` or other "underlying" semantics about the jimage file. Luckily most of these are either used minimally and easily migrated to using nodes, or they were not being used at all. This PR also removes any methods which were already unused across the OpenJDK codebase (if I discover any issues with over-trimming of the API during full CI testing, it will be easy to address). > > ### 2. Simplification of directory child node handling > > The current `ImageReader` code attempts to create parent directories "on demand" for any child nodes it creates. This results in parent directories having a non-empty but incomplete set of child nodes present. This is referred to as the directory being "incomple... David Beaumont has updated the pull request incrementally with one additional commit since the last revision: Feedback related changes. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26054/files - new: https://git.openjdk.org/jdk/pull/26054/files/a8b68c7b..df1705ce Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26054&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26054&range=03-04 Stats: 8 lines in 1 file changed: 0 ins; 1 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/26054.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26054/head:pull/26054 PR: https://git.openjdk.org/jdk/pull/26054 From duke at openjdk.org Wed Jul 2 13:54:03 2025 From: duke at openjdk.org (David Beaumont) Date: Wed, 2 Jul 2025 13:54:03 GMT Subject: RFR: 8360037: Refactor ImageReader in preparation for Valhalla support [v4] In-Reply-To: References: Message-ID: <68BE8CPkVKjER9mJst7MneY26xg4zOSxaHMFjEmYW4Y=.ea7c6d86-3812-4357-a3c2-656b4d611559@github.com> On Wed, 2 Jul 2025 12:51:27 GMT, Alan Bateman wrote: >> David Beaumont has updated the pull request incrementally with one additional commit since the last revision: >> >> Small feedback related tweaks. > > src/java.base/share/classes/jdk/internal/module/SystemModuleFinders.java line 266: > >> 264: >> 265: // The nodes we are processing must exist (every module must have a module-info.class). >> 266: private static ModuleInfo.Attributes loadModuleAttributes(ImageReader reader, String moduleName) { > > Would you mind renaming this to readModuleAttributes as it's confusing to switch to using "load" here. > > Also can you fix the comment as it is very confusing to to say "The nodes we are processing must exist" when the method is simple called to read and parse a module-info. Done. > src/java.base/share/classes/jdk/internal/module/SystemModuleFinders.java line 458: > >> 456: * returned even if a non-resource node exists with the given name. >> 457: */ >> 458: private Optional findResourceNode(ImageReader reader, String name) throws IOException { > > If you change this method use SystemImage.reader (like containsResource does) then it would be a bit nicer. It's okay to change this method to return null when not found too, the read method can box. I changed the return to plain value, but not the use of ImageReader. The caller needs the reader instance too, so it can't be moved into the `findResourceNode()`, only duplicated there. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26054#discussion_r2180118262 PR Review Comment: https://git.openjdk.org/jdk/pull/26054#discussion_r2180122848 From liach at openjdk.org Wed Jul 2 14:32:41 2025 From: liach at openjdk.org (Chen Liang) Date: Wed, 2 Jul 2025 14:32:41 GMT Subject: RFR: 8361018: Re-examine buffering and encoding conversion in BufferedWriter [v6] In-Reply-To: References: Message-ID: <8eih4k_a1QllWM_vcg81TX0F6_bp8wYJmEP77VoCqT0=.acaceaa8-9203-423b-b6ea-67dbcc61a6a7@github.com> On Tue, 1 Jul 2025 00:01:21 GMT, Shaojin Wen wrote: >> BufferedWriter -> OutputStreamWriter -> StreamEncoder >> >> In this call chain, BufferedWriter has a char[] buffer, and StreamEncoder has a ByteBuffer. There are two layers of cache here, or the BufferedWriter layer can be removed. And when charset is UTF8, if the content of write(String) is LATIN1, a conversion from LATIN1 to UTF16 and then to LATIN1 will occur here. >> >> LATIN1 -> UTF16 -> UTF8 >> >> We can improve BufferedWriter. When the parameter Writer instanceof OutputStreamWriter is passed in, remove the cache and call it directly. In addition, improve write(String) in StreamEncoder to avoid unnecessary encoding conversion. > > Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: > > Revert "BufferedWriter buffer use StringBuilder" > > This reverts commit da902ca0b0bd6acc003deb8ad1ca0d6485a29a27. This latest prototype looks great! It means that we can get rid of the old `BufferedImpl` by using `WriterImpl` as the new code, and remove `StreamEncoder.UTF8Impl`. I think this prototype can be split this way: 1. Update ArrayEncoder to pass `dp`, open up StringBuilder in JLA, and make BufferedWriter + StreamEncoder use ArrayEncoder. We can use a benchmark writing encodings like CESU for a first step proof of concept. 2. Make UTF8/ISO88591 array encoders. This will open up a few String UTF8 encoding methods in JLA. 3. More array encoders. For example, GB18030 gets a new array encoder in your patch. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26022#issuecomment-3028104142 From rriggs at openjdk.org Wed Jul 2 14:37:47 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 2 Jul 2025 14:37:47 GMT Subject: RFR: 8354872: Clarify java.lang.Process resource cleanup [v3] In-Reply-To: References: <39KIPIXZDBI9tpPyXew2Ye-uzPvkLSQnOzGJFuK9E2Y=.dc8df88f-f21a-4dd6-8297-5629098bd408@github.com> Message-ID: On Fri, 27 Jun 2025 16:23:59 GMT, Jaikiran Pai wrote: >> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: >> >> javadoc cleanup > > src/java.base/share/classes/java/lang/ProcessBuilder.java line 545: > >> 543: * {@snippet lang = "java" : >> 544: * Redirect.DISCARD.file() // is the filename appropriate for the operating system >> 545: * Redirect.DISCARD.type() == Redirect.Type.WRITE > > With this use of snippet here I think it no longer conveys what the original `{@code}` block was trying to convey. I can't currently think of a better proposal either. Updated `Redirect.DISCARD.file() != null &&` // so its a valid expression. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25884#discussion_r2180227712 From rriggs at openjdk.org Wed Jul 2 14:52:06 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 2 Jul 2025 14:52:06 GMT Subject: RFR: 8354872: Clarify java.lang.Process resource cleanup [v4] In-Reply-To: <39KIPIXZDBI9tpPyXew2Ye-uzPvkLSQnOzGJFuK9E2Y=.dc8df88f-f21a-4dd6-8297-5629098bd408@github.com> References: <39KIPIXZDBI9tpPyXew2Ye-uzPvkLSQnOzGJFuK9E2Y=.dc8df88f-f21a-4dd6-8297-5629098bd408@github.com> Message-ID: > Improve the documentation of Process use of system resources. > > Describe the implementation closing streams when no longer referenced. > Clarify the interactions between inputStream and inputReader and errorStream and errorReader. > Add advice and example using try-with-resources to open and close streams. > Recommend closing streams when no longer in use. Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: Fix links per review comments and snippet syntax in ProcessBuilder.Redirect.DISCARD. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25884/files - new: https://git.openjdk.org/jdk/pull/25884/files/868c93aa..eafd5611 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25884&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25884&range=02-03 Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/25884.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25884/head:pull/25884 PR: https://git.openjdk.org/jdk/pull/25884 From jpai at openjdk.org Wed Jul 2 14:52:06 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 2 Jul 2025 14:52:06 GMT Subject: RFR: 8354872: Clarify java.lang.Process resource cleanup [v4] In-Reply-To: References: <39KIPIXZDBI9tpPyXew2Ye-uzPvkLSQnOzGJFuK9E2Y=.dc8df88f-f21a-4dd6-8297-5629098bd408@github.com> Message-ID: <16a1bcoBtoC1esI0igaE3bWOjyhhDmNkrUoYbBnNfkA=.ead94479-d75d-48da-9550-e16135cc3b04@github.com> On Wed, 2 Jul 2025 14:49:01 GMT, Roger Riggs wrote: >> Improve the documentation of Process use of system resources. >> >> Describe the implementation closing streams when no longer referenced. >> Clarify the interactions between inputStream and inputReader and errorStream and errorReader. >> Add advice and example using try-with-resources to open and close streams. >> Recommend closing streams when no longer in use. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Fix links per review comments and snippet syntax in ProcessBuilder.Redirect.DISCARD. Thank you Roger for these updates. This looks good to me. ------------- Marked as reviewed by jpai (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25884#pullrequestreview-2979467778 From rriggs at openjdk.org Wed Jul 2 14:52:06 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 2 Jul 2025 14:52:06 GMT Subject: RFR: 8354872: Clarify java.lang.Process resource cleanup [v3] In-Reply-To: References: <39KIPIXZDBI9tpPyXew2Ye-uzPvkLSQnOzGJFuK9E2Y=.dc8df88f-f21a-4dd6-8297-5629098bd408@github.com> Message-ID: On Wed, 2 Jul 2025 13:02:04 GMT, Jaikiran Pai wrote: >> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: >> >> javadoc cleanup > > src/java.base/share/classes/java/lang/Process.java line 208: > >> 206: * >> 207: * @apiNote >> 208: * Use either this method or an {@linkplain #inputReader(Charset) input reader} > > I think this should be `{@linkplain #inputReader() input reader}` (i.e. the one that doesn't take a CharSet) to match what was there previously before the changes in this PR. Conundrum... The readable text refers to "an input reader" and covers the case of either inputReader method. But including both links makes the sentence hard to read, so I picked the more expressive reader method to link to. Reverting to no-arg version. Ditto below. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25884#discussion_r2180256774 From jpai at openjdk.org Wed Jul 2 14:52:06 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 2 Jul 2025 14:52:06 GMT Subject: RFR: 8354872: Clarify java.lang.Process resource cleanup [v3] In-Reply-To: References: <39KIPIXZDBI9tpPyXew2Ye-uzPvkLSQnOzGJFuK9E2Y=.dc8df88f-f21a-4dd6-8297-5629098bd408@github.com> Message-ID: On Wed, 2 Jul 2025 14:46:20 GMT, Roger Riggs wrote: > But including both links makes the sentence hard to read, so I picked the more expressive reader method to link to. It didn't realize you had intentionally used the `CharSet` one. If you think the CharSet would provide better guidance to the developers, then I think it's OK to switch to that one. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25884#discussion_r2180263024 From rriggs at openjdk.org Wed Jul 2 14:54:42 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 2 Jul 2025 14:54:42 GMT Subject: RFR: 8361018: Re-examine buffering and encoding conversion in BufferedWriter [v6] In-Reply-To: References: Message-ID: On Tue, 1 Jul 2025 00:01:21 GMT, Shaojin Wen wrote: >> BufferedWriter -> OutputStreamWriter -> StreamEncoder >> >> In this call chain, BufferedWriter has a char[] buffer, and StreamEncoder has a ByteBuffer. There are two layers of cache here, or the BufferedWriter layer can be removed. And when charset is UTF8, if the content of write(String) is LATIN1, a conversion from LATIN1 to UTF16 and then to LATIN1 will occur here. >> >> LATIN1 -> UTF16 -> UTF8 >> >> We can improve BufferedWriter. When the parameter Writer instanceof OutputStreamWriter is passed in, remove the cache and call it directly. In addition, improve write(String) in StreamEncoder to avoid unnecessary encoding conversion. > > Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: > > Revert "BufferedWriter buffer use StringBuilder" > > This reverts commit da902ca0b0bd6acc003deb8ad1ca0d6485a29a27. No more of StringBuilder should be exposed via JLA, it creates new maintenance overhead and risks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26022#issuecomment-3028178422 From liach at openjdk.org Wed Jul 2 15:03:41 2025 From: liach at openjdk.org (Chen Liang) Date: Wed, 2 Jul 2025 15:03:41 GMT Subject: RFR: 8361018: Re-examine buffering and encoding conversion in BufferedWriter [v6] In-Reply-To: References: Message-ID: On Tue, 1 Jul 2025 00:01:21 GMT, Shaojin Wen wrote: >> BufferedWriter -> OutputStreamWriter -> StreamEncoder >> >> In this call chain, BufferedWriter has a char[] buffer, and StreamEncoder has a ByteBuffer. There are two layers of cache here, or the BufferedWriter layer can be removed. And when charset is UTF8, if the content of write(String) is LATIN1, a conversion from LATIN1 to UTF16 and then to LATIN1 will occur here. >> >> LATIN1 -> UTF16 -> UTF8 >> >> We can improve BufferedWriter. When the parameter Writer instanceof OutputStreamWriter is passed in, remove the cache and call it directly. In addition, improve write(String) in StreamEncoder to avoid unnecessary encoding conversion. > > Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: > > Revert "BufferedWriter buffer use StringBuilder" > > This reverts commit da902ca0b0bd6acc003deb8ad1ca0d6485a29a27. It is not about exposing the implementation details of StringBuilder: it is just exporting a method for StringBuilder to encode itself with an ArrayEncoder (which has LATIN1/UTF16 entrypoints) to general JDK audiences. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26022#issuecomment-3028212631 From liach at openjdk.org Wed Jul 2 15:14:56 2025 From: liach at openjdk.org (Chen Liang) Date: Wed, 2 Jul 2025 15:14:56 GMT Subject: RFR: 8360163: Create annotations to mark dumping method handles and runtime setup required classes [v6] In-Reply-To: References: Message-ID: > I have updated this patch to avoid a redundant `runtimeSetup` annotation - we have agreed that the requirement for setup is a side effect of initialization, and such methods in AOTCI classes must be automatically recognized. This latest revision implements that model. > > I intentionally avoided handling Class and ClassLoader `resetArchivedStates` and `MethodType::assemblySetup` - we talked about a generic `assemblyCleanup` method, but I did not find out where is the best place to call such a method in the assembly phase. We cna handle this in a subsequent patch. > > In particular, please review the new AOT.md design document - I split it from the AOTCI annotation to prevent jamming; we can put general AOT information there when we have more AOT-specific annotations. > > --- > > Old description: > Currently, the list of classes that have interdependencies and those that need runtimeSetup are maintained in a hardcoded list in CDS. This makes it risky for core library developers as they might introduce new interdependencies and observe CDS to fail. By moving the mechanism of these lists to core library annotations as a first step, we can gradually expose the AOT contracts as program semantics described by internal annotations, and also helps us to explore how we can expose these functionalities to the public later. Chen Liang has updated the pull request incrementally with two additional commits since the last revision: - Remove design document from code - Some more from reviews ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25922/files - new: https://git.openjdk.org/jdk/pull/25922/files/d5a54f5b..4b3906aa Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25922&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25922&range=04-05 Stats: 168 lines in 10 files changed: 30 ins; 135 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/25922.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25922/head:pull/25922 PR: https://git.openjdk.org/jdk/pull/25922 From liach at openjdk.org Wed Jul 2 15:14:56 2025 From: liach at openjdk.org (Chen Liang) Date: Wed, 2 Jul 2025 15:14:56 GMT Subject: RFR: 8360163: Create annotations to mark dumping method handles and runtime setup required classes [v5] In-Reply-To: References: Message-ID: <4OZnYKuL_IAwNtwQZqs4LkoWGKfhKr3-_n6AVVe3Jm4=.b10c26b4-65f7-4f90-bd21-68ae3a4bad05@github.com> On Wed, 2 Jul 2025 07:48:05 GMT, Andrew Dinn wrote: >> src/java.base/share/classes/java/lang/invoke/ClassSpecializer.java line 68: >> >>> 66: * @param species data type. >>> 67: */ >>> 68: @AOTSafeClassInitializer >> >> This should be placed below the `/*non-public*/` comment. > > Perhaps also the same for BoundMethodHandle? and others? John disclosed these comments were from the initial iteration of JSR 292 implementation. Newer code does not have this comment, so I think I will just remove them outright. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25922#discussion_r2180315616 From lancea at openjdk.org Wed Jul 2 15:27:47 2025 From: lancea at openjdk.org (Lance Andersen) Date: Wed, 2 Jul 2025 15:27:47 GMT Subject: RFR: 8360122: Fix java.sql\Connection.java indentation [v4] In-Reply-To: References: Message-ID: <0UfkXxOmp7jsEH0cPOPBDoh8osWoz6Jp6A8jLh-CmDE=.57a3938f-ba6d-48ee-9caf-ecd3c10678cb@github.com> On Mon, 23 Jun 2025 23:09:13 GMT, simon wrote: >> 8360122: Refine formatting of Connection.java interface >> >> --------- >> ### Progress >> - [ ] Change must be properly reviewed (1 review required, with at least 1 [Reviewer](https://openjdk.org/bylaws#reviewer)) >> - [x] Change must not contain extraneous whitespace >> - [x] Commit message must refer to an issue >> >> >> >> ### Reviewing >>

    Using git >> >> Checkout this PR locally: \ >> `$ git fetch https://git.openjdk.org/jdk.git pull/25925/head:pull/25925` \ >> `$ git checkout pull/25925` >> >> Update a local copy of the PR: \ >> `$ git checkout pull/25925` \ >> `$ git pull https://git.openjdk.org/jdk.git pull/25925/head` >> >>
    >>
    Using Skara CLI tools >> >> Checkout this PR locally: \ >> `$ git pr checkout 25925` >> >> View PR using the GUI difftool: \ >> `$ git pr show -t 25925` >> >>
    >>
    Using diff file >> >> Download this PR as a diff file: \ >> https://git.openjdk.org/jdk/pull/25925.diff >> >>
    >>
    Using Webrev >> >> [Link to Webrev Comment](https://git.openjdk.org/jdk/pull/25925#issuecomment-2993856738) >>
    > > simon has updated the pull request incrementally with one additional commit since the last revision: > > 8360122: revert reformatting method signatures Some initial comments. There are some lines in the methods that were modified that need to wrap around 80 characters, but it would be best to leave as is and can be done as part of the updates that will be coming shorty src/java.sql/share/classes/java/sql/Connection.java line 303: > 301: //====================================================================== > 302: // Advanced features: > 303: Why was this removed as this is not format related src/java.sql/share/classes/java/sql/Connection.java line 1175: > 1173: */ > 1174: void setClientInfo(String name, String value) > 1175: throws SQLClientInfoException; The throws clause could be moved up src/java.sql/share/classes/java/sql/Connection.java line 1208: > 1206: */ > 1207: void setClientInfo(Properties properties) > 1208: throws SQLClientInfoException; The throws clause could be moved up src/java.sql/share/classes/java/sql/Connection.java line 1232: > 1230: * @see java.sql.DatabaseMetaData#getClientInfoProperties > 1231: */ > 1232: String getClientInfo(String name) the throws clause could be moved up src/java.sql/share/classes/java/sql/Connection.java line 1251: > 1249: */ > 1250: Properties getClientInfo() > 1251: throws SQLException; The throws clause could be moved up ------------- Changes requested by lancea (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25925#pullrequestreview-2979431612 PR Review Comment: https://git.openjdk.org/jdk/pull/25925#discussion_r2180233608 PR Review Comment: https://git.openjdk.org/jdk/pull/25925#discussion_r2180324024 PR Review Comment: https://git.openjdk.org/jdk/pull/25925#discussion_r2180322060 PR Review Comment: https://git.openjdk.org/jdk/pull/25925#discussion_r2180318581 PR Review Comment: https://git.openjdk.org/jdk/pull/25925#discussion_r2180317869 From brett.okken.os at gmail.com Wed Jul 2 15:35:43 2025 From: brett.okken.os at gmail.com (Brett Okken) Date: Wed, 2 Jul 2025 10:35:43 -0500 Subject: StringCharBuffer and bulk get In-Reply-To: References: Message-ID: CharBuffer implementation of public default void getChars(int srcBegin, int srcEnd, char[] dst, int dstBegin) uses absolute positioning for the indexes (i.e. ignores the current position). https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/nio/X-Buffer.java.template#L1900-L1935 However, this is not consistent with the implementation of other CharSquence methods: https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/nio/CharBuffer.html#charAt(int) https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/nio/CharBuffer.html#length() https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/nio/CharBuffer.html#subSequence(int,int) The codePoints and chars methods are also relative to the current position, but that is not explicitly called out in javadoc. Is this really intended? On Tue, Jul 1, 2025 at 11:29?AM Chen Liang wrote: > > Hi Brett, I think your suggestion makes sense. I have created https://bugs.openjdk.org/browse/JDK-8361209 to track this RFE. > Feel free to contribute a patch to implement this enhancement. > > ________________________________ > From: core-libs-dev on behalf of Brett Okken > Sent: Tuesday, July 1, 2025 9:57 AM > To: core-libs-dev > Subject: StringCharBuffer and bulk get > > jdk 25 introduced[1] a bulk getChars method to CharSequence[2]. > Should StringCharBuffer be updated to utilize that new method to > implement the bulk get method[3]? > That would presumably require changes to the private getArray[4]. > I think there could also be changes to putBuffer[5] for when the > target has an array. That array could be used for the getChars call. > > [1] - https://github.com/openjdk/jdk/commit/7642556a5a131e9104033ad7d7abfdb4be5012cf > [2] - https://download.java.net/java/early_access/jdk25/docs/api/java.base/java/lang/CharSequence.html#getChars(int,int,char%5B%5D,int) > [3] - https://download.java.net/java/early_access/jdk25/docs/api/java.base/java/nio/CharBuffer.html#get(int,char%5B%5D,int,int) > [4] - https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/nio/X-Buffer.java.template#L953-L985 > [5] - https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/nio/X-Buffer.java.template#L1152-L1156 From brian.burkhalter at oracle.com Wed Jul 2 15:40:18 2025 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 2 Jul 2025 15:40:18 +0000 Subject: StringCharBuffer and bulk get In-Reply-To: References: Message-ID: <08950E51-883A-47E2-B013-F6F4E9B1499B@oracle.com> Some methods are absolute and some relative: https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/nio/Buffer.html#transferring-data-heading On Jul 2, 2025, at 8:35?AM, Brett Okken wrote: CharBuffer implementation of public default void getChars(int srcBegin, int srcEnd, char[] dst, int dstBegin) uses absolute positioning for the indexes (i.e. ignores the current position). -------------- next part -------------- An HTML attachment was scrubbed... URL: From chen.l.liang at oracle.com Wed Jul 2 15:48:13 2025 From: chen.l.liang at oracle.com (Chen Liang) Date: Wed, 2 Jul 2025 15:48:13 +0000 Subject: StringCharBuffer and bulk get In-Reply-To: <08950E51-883A-47E2-B013-F6F4E9B1499B@oracle.com> References: <08950E51-883A-47E2-B013-F6F4E9B1499B@oracle.com> Message-ID: I think Brett is right. The spec of CharBuffer says: The methods defined by {@code CharSequence} operate relative to the current position of the buffer when they are invoked. Yet getChars is an absolute bulk get method. Since JDK25 is still in RDP, we still have a chance to fix this up. ________________________________ From: core-libs-dev on behalf of Brian Burkhalter Sent: Wednesday, July 2, 2025 10:40 AM To: Brett Okken Cc: core-libs-dev Subject: Re: StringCharBuffer and bulk get Some methods are absolute and some relative: https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/nio/Buffer.html#transferring-data-heading On Jul 2, 2025, at 8:35?AM, Brett Okken wrote: CharBuffer implementation of public default void getChars(int srcBegin, int srcEnd, char[] dst, int dstBegin) uses absolute positioning for the indexes (i.e. ignores the current position). -------------- next part -------------- An HTML attachment was scrubbed... URL: From brett.okken.os at gmail.com Wed Jul 2 15:58:04 2025 From: brett.okken.os at gmail.com (Brett Okken) Date: Wed, 2 Jul 2025 10:58:04 -0500 Subject: StringCharBuffer and bulk get In-Reply-To: <08950E51-883A-47E2-B013-F6F4E9B1499B@oracle.com> References: <08950E51-883A-47E2-B013-F6F4E9B1499B@oracle.com> Message-ID: My question here specifically is about treating a CharBuffer as a CharSequence. The specific issue here is that when acting as a CharSequence, all the pre-jdk25 methods are relative indexes. JDK 25 added a new method to CharSequence, but the implementation in CharBuffer uses absolute indexes. This also means that implementation in CharBuffer is not consistent with the default implementation in CharSequence. It seems it should just be optimized - not change the actual behavior. This makes it very difficult to pass a CharBuffer (where the position is not 0) to an api taking a CharSequence - because if that api makes a switch to start using getChars (rather than charAt), it will break. On Wed, Jul 2, 2025 at 10:40?AM Brian Burkhalter wrote: > > Some methods are absolute and some relative: > > https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/nio/Buffer.html#transferring-data-heading > > On Jul 2, 2025, at 8:35?AM, Brett Okken wrote: > > CharBuffer implementation of public default void getChars(int > srcBegin, int srcEnd, char[] dst, int dstBegin) uses absolute > positioning for the indexes (i.e. ignores the current position). > > From brett.okken.os at gmail.com Wed Jul 2 16:00:14 2025 From: brett.okken.os at gmail.com (Brett Okken) Date: Wed, 2 Jul 2025 11:00:14 -0500 Subject: StringCharBuffer and bulk get In-Reply-To: References: <08950E51-883A-47E2-B013-F6F4E9B1499B@oracle.com> Message-ID: Actually it looks like the CharBuffer java doc explicitly states that all CharSequence should be relative: > This class implements the CharSequence interface so that character buffers may be used wherever character sequences are accepted, for example in the regular-expression package java.util.regex. The methods defined by CharSequence operate relative to the current position of the buffer when they are invoked. https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/nio/CharBuffer.html On Wed, Jul 2, 2025 at 10:58?AM Brett Okken wrote: > > My question here specifically is about treating a CharBuffer as a CharSequence. > > The specific issue here is that when acting as a CharSequence, all the > pre-jdk25 methods are relative indexes. JDK 25 added a new method to > CharSequence, but the implementation in CharBuffer uses absolute > indexes. > This also means that implementation in CharBuffer is not consistent > with the default implementation in CharSequence. It seems it should > just be optimized - not change the actual behavior. > > This makes it very difficult to pass a CharBuffer (where the position > is not 0) to an api taking a CharSequence - because if that api makes > a switch to start using getChars (rather than charAt), it will break. > > On Wed, Jul 2, 2025 at 10:40?AM Brian Burkhalter > wrote: > > > > Some methods are absolute and some relative: > > > > https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/nio/Buffer.html#transferring-data-heading > > > > On Jul 2, 2025, at 8:35?AM, Brett Okken wrote: > > > > CharBuffer implementation of public default void getChars(int > > srcBegin, int srcEnd, char[] dst, int dstBegin) uses absolute > > positioning for the indexes (i.e. ignores the current position). > > > > From rriggs at openjdk.org Wed Jul 2 16:02:41 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 2 Jul 2025 16:02:41 GMT Subject: RFR: 8334015: Add Support for UUID Version 7 (UUIDv7) defined in RFC 9562 [v10] In-Reply-To: References: <4b4eB1IhNlZXMVqf-aOj-IIp3kwLiqOVfeqioc2dL9Q=.8af3f74b-7b61-424a-b2c6-421fa6e0c0e6@github.com> Message-ID: On Wed, 2 Jul 2025 10:08:53 GMT, Kieran Farrell wrote: >> Indeed, the sections of the RFC mentioned by @jaikiran do require timestamps to be (strictly) monotonic. The method `monotonicMS()` does not fulfill this requirement. There are some methods described in ?6.2 to help ensuring monotonicity. >> >> While it is true that the 74 bits of randomness help in creating unique ID with high probability, the requirements for the timestamp part in UUID Version 7 seem more restrictive than just uniqueness. > > Hi Jaikiran, You are correct in that the current implementation only supports uniqueness among time clashes and not monotonicity. Although section 5.7 UUID version 7 states that adding monotonic or extra precision bits is optional and that the millisecond portion along with the random bits is sufficient, section 6.2 does state: > >> Take care to ensure UUIDs generated in batches are also monotonic. That is, if one thousand UUIDs are generated for the same timestamp, there should be sufficient logic for organizing the creation order of those one thousand UUIDs > > The use of 'should' here makes it seem like this is a strong recommendation rather than a mandate. Regardless, it might be benifical to better satisfy this guidance. Since we don't currently have access to higher precision time, updating the implementation to include a dedicated counter would be the only viable approach, and comes at the cost of performance. RFC 2119 defines the intention for the word SHOULD, allowing some optionality. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25303#discussion_r2180437393 From brian.burkhalter at oracle.com Wed Jul 2 16:03:11 2025 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 2 Jul 2025 16:03:11 +0000 Subject: StringCharBuffer and bulk get In-Reply-To: References: <08950E51-883A-47E2-B013-F6F4E9B1499B@oracle.com> Message-ID: <440A8C84-C544-4C70-A254-5B83AD974030@oracle.com> I think that this discussion should be redirected to nio-dev: https://mail.openjdk.org/pipermail/nio-dev/ On Jul 2, 2025, at 9:00?AM, Brett Okken wrote: Actually it looks like the CharBuffer java doc explicitly states that all CharSequence should be relative: This class implements the CharSequence interface so that character buffers may be used wherever character sequences are accepted, for example in the regular-expression package java.util.regex. The methods defined by CharSequence operate relative to the current position of the buffer when they are invoked. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rriggs at openjdk.org Wed Jul 2 16:11:46 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 2 Jul 2025 16:11:46 GMT Subject: RFR: 8334015: Add Support for UUID Version 7 (UUIDv7) defined in RFC 9562 [v10] In-Reply-To: References: <4b4eB1IhNlZXMVqf-aOj-IIp3kwLiqOVfeqioc2dL9Q=.8af3f74b-7b61-424a-b2c6-421fa6e0c0e6@github.com> Message-ID: On Wed, 2 Jul 2025 15:59:47 GMT, Roger Riggs wrote: >> Hi Jaikiran, You are correct in that the current implementation only supports uniqueness among time clashes and not monotonicity. Although section 5.7 UUID version 7 states that adding monotonic or extra precision bits is optional and that the millisecond portion along with the random bits is sufficient, section 6.2 does state: >> >>> Take care to ensure UUIDs generated in batches are also monotonic. That is, if one thousand UUIDs are generated for the same timestamp, there should be sufficient logic for organizing the creation order of those one thousand UUIDs >> >> The use of 'should' here makes it seem like this is a strong recommendation rather than a mandate. Regardless, it might be benifical to better satisfy this guidance. Since we don't currently have access to higher precision time, updating the implementation to include a dedicated counter would be the only viable approach, and comes at the cost of performance. > > RFC 2119 defines the intention for the word SHOULD, allowing some optionality. At a minimum, the javadoc should specify the parameters used to generate UUID instances so that an application can decide for itself whether it meets the application's requirements. Note also the tradeoff between performance and rate of generation. To expose higher granularity (than milli-seconds) would require a different API and synchronization. Applications are also free to specify and implement their own algorithm for creating the 128 bits and create UUID instances with the UUID(long, long) or UUID(byte[]) constructors. The system time and nano-time are readily available. There is little information about application requirements to inform the API. If additional operational requirements come to light, a new factory method can be implemented to meet the need. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25303#discussion_r2180456180 From brian.burkhalter at oracle.com Wed Jul 2 16:25:16 2025 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 2 Jul 2025 16:25:16 +0000 Subject: StringCharBuffer and bulk get In-Reply-To: <440A8C84-C544-4C70-A254-5B83AD974030@oracle.com> References: <08950E51-883A-47E2-B013-F6F4E9B1499B@oracle.com> <440A8C84-C544-4C70-A254-5B83AD974030@oracle.com> Message-ID: <07F276E4-D10B-42F5-B6FB-10B0B22B4C79@oracle.com> Sorry, I intended nio-dev at openjdk.org. On Jul 2, 2025, at 9:03?AM, Brian Burkhalter wrote: I think that this discussion should be redirected to nio-dev: https://mail.openjdk.org/pipermail/nio-dev/ On Jul 2, 2025, at 9:00?AM, Brett Okken wrote: Actually it looks like the CharBuffer java doc explicitly states that all CharSequence should be relative: This class implements the CharSequence interface so that character buffers may be used wherever character sequences are accepted, for example in the regular-expression package java.util.regex. The methods defined by CharSequence operate relative to the current position of the buffer when they are invoked. -------------- next part -------------- An HTML attachment was scrubbed... URL: From naoto at openjdk.org Wed Jul 2 16:25:44 2025 From: naoto at openjdk.org (Naoto Sato) Date: Wed, 2 Jul 2025 16:25:44 GMT Subject: Withdrawn: 8360774: Use text representation of normalization data files In-Reply-To: References: Message-ID: On Fri, 27 Jun 2025 20:45:14 GMT, Naoto Sato wrote: > The ICU4J component currently stores binary data files directly in the repository. This change replaces them with base64-encoded text files and converts them to binary during the build process This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/26027 From igraves at openjdk.org Wed Jul 2 16:56:19 2025 From: igraves at openjdk.org (Ian Graves) Date: Wed, 2 Jul 2025 16:56:19 GMT Subject: RFR: 8358768: [vectorapi] Make VectorOperators.SUADD an Associative Message-ID: Adding SUADD an associative operation in the Vector API. Saturated addition on fixed-width unsigned integers is provably associative. ------------- Commit messages: - Adding associative support for SUADD and associated tests Changes: https://git.openjdk.org/jdk/pull/26099/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26099&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8358768 Stats: 1300 lines in 35 files changed: 1299 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/26099.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26099/head:pull/26099 PR: https://git.openjdk.org/jdk/pull/26099 From rgiulietti at openjdk.org Wed Jul 2 17:52:59 2025 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Wed, 2 Jul 2025 17:52:59 GMT Subject: RFR: 8320759: Creation of random BigIntegers can be made faster [v3] In-Reply-To: References: Message-ID: On Wed, 6 Dec 2023 15:07:59 GMT, fabioromano1 wrote: >> So, item 1 is a non-issue and item 2 is not likely a problem in practice. What, if anything, will be done about item 3? > > @bplb Maybe an assertion at the end of `randomBits(int, Random)` method, or a test class. @fabioromano1 Do you perhaps intend to reopen this PR? ------------- PR Comment: https://git.openjdk.org/jdk/pull/16817#issuecomment-3028801479 From alan.bateman at oracle.com Wed Jul 2 18:19:11 2025 From: alan.bateman at oracle.com (Alan Bateman) Date: Wed, 2 Jul 2025 19:19:11 +0100 Subject: StringCharBuffer and bulk get In-Reply-To: References: <08950E51-883A-47E2-B013-F6F4E9B1499B@oracle.com> Message-ID: On 02/07/2025 16:58, Brett Okken wrote: > : > > This makes it very difficult to pass a CharBuffer (where the position > is not 0) to an api taking a CharSequence - because if that api makes > a switch to start using getChars (rather than charAt), it will break. > Thanks for bringing this up. It does need attention. I just chatted with Brian Burkhalter so he's going to look through the spec + implementation changes to address this. If there is any risk or uncertainty then it mean pulling this out. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From liach at openjdk.org Wed Jul 2 18:44:00 2025 From: liach at openjdk.org (Chen Liang) Date: Wed, 2 Jul 2025 18:44:00 GMT Subject: RFR: 8360163: Create annotations to mark dumping method handles and runtime setup required classes [v7] In-Reply-To: References: Message-ID: > I have updated this patch to avoid a redundant `runtimeSetup` annotation - we have agreed that the requirement for setup is a side effect of initialization, and such methods in AOTCI classes must be automatically recognized. This latest revision implements that model. > > I intentionally avoided handling Class and ClassLoader `resetArchivedStates` and `MethodType::assemblySetup` - we talked about a generic `assemblyCleanup` method, but I did not find out where is the best place to call such a method in the assembly phase. We cna handle this in a subsequent patch. > > In particular, please review the new AOT.md design document - I split it from the AOTCI annotation to prevent jamming; we can put general AOT information there when we have more AOT-specific annotations. > > --- > > Old description: > Currently, the list of classes that have interdependencies and those that need runtimeSetup are maintained in a hardcoded list in CDS. This makes it risky for core library developers as they might introduce new interdependencies and observe CDS to fail. By moving the mechanism of these lists to core library annotations as a first step, we can gradually expose the AOT contracts as program semantics described by internal annotations, and also helps us to explore how we can expose these functionalities to the public later. Chen Liang has updated the pull request incrementally with one additional commit since the last revision: Don't fail for patching tests ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25922/files - new: https://git.openjdk.org/jdk/pull/25922/files/4b3906aa..4af1a6af Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25922&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25922&range=05-06 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25922.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25922/head:pull/25922 PR: https://git.openjdk.org/jdk/pull/25922 From liach at openjdk.org Wed Jul 2 18:47:58 2025 From: liach at openjdk.org (Chen Liang) Date: Wed, 2 Jul 2025 18:47:58 GMT Subject: RFR: 8360163: Create annotations to mark dumping method handles and runtime setup required classes [v8] In-Reply-To: References: Message-ID: > I have updated this patch to avoid a redundant `runtimeSetup` annotation - we have agreed that the requirement for setup is a side effect of initialization, and such methods in AOTCI classes must be automatically recognized. This latest revision implements that model. > > I intentionally avoided handling Class and ClassLoader `resetArchivedStates` and `MethodType::assemblySetup` - we talked about a generic `assemblyCleanup` method, but I did not find out where is the best place to call such a method in the assembly phase. We cna handle this in a subsequent patch. > > In particular, please review the new AOT.md design document - I split it from the AOTCI annotation to prevent jamming; we can put general AOT information there when we have more AOT-specific annotations. > > --- > > Old description: > Currently, the list of classes that have interdependencies and those that need runtimeSetup are maintained in a hardcoded list in CDS. This makes it risky for core library developers as they might introduce new interdependencies and observe CDS to fail. By moving the mechanism of these lists to core library annotations as a first step, we can gradually expose the AOT contracts as program semantics described by internal annotations, and also helps us to explore how we can expose these functionalities to the public later. Chen Liang has updated the pull request incrementally with one additional commit since the last revision: Documentation ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25922/files - new: https://git.openjdk.org/jdk/pull/25922/files/4af1a6af..9f6bbd9c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25922&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25922&range=06-07 Stats: 8 lines in 2 files changed: 7 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25922.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25922/head:pull/25922 PR: https://git.openjdk.org/jdk/pull/25922 From brian.burkhalter at oracle.com Wed Jul 2 18:55:48 2025 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 2 Jul 2025 18:55:48 +0000 Subject: StringCharBuffer and bulk get In-Reply-To: References: <08950E51-883A-47E2-B013-F6F4E9B1499B@oracle.com> Message-ID: <892102A7-D6F7-43BE-9753-F4B70091DE76@oracle.com> On Jul 2, 2025, at 11:19?AM, Alan Bateman wrote: On 02/07/2025 16:58, Brett Okken wrote: : This makes it very difficult to pass a CharBuffer (where the position is not 0) to an api taking a CharSequence - because if that api makes a switch to start using getChars (rather than charAt), it will break. Thanks for bringing this up. It does need attention. I just chatted with Brian Burkhalter so he's going to look through the spec + implementation changes to address this. If there is any risk or uncertainty then it mean pulling this out. It looks like only CharBuffer.getChars is broken so the rest of the change can stay. I filed this issue to track it: https://bugs.openjdk.org/browse/JDK-8361299 The fix is straightforward but will break a test and require a CSR. Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From liach at openjdk.org Wed Jul 2 19:26:17 2025 From: liach at openjdk.org (Chen Liang) Date: Wed, 2 Jul 2025 19:26:17 GMT Subject: RFR: 8361300: Document exceptions for Unsafe offset methods Message-ID: Unsafe throws IAE for misusing static vs instance fields, and it's revealed that AtomicXxxFieldUpdaters are using this mechanism to reject static fields. This is not a good practice, but we can at least document this so we don't accidentally introduce problems. ------------- Commit messages: - Simplify - Add static check - Document IAE for Unsafe offset methods Changes: https://git.openjdk.org/jdk/pull/25945/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25945&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8361300 Stats: 25 lines in 5 files changed: 16 ins; 0 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/25945.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25945/head:pull/25945 PR: https://git.openjdk.org/jdk/pull/25945 From duke at openjdk.org Wed Jul 2 19:26:18 2025 From: duke at openjdk.org (ExE Boss) Date: Wed, 2 Jul 2025 19:26:18 GMT Subject: RFR: 8361300: Document exceptions for Unsafe offset methods In-Reply-To: References: Message-ID: On Tue, 24 Jun 2025 00:04:54 GMT, Chen Liang wrote: > Unsafe throws IAE for misusing static vs instance fields, and it's revealed that AtomicXxxFieldUpdaters are using this mechanism to reject static fields. This is not a good practice, but we can at least document this so we don't accidentally introduce problems. I?noticed?that the?native implementation of?`Unsafe?::array?(BaseOffset?/IndexScale)` refers?to the?non?existent class?`java.lang.InvalidClassException` instead of?`java.lang.IllegalArgumentException` (which?results in?`java.lang.NoClassDefFoundError` being?thrown): https://github.com/openjdk/jdk/blob/1ca008fd02496dc33e2707c102560cae1690fba5/src/hotspot/share/prims/unsafe.cpp#L587-L594 src/hotspot/share/prims/unsafe.cpp line 498: > 496: if (fs.access_flags().is_static()) { > 497: offset = -1; > 498: } else { Since?`offset` is?initialised to?`-1`, this?can simply?do: Suggestion: if (!fs.access_flags().is_static()) { src/java.base/share/classes/jdk/internal/misc/Unsafe.java line 1070: > 1068: * > 1069: * @throws NullPointerException if the field is {@code null} > 1070: * @throws IllegalArgumentException if the field is static Maybe?these?checks could?be?done in?**Java**?like: // implicit null check: if ((f.getModifiers() & ACC_STATIC) != 0) { throw new IllegalArgumentException("Field is static"); } and?for the?`staticField(Offset/Base)`?methods: // implicit null check: if ((f.getModifiers() & ACC_STATIC) == 0) { throw new IllegalArgumentException("Field is not static"); } src/java.base/share/classes/jdk/internal/misc/Unsafe.java line 1092: > 1090: * in class {@code c}, i.e., if {@code c.getDeclaredField(name)} > 1091: * would throw {@code java.lang.NoSuchFieldException}, or if such > 1092: * a field is static This?is?actually not?the?case, the?native?code only?checks whether the?field?exists, not?whether it?s?also not?`static`: https://github.com/openjdk/jdk/blob/cbcf401170e0600e48ef74770eaa47c84c7e50b0/src/hotspot/share/prims/unsafe.cpp#L492-L503 Suggestion: * would throw {@code java.lang.NoSuchFieldException}. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25945#issuecomment-3007131955 PR Review Comment: https://git.openjdk.org/jdk/pull/25945#discussion_r2164661450 PR Review Comment: https://git.openjdk.org/jdk/pull/25945#discussion_r2164571411 PR Review Comment: https://git.openjdk.org/jdk/pull/25945#discussion_r2164571852 From liach at openjdk.org Wed Jul 2 19:26:18 2025 From: liach at openjdk.org (Chen Liang) Date: Wed, 2 Jul 2025 19:26:18 GMT Subject: RFR: 8361300: Document exceptions for Unsafe offset methods In-Reply-To: References: Message-ID: On Tue, 24 Jun 2025 00:04:54 GMT, Chen Liang wrote: > Unsafe throws IAE for misusing static vs instance fields, and it's revealed that AtomicXxxFieldUpdaters are using this mechanism to reject static fields. This is not a good practice, but we can at least document this so we don't accidentally introduce problems. For arrayBaseOffset/IndexScale, I don't think I will change it here: they are methods that are exposed via sun.misc.Unsafe. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25945#issuecomment-3029047897 From liach at openjdk.org Wed Jul 2 19:26:18 2025 From: liach at openjdk.org (Chen Liang) Date: Wed, 2 Jul 2025 19:26:18 GMT Subject: RFR: 8361300: Document exceptions for Unsafe offset methods In-Reply-To: References: Message-ID: <-PaFLZAuGHijTUXUlAdJ3mPefIAt0TOURgPj72PamdA=.09dd4c05-ca65-48c2-b64a-0e5423a6f359@github.com> On Tue, 24 Jun 2025 18:34:02 GMT, ExE Boss wrote: >> Unsafe throws IAE for misusing static vs instance fields, and it's revealed that AtomicXxxFieldUpdaters are using this mechanism to reject static fields. This is not a good practice, but we can at least document this so we don't accidentally introduce problems. > > src/hotspot/share/prims/unsafe.cpp line 498: > >> 496: if (fs.access_flags().is_static()) { >> 497: offset = -1; >> 498: } else { > > Since?`offset` is?initialised to?`-1`, this?can simply?do: > Suggestion: > > if (!fs.access_flags().is_static()) { True. Meanwhile I think I will add a comment to indicate this intends to fail fast when a matching static field is encountered. > src/java.base/share/classes/jdk/internal/misc/Unsafe.java line 1070: > >> 1068: * >> 1069: * @throws NullPointerException if the field is {@code null} >> 1070: * @throws IllegalArgumentException if the field is static > > Maybe?these?checks could?be?done in?**Java**?like: > > // implicit null check: > if ((f.getModifiers() & ACC_STATIC) != 0) { > throw new IllegalArgumentException("Field is static"); > } > > and?for the?`staticField(Offset/Base)`?methods: > > // implicit null check: > if ((f.getModifiers() & ACC_STATIC) == 0) { > throw new IllegalArgumentException("Field is not static"); > } Don't think anyone is willing to change code here... > src/java.base/share/classes/jdk/internal/misc/Unsafe.java line 1092: > >> 1090: * in class {@code c}, i.e., if {@code c.getDeclaredField(name)} >> 1091: * would throw {@code java.lang.NoSuchFieldException}, or if such >> 1092: * a field is static > > This?is?actually not?the?case, the?native?code only?checks whether the?field?exists, not?whether it?s?also not?`static`: > https://github.com/openjdk/jdk/blob/cbcf401170e0600e48ef74770eaa47c84c7e50b0/src/hotspot/share/prims/unsafe.cpp#L492-L503 > > Suggestion: > > * would throw {@code java.lang.NoSuchFieldException}. Hmm, didn't know that field stream included static fields ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25945#discussion_r2164666239 PR Review Comment: https://git.openjdk.org/jdk/pull/25945#discussion_r2164623978 PR Review Comment: https://git.openjdk.org/jdk/pull/25945#discussion_r2164623202 From liach at openjdk.org Wed Jul 2 19:26:18 2025 From: liach at openjdk.org (Chen Liang) Date: Wed, 2 Jul 2025 19:26:18 GMT Subject: RFR: 8361300: Document exceptions for Unsafe offset methods In-Reply-To: <-PaFLZAuGHijTUXUlAdJ3mPefIAt0TOURgPj72PamdA=.09dd4c05-ca65-48c2-b64a-0e5423a6f359@github.com> References: <-PaFLZAuGHijTUXUlAdJ3mPefIAt0TOURgPj72PamdA=.09dd4c05-ca65-48c2-b64a-0e5423a6f359@github.com> Message-ID: <3txKdBpCETHPOp_Dd2IH29b_muPVacABqp5Yw8pX9pk=.ea4e0012-c545-4ed0-9867-e533bf6d93d5@github.com> On Tue, 24 Jun 2025 18:16:29 GMT, Chen Liang wrote: >> src/java.base/share/classes/jdk/internal/misc/Unsafe.java line 1070: >> >>> 1068: * >>> 1069: * @throws NullPointerException if the field is {@code null} >>> 1070: * @throws IllegalArgumentException if the field is static >> >> Maybe?these?checks could?be?done in?**Java**?like: >> >> // implicit null check: >> if ((f.getModifiers() & ACC_STATIC) != 0) { >> throw new IllegalArgumentException("Field is static"); >> } >> >> and?for the?`staticField(Offset/Base)`?methods: >> >> // implicit null check: >> if ((f.getModifiers() & ACC_STATIC) == 0) { >> throw new IllegalArgumentException("Field is not static"); >> } > > Don't think anyone is willing to change code here... That said, the only places that depend on this IAE behavior is the AtomicXxxFieldUpdater classes. All other sites pass trusted fields into these methods, of course besides the sun.misc.Unsafe users which definitely need this IAE. Still I personally prefer adding these checks to atomic field updaters instead of here to reduce risky dependencies. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25945#discussion_r2164671689 From brett.okken.os at gmail.com Wed Jul 2 20:05:43 2025 From: brett.okken.os at gmail.com (Brett Okken) Date: Wed, 2 Jul 2025 15:05:43 -0500 Subject: StringCharBuffer and bulk get In-Reply-To: <892102A7-D6F7-43BE-9753-F4B70091DE76@oracle.com> References: <08950E51-883A-47E2-B013-F6F4E9B1499B@oracle.com> <892102A7-D6F7-43BE-9753-F4B70091DE76@oracle.com> Message-ID: > It looks like only CharBuffer.getChars is broken so the rest of the change can stay. I filed this issue to track it: > > https://bugs.openjdk.org/browse/JDK-8361299 > > The fix is straightforward but will break a test and require a CSR. Looks like the testNG GetChars has cb.getChars(cb.position(), cb.limit(), dst, 0); but that should have been cb.getChars(0, cb.remaining(), dst, 0); or cb.getChars(0, cb.length(), dst, 0); - Brett From brian.burkhalter at oracle.com Wed Jul 2 20:09:36 2025 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 2 Jul 2025 20:09:36 +0000 Subject: StringCharBuffer and bulk get In-Reply-To: References: <08950E51-883A-47E2-B013-F6F4E9B1499B@oracle.com> <892102A7-D6F7-43BE-9753-F4B70091DE76@oracle.com> Message-ID: <07D9B721-4BEB-4070-BA6D-B8A154D15B8F@oracle.com> > On Jul 2, 2025, at 1:05?PM, Brett Okken wrote: > >> It looks like only CharBuffer.getChars is broken so the rest of the change can stay. I filed this issue to track it: >> >> https://bugs.openjdk.org/browse/JDK-8361299 >> >> The fix is straightforward but will break a test and require a CSR. > > > Looks like the testNG GetChars has > > cb.getChars(cb.position(), cb.limit(), dst, 0); > > but that should have been > > cb.getChars(0, cb.remaining(), dst, 0); It?s this one ^. Thanks, Brian > or > > cb.getChars(0, cb.length(), dst, 0); > > - Brett From iklam at openjdk.org Wed Jul 2 21:21:40 2025 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 2 Jul 2025 21:21:40 GMT Subject: RFR: 8360163: Create annotations to mark dumping method handles and runtime setup required classes [v8] In-Reply-To: References: Message-ID: On Wed, 2 Jul 2025 18:47:58 GMT, Chen Liang wrote: >> I have updated this patch to avoid a redundant `runtimeSetup` annotation - we have agreed that the requirement for setup is a side effect of initialization, and such methods in AOTCI classes must be automatically recognized. This latest revision implements that model. >> >> I intentionally avoided handling Class and ClassLoader `resetArchivedStates` and `MethodType::assemblySetup` - we talked about a generic `assemblyCleanup` method, but I did not find out where is the best place to call such a method in the assembly phase. We cna handle this in a subsequent patch. >> >> In particular, please review the new AOT.md design document - I split it from the AOTCI annotation to prevent jamming; we can put general AOT information there when we have more AOT-specific annotations. >> >> --- >> >> Old description: >> Currently, the list of classes that have interdependencies and those that need runtimeSetup are maintained in a hardcoded list in CDS. This makes it risky for core library developers as they might introduce new interdependencies and observe CDS to fail. By moving the mechanism of these lists to core library annotations as a first step, we can gradually expose the AOT contracts as program semantics described by internal annotations, and also helps us to explore how we can expose these functionalities to the public later. > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > Documentation Changes requested by iklam (Reviewer). src/hotspot/share/cds/aotClassInitializer.cpp line 219: > 217: // MethodHandleStatics is an example of a class that must NOT get the aot-init treatment, > 218: // because of its strong reliance on (a) final fields which are (b) environmentally determined. > 219: if (ik->has_aot_safe_initializer()) { I think the above 4 lines of comments can be deleted, as this topic is already covered in AOTSafeClassInitializer.java. src/hotspot/share/classfile/classFileParser.cpp line 5171: > 5169: InstanceKlass* intf = _transitive_interfaces->at(i); > 5170: if (intf->class_initializer() != nullptr) { > 5171: if (!intf->has_aot_safe_initializer()) { I think this is better, so you don't need to annotate a supertypes that have no `` if (intf->class_initializer() != nullptr && !intf->has_aot_safe_initializer()) { src/hotspot/share/oops/instanceKlassFlags.hpp line 58: > 56: flag(has_final_method , 1 << 13) /* True if klass has final method */ \ > 57: flag(has_aot_safe_initializer , 1 << 14) /* has @AOTSafeClassInitializer annotation */ \ > 58: flag(is_runtime_setup_required , 1 << 15) /* has a runtimeSetup method to be called */ \ This information is useful only during CDS dumping. Since `_flags` has limited width (only 16 bits) we should avoid using these bits but rather put the information inside `DumpTimeClassInfo`. However, there's a complication here, as `DumpTimeClassInfo` is not yet created when you call `set_has_aot_safe_initializer()`. I think you can go ahead with the current design. I will make a follow-up PR to move the creation of `DumpTimeClassInfo` to an earlier time. Then I'll move these two bits into `DumpTimeClassInfo`. That way we can accommodate more annotations in the future. ------------- PR Review: https://git.openjdk.org/jdk/pull/25922#pullrequestreview-2980604461 PR Review Comment: https://git.openjdk.org/jdk/pull/25922#discussion_r2180955211 PR Review Comment: https://git.openjdk.org/jdk/pull/25922#discussion_r2180988960 PR Review Comment: https://git.openjdk.org/jdk/pull/25922#discussion_r2180982768 From duke at openjdk.org Wed Jul 2 21:34:55 2025 From: duke at openjdk.org (fabioromano1) Date: Wed, 2 Jul 2025 21:34:55 GMT Subject: RFR: 8320759: Creation of random BigIntegers can be made faster [v3] In-Reply-To: References: Message-ID: On Wed, 2 Jul 2025 17:50:28 GMT, Raffaello Giulietti wrote: >> @bplb Maybe an assertion at the end of `randomBits(int, Random)` method, or a test class. > > @fabioromano1 Do you perhaps intend to reopen this PR? @rgiulietti Yes, I will reopen this PR in future. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16817#issuecomment-3029383596 From bpb at openjdk.org Wed Jul 2 21:37:00 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 2 Jul 2025 21:37:00 GMT Subject: RFR: 8358533: Improve performance of java.io.Reader.readAllLines [v11] In-Reply-To: References: Message-ID: > Replaces the implementation `readAllCharsAsString().lines().toList()` with reading into a temporary `char` array which is then processed to detect line terminators and copy non-terminating characters into strings which are added to the list. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8358533: Decrease value of minGrowth parameter ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25863/files - new: https://git.openjdk.org/jdk/pull/25863/files/9eeed767..12196413 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25863&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25863&range=09-10 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25863.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25863/head:pull/25863 PR: https://git.openjdk.org/jdk/pull/25863 From rgiulietti at openjdk.org Wed Jul 2 21:43:53 2025 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Wed, 2 Jul 2025 21:43:53 GMT Subject: RFR: 8320759: Creation of random BigIntegers can be made faster [v3] In-Reply-To: References: Message-ID: On Sat, 2 Dec 2023 15:42:18 GMT, fabioromano1 wrote: >> A faster and simpler way to generate random BigIntegers, avoiding eventually trimming of leading zeros in magnitude array. > > fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: > > Create RandomBigIntegers.java > > Create a benchmark to measure the performance of BigInteger(int, Random) constructor implementation. Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/16817#issuecomment-3029402371 From liach at openjdk.org Wed Jul 2 23:21:39 2025 From: liach at openjdk.org (Chen Liang) Date: Wed, 2 Jul 2025 23:21:39 GMT Subject: RFR: 8360163: Create annotations to mark dumping method handles and runtime setup required classes [v8] In-Reply-To: References: Message-ID: On Wed, 2 Jul 2025 21:18:14 GMT, Ioi Lam wrote: >> Chen Liang has updated the pull request incrementally with one additional commit since the last revision: >> >> Documentation > > src/hotspot/share/classfile/classFileParser.cpp line 5171: > >> 5169: InstanceKlass* intf = _transitive_interfaces->at(i); >> 5170: if (intf->class_initializer() != nullptr) { >> 5171: if (!intf->has_aot_safe_initializer()) { > > I think this is better, so you don't need to annotate a supertypes that have no `` > > > if (intf->class_initializer() != nullptr && !intf->has_aot_safe_initializer()) { Also quick question: Should I use `_transitive_interfaces` or can I use `_local_interfaces`? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25922#discussion_r2181136140 From iklam at openjdk.org Thu Jul 3 00:11:39 2025 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 3 Jul 2025 00:11:39 GMT Subject: RFR: 8360163: Create annotations to mark dumping method handles and runtime setup required classes [v8] In-Reply-To: References: Message-ID: On Wed, 2 Jul 2025 23:18:38 GMT, Chen Liang wrote: >> src/hotspot/share/classfile/classFileParser.cpp line 5171: >> >>> 5169: InstanceKlass* intf = _transitive_interfaces->at(i); >>> 5170: if (intf->class_initializer() != nullptr) { >>> 5171: if (!intf->has_aot_safe_initializer()) { >> >> I think this is better, so you don't need to annotate a supertypes that have no `` >> >> >> if (intf->class_initializer() != nullptr && !intf->has_aot_safe_initializer()) { > > Also quick question: Should I use `_transitive_interfaces` or can I use `_local_interfaces`? local_interfaces is fine, because the interfaces implemented by the super classes would have been checked when the super classes were loaded. BTW, the error message should include the name of both this class and the supertype: classfile_parse_error("AOTSafeClassInitlaizer annotation is required for supertype %s of %s", ... And the checks can be refactored in a separate function to avoid repetition. if (_super_klass != nullptr) { check_aot_safe_initializer(ik, _super_klass, CHECK); } int len = _local_interfaces->length(); for (int i = 0; i < len; i++) { check_aot_safe_initializer(ik, _local_interfaces->at(i), CHECK); } ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25922#discussion_r2181197886 From iklam at openjdk.org Thu Jul 3 00:14:39 2025 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 3 Jul 2025 00:14:39 GMT Subject: RFR: 8360163: Create annotations to mark dumping method handles and runtime setup required classes [v8] In-Reply-To: References: Message-ID: On Wed, 2 Jul 2025 18:47:58 GMT, Chen Liang wrote: >> I have updated this patch to avoid a redundant `runtimeSetup` annotation - we have agreed that the requirement for setup is a side effect of initialization, and such methods in AOTCI classes must be automatically recognized. This latest revision implements that model. >> >> I intentionally avoided handling Class and ClassLoader `resetArchivedStates` and `MethodType::assemblySetup` - we talked about a generic `assemblyCleanup` method, but I did not find out where is the best place to call such a method in the assembly phase. We cna handle this in a subsequent patch. >> >> In particular, please review the new AOT.md design document - I split it from the AOTCI annotation to prevent jamming; we can put general AOT information there when we have more AOT-specific annotations. >> >> --- >> >> Old description: >> Currently, the list of classes that have interdependencies and those that need runtimeSetup are maintained in a hardcoded list in CDS. This makes it risky for core library developers as they might introduce new interdependencies and observe CDS to fail. By moving the mechanism of these lists to core library annotations as a first step, we can gradually expose the AOT contracts as program semantics described by internal annotations, and also helps us to explore how we can expose these functionalities to the public later. > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > Documentation src/hotspot/share/classfile/classFileParser.cpp line 2684: > 2682: if (name != vmSymbols::runtimeSetup() || signature != vmSymbols::void_method_signature() || > 2683: !access_flags.is_private() || !access_flags.is_static()) { > 2684: classfile_parse_error("Incorrect runtimeSetup method declaration in class file %s", CHECK_NULL); Error message should be more specific: "AOTRuntimeSetup annotation requires the method to be static private void runtimeSetup() for class %s" ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25922#discussion_r2181200542 From duke at openjdk.org Thu Jul 3 01:46:41 2025 From: duke at openjdk.org (simon) Date: Thu, 3 Jul 2025 01:46:41 GMT Subject: RFR: 8360122: Fix java.sql\Connection.java indentation [v4] In-Reply-To: <0UfkXxOmp7jsEH0cPOPBDoh8osWoz6Jp6A8jLh-CmDE=.57a3938f-ba6d-48ee-9caf-ecd3c10678cb@github.com> References: <0UfkXxOmp7jsEH0cPOPBDoh8osWoz6Jp6A8jLh-CmDE=.57a3938f-ba6d-48ee-9caf-ecd3c10678cb@github.com> Message-ID: <_YDKPqPvEXlcYuTlaYEiXd9JHJeYmjZMt2fMOOK1QAY=.f29c7bff-9c72-4347-beda-7c4a186190ee@github.com> On Wed, 2 Jul 2025 14:37:04 GMT, Lance Andersen wrote: >> simon has updated the pull request incrementally with one additional commit since the last revision: >> >> 8360122: revert reformatting method signatures > > src/java.sql/share/classes/java/sql/Connection.java line 303: > >> 301: //====================================================================== >> 302: // Advanced features: >> 303: > > Why was this removed as this is not format related It was just a suggestion, but it?s not really related to the main change. I can remove it if you think it?s appropriate ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25925#discussion_r2181347375 From duke at openjdk.org Thu Jul 3 01:59:58 2025 From: duke at openjdk.org (simon) Date: Thu, 3 Jul 2025 01:59:58 GMT Subject: RFR: 8360122: Fix java.sql\Connection.java indentation [v5] In-Reply-To: References: Message-ID: > 8360122: Refine formatting of Connection.java interface > > --------- > ### Progress > - [ ] Change must be properly reviewed (1 review required, with at least 1 [Reviewer](https://openjdk.org/bylaws#reviewer)) > - [x] Change must not contain extraneous whitespace > - [x] Commit message must refer to an issue > > > > ### Reviewing >
    Using git > > Checkout this PR locally: \ > `$ git fetch https://git.openjdk.org/jdk.git pull/25925/head:pull/25925` \ > `$ git checkout pull/25925` > > Update a local copy of the PR: \ > `$ git checkout pull/25925` \ > `$ git pull https://git.openjdk.org/jdk.git pull/25925/head` > >
    >
    Using Skara CLI tools > > Checkout this PR locally: \ > `$ git pr checkout 25925` > > View PR using the GUI difftool: \ > `$ git pr show -t 25925` > >
    >
    Using diff file > > Download this PR as a diff file: \ > https://git.openjdk.org/jdk/pull/25925.diff > >
    >
    Using Webrev > > [Link to Webrev Comment](https://git.openjdk.org/jdk/pull/25925#issuecomment-2993856738) >
    simon has updated the pull request incrementally with one additional commit since the last revision: 8360122: refactored method throws clauses to be inline ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25925/files - new: https://git.openjdk.org/jdk/pull/25925/files/21696cf7..c14699a8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25925&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25925&range=03-04 Stats: 20 lines in 1 file changed: 0 ins; 10 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/25925.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25925/head:pull/25925 PR: https://git.openjdk.org/jdk/pull/25925 From duke at openjdk.org Thu Jul 3 01:59:59 2025 From: duke at openjdk.org (simon) Date: Thu, 3 Jul 2025 01:59:59 GMT Subject: RFR: 8360122: Fix java.sql\Connection.java indentation [v4] In-Reply-To: <0UfkXxOmp7jsEH0cPOPBDoh8osWoz6Jp6A8jLh-CmDE=.57a3938f-ba6d-48ee-9caf-ecd3c10678cb@github.com> References: <0UfkXxOmp7jsEH0cPOPBDoh8osWoz6Jp6A8jLh-CmDE=.57a3938f-ba6d-48ee-9caf-ecd3c10678cb@github.com> Message-ID: On Wed, 2 Jul 2025 15:14:47 GMT, Lance Andersen wrote: >> simon has updated the pull request incrementally with one additional commit since the last revision: >> >> 8360122: revert reformatting method signatures > > src/java.sql/share/classes/java/sql/Connection.java line 1175: > >> 1173: */ >> 1174: void setClientInfo(String name, String value) >> 1175: throws SQLClientInfoException; > > The throws clause could be moved up Fixed > src/java.sql/share/classes/java/sql/Connection.java line 1208: > >> 1206: */ >> 1207: void setClientInfo(Properties properties) >> 1208: throws SQLClientInfoException; > > The throws clause could be moved up Fixed > src/java.sql/share/classes/java/sql/Connection.java line 1232: > >> 1230: * @see java.sql.DatabaseMetaData#getClientInfoProperties >> 1231: */ >> 1232: String getClientInfo(String name) > > the throws clause could be moved up Fixed > src/java.sql/share/classes/java/sql/Connection.java line 1251: > >> 1249: */ >> 1250: Properties getClientInfo() >> 1251: throws SQLException; > > The throws clause could be moved up Fixed ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25925#discussion_r2181380031 PR Review Comment: https://git.openjdk.org/jdk/pull/25925#discussion_r2181379915 PR Review Comment: https://git.openjdk.org/jdk/pull/25925#discussion_r2181379825 PR Review Comment: https://git.openjdk.org/jdk/pull/25925#discussion_r2181379234 From duke at openjdk.org Thu Jul 3 02:03:39 2025 From: duke at openjdk.org (simon) Date: Thu, 3 Jul 2025 02:03:39 GMT Subject: RFR: 8360122: Fix java.sql\Connection.java indentation [v2] In-Reply-To: References: Message-ID: On Mon, 23 Jun 2025 17:45:02 GMT, Lance Andersen wrote: >> simon has updated the pull request incrementally with one additional commit since the last revision: >> >> 8360122: refactor code formatting to enforce 100 chars line length limit for improved readability > > I might not have time this week to look at this as I have some other commitments. I do think we will want to narrow the changes being proposed @LanceAndersen I moved up the throws clauses of other methods in Connection.java, as @RogerRiggs suggested, to maintain consistent formatting in this class. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25925#issuecomment-3030228941 From duke at openjdk.org Thu Jul 3 03:20:47 2025 From: duke at openjdk.org (duke) Date: Thu, 3 Jul 2025 03:20:47 GMT Subject: Withdrawn: 8353795: Add Writer.of(StringBuilder) In-Reply-To: <2xEfp_WiAa-QW5Yao7JoOS3zSOtPKvBq4qV5rk8obWs=.2b1cc84d-2ff4-4d0c-bb0f-bdb276dc109a@github.com> References: <2xEfp_WiAa-QW5Yao7JoOS3zSOtPKvBq4qV5rk8obWs=.2b1cc84d-2ff4-4d0c-bb0f-bdb276dc109a@github.com> Message-ID: On Sat, 5 Apr 2025 17:36:29 GMT, Markus KARG wrote: > This Pull Requests proposes an implementation for [JDK-8353795](https://bugs.openjdk.org/browse/JDK-8353795): Adding the new method `public static Writer Writer.of(StringBuilder)`, providing a non-synchronized Writer implementation optimized for writing into `StringBuilder`. > > A basic test is provided to proof that the new `Writer` behaves as expected. For comparison, the same test is also run against `StringWriter`. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/24469 From alanb at openjdk.org Thu Jul 3 05:45:39 2025 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 3 Jul 2025 05:45:39 GMT Subject: RFR: 8361300: Document exceptions for Unsafe offset methods In-Reply-To: References: Message-ID: On Tue, 24 Jun 2025 00:04:54 GMT, Chen Liang wrote: > Unsafe throws IAE for misusing static vs instance fields, and it's revealed that AtomicXxxFieldUpdaters are using this mechanism to reject static fields. This is not a good practice, but we can at least document this so we don't accidentally introduce problems. src/java.base/share/classes/java/util/concurrent/atomic/AtomicIntegerFieldUpdater.java line 417: > 415: ? caller : tclass; > 416: this.tclass = tclass; > 417: this.offset = U.objectFieldOffset(field); // throws IAE for static AtomicIntegerFieldUpdaterImpl already checks the field type and it is volatile. I think it would be better to expand these checks so that static volatile fields are rejected there rather than "accidentally" calling objectFieldOffset with a static field. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25945#discussion_r2181841464 From xgong at openjdk.org Thu Jul 3 06:10:28 2025 From: xgong at openjdk.org (Xiaohong Gong) Date: Thu, 3 Jul 2025 06:10:28 GMT Subject: RFR: 8359419: AArch64: Relax min vector length to 32-bit for short vectors [v3] In-Reply-To: References: Message-ID: <7VTRz_XqYBSdQ54n7ADzTzYADZjDbgBw6XuW0jehSLI=.24d18b87-4553-47ab-8065-d92fbb5700ae@github.com> > ### Background > On AArch64, the minimum vector length supported is 64-bit for basic types, except for `byte` and `boolean` (32-bit and 16-bit respectively to match special Vector API features). This limitation prevents intrinsification of vector type conversions between `short` and wider types (e.g. `long/double`) in Vector API when the entire vector length is within 128 bits, resulting in degraded performance for such conversions. > > For example, type conversions between `ShortVector.SPECIES_128` and `LongVector.SPECIES_128` are not supported on AArch64 NEON and SVE architectures with 128-bit max vector size. This occurs because the compiler would need to generate a vector with 2 short elements, resulting in a 32-bit vector size. > > To intrinsify such type conversion APIs, we need to relax the min vector length constraint from 64-bit to 32-bit for short vectors. > > ### Impact Analysis > #### 1. Vector types > Vectors only with `short` element types will be affected, as we just supported 32-bit `short` vectors in this change. > > #### 2. Vector API > No impact on Vector API or the vector-specific nodes. The minimum vector shape at API level remains 64-bit. It's not possible to generate a final vector IR with 32-bit vector size. Type conversions may generate intermediate 32-bit vectors, but they will be resized or cast to vectors with at least 64-bit length. > > #### 3. Auto-vectorization > Enables vectorization of cases containing only 2 `short` lanes, with significant performance improvements. Since we have supported 32-bit vectors for `byte` type for a long time, extending this to `short` did not introduce additional risks. > > #### 4. Codegen of vector nodes > NEON doesn't support 32-bit SIMD instructions, so we use 64-bit instructions instead. For lanewise operations, this is safe because the higher half bits can be ignored. > > Details: > - Lanewise vector operations are unaffected as explained above. > - NEON supports vector load/store instructions with 32-bit vector size, which we already use in relevant IRs (shared by SVE). > - Cross-lane operations like reduction may be affected, potentially causing incorrect results for `min/max/mul/and` reductions. The min vector size for such operations should remain 64-bit. We've added assertions in match rules. Since it's currently not possible to generate such reductions (Vector API minimum is 64-bit, and SLP doesn't support subword type reductions), we maintain the status quo. However, adding an explicit vector size check in `match_rule_s... Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision: Refine the comment in ad file ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26057/files - new: https://git.openjdk.org/jdk/pull/26057/files/4e15e588..dfda42a3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26057&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26057&range=01-02 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/26057.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26057/head:pull/26057 PR: https://git.openjdk.org/jdk/pull/26057 From tkiriyama at openjdk.org Thu Jul 3 06:49:49 2025 From: tkiriyama at openjdk.org (Takuya Kiriyama) Date: Thu, 3 Jul 2025 06:49:49 GMT Subject: RFR: 8352016: Improve java/lang/RuntimeTests/RuntimeExitLogTest.java [v3] In-Reply-To: References: Message-ID: On Fri, 4 Apr 2025 10:29:43 GMT, Takuya Kiriyama wrote: >> The current test program for the logging feature added in JDK-8301627 does not fully check some important cases. >> >> Issue Details: >> The test does not properly check cases where logging might not happen due to different logging levels. (e.g. ALL, TRACE, WARNING, etc.) >> The check for the logged stack trace is not enough, as it does not confirm enough details in the output. >> >> Fix Details: >> Added more test cases to check behavior under different logging levels. >> Improved the stack trace check by verifying more details in the logged output. >> These changes make the test more complete and ensure that the logging feature works as expected. >> Also, any existing test cases prior to this pull request are retained. >> >> The test was verified in the following OS environments, and it passed successfully in both environments. >> - Windows Server 2022 Standard 21H2 >> - Red Hat Enterprise Linux release 9.2 (Plow) >> >> Could you please review this fix? > > Takuya Kiriyama has updated the pull request incrementally with one additional commit since the last revision: > > 8352016: Improve java/lang/RuntimeTests/RuntimeExitLogTest.java Thanks for the review! ------------- PR Comment: https://git.openjdk.org/jdk/pull/24050#issuecomment-3031069608 From tkiriyama at openjdk.org Thu Jul 3 06:49:50 2025 From: tkiriyama at openjdk.org (Takuya Kiriyama) Date: Thu, 3 Jul 2025 06:49:50 GMT Subject: Integrated: 8352016: Improve java/lang/RuntimeTests/RuntimeExitLogTest.java In-Reply-To: References: Message-ID: <0fbqyQH-sLdVi3yh_qUvtD78lJRb-7rhicLoNexmJtQ=.8fa636b5-904b-4649-8342-6910e1e7d3c6@github.com> On Fri, 14 Mar 2025 09:17:06 GMT, Takuya Kiriyama wrote: > The current test program for the logging feature added in JDK-8301627 does not fully check some important cases. > > Issue Details: > The test does not properly check cases where logging might not happen due to different logging levels. (e.g. ALL, TRACE, WARNING, etc.) > The check for the logged stack trace is not enough, as it does not confirm enough details in the output. > > Fix Details: > Added more test cases to check behavior under different logging levels. > Improved the stack trace check by verifying more details in the logged output. > These changes make the test more complete and ensure that the logging feature works as expected. > Also, any existing test cases prior to this pull request are retained. > > The test was verified in the following OS environments, and it passed successfully in both environments. > - Windows Server 2022 Standard 21H2 > - Red Hat Enterprise Linux release 9.2 (Plow) > > Could you please review this fix? This pull request has now been integrated. Changeset: 1926aeb1 Author: Takuya Kiriyama URL: https://git.openjdk.org/jdk/commit/1926aeb1a3b39cf2e4ea48f4c489cd023b5aa77d Stats: 110 lines in 8 files changed: 90 ins; 0 del; 20 mod 8352016: Improve java/lang/RuntimeTests/RuntimeExitLogTest.java Reviewed-by: rriggs ------------- PR: https://git.openjdk.org/jdk/pull/24050 From duke at openjdk.org Thu Jul 3 07:03:49 2025 From: duke at openjdk.org (erifan) Date: Thu, 3 Jul 2025 07:03:49 GMT Subject: RFR: 8354242: VectorAPI: combine vector not operation with compare [v7] In-Reply-To: <15TW6hiffz65NhHevPefL_6swSC07UD-GwiJ4tPDtFs=.b83081df-8abd-4756-b4e0-1d969678a0d2@github.com> References: <15TW6hiffz65NhHevPefL_6swSC07UD-GwiJ4tPDtFs=.b83081df-8abd-4756-b4e0-1d969678a0d2@github.com> Message-ID: On Thu, 5 Jun 2025 11:05:48 GMT, Emanuel Peter wrote: >>> > FYI: `BoolTest::negate` already does what you want: `mask negate( ) const { return mask(_test^4); }` I think you should use that instead :) >>> >>> Indeed, I hadn't noticed that, thank you. >> >> Oh I think we still cannot use `BoolTest::negate`, because we cannot instantiate a `BoolTest` object with **unsigned** comparison. `BoolTest::negate` is a non-static function. > >> Oh I think we still cannot use `BoolTest::negate`, because we cannot instantiate a `BoolTest` object with **unsigned** comparison. `BoolTest::negate` is a non-static function. > > I see. Ok. Hmm. I still think that the logic should be in `BoolTest`, because that is where the exact implementation of the enum values is. In that context it is easier to see why `^4` does the negation. And imagine we were ever to change the enum values, then it would be harder to find your code and fix it. > > Maybe it could be called `BoolTest::negate_mask(mast btm)` and explain in a comment that both signed and unsigned is supported. Hi @eme64 @jatin-bhateja , would you mind taking another look of this PR, thanks~ ------------- PR Comment: https://git.openjdk.org/jdk/pull/24674#issuecomment-3031109432 From alanb at openjdk.org Thu Jul 3 07:05:43 2025 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 3 Jul 2025 07:05:43 GMT Subject: RFR: 8334015: Add Support for UUID Version 7 (UUIDv7) defined in RFC 9562 [v12] In-Reply-To: References: Message-ID: <0aWMgDcLLb77dhbIH-gZgRyxjBS0xi9Rt9XvrPSqXqU=.aed892d2-e248-42f7-aa6a-948e2ed65151@github.com> On Wed, 2 Jul 2025 10:46:56 GMT, Kieran Farrell wrote: >> With the recent approval of UUIDv7 (https://datatracker.ietf.org/doc/rfc9562/), this PR aims to add a new static method UUID.timestampUUID() which constructs and returns a UUID in support of the new time generated UUID version. >> >> The specification requires embedding the current timestamp in milliseconds into the first bits 0?47. The version number in bits 48?51, bits 52?63 are available for sub-millisecond precision or for pseudorandom data. The variant is set in bits 64?65. The remaining bits 66?127 are free to use for more pseudorandom data or to employ a counter based approach for increased time percision (https://www.rfc-editor.org/rfc/rfc9562.html#name-uuid-version-7). >> >> The choice of implementation comes down to balancing the sensitivity level of being able to distingush UUIDs created below <1ms apart with performance. A test simulating a high-concurrency environment with 4 threads generating 10000 UUIDv7 values in parallel to measure the collision rate of each implementation (the amount of times the time based portion of the UUID was not unique and entries could not distinguished by time) yeilded the following results for each implemtation: >> >> >> - random-byte-only - 99.8% >> - higher-precision - 3.5% >> - counter-based - 0% >> >> >> Performance tests show a decrease in performance as expected with the counter based implementation due to the introduction of synchronization: >> >> - random-byte-only 143.487 ? 10.932 ns/op >> - higher-precision 149.651 ? 8.438 ns/op >> - counter-based 245.036 ? 2.943 ns/op >> >> The best balance here might be to employ a higher-precision implementation as the large increase in time sensitivity comes at a very slight performance cost. > > Kieran Farrell has updated the pull request incrementally with one additional commit since the last revision: > > rm whitespace src/java.base/share/classes/java/util/UUID.java line 212: > 210: * @since 26 > 211: */ > 212: public static UUID unixEpochTimeMillis() { Is there a list anywhere on the names that have been discussed already? Asking because the existing static factory method for a type 4 is randomUUID(). Also, there are several methods (esp. in java.time) that use "Epoch" in method names name rather than "Unix Epoch". Also if you rename the timestamp parameter to something that includes "millis" in the name then it would help usage in IDEs where it's more obvious at the use-site that the parameter is in millis. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25303#discussion_r2182017482 From jpai at openjdk.org Thu Jul 3 07:17:44 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 3 Jul 2025 07:17:44 GMT Subject: RFR: 8361018: Re-examine buffering and encoding conversion in BufferedWriter [v6] In-Reply-To: References: Message-ID: <6o5VBnWWZEpIwPsRrXFWwRO6S7hwnfPQVMhrnD97FkM=.f9e3d344-2757-48fd-957c-d92e5e83e8e8@github.com> On Tue, 1 Jul 2025 00:01:21 GMT, Shaojin Wen wrote: >> BufferedWriter -> OutputStreamWriter -> StreamEncoder >> >> In this call chain, BufferedWriter has a char[] buffer, and StreamEncoder has a ByteBuffer. There are two layers of cache here, or the BufferedWriter layer can be removed. And when charset is UTF8, if the content of write(String) is LATIN1, a conversion from LATIN1 to UTF16 and then to LATIN1 will occur here. >> >> LATIN1 -> UTF16 -> UTF8 >> >> We can improve BufferedWriter. When the parameter Writer instanceof OutputStreamWriter is passed in, remove the cache and call it directly. In addition, improve write(String) in StreamEncoder to avoid unnecessary encoding conversion. > > Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: > > Revert "BufferedWriter buffer use StringBuilder" > > This reverts commit da902ca0b0bd6acc003deb8ad1ca0d6485a29a27. I agree with Roger - introducing new methods on JavaLangAccess to access the methods on String/StringBuilder and related core APIs is not the way to engineer the implementation of these APIs. I believe the whole exercise in this PR is premature, and it's not the first time either. The contributor opened a mail in the core-libs-dev mailing list, did not wait to hear from the people knowledegable in this area, went ahead and created a JBS issue, then created a PR and linked the PR to that issue which generated an official RFR inviting official reviews, when the entire idea is half baked. In all of this, the PR has zero regression tests added/referenced with the changes. In the mailing list discussion, the contributor was asked if they had looked into the tests to ensure whether there is enough coverage for these changes and what kind of testing might have been done https://mail.openjdk.org/pipermail/core-libs-dev/2025-June/148231.html. The response from the contributor is this https://mail.openjdk.org/pipermail/core-libs-dev/2025-June/148236.html which says that a new micro benchmark shows some percentage. I haven't seen any indication in the reply, stating what kind of tes ting has been done or what tests have been analyzed and why no new tests have been added. This isn't the first PR of such nature either, so I am not leaning towards giving the benefit of doubt that maybe the contributor misunderstood the question, I believe it's way past that point now. Changes like these require additional tests or a detailed analysis and explanation about which tests cover these changes and why new tests cannot be introduced. I believe pointing to new manually run microbenchmarks and claiming these are performance driven changes isn't appropriate. Some reviewers try and stay away from PRs like these for valid reasons. Some reviewers do allow some benefit of doubt to the contributors who are new (the current contributor isn't) and help/guide them in such PRs, and that's a good thing. But when PRs are linked against JBS issue and have generated a RFR, it becomes extremely hard to stay away from reviewing those when the proposed changes are going in a direction that isn't maintainable. Dragging in the JBS infrastructure and the official review process in these experimental changes wastes a lot of time, energy and patience. My suggestion is to put this PR into draft mode, edit the subject of the PR to remove the reference to the JBS issue so that it hopefully doesn't generate additional RFR mails and then go back to the original email discussion in core-libs-dev and seek inputs on how or whether these changes should be done. It's OK if that process takes a (very) long time, that's intentional for changes like these. It's also OK if the contributor doesn't have the time or doesn't wish to follow the slow nature of these discussions and then implementing those changes in a way which keeps it maintainable and adds and exercises the relevant tests. They can ask people familiar with this area whether the proposed idea merits creating a JBS issue and only then create one so that anyone else who is willing to follow these processes can pursue it further. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26022#issuecomment-3031150436 From kfarrell at openjdk.org Thu Jul 3 08:47:20 2025 From: kfarrell at openjdk.org (Kieran Farrell) Date: Thu, 3 Jul 2025 08:47:20 GMT Subject: RFR: 8334015: Add Support for UUID Version 7 (UUIDv7) defined in RFC 9562 [v13] In-Reply-To: References: Message-ID: > With the recent approval of UUIDv7 (https://datatracker.ietf.org/doc/rfc9562/), this PR aims to add a new static method UUID.timestampUUID() which constructs and returns a UUID in support of the new time generated UUID version. > > The specification requires embedding the current timestamp in milliseconds into the first bits 0?47. The version number in bits 48?51, bits 52?63 are available for sub-millisecond precision or for pseudorandom data. The variant is set in bits 64?65. The remaining bits 66?127 are free to use for more pseudorandom data or to employ a counter based approach for increased time percision (https://www.rfc-editor.org/rfc/rfc9562.html#name-uuid-version-7). > > The choice of implementation comes down to balancing the sensitivity level of being able to distingush UUIDs created below <1ms apart with performance. A test simulating a high-concurrency environment with 4 threads generating 10000 UUIDv7 values in parallel to measure the collision rate of each implementation (the amount of times the time based portion of the UUID was not unique and entries could not distinguished by time) yeilded the following results for each implemtation: > > > - random-byte-only - 99.8% > - higher-precision - 3.5% > - counter-based - 0% > > > Performance tests show a decrease in performance as expected with the counter based implementation due to the introduction of synchronization: > > - random-byte-only 143.487 ? 10.932 ns/op > - higher-precision 149.651 ? 8.438 ns/op > - counter-based 245.036 ? 2.943 ns/op > > The best balance here might be to employ a higher-precision implementation as the large increase in time sensitivity comes at a very slight performance cost. Kieran Farrell has updated the pull request incrementally with one additional commit since the last revision: update note to @api note ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25303/files - new: https://git.openjdk.org/jdk/pull/25303/files/a72f1834..be7dea7a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25303&range=12 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25303&range=11-12 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25303.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25303/head:pull/25303 PR: https://git.openjdk.org/jdk/pull/25303 From kfarrell at openjdk.org Thu Jul 3 09:55:43 2025 From: kfarrell at openjdk.org (Kieran Farrell) Date: Thu, 3 Jul 2025 09:55:43 GMT Subject: RFR: 8334015: Add Support for UUID Version 7 (UUIDv7) defined in RFC 9562 [v12] In-Reply-To: <0aWMgDcLLb77dhbIH-gZgRyxjBS0xi9Rt9XvrPSqXqU=.aed892d2-e248-42f7-aa6a-948e2ed65151@github.com> References: <0aWMgDcLLb77dhbIH-gZgRyxjBS0xi9Rt9XvrPSqXqU=.aed892d2-e248-42f7-aa6a-948e2ed65151@github.com> Message-ID: On Thu, 3 Jul 2025 07:03:19 GMT, Alan Bateman wrote: >> Kieran Farrell has updated the pull request incrementally with one additional commit since the last revision: >> >> rm whitespace > > src/java.base/share/classes/java/util/UUID.java line 212: > >> 210: * @since 26 >> 211: */ >> 212: public static UUID unixEpochTimeMillis() { > > Is there a list anywhere on the names that have been discussed already? Asking because the existing static factory method for a type 4 is randomUUID(). Also, there are several methods (esp. in java.time) that use "Epoch" in method names name rather than "Unix Epoch". Also if you rename the timestamp parameter to something that includes "millis" in the name then it would help usage in IDEs where it's more obvious at the use-site that the parameter is in millis. The original proposed name was `timestampUUID` but it was decided against to avoid confusion with UUID-v1, which is also time-based, there hasnt been much discussion beyond that. Maybe something like `epochMilliUUID()` would better follow the naming conventions? Reagarding the parameter, updating to something like `epochMillis` or `timestampMillis` would make sense. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25303#discussion_r2182365873 From jpai at openjdk.org Thu Jul 3 11:48:41 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 3 Jul 2025 11:48:41 GMT Subject: RFR: 8354872: Clarify java.lang.Process resource cleanup [v4] In-Reply-To: References: <39KIPIXZDBI9tpPyXew2Ye-uzPvkLSQnOzGJFuK9E2Y=.dc8df88f-f21a-4dd6-8297-5629098bd408@github.com> Message-ID: On Wed, 2 Jul 2025 14:52:06 GMT, Roger Riggs wrote: >> Improve the documentation of Process use of system resources. >> >> Describe the implementation closing streams when no longer referenced. >> Clarify the interactions between inputStream and inputReader and errorStream and errorReader. >> Add advice and example using try-with-resources to open and close streams. >> Recommend closing streams when no longer in use. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Fix links per review comments and snippet syntax in ProcessBuilder.Redirect.DISCARD. src/java.base/share/classes/java/lang/Process.java line 113: > 111: * releasing the operating system resources. > 112: * {@code Try-with-resources} can be used to open and close the streams. > 113: *

    For example, to capture the output of a program known to produce some output and then exit: Hello Roger, co-incidentally, I was experimenting with the `Process` APIs in a different area. The code snippet that we recommend here will only capture the standard output of the invoked process. Although the sentence here says "output" of a program, do you think we should make it more clearer that it's the standard output of the program? Arguably, since the snippet already uses `inputReader()` whose javadoc notes that it represents the standard output, then maybe the additional clarification isn't needed? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25884#discussion_r2182579944 From aph at openjdk.org Thu Jul 3 13:34:23 2025 From: aph at openjdk.org (Andrew Haley) Date: Thu, 3 Jul 2025 13:34:23 GMT Subject: RFR: 8360884: Better scoped values [v5] In-Reply-To: <8yqi3J3JfLa2NNags9waBIshIMIuOJRjm-rHF--Wjws=.d04990af-5fdb-4218-a8da-60bda679b1d1@github.com> References: <8yqi3J3JfLa2NNags9waBIshIMIuOJRjm-rHF--Wjws=.d04990af-5fdb-4218-a8da-60bda679b1d1@github.com> Message-ID: <8YDqH1VyzAZP8rE_p3dnZSiFIj3Fe0Z3WAwYjC4Zd90=.1be6948e-658a-4677-84e8-d4051b909627@github.com> > Scoped values cannot be used early in the JDK boot process because of some dependencies on System.getProperty(). This dependency should be removed in a way that allows scoped values to be created (but not necessarily bound) at any stage during boot. > > Also, Scoped Value's constructor has a synchronized block, which limits the use of scoped values at runtime. Constructing a scoped value should be a thread-local operation. Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: Little things. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26019/files - new: https://git.openjdk.org/jdk/pull/26019/files/f8ff2965..c87e8367 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26019&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26019&range=03-04 Stats: 6 lines in 1 file changed: 2 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/26019.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26019/head:pull/26019 PR: https://git.openjdk.org/jdk/pull/26019 From rriggs at openjdk.org Thu Jul 3 13:43:44 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 3 Jul 2025 13:43:44 GMT Subject: RFR: 8358533: Improve performance of java.io.Reader.readAllLines [v11] In-Reply-To: References: Message-ID: On Wed, 2 Jul 2025 21:37:00 GMT, Brian Burkhalter wrote: >> Replaces the implementation `readAllCharsAsString().lines().toList()` with reading into a temporary `char` array which is then processed to detect line terminators and copy non-terminating characters into strings which are added to the list. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8358533: Decrease value of minGrowth parameter Look good. Thanks Another review would be good too. ------------- Marked as reviewed by rriggs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25863#pullrequestreview-2983245903 PR Comment: https://git.openjdk.org/jdk/pull/25863#issuecomment-3032324398 From liach at openjdk.org Thu Jul 3 13:45:02 2025 From: liach at openjdk.org (Chen Liang) Date: Thu, 3 Jul 2025 13:45:02 GMT Subject: RFR: 8355536: Create version constants to model preview language and vm features [v6] In-Reply-To: References: Message-ID: > Sometimes, for version-specific feature access APIs, we wish to access the preview features of the current Java SE release. To reduce the impact of adding one preview-specific version on every site, we can add a constant modeling the preview features as a fake version. Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains nine commits: - Merge branch 'master' of https://github.com/openjdk/jdk into feature/preview-cffv - Merge branch 'master' of https://github.com/openjdk/jdk into feature/preview-cffv - Update src/java.base/share/classes/java/lang/reflect/ClassFileFormatVersion.java - Update src/java.compiler/share/classes/javax/lang/model/SourceVersion.java Co-authored-by: Luca Kellermann - Don't need to update latestSupported later - Merge branch 'pr/25015' of https://github.com/openjdk/jdk into feature/preview-cffv - JDK-8356108: Update SourceVersion.RELEASE_25 description for JEPs 511 and 512 - Add advanced testing for different latestSupported - 8355536: Create version constants to model preview language and vm features ------------- Changes: https://git.openjdk.org/jdk/pull/25017/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25017&range=05 Stats: 1265 lines in 6 files changed: 1123 ins; 83 del; 59 mod Patch: https://git.openjdk.org/jdk/pull/25017.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25017/head:pull/25017 PR: https://git.openjdk.org/jdk/pull/25017 From liach at openjdk.org Thu Jul 3 13:56:24 2025 From: liach at openjdk.org (Chen Liang) Date: Thu, 3 Jul 2025 13:56:24 GMT Subject: RFR: 8361300: Document exceptions for Unsafe offset methods [v2] In-Reply-To: References: Message-ID: > Unsafe throws IAE for misusing static vs instance fields, and it's revealed that AtomicXxxFieldUpdaters are using this mechanism to reject static fields. This is not a good practice, but we can at least document this so we don't accidentally introduce problems. Chen Liang has updated the pull request incrementally with one additional commit since the last revision: Explicit static checks ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25945/files - new: https://git.openjdk.org/jdk/pull/25945/files/db465d72..904237c6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25945&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25945&range=00-01 Stats: 12 lines in 3 files changed: 9 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/25945.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25945/head:pull/25945 PR: https://git.openjdk.org/jdk/pull/25945 From liach at openjdk.org Thu Jul 3 14:08:23 2025 From: liach at openjdk.org (Chen Liang) Date: Thu, 3 Jul 2025 14:08:23 GMT Subject: RFR: 8361300: Document exceptions for Unsafe offset methods [v3] In-Reply-To: References: Message-ID: > Unsafe throws IAE for misusing static vs instance fields, and it's revealed that AtomicXxxFieldUpdaters are using this mechanism to reject static fields. This is not a good practice, but we can at least document this so we don't accidentally introduce problems. Chen Liang has updated the pull request incrementally with one additional commit since the last revision: Add tck coverage ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25945/files - new: https://git.openjdk.org/jdk/pull/25945/files/904237c6..c8fcf03c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25945&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25945&range=01-02 Stats: 34 lines in 3 files changed: 34 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/25945.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25945/head:pull/25945 PR: https://git.openjdk.org/jdk/pull/25945 From liach at openjdk.org Thu Jul 3 14:08:23 2025 From: liach at openjdk.org (Chen Liang) Date: Thu, 3 Jul 2025 14:08:23 GMT Subject: RFR: 8361300: Document exceptions for Unsafe offset methods [v2] In-Reply-To: References: Message-ID: On Thu, 3 Jul 2025 13:56:24 GMT, Chen Liang wrote: >> Unsafe throws IAE for misusing static vs instance fields, and it's revealed that AtomicXxxFieldUpdaters are using this mechanism to reject static fields. This is not a good practice, but we can at least document this so we don't accidentally introduce problems. > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > Explicit static checks Thanks for this permission to update the Atomic updaters. I found that there's no coverage in tck when these IAE on static fields are acknowledged recently, so I took the liberty to add them. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25945#issuecomment-3032406801 From liach at openjdk.org Thu Jul 3 14:10:39 2025 From: liach at openjdk.org (Chen Liang) Date: Thu, 3 Jul 2025 14:10:39 GMT Subject: RFR: 8360884: Better scoped values [v5] In-Reply-To: <8YDqH1VyzAZP8rE_p3dnZSiFIj3Fe0Z3WAwYjC4Zd90=.1be6948e-658a-4677-84e8-d4051b909627@github.com> References: <8yqi3J3JfLa2NNags9waBIshIMIuOJRjm-rHF--Wjws=.d04990af-5fdb-4218-a8da-60bda679b1d1@github.com> <8YDqH1VyzAZP8rE_p3dnZSiFIj3Fe0Z3WAwYjC4Zd90=.1be6948e-658a-4677-84e8-d4051b909627@github.com> Message-ID: <3rOCE0Bx2azlW0m5Ad3gy35EVgoxFGzVpPB1j8w_WYk=.7e02a35d-c5be-4b19-852c-aa83795294d8@github.com> On Thu, 3 Jul 2025 13:34:23 GMT, Andrew Haley wrote: >> Scoped values cannot be used early in the JDK boot process because of some dependencies on System.getProperty(). This dependency should be removed in a way that allows scoped values to be created (but not necessarily bound) at any stage during boot. >> >> Also, Scoped Value's constructor has a synchronized block, which limits the use of scoped values at runtime. Constructing a scoped value should be a thread-local operation. > > Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: > > Little things. The latest updates to use stable static fields and to avoid double field read look good. ------------- Marked as reviewed by liach (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26019#pullrequestreview-2983343085 From rriggs at openjdk.org Thu Jul 3 14:25:43 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 3 Jul 2025 14:25:43 GMT Subject: RFR: 8354872: Clarify java.lang.Process resource cleanup [v4] In-Reply-To: References: <39KIPIXZDBI9tpPyXew2Ye-uzPvkLSQnOzGJFuK9E2Y=.dc8df88f-f21a-4dd6-8297-5629098bd408@github.com> Message-ID: On Thu, 3 Jul 2025 11:46:32 GMT, Jaikiran Pai wrote: >> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix links per review comments and snippet syntax in ProcessBuilder.Redirect.DISCARD. > > src/java.base/share/classes/java/lang/Process.java line 113: > >> 111: * releasing the operating system resources. >> 112: * {@code Try-with-resources} can be used to open and close the streams. >> 113: *

    For example, to capture the output of a program known to produce some output and then exit: > > Hello Roger, co-incidentally, I was experimenting with the `Process` APIs in a different area. The code snippet that we recommend here will only capture the standard output of the invoked process. Although the sentence here says "output" of a program, do you think we should make it more clearer that it's the standard output of the program? Arguably, since the snippet already uses `inputReader()` whose javadoc notes that it represents the standard output, then maybe the additional clarification isn't needed? `inputReader()` is specific as to the output of the sub-process and the example covers only the most common case. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25884#discussion_r2182928151 From liach at openjdk.org Thu Jul 3 14:26:42 2025 From: liach at openjdk.org (Chen Liang) Date: Thu, 3 Jul 2025 14:26:42 GMT Subject: RFR: 8360163: Create annotations to mark dumping method handles and runtime setup required classes [v8] In-Reply-To: References: Message-ID: <_33LVgbvoF-SWOlZNwVbaxNxhGWc7HmZf8sW4qd3gww=.66d0a41b-3c26-4a05-9f4d-0fddb2ac4a72@github.com> On Thu, 3 Jul 2025 00:09:14 GMT, Ioi Lam wrote: >> Also quick question: Should I use `_transitive_interfaces` or can I use `_local_interfaces`? > > local_interfaces is fine, because the interfaces implemented by the super classes would have been checked when the super classes were loaded. > > BTW, the error message should include the name of both this class and the supertype: > > > classfile_parse_error("AOTSafeClassInitlaizer annotation is required for supertype %s of %s", ... > > > And the checks can be refactored in a separate function to avoid repetition. > > > if (_super_klass != nullptr) { > check_aot_safe_initializer(ik, _super_klass, CHECK); > } > int len = _local_interfaces->length(); > for (int i = 0; i < len; i++) { > check_aot_safe_initializer(ik, _local_interfaces->at(i), CHECK); > } I don't want to introduce a new declaration in the header for this function - to shrink the size, I think I can use `guarantee_property` instead. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25922#discussion_r2182930135 From yujige at gmail.com Thu Jul 3 14:36:40 2025 From: yujige at gmail.com (Jige Yu) Date: Thu, 3 Jul 2025 07:36:40 -0700 Subject: Question about mapConcurrent() Behavior and Happens-Before Guarantees Message-ID: Hi JDK Core Devs, I'm writing to you today with a question about the behavior of mapConcurrent() and its interaction with unchecked exceptions. I've been experimenting with the API and observed that mapConcurrent() blocks and joins all virtual threads upon an unchecked exception before propagating it. Initially, I thought this design choice might provide a strong happens-before guarantee. My assumption was that an application catching a RuntimeException would be able to *observe all side effects* from the virtual threads, even though this practice is generally discouraged. This seemed like a potentially significant advantage, outweighing the risk of a virtual thread failing to respond to interruption or responding slowly. However, I've since realized that mapConcurrent() cannot fully guarantee a strong happens-before relationship when an unchecked exception occurs *somewhere* in the stream pipeline. While it can block and wait for exceptions thrown by the mapper function or downstream operations, it appears unable to intercept unchecked exceptions *thrown by an upstream* source. Consider a scenario with two input elements: if the first element starts a virtual thread, and then the second element causes an unchecked exception from the upstream *before* reaching the gather() call, the virtual thread initiated by the first element would not be interrupted. This makes the "happens-before" guarantee quite nuanced in practice. This brings me to my core questions: 1. Is providing a happens-before guarantee upon an unchecked exception a design goal for mapConcurrent()? 2. If not, would it be more desirable to *not* join on virtual threads when unchecked exceptions occur? This would allow the application code to catch the exception sooner and avoid the risk of being blocked indefinitely. Thank you for your time and insights. Best regards, Ben Yu -------------- next part -------------- An HTML attachment was scrubbed... URL: From pponec at gmail.com Thu Jul 3 15:08:38 2025 From: pponec at gmail.com (Pavel Ponec) Date: Thu, 3 Jul 2025 17:08:38 +0200 Subject: =?UTF-8?Q?RFD=3A_UnicodeCharacter_=E2=80=93_Object_representation_of_U?= =?UTF-8?Q?nicode_code_points?= Message-ID: Hi all, I'd like to propose the addition of a new object-oriented abstraction for representing full Unicode characters in Java: `UnicodeCharacter`. This class addresses a fundamental limitation of the current `Character` type, which wraps a single `char` and therefore cannot properly represent Unicode characters outside the Basic Multilingual Plane (BMP). With the growing importance of supplementary characters (e.g., emoji, non-Latin scripts, rare CJK glyphs), a more complete and object-oriented Unicode abstraction would be beneficial to the JDK. ### Motivation The `Character` type is limited to 16-bit `char` units, and cannot represent characters requiring surrogate pairs (code points > U+FFFF). Java developers working with text must often deal with `codePointAt`, `toChars`, and `offsetByCodePoints`, resulting in fragile and error-prone code. Furthermore, there's no immutable object type that cleanly encapsulates a single logical Unicode character. ### Proposed Class: UnicodeCharacter This proposal introduces a final, immutable class that wraps a valid Unicode code point and exposes convenient methods to work with it. A reference implementation is available here: https://github.com/pponec/ujorm/blob/master/project-m2/ujo-tools/src/main/java/org/ujorm/tools/common/UnicodeCharacter.java Highlights: ```java public final class UnicodeCharacter implements CharSequence, Comparable { public static UnicodeCharacter of(final int codePoint); public static UnicodeCharacter of(final CharSequence text, final int unicodeIndex); public int codePoint(); public char[] toChars(); public int charCount(); public boolean equals(char c); @Override public String toString(); @Override public int length(); @Override public char charAt(int index); @Override public CharSequence subSequence(int start, int end); } Benefits Proper support for the full Unicode range, including supplementary characters. Immutable and type-safe object model. Simpler and safer text iteration and processing. Aligns well with modern Java idioms, e.g. Stream from a String. Object-oriented alternative to repeated Character.toChars(...), codePointAt(...), etc. Compatibility The proposed class is entirely new and doesn't break any existing APIs. It complements existing types and uses only standard Java APIs. It can be introduced in the java.lang or java.text package without VM-level changes. Adoption This type can be used by libraries, UI frameworks, editors, and any text-processing tools where proper Unicode character semantics are critical. It promotes correctness in multilingual and emoji-rich applications. Please let me know if there's interest. I'm happy to further develop this idea into a JEP if the community agrees it's worth exploring. Best regards, Pavel Ponec pponec at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From alanb at openjdk.org Thu Jul 3 15:31:44 2025 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 3 Jul 2025 15:31:44 GMT Subject: RFR: 8360884: Better scoped values [v5] In-Reply-To: <8YDqH1VyzAZP8rE_p3dnZSiFIj3Fe0Z3WAwYjC4Zd90=.1be6948e-658a-4677-84e8-d4051b909627@github.com> References: <8yqi3J3JfLa2NNags9waBIshIMIuOJRjm-rHF--Wjws=.d04990af-5fdb-4218-a8da-60bda679b1d1@github.com> <8YDqH1VyzAZP8rE_p3dnZSiFIj3Fe0Z3WAwYjC4Zd90=.1be6948e-658a-4677-84e8-d4051b909627@github.com> Message-ID: On Thu, 3 Jul 2025 13:34:23 GMT, Andrew Haley wrote: >> Scoped values cannot be used early in the JDK boot process because of some dependencies on System.getProperty(). This dependency should be removed in a way that allows scoped values to be created (but not necessarily bound) at any stage during boot. >> >> Also, Scoped Value's constructor has a synchronized block, which limits the use of scoped values at runtime. Constructing a scoped value should be a thread-local operation. > > Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: > > Little things. Marked as reviewed by alanb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26019#pullrequestreview-2983662977 From liach at openjdk.org Thu Jul 3 16:53:25 2025 From: liach at openjdk.org (Chen Liang) Date: Thu, 3 Jul 2025 16:53:25 GMT Subject: RFR: 8360163: Create annotations to mark dumping method handles and runtime setup required classes [v9] In-Reply-To: References: Message-ID: > I have updated this patch to avoid a redundant `runtimeSetup` annotation - we have agreed that the requirement for setup is a side effect of initialization, and such methods in AOTCI classes must be automatically recognized. This latest revision implements that model. > > I intentionally avoided handling Class and ClassLoader `resetArchivedStates` and `MethodType::assemblySetup` - we talked about a generic `assemblyCleanup` method, but I did not find out where is the best place to call such a method in the assembly phase. We cna handle this in a subsequent patch. > > In particular, please review the new AOT.md design document - I split it from the AOTCI annotation to prevent jamming; we can put general AOT information there when we have more AOT-specific annotations. > > --- > > Old description: > Currently, the list of classes that have interdependencies and those that need runtimeSetup are maintained in a hardcoded list in CDS. This makes it risky for core library developers as they might introduce new interdependencies and observe CDS to fail. By moving the mechanism of these lists to core library annotations as a first step, we can gradually expose the AOT contracts as program semantics described by internal annotations, and also helps us to explore how we can expose these functionalities to the public later. Chen Liang has updated the pull request incrementally with one additional commit since the last revision: Reviews ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25922/files - new: https://git.openjdk.org/jdk/pull/25922/files/9f6bbd9c..47c5affa Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25922&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25922&range=07-08 Stats: 18 lines in 2 files changed: 0 ins; 7 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/25922.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25922/head:pull/25922 PR: https://git.openjdk.org/jdk/pull/25922 From davidalayachew at gmail.com Thu Jul 3 17:28:49 2025 From: davidalayachew at gmail.com (David Alayachew) Date: Thu, 3 Jul 2025 13:28:49 -0400 Subject: Question about mapConcurrent() Behavior and Happens-Before Guarantees In-Reply-To: References: Message-ID: These questions necessitate runnable examples. Do you have any On Thu, Jul 3, 2025, 10:37?AM Jige Yu wrote: > Hi JDK Core Devs, > > I'm writing to you today with a question about the behavior of > mapConcurrent() and its interaction with unchecked exceptions. I've been > experimenting with the API and observed that mapConcurrent() blocks and > joins all virtual threads upon an unchecked exception before propagating it. > > Initially, I thought this design choice might provide a strong > happens-before guarantee. My assumption was that an application catching a > RuntimeException would be able to *observe all side effects* from the > virtual threads, even though this practice is generally discouraged. This > seemed like a potentially significant advantage, outweighing the risk of a > virtual thread failing to respond to interruption or responding slowly. > > However, I've since realized that mapConcurrent() cannot fully guarantee > a strong happens-before relationship when an unchecked exception occurs > *somewhere* in the stream pipeline. While it can block and wait for > exceptions thrown by the mapper function or downstream operations, it > appears unable to intercept unchecked exceptions *thrown by an upstream* > source. > > Consider a scenario with two input elements: if the first element starts a > virtual thread, and then the second element causes an unchecked exception > from the upstream *before* reaching the gather() call, the virtual thread > initiated by the first element would not be interrupted. This makes the > "happens-before" guarantee quite nuanced in practice. > > This brings me to my core questions: > > 1. > > Is providing a happens-before guarantee upon an unchecked exception a > design goal for mapConcurrent()? > 2. > > If not, would it be more desirable to *not* join on virtual threads > when unchecked exceptions occur? This would allow the application code to > catch the exception sooner and avoid the risk of being blocked indefinitely. > > Thank you for your time and insights. > > Best regards, > > Ben Yu > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bchristi at openjdk.org Thu Jul 3 18:14:40 2025 From: bchristi at openjdk.org (Brent Christian) Date: Thu, 3 Jul 2025 18:14:40 GMT Subject: RFR: 8344332: (bf) Migrate DirectByteBuffer away from jdk.internal.ref.Cleaner [v7] In-Reply-To: References: Message-ID: <9rki3teH2JS04QJZA4zEmory8F8vnRhRnh9bBOIEey0=.3ac76f66-e9e0-45dd-bc5e-0c8bec56632c@github.com> On Sun, 29 Jun 2025 20:43:56 GMT, Kim Barrett wrote: >> This change makes java.nio no longer use jdk.internal.ref.Cleaner to manage >> native memory for Direct-X-Buffers. Instead it uses bespoke PhantomReferences >> and a dedicated ReferenceQueue. This differs from PR 22165, which proposed to >> use java.lang.ref.Cleaner. >> >> This change is algorithmically similar to the two previous versions: >> JDK-6857566 and JDK-8156500 (current mainline). The critical function is >> Bits::reserveMemory(). For both of those versions and this change, a thread >> calls that function and tries to reserve some space. If it fails, then it >> keeps trying until all cleaners deactivated (cleared) by prior GCs have been >> cleaned. If reservation still fails, then it invokes the GC to try to >> deactivate more cleaners for cleaning. After that GC it keeps trying the >> reservation and waiting for cleaning, with sleeps to avoid a spin loop, >> eventually either succeeding or giving up and throwing OOME. >> >> Retaining that algorithmic approach is one of the goals of this change, since >> it has been successfully in use since JDK 9 (and was originally developed and >> extensively tested in JDK 8). >> >> The key to this approach is having a way to determine that deactivated >> cleaners have been cleaned. JDK-6857566 accomplished this by having waiting >> threads help the reference processor until there was no available work. >> JDK-8156500 waits for the reference processor to quiesce, relying on its >> immediate processing of cleaners. java.lang.ref.Cleaner doesn't provide a way >> to do this, which is why this change rolls its own Cleaner-like mechanism from >> the underlying primitives. Like JDK-6857566, this change has waiting threads >> help with cleaning references. This was a potentially undesirable feature of >> JDK-6857566, as arbitrary allocating threads were invoking arbitrary cleaners. >> (Though by the time of JDK-6857566 the cleaners were only used by DBB, and >> became internal-only somewhere around that time as well.) That's not a concern >> here, as the cleaners involved are only from DBB, and we know what they look >> like. >> >> As noted in the discussion of JDK-6857566, it's good to have DBB cleaning >> being done off the reference processing thread, as it may be expensive and >> slow down enqueuing other pending references. JDK-6857566 only did some of >> that, and JDK-8156500 lost that feature. This change moves all of the DBB >> cleaning off of the reference processing thread. (So does PR 22165.) >> >> Neither JDK-6857566 nor this change are... > > Kim Barrett has updated the pull request incrementally with two additional commits since the last revision: > > - add @Override for clean() method > - more commentary for reserveMemory Marked as reviewed by bchristi (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25289#pullrequestreview-2984204948 From sherman at openjdk.org Thu Jul 3 18:15:43 2025 From: sherman at openjdk.org (Xueming Shen) Date: Thu, 3 Jul 2025 18:15:43 GMT Subject: RFR: 8358533: Improve performance of java.io.Reader.readAllLines [v11] In-Reply-To: References: Message-ID: On Wed, 2 Jul 2025 21:37:00 GMT, Brian Burkhalter wrote: >> Replaces the implementation `readAllCharsAsString().lines().toList()` with reading into a temporary `char` array which is then processed to detect line terminators and copy non-terminating characters into strings which are added to the list. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8358533: Decrease value of minGrowth parameter lgtm ------------- Marked as reviewed by sherman (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25863#pullrequestreview-2984206421 From bpb at openjdk.org Thu Jul 3 18:21:42 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 3 Jul 2025 18:21:42 GMT Subject: RFR: 8358533: Improve performance of java.io.Reader.readAllLines [v11] In-Reply-To: References: Message-ID: On Thu, 3 Jul 2025 13:41:02 GMT, Roger Riggs wrote: >> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: >> >> 8358533: Decrease value of minGrowth parameter > > Another review would be good too. Thanks @RogerRiggs, @xuemingshen-oracle for the approvals. I will hold off integrating until next week. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25863#issuecomment-3033157216 From liach at openjdk.org Thu Jul 3 18:41:27 2025 From: liach at openjdk.org (Chen Liang) Date: Thu, 3 Jul 2025 18:41:27 GMT Subject: RFR: 8361300: Document exceptions for Unsafe offset methods [v4] In-Reply-To: References: Message-ID: > Unsafe throws IAE for misusing static vs instance fields, and it's revealed that AtomicXxxFieldUpdaters are using this mechanism to reject static fields. This is not a good practice, but we can at least document this so we don't accidentally introduce problems. Chen Liang has updated the pull request incrementally with one additional commit since the last revision: Test to verify observed internal unsafe behaviors ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25945/files - new: https://git.openjdk.org/jdk/pull/25945/files/c8fcf03c..57f863b7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25945&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25945&range=02-03 Stats: 102 lines in 1 file changed: 102 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/25945.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25945/head:pull/25945 PR: https://git.openjdk.org/jdk/pull/25945 From liach at openjdk.org Thu Jul 3 18:41:27 2025 From: liach at openjdk.org (Chen Liang) Date: Thu, 3 Jul 2025 18:41:27 GMT Subject: RFR: 8361300: Document exceptions for Unsafe offset methods In-Reply-To: References: Message-ID: On Thu, 26 Jun 2025 05:42:24 GMT, ExE Boss wrote: >> Unsafe throws IAE for misusing static vs instance fields, and it's revealed that AtomicXxxFieldUpdaters are using this mechanism to reject static fields. This is not a good practice, but we can at least document this so we don't accidentally introduce problems. > > I?noticed?that the?native implementation of?`Unsafe?::array?(BaseOffset?/IndexScale)` refers?to the?non?existent class?`java.lang.InvalidClassException` instead of?`java.lang.IllegalArgumentException` (which?results in?`java.lang.NoClassDefFoundError` being?thrown): > https://github.com/openjdk/jdk/blob/1ca008fd02496dc33e2707c102560cae1690fba5/src/hotspot/share/prims/unsafe.cpp#L587-L594 I have added test cases to verify the current behaviors of Atomic field updaters and Unsafe memory address calculation methods, including untouched ones for arrays pointed out by @ExE-Boss. All of these are currently exposed through public APIs. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25945#issuecomment-3033199829 From xgong at openjdk.org Fri Jul 4 01:37:42 2025 From: xgong at openjdk.org (Xiaohong Gong) Date: Fri, 4 Jul 2025 01:37:42 GMT Subject: RFR: 8359419: AArch64: Relax min vector length to 32-bit for short vectors [v3] In-Reply-To: <7VTRz_XqYBSdQ54n7ADzTzYADZjDbgBw6XuW0jehSLI=.24d18b87-4553-47ab-8065-d92fbb5700ae@github.com> References: <7VTRz_XqYBSdQ54n7ADzTzYADZjDbgBw6XuW0jehSLI=.24d18b87-4553-47ab-8065-d92fbb5700ae@github.com> Message-ID: On Thu, 3 Jul 2025 06:10:28 GMT, Xiaohong Gong wrote: >> ### Background >> On AArch64, the minimum vector length supported is 64-bit for basic types, except for `byte` and `boolean` (32-bit and 16-bit respectively to match special Vector API features). This limitation prevents intrinsification of vector type conversions between `short` and wider types (e.g. `long/double`) in Vector API when the entire vector length is within 128 bits, resulting in degraded performance for such conversions. >> >> For example, type conversions between `ShortVector.SPECIES_128` and `LongVector.SPECIES_128` are not supported on AArch64 NEON and SVE architectures with 128-bit max vector size. This occurs because the compiler would need to generate a vector with 2 short elements, resulting in a 32-bit vector size. >> >> To intrinsify such type conversion APIs, we need to relax the min vector length constraint from 64-bit to 32-bit for short vectors. >> >> ### Impact Analysis >> #### 1. Vector types >> Vectors only with `short` element types will be affected, as we just supported 32-bit `short` vectors in this change. >> >> #### 2. Vector API >> No impact on Vector API or the vector-specific nodes. The minimum vector shape at API level remains 64-bit. It's not possible to generate a final vector IR with 32-bit vector size. Type conversions may generate intermediate 32-bit vectors, but they will be resized or cast to vectors with at least 64-bit length. >> >> #### 3. Auto-vectorization >> Enables vectorization of cases containing only 2 `short` lanes, with significant performance improvements. Since we have supported 32-bit vectors for `byte` type for a long time, extending this to `short` did not introduce additional risks. >> >> #### 4. Codegen of vector nodes >> NEON doesn't support 32-bit SIMD instructions, so we use 64-bit instructions instead. For lanewise operations, this is safe because the higher half bits can be ignored. >> >> Details: >> - Lanewise vector operations are unaffected as explained above. >> - NEON supports vector load/store instructions with 32-bit vector size, which we already use in relevant IRs (shared by SVE). >> - Cross-lane operations like reduction may be affected, potentially causing incorrect results for `min/max/mul/and` reductions. The min vector size for such operations should remain 64-bit. We've added assertions in match rules. Since it's currently not possible to generate such reductions (Vector API minimum is 64-bit, and SLP doesn't support subword type reductions), we maintain the status quo. However, addin... > > Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision: > > Refine the comment in ad file Hi @theRealAph , the review comments have been addressed. Would you mind taking another look please? Thank you so much! ------------- PR Comment: https://git.openjdk.org/jdk/pull/26057#issuecomment-3034155586 From jpai at openjdk.org Fri Jul 4 01:57:39 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 4 Jul 2025 01:57:39 GMT Subject: RFR: 8354872: Clarify java.lang.Process resource cleanup [v4] In-Reply-To: References: <39KIPIXZDBI9tpPyXew2Ye-uzPvkLSQnOzGJFuK9E2Y=.dc8df88f-f21a-4dd6-8297-5629098bd408@github.com> Message-ID: On Thu, 3 Jul 2025 14:23:00 GMT, Roger Riggs wrote: >> src/java.base/share/classes/java/lang/Process.java line 113: >> >>> 111: * releasing the operating system resources. >>> 112: * {@code Try-with-resources} can be used to open and close the streams. >>> 113: *

    For example, to capture the output of a program known to produce some output and then exit: >> >> Hello Roger, co-incidentally, I was experimenting with the `Process` APIs in a different area. The code snippet that we recommend here will only capture the standard output of the invoked process. Although the sentence here says "output" of a program, do you think we should make it more clearer that it's the standard output of the program? Arguably, since the snippet already uses `inputReader()` whose javadoc notes that it represents the standard output, then maybe the additional clarification isn't needed? > > `inputReader()` is specific as to the output of the sub-process and the example covers only the most common case. What you note sounds fine to me. Thank you. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25884#discussion_r2184125455 From rriggs at openjdk.org Fri Jul 4 03:04:40 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 4 Jul 2025 03:04:40 GMT Subject: RFR: 8344332: (bf) Migrate DirectByteBuffer away from jdk.internal.ref.Cleaner [v7] In-Reply-To: References: Message-ID: <96W7Z-kXZQxhp4r-tSvQ8d3T0UjPF4wqt8tKvnATxqw=.9d641157-375c-4f87-acab-cb8e4adb746a@github.com> On Sun, 29 Jun 2025 20:43:56 GMT, Kim Barrett wrote: >> This change makes java.nio no longer use jdk.internal.ref.Cleaner to manage >> native memory for Direct-X-Buffers. Instead it uses bespoke PhantomReferences >> and a dedicated ReferenceQueue. This differs from PR 22165, which proposed to >> use java.lang.ref.Cleaner. >> >> This change is algorithmically similar to the two previous versions: >> JDK-6857566 and JDK-8156500 (current mainline). The critical function is >> Bits::reserveMemory(). For both of those versions and this change, a thread >> calls that function and tries to reserve some space. If it fails, then it >> keeps trying until all cleaners deactivated (cleared) by prior GCs have been >> cleaned. If reservation still fails, then it invokes the GC to try to >> deactivate more cleaners for cleaning. After that GC it keeps trying the >> reservation and waiting for cleaning, with sleeps to avoid a spin loop, >> eventually either succeeding or giving up and throwing OOME. >> >> Retaining that algorithmic approach is one of the goals of this change, since >> it has been successfully in use since JDK 9 (and was originally developed and >> extensively tested in JDK 8). >> >> The key to this approach is having a way to determine that deactivated >> cleaners have been cleaned. JDK-6857566 accomplished this by having waiting >> threads help the reference processor until there was no available work. >> JDK-8156500 waits for the reference processor to quiesce, relying on its >> immediate processing of cleaners. java.lang.ref.Cleaner doesn't provide a way >> to do this, which is why this change rolls its own Cleaner-like mechanism from >> the underlying primitives. Like JDK-6857566, this change has waiting threads >> help with cleaning references. This was a potentially undesirable feature of >> JDK-6857566, as arbitrary allocating threads were invoking arbitrary cleaners. >> (Though by the time of JDK-6857566 the cleaners were only used by DBB, and >> became internal-only somewhere around that time as well.) That's not a concern >> here, as the cleaners involved are only from DBB, and we know what they look >> like. >> >> As noted in the discussion of JDK-6857566, it's good to have DBB cleaning >> being done off the reference processing thread, as it may be expensive and >> slow down enqueuing other pending references. JDK-6857566 only did some of >> that, and JDK-8156500 lost that feature. This change moves all of the DBB >> cleaning off of the reference processing thread. (So does PR 22165.) >> >> Neither JDK-6857566 nor this change are... > > Kim Barrett has updated the pull request incrementally with two additional commits since the last revision: > > - add @Override for clean() method > - more commentary for reserveMemory Marked as reviewed by rriggs (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25289#pullrequestreview-2985267261 From kbarrett at openjdk.org Fri Jul 4 04:11:53 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Fri, 4 Jul 2025 04:11:53 GMT Subject: RFR: 8344332: (bf) Migrate DirectByteBuffer away from jdk.internal.ref.Cleaner [v7] In-Reply-To: <96W7Z-kXZQxhp4r-tSvQ8d3T0UjPF4wqt8tKvnATxqw=.9d641157-375c-4f87-acab-cb8e4adb746a@github.com> References: <96W7Z-kXZQxhp4r-tSvQ8d3T0UjPF4wqt8tKvnATxqw=.9d641157-375c-4f87-acab-cb8e4adb746a@github.com> Message-ID: <9T0IH7MPf51_gVvSapU43ys6JbPVpWU3gEuAaJyjJ_k=.692c5970-60cc-4392-b80c-9b89c5b8e3bd@github.com> On Fri, 4 Jul 2025 03:02:07 GMT, Roger Riggs wrote: >> Kim Barrett has updated the pull request incrementally with two additional commits since the last revision: >> >> - add @Override for clean() method >> - more commentary for reserveMemory > > Marked as reviewed by rriggs (Reviewer). Thanks for reviews, @RogerRiggs and @bchristi-git ------------- PR Comment: https://git.openjdk.org/jdk/pull/25289#issuecomment-3034379255 From kbarrett at openjdk.org Fri Jul 4 04:11:55 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Fri, 4 Jul 2025 04:11:55 GMT Subject: Integrated: 8344332: (bf) Migrate DirectByteBuffer away from jdk.internal.ref.Cleaner In-Reply-To: References: Message-ID: On Sun, 18 May 2025 11:35:55 GMT, Kim Barrett wrote: > This change makes java.nio no longer use jdk.internal.ref.Cleaner to manage > native memory for Direct-X-Buffers. Instead it uses bespoke PhantomReferences > and a dedicated ReferenceQueue. This differs from PR 22165, which proposed to > use java.lang.ref.Cleaner. > > This change is algorithmically similar to the two previous versions: > JDK-6857566 and JDK-8156500 (current mainline). The critical function is > Bits::reserveMemory(). For both of those versions and this change, a thread > calls that function and tries to reserve some space. If it fails, then it > keeps trying until all cleaners deactivated (cleared) by prior GCs have been > cleaned. If reservation still fails, then it invokes the GC to try to > deactivate more cleaners for cleaning. After that GC it keeps trying the > reservation and waiting for cleaning, with sleeps to avoid a spin loop, > eventually either succeeding or giving up and throwing OOME. > > Retaining that algorithmic approach is one of the goals of this change, since > it has been successfully in use since JDK 9 (and was originally developed and > extensively tested in JDK 8). > > The key to this approach is having a way to determine that deactivated > cleaners have been cleaned. JDK-6857566 accomplished this by having waiting > threads help the reference processor until there was no available work. > JDK-8156500 waits for the reference processor to quiesce, relying on its > immediate processing of cleaners. java.lang.ref.Cleaner doesn't provide a way > to do this, which is why this change rolls its own Cleaner-like mechanism from > the underlying primitives. Like JDK-6857566, this change has waiting threads > help with cleaning references. This was a potentially undesirable feature of > JDK-6857566, as arbitrary allocating threads were invoking arbitrary cleaners. > (Though by the time of JDK-6857566 the cleaners were only used by DBB, and > became internal-only somewhere around that time as well.) That's not a concern > here, as the cleaners involved are only from DBB, and we know what they look > like. > > As noted in the discussion of JDK-6857566, it's good to have DBB cleaning > being done off the reference processing thread, as it may be expensive and > slow down enqueuing other pending references. JDK-6857566 only did some of > that, and JDK-8156500 lost that feature. This change moves all of the DBB > cleaning off of the reference processing thread. (So does PR 22165.) > > Neither JDK-6857566 nor this change are completely precise. For both, a thread > may find there is no available work whil... This pull request has now been integrated. Changeset: 21f2e9a7 Author: Kim Barrett URL: https://git.openjdk.org/jdk/commit/21f2e9a71c31320a8b1248e3970a82b871c63c2b Stats: 524 lines in 9 files changed: 480 ins; 24 del; 20 mod 8344332: (bf) Migrate DirectByteBuffer away from jdk.internal.ref.Cleaner Reviewed-by: rriggs, bchristi ------------- PR: https://git.openjdk.org/jdk/pull/25289 From duke at openjdk.org Fri Jul 4 06:12:51 2025 From: duke at openjdk.org (Vladimir Yaroslavskiy) Date: Fri, 4 Jul 2025 06:12:51 GMT Subject: RFR: 8266431: Dual-Pivot Quicksort improvements (Radix sort) [v11] In-Reply-To: References: <918oCEfFu2JweXfV-afD1l_AGDDuc7dJwAxip-Ze6ZI=.8d5e9692-23db-47e4-9586-99e53b9cfbb6@github.com> Message-ID: On Sun, 22 Oct 2023 17:26:52 GMT, Laurent Bourg?s wrote: >> * improved mixed insertion sort (makes whole sorting faster) >> * introduced Radix which sort shows several times boost of performance and has linear complexity instead of n*ln(n) >> * improved merging sort for almost sorted data >> * optimized parallel sorting >> * improved step for pivot candidates and pivot partitioning >> * extended existing tests >> * added benchmarking JMH tests >> * suggested better buffer allocation: if no memory, it is switched to in-place sorting with no OutOfMemoryError, threshold is 1/16th heap >> >> I am going on previous PR by Vladimir Yaroslavskyi: https://github.com/openjdk/jdk/pull/3938 > > Laurent Bourg?s has updated the pull request incrementally with one additional commit since the last revision: > > add @SuppressWarnings (serial) keep alive, need time to finish ------------- PR Comment: https://git.openjdk.org/jdk/pull/13568#issuecomment-3034654682 From aph at openjdk.org Fri Jul 4 09:14:39 2025 From: aph at openjdk.org (Andrew Haley) Date: Fri, 4 Jul 2025 09:14:39 GMT Subject: RFR: 8359419: AArch64: Relax min vector length to 32-bit for short vectors [v3] In-Reply-To: <7VTRz_XqYBSdQ54n7ADzTzYADZjDbgBw6XuW0jehSLI=.24d18b87-4553-47ab-8065-d92fbb5700ae@github.com> References: <7VTRz_XqYBSdQ54n7ADzTzYADZjDbgBw6XuW0jehSLI=.24d18b87-4553-47ab-8065-d92fbb5700ae@github.com> Message-ID: On Thu, 3 Jul 2025 06:10:28 GMT, Xiaohong Gong wrote: >> ### Background >> On AArch64, the minimum vector length supported is 64-bit for basic types, except for `byte` and `boolean` (32-bit and 16-bit respectively to match special Vector API features). This limitation prevents intrinsification of vector type conversions between `short` and wider types (e.g. `long/double`) in Vector API when the entire vector length is within 128 bits, resulting in degraded performance for such conversions. >> >> For example, type conversions between `ShortVector.SPECIES_128` and `LongVector.SPECIES_128` are not supported on AArch64 NEON and SVE architectures with 128-bit max vector size. This occurs because the compiler would need to generate a vector with 2 short elements, resulting in a 32-bit vector size. >> >> To intrinsify such type conversion APIs, we need to relax the min vector length constraint from 64-bit to 32-bit for short vectors. >> >> ### Impact Analysis >> #### 1. Vector types >> Vectors only with `short` element types will be affected, as we just supported 32-bit `short` vectors in this change. >> >> #### 2. Vector API >> No impact on Vector API or the vector-specific nodes. The minimum vector shape at API level remains 64-bit. It's not possible to generate a final vector IR with 32-bit vector size. Type conversions may generate intermediate 32-bit vectors, but they will be resized or cast to vectors with at least 64-bit length. >> >> #### 3. Auto-vectorization >> Enables vectorization of cases containing only 2 `short` lanes, with significant performance improvements. Since we have supported 32-bit vectors for `byte` type for a long time, extending this to `short` did not introduce additional risks. >> >> #### 4. Codegen of vector nodes >> NEON doesn't support 32-bit SIMD instructions, so we use 64-bit instructions instead. For lanewise operations, this is safe because the higher half bits can be ignored. >> >> Details: >> - Lanewise vector operations are unaffected as explained above. >> - NEON supports vector load/store instructions with 32-bit vector size, which we already use in relevant IRs (shared by SVE). >> - Cross-lane operations like reduction may be affected, potentially causing incorrect results for `min/max/mul/and` reductions. The min vector size for such operations should remain 64-bit. We've added assertions in match rules. Since it's currently not possible to generate such reductions (Vector API minimum is 64-bit, and SLP doesn't support subword type reductions), we maintain the status quo. However, addin... > > Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision: > > Refine the comment in ad file This looks good. Thanks. ------------- Marked as reviewed by aph (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26057#pullrequestreview-2986219682 From xgong at openjdk.org Fri Jul 4 09:17:40 2025 From: xgong at openjdk.org (Xiaohong Gong) Date: Fri, 4 Jul 2025 09:17:40 GMT Subject: RFR: 8359419: AArch64: Relax min vector length to 32-bit for short vectors [v3] In-Reply-To: References: <7VTRz_XqYBSdQ54n7ADzTzYADZjDbgBw6XuW0jehSLI=.24d18b87-4553-47ab-8065-d92fbb5700ae@github.com> Message-ID: On Fri, 4 Jul 2025 09:11:40 GMT, Andrew Haley wrote: > This looks good. Thanks. Thanks so much for your review! ------------- PR Comment: https://git.openjdk.org/jdk/pull/26057#issuecomment-3035115512 From djelinski at openjdk.org Fri Jul 4 09:50:52 2025 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Fri, 4 Jul 2025 09:50:52 GMT Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API [v9] In-Reply-To: References: Message-ID: On Wed, 2 Jul 2025 07:47:31 GMT, Daniel Jeli?ski wrote: >> src/java.base/share/classes/sun/security/ssl/X509Authentication.java line 224: >> >>> 222: // TODO in future, when QuicTLSEngine might become a public exported interface >>> 223: // we should have a method on javax.net.ssl.X509ExtendedKeyManager that >>> 224: // takes QuicTLSEngine. >> >> Suggestion: >> >> // TODO in future, if QuicTLSEngine ever becomes a public exported interface >> // we might have a method on javax.net.ssl.X509ExtendedKeyManager that >> // takes QuicTLSEngine. > > Maybe we could stop guessing the future, and use this instead: > Suggestion: > > // TODO add a method on javax.net.ssl.X509ExtendedKeyManager that > // takes QuicTLSEngine. Removed speculations about the future ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2184893641 From aturbanov at openjdk.org Fri Jul 4 12:43:43 2025 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Fri, 4 Jul 2025 12:43:43 GMT Subject: RFR: 8360037: Refactor ImageReader in preparation for Valhalla support [v5] In-Reply-To: References: Message-ID: On Wed, 2 Jul 2025 13:54:02 GMT, David Beaumont wrote: >> Refactoring `ImageReader` to make it easy to add preview mode functionality for Valhalla. >> >> This PR is a large change to `ImageReader` (effectively a rewrite) but reduces the surface area of the API significantly, reduces code complexity and increases performance/memory efficiency. The need for this sort of change comes from the need to support "preview mode" in Valhalla for classes loaded from core modules. >> >> ### Preview Mode >> >> In the proposed preview mode support for Valhalla, a resource with the name `/modules//` may come from one of two locations in the underlying jimage file; `//` or `//META-INF/preview/`. Furthermore, directories (represented as directory nodes via the API) will have a potentially different number of child nodes depending on whether preview mode is in effect, and some directories may only exist at all in preview mode. >> >> Furthermore, the directories and symbolic link nodes in `/packages/...` will also be affected by the existence of new package directories. To retain consistency and avoid "surprises" later, all of this needs to be taken into account. >> >> Below is a summary of the main changes for mainline JDK to better support preview mode later: >> >> ### 1: Improved encapsulation for preview mode >> >> The current `ImageReader` code exposes the data from the jimage file in several ways; via the `Node` abstraction, but also with methods which return an `ImageLocation` instance directly. In preview mode it would not be acceptable to return the `ImageLocation`, since that would leak the existence of resources in the `META-INF/preview` namespace and lets users see resource nodes with names that don't match the underlying `ImageLocation` from which their contents come. >> >> As such, the PR removes all methods which can leak `ImageLocation` or other "underlying" semantics about the jimage file. Luckily most of these are either used minimally and easily migrated to using nodes, or they were not being used at all. This PR also removes any methods which were already unused across the OpenJDK codebase (if I discover any issues with over-trimming of the API during full CI testing, it will be easy to address). >> >> ### 2. Simplification of directory child node handling >> >> The current `ImageReader` code attempts to create parent directories "on demand" for any child nodes it creates. This results in parent directories having a non-empty but incomplete set of child nodes present. This is re... > > David Beaumont has updated the pull request incrementally with one additional commit since the last revision: > > Feedback related changes. src/java.base/share/classes/jdk/internal/jimage/ImageReader.java line 193: > 191: // of the jimage file itself (creation, modification, access times). > 192: // Initialized lazily, see imageFileAttributes(). > 193: private BasicFileAttributes imageFileAttributes; It seems there is no reason to keep its initialization lazy: now we call `newDirectory` in constructor which will trigger its initialization anyway. We can make it `final` and simplify code a bit. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26054#discussion_r2185271221 From mhaessig at openjdk.org Fri Jul 4 13:09:43 2025 From: mhaessig at openjdk.org (Manuel =?UTF-8?B?SMOkc3NpZw==?=) Date: Fri, 4 Jul 2025 13:09:43 GMT Subject: RFR: 8361253: CommandLineOptionTest library should report observed values on failure In-Reply-To: References: Message-ID: On Wed, 2 Jul 2025 11:00:44 GMT, Manuel H?ssig wrote: > When a check in `CommandLineOptionTest` fails, the `AssertionError` message contains the expected value, but not the observed value. To reduce the amount of digging in the logs we have to do when analyzing a failure, this PR adds the observed value to the error messages. So instead of > > > java.lang.AssertionError: Option 'CICompilerCount' is expected to have '12' value > > > a mismatch in the `CICompilerCount` will now print > > > java.lang.AssertionError: Option 'CICompilerCount' is expected to have '12' value, but is 'CICompilerCount = 6'. > > > Testing: > - [x] Github Actions > - [x] tier1 through tier3 plus Oracle internal testing Thank you for your reviews. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26092#issuecomment-3036225388 From mhaessig at openjdk.org Fri Jul 4 13:09:44 2025 From: mhaessig at openjdk.org (Manuel =?UTF-8?B?SMOkc3NpZw==?=) Date: Fri, 4 Jul 2025 13:09:44 GMT Subject: Integrated: 8361253: CommandLineOptionTest library should report observed values on failure In-Reply-To: References: Message-ID: On Wed, 2 Jul 2025 11:00:44 GMT, Manuel H?ssig wrote: > When a check in `CommandLineOptionTest` fails, the `AssertionError` message contains the expected value, but not the observed value. To reduce the amount of digging in the logs we have to do when analyzing a failure, this PR adds the observed value to the error messages. So instead of > > > java.lang.AssertionError: Option 'CICompilerCount' is expected to have '12' value > > > a mismatch in the `CICompilerCount` will now print > > > java.lang.AssertionError: Option 'CICompilerCount' is expected to have '12' value, but is 'CICompilerCount = 6'. > > > Testing: > - [x] Github Actions > - [x] tier1 through tier3 plus Oracle internal testing This pull request has now been integrated. Changeset: f153e415 Author: Manuel H?ssig URL: https://git.openjdk.org/jdk/commit/f153e415d740f4ede272929171e9bb3e73ddbe1c Stats: 7 lines in 1 file changed: 3 ins; 0 del; 4 mod 8361253: CommandLineOptionTest library should report observed values on failure Reviewed-by: dholmes, shade ------------- PR: https://git.openjdk.org/jdk/pull/26092 From yujige at gmail.com Fri Jul 4 15:55:12 2025 From: yujige at gmail.com (Jige Yu) Date: Fri, 4 Jul 2025 08:55:12 -0700 Subject: Question about mapConcurrent() Behavior and Happens-Before Guarantees In-Reply-To: References: Message-ID: Yes. I got two tests that show the behavior difference between downstream exception and upstream exception: @Test public void mapConcurrently_upstreamFailureDoesNotInterrupt() { ConcurrentLinkedQueue started = new ConcurrentLinkedQueue<>(); ConcurrentLinkedQueue interrupted = new ConcurrentLinkedQueue<>(); RuntimeException thrown = assertThrows( RuntimeException.class, () -> Stream.of(1, 10, 3, 0) .peek(n -> { if (n == 3) { try { // give 1 and 3 some time to have at least started Thread.sleep(100); } catch (InterruptedException e) { interrupted.add(n); } throw new IllegalArgumentException(String.valueOf(n)); } }) .gather(mapConcurrently(3, n -> { started.add(n); try { Thread.sleep(n * 10000); } catch (InterruptedException e) { interrupted.add(n); } return n; })) .findAny()); assertThat(started).containsExactly(10, 1); assertThat(interrupted).isEmpty(); assertThat(thrown).hasMessageThat().isEqualTo("3"); } @Test public void mapConcurrently_downstreamFailurePropagated() { ConcurrentLinkedQueue started = new ConcurrentLinkedQueue<>(); ConcurrentLinkedQueue interrupted = new ConcurrentLinkedQueue<>(); RuntimeException thrown = assertThrows( RuntimeException.class, () -> Stream.of(10, 1, 3, 0) .gather(mapConcurrently(3, n -> { started.add(n); try { Thread.sleep(n * 1000); } catch (InterruptedException e) { interrupted.add(n); } return n; })) .peek(n -> { throw new IllegalArgumentException(String.valueOf(n)); }) .findAny()); assertThat(started).containsExactly(10, 1, 3); assertThat(interrupted).containsExactly(3, 10); assertThat(thrown).hasMessageThat().isEqualTo("1"); } Both with maxConcurrenc=3. When the downstream peek() throws on the first element "1" it gets, it will interrupt (and join) the other two pending threads (3 and 10). The interrupted ConcurrentLinkedQueue is guaranteed to see [3, 10] because of the happens-before guarantee. When the upstream peek() throws on 3, [1, 10] are also already running concurrently. But no thread is interrupted. On Thu, Jul 3, 2025 at 10:29?AM David Alayachew wrote: > These questions necessitate runnable examples. Do you have any > > On Thu, Jul 3, 2025, 10:37?AM Jige Yu wrote: > >> Hi JDK Core Devs, >> >> I'm writing to you today with a question about the behavior of >> mapConcurrent() and its interaction with unchecked exceptions. I've been >> experimenting with the API and observed that mapConcurrent() blocks and >> joins all virtual threads upon an unchecked exception before propagating it. >> >> Initially, I thought this design choice might provide a strong >> happens-before guarantee. My assumption was that an application catching a >> RuntimeException would be able to *observe all side effects* from the >> virtual threads, even though this practice is generally discouraged. This >> seemed like a potentially significant advantage, outweighing the risk of a >> virtual thread failing to respond to interruption or responding slowly. >> >> However, I've since realized that mapConcurrent() cannot fully guarantee >> a strong happens-before relationship when an unchecked exception occurs >> *somewhere* in the stream pipeline. While it can block and wait for >> exceptions thrown by the mapper function or downstream operations, it >> appears unable to intercept unchecked exceptions *thrown by an upstream* >> source. >> >> Consider a scenario with two input elements: if the first element starts >> a virtual thread, and then the second element causes an unchecked exception >> from the upstream *before* reaching the gather() call, the virtual >> thread initiated by the first element would not be interrupted. This makes >> the "happens-before" guarantee quite nuanced in practice. >> >> This brings me to my core questions: >> >> 1. >> >> Is providing a happens-before guarantee upon an unchecked exception a >> design goal for mapConcurrent()? >> 2. >> >> If not, would it be more desirable to *not* join on virtual threads >> when unchecked exceptions occur? This would allow the application code to >> catch the exception sooner and avoid the risk of being blocked indefinitely. >> >> Thank you for your time and insights. >> >> Best regards, >> >> Ben Yu >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbarrett at openjdk.org Sat Jul 5 00:10:18 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Sat, 5 Jul 2025 00:10:18 GMT Subject: RFR: 8361426: (ref) Remove jdk.internal.ref.Cleaner Message-ID: Please review this change that removes the class jdk.internal.ref.Cleaner. It is no longer used after JDK-8344332. Testing: mach5 tier1-3 ------------- Commit messages: - remove jdk.internal.ref.Cleaner Changes: https://git.openjdk.org/jdk/pull/26141/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26141&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8361426 Stats: 233 lines in 3 files changed: 0 ins; 232 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/26141.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26141/head:pull/26141 PR: https://git.openjdk.org/jdk/pull/26141 From yujige at gmail.com Sat Jul 5 03:09:39 2025 From: yujige at gmail.com (Jige Yu) Date: Fri, 4 Jul 2025 20:09:39 -0700 Subject: Question about mapConcurrent() Behavior and Happens-Before Guarantees In-Reply-To: References: Message-ID: Assuming the test code and my reading of the mapConcurrent() code haven't misled me, I think this observation suggests that if an *upstream exception* terminates the stream, mapConcurrent() may not be able to properly cancel or interrupt the virtual threads it has already started. This could potentially lead to *resource leaks* or "zombie" threads that continue to run or block indefinitely in the background, consuming resources unnecessarily. This behavior might be surprising to developers. For instance, Stream.parallel(), which leverages ForkJoinPool, effectively manages its entire pipeline. It can interrupt running threads and join() them to enforce *happens-before guarantees* even when exceptions occur upstream. Users might naturally expect a similar level of robust resource management and memory visibility from mapConcurrent(). While explicit documentation could clarify this behavior, such a fundamental difference might still lead to confusion and unintended issues. ------------------------------ A Potential Design Adjustment for More Robustness To address these concerns while maintaining mapConcurrent()'s core benefits, I'd like to propose a strawman design adjustment. Instead of mapConcurrent() being an intermediary Gatherer (which has limited control over upstream events), consider exposing its functionality as a *terminal Collector *(let's tentatively call it concurrently()) For example, instead of: inputs.stream().filter(...).gather(mapConcurrent(10, input -> callBackend(input))).toList(); We could use a Collector-based approach: inputs.stream().filter(...).collect(concurrently(10, input -> callBackend(input))).toList(); Here's how this Collector-based design could mitigate the issues: - *Pre-emptive Upstream Processing:* The concurrently() Collector could internally use collectingAndThen(toList(), ...) or a similar mechanism. This would ensure that *all upstream elements are eagerly consumed* and any upstream exceptions are thrown and handled *before* the concurrent virtual threads are ever launched for the mapConcurrent-like operations. - *Controlled Concurrent Operations:* Only once the upstream processing is complete and validated would the concurrent mapping begin. The concurrent operations would still be *lazy and concurrency-limited*, but they would only apply to the concurrent operations started by concurrently(). - *Resolved Concerns:* This design would effectively make the *happens-before* and *resource leak* concerns caused by upstream exceptions moot, as such exceptions would occur and be dealt with at an earlier, more controlled stage with zero concurrency complications. The most apparent trade-off is that this Collector approach would eagerly consume all input elements, potentially increasing memory usage and sacrificing the full laziness a Gatherer might offer. However, mapConcurrent()'s primary use cases typically involve I/O-intensive fan-outs, which generally don't operate on an extremely large number of inputs. For the rare instances involving infinite or very large streams, the limitation becomes a clear "*not designed for this*" scenario, simpler than navigating the current nuanced caveats around happens-before enforcement and thread cancellation. Just my 2c, Cheers On Fri, Jul 4, 2025 at 8:55?AM Jige Yu wrote: > Yes. > > I got two tests that show the behavior difference between downstream > exception and upstream exception: > > > @Test public void mapConcurrently_upstreamFailureDoesNotInterrupt() { > > ConcurrentLinkedQueue started = new ConcurrentLinkedQueue<>(); > > ConcurrentLinkedQueue interrupted = new > ConcurrentLinkedQueue<>(); > > RuntimeException thrown = assertThrows( > > RuntimeException.class, > > () -> Stream.of(1, 10, 3, 0) > > .peek(n -> { > > if (n == 3) { > > try { // give 1 and 3 some time to have at least started > > Thread.sleep(100); > > } catch (InterruptedException e) { > > interrupted.add(n); > > } > > throw new IllegalArgumentException(String.valueOf(n)); > > } > > }) > > .gather(mapConcurrently(3, n -> { > > started.add(n); > > try { > > Thread.sleep(n * 10000); > > } catch (InterruptedException e) { > > interrupted.add(n); > > } > > return n; > > })) > > .findAny()); > > assertThat(started).containsExactly(10, 1); > > assertThat(interrupted).isEmpty(); > > assertThat(thrown).hasMessageThat().isEqualTo("3"); > > } > > > @Test public void mapConcurrently_downstreamFailurePropagated() { > > ConcurrentLinkedQueue started = new ConcurrentLinkedQueue<>(); > > ConcurrentLinkedQueue interrupted = new > ConcurrentLinkedQueue<>(); > > RuntimeException thrown = assertThrows( > > RuntimeException.class, > > () -> Stream.of(10, 1, 3, 0) > > .gather(mapConcurrently(3, n -> { > > started.add(n); > > try { > > Thread.sleep(n * 1000); > > } catch (InterruptedException e) { > > interrupted.add(n); > > } > > return n; > > })) > > .peek(n -> { > > throw new IllegalArgumentException(String.valueOf(n)); > > }) > > .findAny()); > > assertThat(started).containsExactly(10, 1, 3); > > assertThat(interrupted).containsExactly(3, 10); > > assertThat(thrown).hasMessageThat().isEqualTo("1"); > > } > > > Both with maxConcurrenc=3. > > When the downstream peek() throws on the first element "1" it gets, it > will interrupt (and join) the other two pending threads (3 and 10). > The interrupted ConcurrentLinkedQueue is guaranteed to see [3, 10] because > of the happens-before guarantee. > > When the upstream peek() throws on 3, [1, 10] are also already running > concurrently. But no thread is interrupted. > > > > On Thu, Jul 3, 2025 at 10:29?AM David Alayachew > wrote: > >> These questions necessitate runnable examples. Do you have any >> >> On Thu, Jul 3, 2025, 10:37?AM Jige Yu wrote: >> >>> Hi JDK Core Devs, >>> >>> I'm writing to you today with a question about the behavior of >>> mapConcurrent() and its interaction with unchecked exceptions. I've >>> been experimenting with the API and observed that mapConcurrent() >>> blocks and joins all virtual threads upon an unchecked exception before >>> propagating it. >>> >>> Initially, I thought this design choice might provide a strong >>> happens-before guarantee. My assumption was that an application catching a >>> RuntimeException would be able to *observe all side effects* from the >>> virtual threads, even though this practice is generally discouraged. This >>> seemed like a potentially significant advantage, outweighing the risk of a >>> virtual thread failing to respond to interruption or responding slowly. >>> >>> However, I've since realized that mapConcurrent() cannot fully >>> guarantee a strong happens-before relationship when an unchecked exception >>> occurs *somewhere* in the stream pipeline. While it can block and wait >>> for exceptions thrown by the mapper function or downstream operations, it >>> appears unable to intercept unchecked exceptions *thrown by an upstream* >>> source. >>> >>> Consider a scenario with two input elements: if the first element starts >>> a virtual thread, and then the second element causes an unchecked exception >>> from the upstream *before* reaching the gather() call, the virtual >>> thread initiated by the first element would not be interrupted. This makes >>> the "happens-before" guarantee quite nuanced in practice. >>> >>> This brings me to my core questions: >>> >>> 1. >>> >>> Is providing a happens-before guarantee upon an unchecked exception >>> a design goal for mapConcurrent()? >>> 2. >>> >>> If not, would it be more desirable to *not* join on virtual threads >>> when unchecked exceptions occur? This would allow the application code to >>> catch the exception sooner and avoid the risk of being blocked indefinitely. >>> >>> Thank you for your time and insights. >>> >>> Best regards, >>> >>> Ben Yu >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From fgao at openjdk.org Sat Jul 5 14:04:39 2025 From: fgao at openjdk.org (Fei Gao) Date: Sat, 5 Jul 2025 14:04:39 GMT Subject: RFR: 8359419: AArch64: Relax min vector length to 32-bit for short vectors [v3] In-Reply-To: References: <7VTRz_XqYBSdQ54n7ADzTzYADZjDbgBw6XuW0jehSLI=.24d18b87-4553-47ab-8065-d92fbb5700ae@github.com> Message-ID: On Fri, 4 Jul 2025 09:15:14 GMT, Xiaohong Gong wrote: >> This looks good. Thanks. > >> This looks good. Thanks. > > Thanks so much for your review! Hi @XiaohongGong, thanks for your work! Shall we also relax the IR check condition in the following cases for `aarch64` and `x86`? https://github.com/openjdk/jdk/blob/f2d2eef988c57cc9f6194a8fd5b2b422035ee68f/test/hotspot/jtreg/compiler/vectorization/runner/ArrayTypeConvertTest.java#L254-L258 https://github.com/openjdk/jdk/blob/f2d2eef988c57cc9f6194a8fd5b2b422035ee68f/test/hotspot/jtreg/compiler/vectorization/runner/ArrayTypeConvertTest.java#L376-L380 https://github.com/openjdk/jdk/blob/f2d2eef988c57cc9f6194a8fd5b2b422035ee68f/test/hotspot/jtreg/compiler/vectorization/runner/ArrayTypeConvertTest.java#L388-L392 ------------- PR Comment: https://git.openjdk.org/jdk/pull/26057#issuecomment-3038978749 From fgao at openjdk.org Sat Jul 5 15:11:40 2025 From: fgao at openjdk.org (Fei Gao) Date: Sat, 5 Jul 2025 15:11:40 GMT Subject: RFR: 8359419: AArch64: Relax min vector length to 32-bit for short vectors [v3] In-Reply-To: <7VTRz_XqYBSdQ54n7ADzTzYADZjDbgBw6XuW0jehSLI=.24d18b87-4553-47ab-8065-d92fbb5700ae@github.com> References: <7VTRz_XqYBSdQ54n7ADzTzYADZjDbgBw6XuW0jehSLI=.24d18b87-4553-47ab-8065-d92fbb5700ae@github.com> Message-ID: <5H0NP8vFqCDf1JgHIDee3WrYRbJ6koj5wQsxEGTW8nI=.87d74c6a-54b3-45cc-a972-c4350d5e2acf@github.com> On Thu, 3 Jul 2025 06:10:28 GMT, Xiaohong Gong wrote: >> ### Background >> On AArch64, the minimum vector length supported is 64-bit for basic types, except for `byte` and `boolean` (32-bit and 16-bit respectively to match special Vector API features). This limitation prevents intrinsification of vector type conversions between `short` and wider types (e.g. `long/double`) in Vector API when the entire vector length is within 128 bits, resulting in degraded performance for such conversions. >> >> For example, type conversions between `ShortVector.SPECIES_128` and `LongVector.SPECIES_128` are not supported on AArch64 NEON and SVE architectures with 128-bit max vector size. This occurs because the compiler would need to generate a vector with 2 short elements, resulting in a 32-bit vector size. >> >> To intrinsify such type conversion APIs, we need to relax the min vector length constraint from 64-bit to 32-bit for short vectors. >> >> ### Impact Analysis >> #### 1. Vector types >> Vectors only with `short` element types will be affected, as we just supported 32-bit `short` vectors in this change. >> >> #### 2. Vector API >> No impact on Vector API or the vector-specific nodes. The minimum vector shape at API level remains 64-bit. It's not possible to generate a final vector IR with 32-bit vector size. Type conversions may generate intermediate 32-bit vectors, but they will be resized or cast to vectors with at least 64-bit length. >> >> #### 3. Auto-vectorization >> Enables vectorization of cases containing only 2 `short` lanes, with significant performance improvements. Since we have supported 32-bit vectors for `byte` type for a long time, extending this to `short` did not introduce additional risks. >> >> #### 4. Codegen of vector nodes >> NEON doesn't support 32-bit SIMD instructions, so we use 64-bit instructions instead. For lanewise operations, this is safe because the higher half bits can be ignored. >> >> Details: >> - Lanewise vector operations are unaffected as explained above. >> - NEON supports vector load/store instructions with 32-bit vector size, which we already use in relevant IRs (shared by SVE). >> - Cross-lane operations like reduction may be affected, potentially causing incorrect results for `min/max/mul/and` reductions. The min vector size for such operations should remain 64-bit. We've added assertions in match rules. Since it's currently not possible to generate such reductions (Vector API minimum is 64-bit, and SLP doesn't support subword type reductions), we maintain the status quo. However, addin... > > Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision: > > Refine the comment in ad file Have you measured the performance of this micro-benchmark on NEON machine? https://github.com/openjdk/jdk/blob/f2d2eef988c57cc9f6194a8fd5b2b422035ee68f/test/micro/org/openjdk/bench/vm/compiler/TypeVectorOperations.java#L251-L256 We added an limitation only for `int` before: https://github.com/openjdk/jdk/blob/f2d2eef988c57cc9f6194a8fd5b2b422035ee68f/src/hotspot/cpu/aarch64/aarch64_vector.ad#L131-L134 Perhaps we also need to impose a similar limitation on `short` if the same regression occurs. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26057#issuecomment-3039090274 From duke at openjdk.org Sun Jul 6 18:37:39 2025 From: duke at openjdk.org (ExE Boss) Date: Sun, 6 Jul 2025 18:37:39 GMT Subject: RFR: 8361300: Document exceptions for Unsafe offset methods [v4] In-Reply-To: References: Message-ID: On Thu, 3 Jul 2025 18:41:27 GMT, Chen Liang wrote: >> Unsafe throws IAE for misusing static vs instance fields, and it's revealed that AtomicXxxFieldUpdaters are using this mechanism to reject static fields. This is not a good practice, but we can at least document this so we don't accidentally introduce problems. > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > Test to verify observed internal unsafe behaviors test/jdk/jdk/internal/misc/Unsafe/AddressComputationContractTest.java line 91: > 89: assertDoesNotThrow(() -> getUnsafe().arrayBaseOffset(int[].class)); > 90: assertThrows(NullPointerException.class, () -> getUnsafe().arrayBaseOffset(null)); > 91: // Caused by VM trying to throw java.lang.InvalidClassException (there's one in java.io instead) Note?that the?one in?`java.io` is?also a?checked?exception (extends?`java.io.ObjectStreamException` which?extends?`java.io.IOException`). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25945#discussion_r2188513237 From liach at openjdk.org Sun Jul 6 21:29:39 2025 From: liach at openjdk.org (Chen Liang) Date: Sun, 6 Jul 2025 21:29:39 GMT Subject: RFR: 8361300: Document exceptions for Unsafe offset methods [v4] In-Reply-To: References: Message-ID: On Sun, 6 Jul 2025 18:32:56 GMT, ExE Boss wrote: >> Chen Liang has updated the pull request incrementally with one additional commit since the last revision: >> >> Test to verify observed internal unsafe behaviors > > test/jdk/jdk/internal/misc/Unsafe/AddressComputationContractTest.java line 91: > >> 89: assertDoesNotThrow(() -> getUnsafe().arrayBaseOffset(int[].class)); >> 90: assertThrows(NullPointerException.class, () -> getUnsafe().arrayBaseOffset(null)); >> 91: // Caused by VM trying to throw java.lang.InvalidClassException (there's one in java.io instead) > > Note?that the?one in?`java.io` is?also a?checked?exception (extends?`java.io.ObjectStreamException` which?extends?`java.io.IOException`). Yes, but there has been precedent of some sort of code throwing checked exceptions in a potentially-unchecked context, such as the lookup getter in proxy classes throw IllegalAccessException instead of IllegalAccessError. Anyways, an java.io exception is definitely not suitable here. When sun.misc.Unsafe memory access methods are gone, we might simply change this to an IAE instead. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25945#discussion_r2188630344 From xgong at openjdk.org Mon Jul 7 02:07:50 2025 From: xgong at openjdk.org (Xiaohong Gong) Date: Mon, 7 Jul 2025 02:07:50 GMT Subject: RFR: 8355563: VectorAPI: Refactor current implementation of subword gather load API [v2] In-Reply-To: References: <7GrGfBF_v8F0v02sRHC78ofMZwpMdzQZaHeYlNvi_N0=.93defb9e-ca9b-41b4-8722-1746692e2316@github.com> Message-ID: On Wed, 2 Jul 2025 08:24:22 GMT, Emanuel Peter wrote: >>> Agree with Paul, these are minor regressions. Let us proceed with this patch. >> >> Thanks so much for your review @sviswa7 ! > > @XiaohongGong I quickly scanned the patch, it looks good to me too. I'm submitting some internal testing now, to make sure our extended testing does not break on integration. Should take about 24h. Hi @eme64 , may I ask how the testing is going on? Can we move on and integrate this patch now? Thanks a lot! ------------- PR Comment: https://git.openjdk.org/jdk/pull/25138#issuecomment-3043273111 From duke at openjdk.org Mon Jul 7 02:38:46 2025 From: duke at openjdk.org (duke) Date: Mon, 7 Jul 2025 02:38:46 GMT Subject: Withdrawn: 8349716: IllegalAccessError when Proxy methods return object of a package-private type In-Reply-To: <9yD4li2CQ0XdnS4VGoa4udyr_8M7rvFU-jYjeigSu_I=.8b525314-a566-48f0-bcf5-27fd72c14bfb@github.com> References: <9yD4li2CQ0XdnS4VGoa4udyr_8M7rvFU-jYjeigSu_I=.8b525314-a566-48f0-bcf5-27fd72c14bfb@github.com> Message-ID: On Sun, 13 Apr 2025 09:49:46 GMT, Chen Liang wrote: > Proxy currently places proxy classes that proxy interfaces with package-private return types in dynamic modules. This means that if a return value is non-null, Proxy cannot return it and throws IllegalAccessError. > > This patch changes strategy so proxy classes for any reference to package-private types (in parameter or return) are now considered as package-private, tightening the restrictions on proxy factories. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/24611 From missa at openjdk.org Mon Jul 7 03:10:15 2025 From: missa at openjdk.org (Mohamed Issa) Date: Mon, 7 Jul 2025 03:10:15 GMT Subject: RFR: 8360559: Optimize Math.sinh for x86 64 bit platforms Message-ID: The goal of this PR is to implement an x86_64 intrinsic for java.lang.Math.sinh() using libm. There is a new set of micro-benchmarks are included to check the performance of specific input value ranges to help prevent regressions in the future. The command to run all range specific micro-benchmarks is posted below. `make test TEST="micro:SinhPerf.SinhPerfRanges"` The results of all tests posted below were captured with an [Intel? Xeon 8488C](https://advisor.cloudzero.com/aws/ec2/r7i.metal-24xl) using [OpenJDK v26-b4](https://github.com/openjdk/jdk/releases/tag/jdk-26%2B4) as the baseline version. For performance data collected with the new built in range micro-benchmark, see the table below. Each result is the mean of 8 individual runs, and the input ranges used match those from the original Java implementation. Overall, the intrinsic provides an an average uplift of 64% when input values fall into the middle three ranges where heavy computation is required. However, very small inputs and very large inputs show drops of 74% and 66% respectively. | Input range(s) | Baseline throughput (ops/ms) | Intrinsic throughput (ops/ms) | Speedup | | :------------------------------------: | :-------------------------------: | :--------------------------------: | :--------: | | [-2^(-28), 2^(-28)] | 844160 | 216029 | 0.26x | | [-22, -2^(-28)], [2^(-28), 22] | 81662 | 157351 | 1.93x | | [-709.78, -22], [22, 709.78] | 119075 | 167635 | 1.41x | | [-710.48, -709.78], [709.78, 710.48] | 111636 | 177125 | 1.59x | | (-INF, -710.48], [710.48, INF) | 959296 | 313839 | 0.33x | Finally, the `jtreg:test/jdk/java/lang/Math/HyperbolicTests.java` test passed with the changes. ------------- Commit messages: - x86_64 intrinsic for sinh using libm Changes: https://git.openjdk.org/jdk/pull/26152/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26152&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8360559 Stats: 740 lines in 26 files changed: 737 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/26152.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26152/head:pull/26152 PR: https://git.openjdk.org/jdk/pull/26152 From fweimer at openjdk.org Mon Jul 7 04:50:37 2025 From: fweimer at openjdk.org (Florian Weimer) Date: Mon, 7 Jul 2025 04:50:37 GMT Subject: RFR: 8360559: Optimize Math.sinh for x86 64 bit platforms In-Reply-To: References: Message-ID: On Mon, 7 Jul 2025 03:05:15 GMT, Mohamed Issa wrote: > The goal of this PR is to implement an x86_64 intrinsic for java.lang.Math.sinh() using libm. There is a new set of micro-benchmarks are included to check the performance of specific input value ranges to help prevent regressions in the future. > > The command to run all range specific micro-benchmarks is posted below. > > `make test TEST="micro:SinhPerf.SinhPerfRanges"` > > The results of all tests posted below were captured with an [Intel? Xeon 8488C](https://advisor.cloudzero.com/aws/ec2/r7i.metal-24xl) using [OpenJDK v26-b4](https://github.com/openjdk/jdk/releases/tag/jdk-26%2B4) as the baseline version. > > For performance data collected with the new built in range micro-benchmark, see the table below. Each result is the mean of 8 individual runs, and the input ranges used match those from the original Java implementation. Overall, the intrinsic provides an an average uplift of 64% when input values fall into the middle three ranges where heavy computation is required. However, very small inputs and very large inputs show drops of 74% and 66% respectively. > > | Input range(s) | Baseline throughput (ops/ms) | Intrinsic throughput (ops/ms) | Speedup | > | :------------------------------------: | :-------------------------------: | :--------------------------------: | :--------: | > | [-2^(-28), 2^(-28)] | 844160 | 216029 | 0.26x | > | [-22, -2^(-28)], [2^(-28), 22] | 81662 | 157351 | 1.93x | > | [-709.78, -22], [22, 709.78] | 119075 | 167635 | 1.41x | > | [-710.48, -709.78], [709.78, 710.48] | 111636 | 177125 | 1.59x | > | (-INF, -710.48], [710.48, INF) | 959296 | 313839 | 0.33x | > > Finally, the `jtreg:test/jdk/java/lang/Math/HyperbolicTests.java` test passed with the changes. Isn't this effectively a libm benchmark (where the `sinh` implementation resides)? Please include the libm version for reference here. Thanks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26152#issuecomment-3043465393 From epeter at openjdk.org Mon Jul 7 06:04:45 2025 From: epeter at openjdk.org (Emanuel Peter) Date: Mon, 7 Jul 2025 06:04:45 GMT Subject: RFR: 8355563: VectorAPI: Refactor current implementation of subword gather load API [v2] In-Reply-To: References: Message-ID: On Wed, 25 Jun 2025 09:16:48 GMT, Xiaohong Gong wrote: >> JDK-8318650 introduced hotspot intrinsification of subword gather load APIs for X86 platforms [1]. However, the current implementation is not optimal for AArch64 SVE platform, which natively supports vector instructions for subword gather load operations using an int vector for indices (see [2][3]). >> >> Two key areas require improvement: >> 1. At the Java level, vector indices generated for range validation could be reused for the subsequent gather load operation on architectures with native vector instructions like AArch64 SVE. However, the current implementation prevents compiler reuse of these index vectors due to divergent control flow, potentially impacting performance. >> 2. At the compiler IR level, the additional `offset` input for `LoadVectorGather`/`LoadVectorGatherMasked` with subword types increases IR complexity and complicates backend implementation. Furthermore, generating `add` instructions before each memory access negatively impacts performance. >> >> This patch refactors the implementation at both the Java level and compiler mid-end to improve efficiency and maintainability across different architectures. >> >> Main changes: >> 1. Java-side API refactoring: >> - Explicitly passes generated index vectors to hotspot, eliminating duplicate index vectors for gather load instructions on >> architectures like AArch64. >> 2. C2 compiler IR refactoring: >> - Refactors `LoadVectorGather`/`LoadVectorGatherMasked` IR for subword types by removing the memory offset input and incorporating it into the memory base `addr` at the IR level. This simplifies backend implementation, reduces add operations, and unifies the IR across all types. >> 3. Backend changes: >> - Streamlines X86 implementation of subword gather operations following the removal of the offset input from the IR level. >> >> Performance: >> The performance of the relative JMH improves up to 27% on a X86 AVX512 system. Please see the data below: >> >> Benchmark Mode Cnt Unit SIZE Before After Gain >> GatherOperationsBenchmark.microByteGather128 thrpt 30 ops/ms 64 53682.012 52650.325 0.98 >> GatherOperationsBenchmark.microByteGather128 thrpt 30 ops/ms 256 14484.252 14255.156 0.98 >> GatherOperationsBenchmark.microByteGather128 thrpt 30 ops/ms 1024 3664.900 3595.615 0.98 >> GatherOperationsBenchmark.microByteGather128 thrpt 30 ops/ms 4096 908.31... > > Xiaohong Gong has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: > > - Address review comments > - Merge 'jdk:master' into JDK-8355563 > - 8355563: VectorAPI: Refactor current implementation of subword gather load API @XiaohongGong Thanks for putting in the work! Tests pass, and patch looks reasonable. ------------- Marked as reviewed by epeter (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25138#pullrequestreview-2992282121 From epeter at openjdk.org Mon Jul 7 06:21:48 2025 From: epeter at openjdk.org (Emanuel Peter) Date: Mon, 7 Jul 2025 06:21:48 GMT Subject: RFR: 8354242: VectorAPI: combine vector not operation with compare [v9] In-Reply-To: References: Message-ID: On Wed, 25 Jun 2025 10:08:23 GMT, erifan wrote: >> This patch optimizes the following patterns: >> For integer types: >> >> (XorV (VectorMaskCmp src1 src2 cond) (Replicate -1)) >> => (VectorMaskCmp src1 src2 ncond) >> (XorVMask (VectorMaskCmp src1 src2 cond) (MaskAll m1)) >> => (VectorMaskCmp src1 src2 ncond) >> >> cond can be eq, ne, le, ge, lt, gt, ule, uge, ult and ugt, ncond is the negative comparison of cond. >> >> For float and double types: >> >> (XorV (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (Replicate -1)) >> => (VectorMaskCast (VectorMaskCmp src1 src2 ncond)) >> (XorVMask (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (MaskAll m1)) >> => (VectorMaskCast (VectorMaskCmp src1 src2 ncond)) >> >> cond can be eq or ne. >> >> Benchmarks on Nvidia Grace machine with 128-bit SVE2: With option `-XX:UseSVE=2`: >> >> Benchmark Unit Before Score Error After Score Error Uplift >> testCompareEQMaskNotByte ops/s 7912127.225 2677.289518 10266136.26 8955.008548 1.29 >> testCompareEQMaskNotDouble ops/s 884737.6799 446.963779 1179760.772 448.031844 1.33 >> testCompareEQMaskNotFloat ops/s 1765045.787 682.332214 2359520.803 896.305743 1.33 >> testCompareEQMaskNotInt ops/s 1787221.411 977.743935 2353952.519 960.069976 1.31 >> testCompareEQMaskNotLong ops/s 895297.1974 673.44808 1178449.02 323.804205 1.31 >> testCompareEQMaskNotShort ops/s 3339987.002 3415.2226 4712761.965 2110.862053 1.41 >> testCompareGEMaskNotByte ops/s 7907615.16 4094.243652 10251646.9 9486.699831 1.29 >> testCompareGEMaskNotInt ops/s 1683738.958 4233.813092 2352855.205 1251.952546 1.39 >> testCompareGEMaskNotLong ops/s 854496.1561 8594.598885 1177811.493 521.1229 1.37 >> testCompareGEMaskNotShort ops/s 3341860.309 1578.975338 4714008.434 1681.10365 1.41 >> testCompareGTMaskNotByte ops/s 7910823.674 2993.367032 10245063.58 9774.75138 1.29 >> testCompareGTMaskNotInt ops/s 1673393.928 3153.099431 2353654.521 1190.848583 1.4 >> testCompareGTMaskNotLong ops/s 849405.9159 2432.858159 1177952.041 359.96413 1.38 >> testCompareGTMaskNotShort ops/s 3339509.141 3339.976585 4711442.496 2673.364893 1.41 >> testCompareLEMaskNotByte ops/s 7911340.004 3114.69191 10231626.5 27134.20035 1.29 >> testCompareLEMaskNotInt ops/s 1675812.113 1340.969885 2353255.341 1452.4522 1.4 >> testCompareLEMaskNotLong ops/s 848862.8036 6564.841731 1177763.623 539.290106 1.38 >> testCompareLEMaskNotShort ops/s 3324951.54 2380.29473 4712116.251 1544.559684 1.41 >> testCompareLTMaskNotByte ops/s 7910390.844 2630.861436 10239567.69 6487.441672 1.29 >> testCompareLTMaskNotInt ops/s 16721... > > erifan has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 15 additional commits since the last revision: > > - Address more comments > > ATT. > - Merge branch 'master' into JDK-8354242 > - Support negating unsigned comparison for BoolTest::mask > > Added a static method `negate_mask(mask btm)` into BoolTest class to > negate both signed and unsigned comparison. > - Addressed some review comments > - Merge branch 'master' into JDK-8354242 > - Refactor the JTReg tests for compare.xor(maskAll) > > Also made a bit change to support pattern `VectorMask.fromLong()`. > - Merge branch 'master' into JDK-8354242 > - Refactor code > > Add a new function XorVNode::Ideal_XorV_VectorMaskCmp to do this > optimization, making the code more modular. > - Merge branch 'master' into JDK-8354242 > - Update the jtreg test > - ... and 5 more: https://git.openjdk.org/jdk/compare/78e42324...5ebdc572 src/hotspot/share/opto/vectornode.cpp line 2243: > 2241: !VectorNode::is_all_ones_vector(in2)) { > 2242: return nullptr; > 2243: } Suggestion: if (in1->Opcode() != Op_VectorMaskCmp || in1->outcnt() != 1 || !(in1->as_VectorMaskCmp())->predicate_can_be_negated() || !VectorNode::is_all_ones_vector(in2)) { return nullptr; } Indentation for clarity. Currently, you exiting if one of these is the case: 1. Not `MaskCmp` 2. More than one use 3. predicate cannot be negated AND the vector is all ones. Can you explain this condition? Do you have tests for cases: - predicate negatable and vector not all ones - predircate not negatable and vector not all ones - predicate negatable and vector all ones - predicate not negatable and vectors all ones Why do you guard against `VectorNode::is_all_ones_vector(in2)` at all? The condition for 3. is easy to get wrong, so good testing is important here :) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24674#discussion_r2189075462 From xgong at openjdk.org Mon Jul 7 06:55:46 2025 From: xgong at openjdk.org (Xiaohong Gong) Date: Mon, 7 Jul 2025 06:55:46 GMT Subject: RFR: 8355563: VectorAPI: Refactor current implementation of subword gather load API [v2] In-Reply-To: References: <7GrGfBF_v8F0v02sRHC78ofMZwpMdzQZaHeYlNvi_N0=.93defb9e-ca9b-41b4-8722-1746692e2316@github.com> Message-ID: On Mon, 7 Jul 2025 02:05:06 GMT, Xiaohong Gong wrote: >> @XiaohongGong I quickly scanned the patch, it looks good to me too. I'm submitting some internal testing now, to make sure our extended testing does not break on integration. Should take about 24h. > > Hi @eme64 , may I ask how the testing is going on? Can we move on and integrate this patch now? Thanks a lot! > @XiaohongGong Thanks for putting in the work! > > Tests pass, and patch looks reasonable. Thanks so much for your review and test! ------------- PR Comment: https://git.openjdk.org/jdk/pull/25138#issuecomment-3043679621 From xgong at openjdk.org Mon Jul 7 06:55:47 2025 From: xgong at openjdk.org (Xiaohong Gong) Date: Mon, 7 Jul 2025 06:55:47 GMT Subject: Integrated: 8355563: VectorAPI: Refactor current implementation of subword gather load API In-Reply-To: References: Message-ID: On Fri, 9 May 2025 07:35:41 GMT, Xiaohong Gong wrote: > JDK-8318650 introduced hotspot intrinsification of subword gather load APIs for X86 platforms [1]. However, the current implementation is not optimal for AArch64 SVE platform, which natively supports vector instructions for subword gather load operations using an int vector for indices (see [2][3]). > > Two key areas require improvement: > 1. At the Java level, vector indices generated for range validation could be reused for the subsequent gather load operation on architectures with native vector instructions like AArch64 SVE. However, the current implementation prevents compiler reuse of these index vectors due to divergent control flow, potentially impacting performance. > 2. At the compiler IR level, the additional `offset` input for `LoadVectorGather`/`LoadVectorGatherMasked` with subword types increases IR complexity and complicates backend implementation. Furthermore, generating `add` instructions before each memory access negatively impacts performance. > > This patch refactors the implementation at both the Java level and compiler mid-end to improve efficiency and maintainability across different architectures. > > Main changes: > 1. Java-side API refactoring: > - Explicitly passes generated index vectors to hotspot, eliminating duplicate index vectors for gather load instructions on > architectures like AArch64. > 2. C2 compiler IR refactoring: > - Refactors `LoadVectorGather`/`LoadVectorGatherMasked` IR for subword types by removing the memory offset input and incorporating it into the memory base `addr` at the IR level. This simplifies backend implementation, reduces add operations, and unifies the IR across all types. > 3. Backend changes: > - Streamlines X86 implementation of subword gather operations following the removal of the offset input from the IR level. > > Performance: > The performance of the relative JMH improves up to 27% on a X86 AVX512 system. Please see the data below: > > Benchmark Mode Cnt Unit SIZE Before After Gain > GatherOperationsBenchmark.microByteGather128 thrpt 30 ops/ms 64 53682.012 52650.325 0.98 > GatherOperationsBenchmark.microByteGather128 thrpt 30 ops/ms 256 14484.252 14255.156 0.98 > GatherOperationsBenchmark.microByteGather128 thrpt 30 ops/ms 1024 3664.900 3595.615 0.98 > GatherOperationsBenchmark.microByteGather128 thrpt 30 ops/ms 4096 908.312 935.269 1.02 > GatherOperationsBenchmark.micr... This pull request has now been integrated. Changeset: d75ea7e6 Author: Xiaohong Gong URL: https://git.openjdk.org/jdk/commit/d75ea7e67951275fe27f1e137c961f39d779a046 Stats: 450 lines in 15 files changed: 109 ins; 176 del; 165 mod 8355563: VectorAPI: Refactor current implementation of subword gather load API Reviewed-by: epeter, psandoz, sviswanathan, jbhateja ------------- PR: https://git.openjdk.org/jdk/pull/25138 From xgong at openjdk.org Mon Jul 7 07:01:39 2025 From: xgong at openjdk.org (Xiaohong Gong) Date: Mon, 7 Jul 2025 07:01:39 GMT Subject: RFR: 8359419: AArch64: Relax min vector length to 32-bit for short vectors [v3] In-Reply-To: <5H0NP8vFqCDf1JgHIDee3WrYRbJ6koj5wQsxEGTW8nI=.87d74c6a-54b3-45cc-a972-c4350d5e2acf@github.com> References: <7VTRz_XqYBSdQ54n7ADzTzYADZjDbgBw6XuW0jehSLI=.24d18b87-4553-47ab-8065-d92fbb5700ae@github.com> <5H0NP8vFqCDf1JgHIDee3WrYRbJ6koj5wQsxEGTW8nI=.87d74c6a-54b3-45cc-a972-c4350d5e2acf@github.com> Message-ID: <0XcbEZkrW7fvJhPwQPP1UtT9aC3_OnT7sjoiHo0fOuQ=.1ec5ae91-55cb-4d8b-9e91-44ec02e63747@github.com> On Sat, 5 Jul 2025 15:08:35 GMT, Fei Gao wrote: > Have you measured the performance of this micro-benchmark on NEON machine? > > https://github.com/openjdk/jdk/blob/f2d2eef988c57cc9f6194a8fd5b2b422035ee68f/test/micro/org/openjdk/bench/vm/compiler/TypeVectorOperations.java#L251-L256 > > We added an limitation only for `int` before: > > https://github.com/openjdk/jdk/blob/f2d2eef988c57cc9f6194a8fd5b2b422035ee68f/src/hotspot/cpu/aarch64/aarch64_vector.ad#L131-L134 > > Perhaps we also need to impose a similar limitation on `short` if the same regression occurs. Good catch, and thanks so much for your input @fg1417 ! I will test the performance and disable auto-vectorization for double to short casting if the performance has regression. > https://github.com/openjdk/jdk/blob/f2d2eef988c57cc9f6194a8fd5b2b422035ee68f/test/hotspot/jtreg/compiler/vectorization/runner/ArrayTypeConvertTest.java#L388-L392 Actually I didn't change the min vector size for `char` vectors in this patch. Relaxing `short` vectors to 32-bit is to support the vector cast for Vector API, and there is no `char` species in it. Do you think it's better to do the same change for `char` as well? This will just benefit auto-vectorization. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26057#issuecomment-3043711086 From aph at openjdk.org Mon Jul 7 09:19:47 2025 From: aph at openjdk.org (Andrew Haley) Date: Mon, 7 Jul 2025 09:19:47 GMT Subject: Integrated: 8360884: Better scoped values In-Reply-To: <8yqi3J3JfLa2NNags9waBIshIMIuOJRjm-rHF--Wjws=.d04990af-5fdb-4218-a8da-60bda679b1d1@github.com> References: <8yqi3J3JfLa2NNags9waBIshIMIuOJRjm-rHF--Wjws=.d04990af-5fdb-4218-a8da-60bda679b1d1@github.com> Message-ID: On Fri, 27 Jun 2025 14:32:11 GMT, Andrew Haley wrote: > Scoped values cannot be used early in the JDK boot process because of some dependencies on System.getProperty(). This dependency should be removed in a way that allows scoped values to be created (but not necessarily bound) at any stage during boot. > > Also, Scoped Value's constructor has a synchronized block, which limits the use of scoped values at runtime. Constructing a scoped value should be a thread-local operation. This pull request has now been integrated. Changeset: 4df9c873 Author: Andrew Haley URL: https://git.openjdk.org/jdk/commit/4df9c873452293ccde3c7dbcd64e1ced6b6af52e Stats: 124 lines in 3 files changed: 73 ins; 8 del; 43 mod 8360884: Better scoped values Reviewed-by: liach, alanb ------------- PR: https://git.openjdk.org/jdk/pull/26019 From viktor.klang at oracle.com Mon Jul 7 09:34:57 2025 From: viktor.klang at oracle.com (Viktor Klang) Date: Mon, 7 Jul 2025 09:34:57 +0000 Subject: Question about mapConcurrent() Behavior and Happens-Before Guarantees In-Reply-To: References: Message-ID: Hi Jige, >Initially, I thought this design choice might provide a strong happens-before guarantee. My assumption was that an application catching a RuntimeException would be able to observe all side effects from the virtual threads, even though this practice is generally discouraged. This seemed like a potentially significant advantage, outweighing the risk of a virtual thread failing to respond to interruption or responding slowly. Unless explicitly stated in the API contract, no such guarantees should be presumed to exist. As for general resource-management in Stream, I have contemplated designs for Gatherer (and Collector) to be able to participate in the onClose actions, but there's a lot of ground to cover to ensure correct ordering and sufficiently-encompassing of cleanup action execution. Cheers, ? Viktor Klang Software Architect, Java Platform Group Oracle ________________________________ From: core-libs-dev on behalf of Jige Yu Sent: Thursday, 3 July 2025 16:36 To: core-libs-dev at openjdk.org Subject: Question about mapConcurrent() Behavior and Happens-Before Guarantees Hi JDK Core Devs, I'm writing to you today with a question about the behavior of mapConcurrent() and its interaction with unchecked exceptions. I've been experimenting with the API and observed that mapConcurrent() blocks and joins all virtual threads upon an unchecked exception before propagating it. Initially, I thought this design choice might provide a strong happens-before guarantee. My assumption was that an application catching a RuntimeException would be able to observe all side effects from the virtual threads, even though this practice is generally discouraged. This seemed like a potentially significant advantage, outweighing the risk of a virtual thread failing to respond to interruption or responding slowly. However, I've since realized that mapConcurrent() cannot fully guarantee a strong happens-before relationship when an unchecked exception occurs somewhere in the stream pipeline. While it can block and wait for exceptions thrown by the mapper function or downstream operations, it appears unable to intercept unchecked exceptions thrown by an upstream source. Consider a scenario with two input elements: if the first element starts a virtual thread, and then the second element causes an unchecked exception from the upstream before reaching the gather() call, the virtual thread initiated by the first element would not be interrupted. This makes the "happens-before" guarantee quite nuanced in practice. This brings me to my core questions: 1. Is providing a happens-before guarantee upon an unchecked exception a design goal for mapConcurrent()? 2. If not, would it be more desirable to not join on virtual threads when unchecked exceptions occur? This would allow the application code to catch the exception sooner and avoid the risk of being blocked indefinitely. Thank you for your time and insights. Best regards, Ben Yu -------------- next part -------------- An HTML attachment was scrubbed... URL: From duke at openjdk.org Mon Jul 7 09:35:47 2025 From: duke at openjdk.org (erifan) Date: Mon, 7 Jul 2025 09:35:47 GMT Subject: RFR: 8354242: VectorAPI: combine vector not operation with compare [v9] In-Reply-To: References: Message-ID: On Mon, 7 Jul 2025 06:19:15 GMT, Emanuel Peter wrote: >> erifan has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 15 additional commits since the last revision: >> >> - Address more comments >> >> ATT. >> - Merge branch 'master' into JDK-8354242 >> - Support negating unsigned comparison for BoolTest::mask >> >> Added a static method `negate_mask(mask btm)` into BoolTest class to >> negate both signed and unsigned comparison. >> - Addressed some review comments >> - Merge branch 'master' into JDK-8354242 >> - Refactor the JTReg tests for compare.xor(maskAll) >> >> Also made a bit change to support pattern `VectorMask.fromLong()`. >> - Merge branch 'master' into JDK-8354242 >> - Refactor code >> >> Add a new function XorVNode::Ideal_XorV_VectorMaskCmp to do this >> optimization, making the code more modular. >> - Merge branch 'master' into JDK-8354242 >> - Update the jtreg test >> - ... and 5 more: https://git.openjdk.org/jdk/compare/8e600a2f...5ebdc572 > > src/hotspot/share/opto/vectornode.cpp line 2243: > >> 2241: !VectorNode::is_all_ones_vector(in2)) { >> 2242: return nullptr; >> 2243: } > > Suggestion: > > if (in1->Opcode() != Op_VectorMaskCmp || > in1->outcnt() != 1 || > !(in1->as_VectorMaskCmp())->predicate_can_be_negated() || > !VectorNode::is_all_ones_vector(in2)) { > return nullptr; > } > > Indentation for clarity. > > Currently, you exiting if one of these is the case: > 1. Not `MaskCmp` > 2. More than one use > 3. predicate cannot be negated AND the vector is all ones. Can you explain this condition? Do you have tests for cases: > - predicate negatable and vector not all ones > - predircate not negatable and vector not all ones > - predicate negatable and vector all ones > - predicate not negatable and vectors all ones > > Why do you guard against `VectorNode::is_all_ones_vector(in2)` at all? > > The condition for 3. is easy to get wrong, so good testing is important here :) The current testing status for the conditions you listed: > 1. Not MaskCmp. **No test for it, tested locally**, Because I think this condition is too straightforward. > 2. More than one use. **Tested**, see `VectorMaskCompareNotTest.java line 1118`. > predicate negatable and vector not all ones. **Tested**, see `VectorMaskCompareNotTest.java line 1126`. > predicate not negatable and vector not all ones. **No test for it**, because we have tests for `predicate not negatable` or `vector not all ones`. If either is `false`, return nullptr. > predicate negatable and vector all ones. **A lot of tests for it**. For example `VectorMaskCompareNotTest.java line 1014`. > predicate not negatable and vectors all ones. **Tested**, see `VectorMaskCompareNotTest.java line 1222`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24674#discussion_r2189495935 From dfuchs at openjdk.org Mon Jul 7 09:51:32 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Mon, 7 Jul 2025 09:51:32 GMT Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API [v10] In-Reply-To: References: Message-ID: > Hi, > > Please find here a PR for the implementation of [JEP 517: HTTP/3 for the HTTP Client API](https://openjdk.org/jeps/517). > > The CSR can be viewed at [JDK-8350588: Implement JEP 517: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588) > > This JEP proposes to enhance the HttpClient implementation to support HTTP/3. > It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider. Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 545 commits: - http3: rename PacketSpaceManager::isAcknowledging to PacketSpaceManager::trackAcknowledgement - merge latest changes from master branch - http3: fix typo in UniStreamPair.java - WriterQueue may leak before the constructor completes - Limit the number of retries in H3UserInfoTest - Implement IntReader - Remove dispatchers field - http3: when looking for a connection in the pool, prefer advertised connections for ANY - http3: fix Http3PendingConnections::removeCompleted to take into account the case where the Http3Connection was created with an AltService, but we don't have it because the handshake failed - Use default timeout in BasicHttp3Test - ... and 535 more: https://git.openjdk.org/jdk/compare/5cf349c3...9d67d4a6 ------------- Changes: https://git.openjdk.org/jdk/pull/24751/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24751&range=09 Stats: 105147 lines in 470 files changed: 102317 ins; 1335 del; 1495 mod Patch: https://git.openjdk.org/jdk/pull/24751.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24751/head:pull/24751 PR: https://git.openjdk.org/jdk/pull/24751 From pminborg at openjdk.org Mon Jul 7 10:00:54 2025 From: pminborg at openjdk.org (Per Minborg) Date: Mon, 7 Jul 2025 10:00:54 GMT Subject: RFR: 8361300: Document exceptions for Unsafe offset methods [v4] In-Reply-To: References: Message-ID: On Thu, 3 Jul 2025 18:41:27 GMT, Chen Liang wrote: >> Unsafe throws IAE for misusing static vs instance fields, and it's revealed that AtomicXxxFieldUpdaters are using this mechanism to reject static fields. This is not a good practice, but we can at least document this so we don't accidentally introduce problems. > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > Test to verify observed internal unsafe behaviors src/java.base/share/classes/java/util/concurrent/atomic/AtomicIntegerFieldUpdater.java line 405: > 403: throw new IllegalArgumentException("Must be volatile type"); > 404: > 405: if (Modifier.isStatic(modifiers)) Can we break out the Modifier tests in the three updater classes to a common method? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25945#discussion_r2189548142 From alanb at openjdk.org Mon Jul 7 10:00:55 2025 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 7 Jul 2025 10:00:55 GMT Subject: RFR: 8361300: Document exceptions for Unsafe offset methods [v4] In-Reply-To: References: Message-ID: On Thu, 3 Jul 2025 18:41:27 GMT, Chen Liang wrote: >> Unsafe throws IAE for misusing static vs instance fields, and it's revealed that AtomicXxxFieldUpdaters are using this mechanism to reject static fields. This is not a good practice, but we can at least document this so we don't accidentally introduce problems. > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > Test to verify observed internal unsafe behaviors src/java.base/share/classes/java/util/concurrent/atomic/AtomicIntegerFieldUpdater.java line 407: > 405: if (Modifier.isStatic(modifiers)) > 406: throw new IllegalArgumentException("Must not be a static field"); > 407: @viktorklang-ora @DougLea Should we update the Atomic*FieldUpdater to specify the IAE when the factory method is called with a static Field? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25945#discussion_r2189553083 From vklang at openjdk.org Mon Jul 7 10:00:55 2025 From: vklang at openjdk.org (Viktor Klang) Date: Mon, 7 Jul 2025 10:00:55 GMT Subject: RFR: 8361300: Document exceptions for Unsafe offset methods [v4] In-Reply-To: References: Message-ID: On Mon, 7 Jul 2025 09:56:07 GMT, Alan Bateman wrote: >> Chen Liang has updated the pull request incrementally with one additional commit since the last revision: >> >> Test to verify observed internal unsafe behaviors > > src/java.base/share/classes/java/util/concurrent/atomic/AtomicIntegerFieldUpdater.java line 407: > >> 405: if (Modifier.isStatic(modifiers)) >> 406: throw new IllegalArgumentException("Must not be a static field"); >> 407: > > @viktorklang-ora @DougLea Should we update the Atomic*FieldUpdater to specify the IAE when the factory method is called with a static Field? @AlanBateman Yeah, I think that makes sense?IIRC it's been that way in practice since forever, but making it clear in documentation seems like the right thing to do. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25945#discussion_r2189557771 From bkilambi at openjdk.org Mon Jul 7 10:27:39 2025 From: bkilambi at openjdk.org (Bhavana Kilambi) Date: Mon, 7 Jul 2025 10:27:39 GMT Subject: RFR: 8359419: AArch64: Relax min vector length to 32-bit for short vectors [v3] In-Reply-To: <0XcbEZkrW7fvJhPwQPP1UtT9aC3_OnT7sjoiHo0fOuQ=.1ec5ae91-55cb-4d8b-9e91-44ec02e63747@github.com> References: <7VTRz_XqYBSdQ54n7ADzTzYADZjDbgBw6XuW0jehSLI=.24d18b87-4553-47ab-8065-d92fbb5700ae@github.com> <5H0NP8vFqCDf1JgHIDee3WrYRbJ6koj5wQsxEGTW8nI=.87d74c6a-54b3-45cc-a972-c4350d5e2acf@github.com> <0XcbEZkrW7fvJhPwQPP1UtT9aC3_OnT7sjoiHo0fOuQ=.1ec5ae91-55cb-4d8b-9e91-44ec02e63747@github.com> Message-ID: On Mon, 7 Jul 2025 06:59:20 GMT, Xiaohong Gong wrote: >> Have you measured the performance of this micro-benchmark on NEON machine? >> https://github.com/openjdk/jdk/blob/f2d2eef988c57cc9f6194a8fd5b2b422035ee68f/test/micro/org/openjdk/bench/vm/compiler/TypeVectorOperations.java#L251-L256 >> >> We added an limitation only for `int` before: >> https://github.com/openjdk/jdk/blob/f2d2eef988c57cc9f6194a8fd5b2b422035ee68f/src/hotspot/cpu/aarch64/aarch64_vector.ad#L131-L134 >> >> Perhaps we also need to impose a similar limitation on `short` if the same regression occurs. > >> Have you measured the performance of this micro-benchmark on NEON machine? >> >> https://github.com/openjdk/jdk/blob/f2d2eef988c57cc9f6194a8fd5b2b422035ee68f/test/micro/org/openjdk/bench/vm/compiler/TypeVectorOperations.java#L251-L256 >> >> We added an limitation only for `int` before: >> >> https://github.com/openjdk/jdk/blob/f2d2eef988c57cc9f6194a8fd5b2b422035ee68f/src/hotspot/cpu/aarch64/aarch64_vector.ad#L131-L134 >> >> Perhaps we also need to impose a similar limitation on `short` if the same regression occurs. > > Good catch, and thanks so much for your input @fg1417 ! I will test the performance and disable auto-vectorization for double to short casting if the performance has regression. > >> https://github.com/openjdk/jdk/blob/f2d2eef988c57cc9f6194a8fd5b2b422035ee68f/test/hotspot/jtreg/compiler/vectorization/runner/ArrayTypeConvertTest.java#L388-L392 > > Actually I didn't change the min vector size for `char` vectors in this patch. Relaxing `short` vectors to 32-bit is to support the vector cast for Vector API, and there is no `char` species in it. Do you think it's better to do the same change for `char` as well? This will just benefit auto-vectorization. Hi @XiaohongGong, is there any way we can implement 2HF -> 2S and 2S -> 2HF in these match rules ? https://github.com/openjdk/jdk/blob/f2d2eef988c57cc9f6194a8fd5b2b422035ee68f/src/hotspot/cpu/aarch64/aarch64_vector.ad#L4697 https://github.com/openjdk/jdk/blob/f2d2eef988c57cc9f6194a8fd5b2b422035ee68f/src/hotspot/cpu/aarch64/aarch64_vector.ad#L4679 The `fcvtn` and `fcvtl` instructions do not support these arrangements. I was wondering if there is any other way we can implement these by any chance? ------------- PR Comment: https://git.openjdk.org/jdk/pull/26057#issuecomment-3044358446 From liach at openjdk.org Mon Jul 7 12:09:39 2025 From: liach at openjdk.org (Chen Liang) Date: Mon, 7 Jul 2025 12:09:39 GMT Subject: RFR: 8361300: Document exceptions for Unsafe offset methods [v4] In-Reply-To: References: Message-ID: On Mon, 7 Jul 2025 09:54:28 GMT, Per Minborg wrote: >> Chen Liang has updated the pull request incrementally with one additional commit since the last revision: >> >> Test to verify observed internal unsafe behaviors > > src/java.base/share/classes/java/util/concurrent/atomic/AtomicIntegerFieldUpdater.java line 405: > >> 403: throw new IllegalArgumentException("Must be volatile type"); >> 404: >> 405: if (Modifier.isStatic(modifiers)) > > Can we break out the Modifier tests in the three updater classes to a common method? Should we include that in this patch? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25945#discussion_r2189863484 From liach at openjdk.org Mon Jul 7 12:09:40 2025 From: liach at openjdk.org (Chen Liang) Date: Mon, 7 Jul 2025 12:09:40 GMT Subject: RFR: 8361300: Document exceptions for Unsafe offset methods [v4] In-Reply-To: References: Message-ID: <3stoVvRmIX7pk8ehqJSYzQwDu2MgQHPnezsoCgEo9Xo=.64f6a467-d0eb-47be-993d-e64a53a7e442@github.com> On Mon, 7 Jul 2025 09:58:15 GMT, Viktor Klang wrote: >> src/java.base/share/classes/java/util/concurrent/atomic/AtomicIntegerFieldUpdater.java line 407: >> >>> 405: if (Modifier.isStatic(modifiers)) >>> 406: throw new IllegalArgumentException("Must not be a static field"); >>> 407: >> >> @viktorklang-ora @DougLea Should we update the Atomic*FieldUpdater to specify the IAE when the factory method is called with a static Field? > > @AlanBateman Yeah, I think that makes sense?IIRC it's been that way in practice since forever, but making it clear in documentation seems like the right thing to do. Tracked in 8360541; I think we can implement in a separate patch. Don't know if this is worth backporting to MRs. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25945#discussion_r2189865695 From jpai at openjdk.org Mon Jul 7 12:32:44 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 7 Jul 2025 12:32:44 GMT Subject: RFR: 8357272: Add overrides for all default methods to wrapper collections In-Reply-To: References: Message-ID: On Wed, 28 May 2025 03:03:45 GMT, Stuart Marks wrote: > This mostly just adds overrides to the wrapper implementations in java.util.Collections. However, in order to satisfy the test, some overrides are also added to ReverseOrderSortedMapView, which is used by the SortedMap wrapper keySet, values, and entrySet views. These overrides don't do anything except to call super, so they're arguably dead code. However, they enable all combinations of sequenced map views to be tested, which is valuable. src/java.base/share/classes/java/util/Collections.java line 1052: > 1050: * are intended to override but are declared improperly will be detected through testing. > 1051: * (The @Override annotation still occurs in several places in this file. These will be > 1052: * removed over time.) Nit - The last sentence, I think, isn't necessary. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25478#discussion_r2189932047 From tschatzl at openjdk.org Mon Jul 7 12:36:40 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 7 Jul 2025 12:36:40 GMT Subject: RFR: 8342382: Implementation of JEP G1: Improve Application Throughput with a More Efficient Write-Barrier [v41] In-Reply-To: References: Message-ID: > Hi all, > > please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier. > > The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25. > > ### Current situation > > With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier. > > The main reason for the current barrier is how g1 implements concurrent refinement: > * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations. > * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads, > * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible. > > These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code: > > > // Filtering > if (region(@x.a) == region(y)) goto done; // same region check > if (y == null) goto done; // null value check > if (card(@x.a) == young_card) goto done; // write to young gen check > StoreLoad; // synchronize > if (card(@x.a) == dirty_card) goto done; > > *card(@x.a) = dirty > > // Card tracking > enqueue(card-address(@x.a)) into thread-local-dcq; > if (thread-local-dcq is not full) goto done; > > call runtime to move thread-local-dcq into dcqs > > done: > > > Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc. > > The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining. > > There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links). > > The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching card tables. Mutators only work on the "primary" card table, refinement threads on a se... Thomas Schatzl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 57 commits: - Merge branch 'master' into 8342382-card-table-instead-of-dcq - Merge branch 'master' into 8342382-card-table-instead-of-dcq - Merge branch 'master' into 8342382-card-table-instead-of-dcq - Merge branch 'master' into 8342382-card-table-instead-of-dcq - * ayang review: remove sweep_epoch - Merge branch 'master' into card-table-as-dcq-merge - Merge branch 'master' into 8342382-card-table-instead-of-dcq - * ayang review (part 2 - yield duration changes) - * ayang review (part 1) - * indentation fix - ... and 47 more: https://git.openjdk.org/jdk/compare/d75ea7e6...441c234a ------------- Changes: https://git.openjdk.org/jdk/pull/23739/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=40 Stats: 7121 lines in 112 files changed: 2585 ins; 3590 del; 946 mod Patch: https://git.openjdk.org/jdk/pull/23739.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23739/head:pull/23739 PR: https://git.openjdk.org/jdk/pull/23739 From jpai at openjdk.org Mon Jul 7 12:38:47 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 7 Jul 2025 12:38:47 GMT Subject: RFR: 8357272: Add overrides for all default methods to wrapper collections In-Reply-To: References: Message-ID: On Wed, 28 May 2025 03:03:45 GMT, Stuart Marks wrote: > This mostly just adds overrides to the wrapper implementations in java.util.Collections. However, in order to satisfy the test, some overrides are also added to ReverseOrderSortedMapView, which is used by the SortedMap wrapper keySet, values, and entrySet views. These overrides don't do anything except to call super, so they're arguably dead code. However, they enable all combinations of sequenced map views to be tested, which is valuable. src/java.base/share/classes/java/util/Collections.java line 1407: > 1405: public E removeFirst() {throw new UnsupportedOperationException();} > 1406: public E removeLast() {throw new UnsupportedOperationException();} > 1407: Is this `UnmodifiableSortedSet` missing an override for the `Spliterator spliterator()` default method that's on `SortedSet`? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25478#discussion_r2189950431 From jpai at openjdk.org Mon Jul 7 12:46:55 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 7 Jul 2025 12:46:55 GMT Subject: RFR: 8357272: Add overrides for all default methods to wrapper collections In-Reply-To: References: Message-ID: On Wed, 28 May 2025 03:03:45 GMT, Stuart Marks wrote: > This mostly just adds overrides to the wrapper implementations in java.util.Collections. However, in order to satisfy the test, some overrides are also added to ReverseOrderSortedMapView, which is used by the SortedMap wrapper keySet, values, and entrySet views. These overrides don't do anything except to call super, so they're arguably dead code. However, they enable all combinations of sequenced map views to be tested, which is valuable. src/java.base/share/classes/java/util/Collections.java line 1498: > 1496: public E removeFirst() { throw new UnsupportedOperationException(); } > 1497: public E removeLast() { throw new UnsupportedOperationException(); } > 1498: This one too appears to be missing the override for the default `spliterator()`? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25478#discussion_r2189969609 From rriggs at openjdk.org Mon Jul 7 12:46:56 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Mon, 7 Jul 2025 12:46:56 GMT Subject: Integrated: 8354872: Clarify java.lang.Process resource cleanup In-Reply-To: <39KIPIXZDBI9tpPyXew2Ye-uzPvkLSQnOzGJFuK9E2Y=.dc8df88f-f21a-4dd6-8297-5629098bd408@github.com> References: <39KIPIXZDBI9tpPyXew2Ye-uzPvkLSQnOzGJFuK9E2Y=.dc8df88f-f21a-4dd6-8297-5629098bd408@github.com> Message-ID: On Wed, 18 Jun 2025 20:16:18 GMT, Roger Riggs wrote: > Improve the documentation of Process use of system resources. > > Describe the implementation closing streams when no longer referenced. > Clarify the interactions between inputStream and inputReader and errorStream and errorReader. > Add advice and example using try-with-resources to open and close streams. > Recommend closing streams when no longer in use. This pull request has now been integrated. Changeset: afb4a1be Author: Roger Riggs URL: https://git.openjdk.org/jdk/commit/afb4a1be9e5dc2a9c0d812f5a36717c9f82241a9 Stats: 185 lines in 2 files changed: 99 ins; 7 del; 79 mod 8354872: Clarify java.lang.Process resource cleanup Reviewed-by: jpai ------------- PR: https://git.openjdk.org/jdk/pull/25884 From jpai at openjdk.org Mon Jul 7 12:54:41 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 7 Jul 2025 12:54:41 GMT Subject: RFR: 8357272: Add overrides for all default methods to wrapper collections In-Reply-To: References: Message-ID: <93htmEhZdx-X66IxK5qMvJMC4MT7zQJe4vhUf1QPkzk=.c5bee49c-478e-42e6-a7e4-c7dceef86870@github.com> On Wed, 28 May 2025 03:03:45 GMT, Stuart Marks wrote: > This mostly just adds overrides to the wrapper implementations in java.util.Collections. However, in order to satisfy the test, some overrides are also added to ReverseOrderSortedMapView, which is used by the SortedMap wrapper keySet, values, and entrySet views. These overrides don't do anything except to call super, so they're arguably dead code. However, they enable all combinations of sequenced map views to be tested, which is valuable. src/java.base/share/classes/java/util/Collections.java line 1600: > 1598: > 1599: public List reversed() { > 1600: return ReverseOrderListView.of(this, false); In some other overrides in this PR, we implement this like `return new UnmodifiableNavigableSet<>(ns.reversed());`. Is there a semantical difference between that style compared to using `ReverseOrderListView.of(this, false);`? In other words, for consistency, can this override be implemented as: return new UnmodifiableList<>(list.reversed()); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25478#discussion_r2189989621 From jpai at openjdk.org Mon Jul 7 13:01:55 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 7 Jul 2025 13:01:55 GMT Subject: RFR: 8357272: Add overrides for all default methods to wrapper collections In-Reply-To: References: Message-ID: On Wed, 28 May 2025 03:03:45 GMT, Stuart Marks wrote: > This mostly just adds overrides to the wrapper implementations in java.util.Collections. However, in order to satisfy the test, some overrides are also added to ReverseOrderSortedMapView, which is used by the SortedMap wrapper keySet, values, and entrySet views. These overrides don't do anything except to call super, so they're arguably dead code. However, they enable all combinations of sequenced map views to be tested, which is valuable. src/java.base/share/classes/java/util/Collections.java line 2768: > 2766: } > 2767: } > 2768: Is this `SynchronizedNavigableSet` missing overrides for the `addFirst/addLast/removeFirst/removeLast/getFirst/getLast` default methods? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25478#discussion_r2190003455 From jpai at openjdk.org Mon Jul 7 13:05:44 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 7 Jul 2025 13:05:44 GMT Subject: RFR: 8357272: Add overrides for all default methods to wrapper collections In-Reply-To: References: Message-ID: On Mon, 7 Jul 2025 12:58:39 GMT, Jaikiran Pai wrote: >> This mostly just adds overrides to the wrapper implementations in java.util.Collections. However, in order to satisfy the test, some overrides are also added to ReverseOrderSortedMapView, which is used by the SortedMap wrapper keySet, values, and entrySet views. These overrides don't do anything except to call super, so they're arguably dead code. However, they enable all combinations of sequenced map views to be tested, which is valuable. > > src/java.base/share/classes/java/util/Collections.java line 2768: > >> 2766: } >> 2767: } >> 2768: > > Is this `SynchronizedNavigableSet` missing overrides for the `addFirst/addLast/removeFirst/removeLast/getFirst/getLast` default methods? Maybe not, because this extends the nearby `SynchronizedSortedSet` which has the overridden default methods. Would it still be worth considering overriding those here too? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25478#discussion_r2190014774 From fgao at openjdk.org Mon Jul 7 13:27:40 2025 From: fgao at openjdk.org (Fei Gao) Date: Mon, 7 Jul 2025 13:27:40 GMT Subject: RFR: 8359419: AArch64: Relax min vector length to 32-bit for short vectors [v3] In-Reply-To: <0XcbEZkrW7fvJhPwQPP1UtT9aC3_OnT7sjoiHo0fOuQ=.1ec5ae91-55cb-4d8b-9e91-44ec02e63747@github.com> References: <7VTRz_XqYBSdQ54n7ADzTzYADZjDbgBw6XuW0jehSLI=.24d18b87-4553-47ab-8065-d92fbb5700ae@github.com> <5H0NP8vFqCDf1JgHIDee3WrYRbJ6koj5wQsxEGTW8nI=.87d74c6a-54b3-45cc-a972-c4350d5e2acf@github.com> <0XcbEZkrW7fvJhPwQPP1UtT9aC3_OnT7sjoiHo0fOuQ=.1ec5ae91-55cb-4d8b-9e91-44ec02e63747@github.com> Message-ID: On Mon, 7 Jul 2025 06:59:20 GMT, Xiaohong Gong wrote: > > https://github.com/openjdk/jdk/blob/f2d2eef988c57cc9f6194a8fd5b2b422035ee68f/test/hotspot/jtreg/compiler/vectorization/runner/ArrayTypeConvertTest.java#L388-L392 > > Actually I didn't change the min vector size for `char` vectors in this patch. Relaxing `short` vectors to 32-bit is to support the vector cast for Vector API, and there is no `char` species in it. Do you think it's better to do the same change for `char` as well? This will just benefit auto-vectorization. Hi @XiaohongGong thanks for asking. In many auto-vectorization cases involving `char`, the vector elements are represented using `T_SHORT` as the `BasicType`, rather than `T_CHAR`. This is because, in Java, operands of subword types are always promoted to `int` before any arithmetic operation. As a result, when handling a node like `ConvD2I`, we don?t initially know its actual subword type. Later, the SuperWord phase propagates a narrowed integer type backward to help determine the correct subword type. See: https://github.com/openjdk/jdk/blob/f2d2eef988c57cc9f6194a8fd5b2b422035ee68f/src/hotspot/share/opto/superword.cpp#L2551-L2558 Since SuperWord assigns `T_SHORT` to `StoreC` early on https://github.com/openjdk/jdk/blob/f2d2eef988c57cc9f6194a8fd5b2b422035ee68f/src/hotspot/share/opto/superword.cpp#L2646-L2650 the entire propagation chain tends to use `T_SHORT` as well. This applies to most operations, with the exception of a few like `RShiftI`, `Abs`, and `ReverseBytesI`, which are handled separately. So your change already benefits many char-related vectorization cases like `convertDoubleToChar` above. That?s why we can safely relax the IR condition mentioned earlier. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26057#issuecomment-3045113900 From duke at openjdk.org Mon Jul 7 15:40:50 2025 From: duke at openjdk.org (Khalid Boulanouare) Date: Mon, 7 Jul 2025 15:40:50 GMT Subject: RFR: 8361188: Test java/awt/Mixing/AWT_Mixing/JComboBoxOverlapping.java fails on Mac OS X Message-ID: Fixed an issue where null value component is not checked in class java/awt/Mixing/AWT_Mixing/OverlappingTestBase. Also removed test java/awt/Mixing/AWT_Mixing/JComboBoxOverlapping.java from problem list file. ------------- Depends on: https://git.openjdk.org/jdk/pull/25971 Commit messages: - Merge branch 'pr/25971' into jdk-8361188 - Merge branch 'pr/25971' into jdk-8361188 - Merge branch 'openjdk:master' into jdk-8361188 - Removes test from Problem List - Returns false if component is null, in the case of embedded frame Changes: https://git.openjdk.org/jdk/pull/26162/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26162&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8361188 Stats: 3 lines in 2 files changed: 1 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/26162.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26162/head:pull/26162 PR: https://git.openjdk.org/jdk/pull/26162 From aph at openjdk.org Mon Jul 7 16:19:20 2025 From: aph at openjdk.org (Andrew Haley) Date: Mon, 7 Jul 2025 16:19:20 GMT Subject: RFR: 8361497: Scoped Values: orElse and orElseThrow do not access the cache Message-ID: Neither `ScopedValue.orElse` nor `ScopedValue.orElseThrow` consult the cache when searching for a binding. Neither do they update the cache when a binding is found. While this issue does not affect spec compliance, it is surprising to users that `x.orElse(other)` should be slower than `x.isBound ? x.get() : other`. ------------- Commit messages: - 8361497: Scoped Values: orElse and orElseThrow do not access the cache - Merge branch 'master' into JDK-8361497 - 8361497: Scoped Values: orElse and orElseThrow do not access the cache Changes: https://git.openjdk.org/jdk/pull/26164/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26164&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8361497 Stats: 100 lines in 2 files changed: 85 ins; 0 del; 15 mod Patch: https://git.openjdk.org/jdk/pull/26164.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26164/head:pull/26164 PR: https://git.openjdk.org/jdk/pull/26164 From aph at openjdk.org Mon Jul 7 16:19:20 2025 From: aph at openjdk.org (Andrew Haley) Date: Mon, 7 Jul 2025 16:19:20 GMT Subject: RFR: 8361497: Scoped Values: orElse and orElseThrow do not access the cache In-Reply-To: References: Message-ID: On Mon, 7 Jul 2025 16:13:08 GMT, Andrew Haley wrote: > Neither `ScopedValue.orElse` nor `ScopedValue.orElseThrow` consult the cache when searching for a binding. Neither do they update the cache when a binding is found. > While this issue does not affect spec compliance, it is surprising to users that `x.orElse(other)` should be slower than `x.isBound ? x.get() : other`. I've also added some more performance tests to ensure that `orElse()` really does consult the cache. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26164#issuecomment-3045772935 From liach at openjdk.org Mon Jul 7 16:35:39 2025 From: liach at openjdk.org (Chen Liang) Date: Mon, 7 Jul 2025 16:35:39 GMT Subject: RFR: 8361497: Scoped Values: orElse and orElseThrow do not access the cache In-Reply-To: References: Message-ID: <-wBBj6wgMQayipWS3L3-L5ItuUX0OeHcjQR22tci3pg=.a340f85a-683b-40e5-9cec-afa62efe11fb@github.com> On Mon, 7 Jul 2025 16:13:08 GMT, Andrew Haley wrote: > Neither `ScopedValue.orElse` nor `ScopedValue.orElseThrow` consult the cache when searching for a binding. Neither do they update the cache when a binding is found. > While this issue does not affect spec compliance, it is surprising to users that `x.orElse(other)` should be slower than `x.isBound ? x.get() : other`. Can `get` and `slowGet` be refactored to use this `findBinding` too? That way we have just one piece of code accessing the cache, easier for long-term maintenance. `get` can probably become something like: var value = findBinding(); if (value == Snapshot.NIL) { throw new NoSuchElementException("ScopedValue not bound"); } return (T)value; and remove `slowGet` altogether. P.S. moved from inline comments, not really suitable for inline ------------- PR Comment: https://git.openjdk.org/jdk/pull/26164#issuecomment-3045855108 From darcy at openjdk.org Mon Jul 7 18:03:40 2025 From: darcy at openjdk.org (Joe Darcy) Date: Mon, 7 Jul 2025 18:03:40 GMT Subject: RFR: 8360559: Optimize Math.sinh for x86 64 bit platforms In-Reply-To: References: Message-ID: On Mon, 7 Jul 2025 03:05:15 GMT, Mohamed Issa wrote: > The goal of this PR is to implement an x86_64 intrinsic for java.lang.Math.sinh() using libm. There is a new set of micro-benchmarks are included to check the performance of specific input value ranges to help prevent regressions in the future. > > The command to run all range specific micro-benchmarks is posted below. > > `make test TEST="micro:SinhPerf.SinhPerfRanges"` > > The results of all tests posted below were captured with an [Intel? Xeon 8488C](https://advisor.cloudzero.com/aws/ec2/r7i.metal-24xl) using [OpenJDK v26-b4](https://github.com/openjdk/jdk/releases/tag/jdk-26%2B4) as the baseline version. > > For performance data collected with the new built in range micro-benchmark, see the table below. Each result is the mean of 8 individual runs, and the input ranges used match those from the original Java implementation. Overall, the intrinsic provides an an average uplift of 64% when input values fall into the middle three ranges where heavy computation is required. However, very small inputs and very large inputs show drops of 74% and 66% respectively. > > | Input range(s) | Baseline throughput (ops/ms) | Intrinsic throughput (ops/ms) | Speedup | > | :------------------------------------: | :-------------------------------: | :--------------------------------: | :--------: | > | [-2^(-28), 2^(-28)] | 844160 | 216029 | 0.26x | > | [-22, -2^(-28)], [2^(-28), 22] | 81662 | 157351 | 1.93x | > | [-709.78, -22], [22, 709.78] | 119075 | 167635 | 1.41x | > | [-710.48, -709.78], [709.78, 710.48] | 111636 | 177125 | 1.59x | > | (-INF, -710.48], [710.48, INF) | 959296 | 313839 | 0.33x | > > Finally, the `jtreg:test/jdk/java/lang/Math/HyperbolicTests.java` test passed with the changes. Are there plans for a cosh intrinsic as follow-up work? There was a previous effort to intrinsify tanh. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26152#issuecomment-3046086649 From darcy at openjdk.org Mon Jul 7 18:06:39 2025 From: darcy at openjdk.org (Joe Darcy) Date: Mon, 7 Jul 2025 18:06:39 GMT Subject: RFR: 8360559: Optimize Math.sinh for x86 64 bit platforms In-Reply-To: References: Message-ID: On Mon, 7 Jul 2025 03:05:15 GMT, Mohamed Issa wrote: > The goal of this PR is to implement an x86_64 intrinsic for java.lang.Math.sinh() using libm. There is a new set of micro-benchmarks are included to check the performance of specific input value ranges to help prevent regressions in the future. > > The command to run all range specific micro-benchmarks is posted below. > > `make test TEST="micro:SinhPerf.SinhPerfRanges"` > > The results of all tests posted below were captured with an [Intel? Xeon 8488C](https://advisor.cloudzero.com/aws/ec2/r7i.metal-24xl) using [OpenJDK v26-b4](https://github.com/openjdk/jdk/releases/tag/jdk-26%2B4) as the baseline version. > > For performance data collected with the new built in range micro-benchmark, see the table below. Each result is the mean of 8 individual runs, and the input ranges used match those from the original Java implementation. Overall, the intrinsic provides an an average uplift of 64% when input values fall into the middle three ranges where heavy computation is required. However, very small inputs and very large inputs show drops of 74% and 66% respectively. > > | Input range(s) | Baseline throughput (ops/ms) | Intrinsic throughput (ops/ms) | Speedup | > | :------------------------------------: | :-------------------------------: | :--------------------------------: | :--------: | > | [-2^(-28), 2^(-28)] | 844160 | 216029 | 0.26x | > | [-22, -2^(-28)], [2^(-28), 22] | 81662 | 157351 | 1.93x | > | [-709.78, -22], [22, 709.78] | 119075 | 167635 | 1.41x | > | [-710.48, -709.78], [709.78, 710.48] | 111636 | 177125 | 1.59x | > | (-INF, -710.48], [710.48, INF) | 959296 | 313839 | 0.33x | > > Finally, the `jtreg:test/jdk/java/lang/Math/HyperbolicTests.java` test passed with the changes. A large fraction of floating-point numbers are in the [-2^(-28), 2^(-28)] range where there is a performance degradation with the new implementation. What is the expected distribution of arguments to sinh? ------------- PR Comment: https://git.openjdk.org/jdk/pull/26152#issuecomment-3046093111 From rriggs at openjdk.org Mon Jul 7 18:34:16 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Mon, 7 Jul 2025 18:34:16 GMT Subject: [jdk25] RFR: 8354872: Clarify java.lang.Process resource cleanup Message-ID: Identical doc-only backport to jdk 25. Already approved in the CSR. ------------- Commit messages: - Backport afb4a1be9e5dc2a9c0d812f5a36717c9f82241a9 Changes: https://git.openjdk.org/jdk/pull/26168/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26168&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8354872 Stats: 185 lines in 2 files changed: 99 ins; 7 del; 79 mod Patch: https://git.openjdk.org/jdk/pull/26168.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26168/head:pull/26168 PR: https://git.openjdk.org/jdk/pull/26168 From iris at openjdk.org Mon Jul 7 18:45:40 2025 From: iris at openjdk.org (Iris Clark) Date: Mon, 7 Jul 2025 18:45:40 GMT Subject: [jdk25] RFR: 8354872: Clarify java.lang.Process resource cleanup In-Reply-To: References: Message-ID: On Mon, 7 Jul 2025 18:29:34 GMT, Roger Riggs wrote: > Identical doc-only backport to jdk 25. Already approved in the CSR. Changes appear to be identical to those in `master` branch. ------------- Marked as reviewed by iris (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26168#pullrequestreview-2994952826 From naoto at openjdk.org Mon Jul 7 19:13:15 2025 From: naoto at openjdk.org (Naoto Sato) Date: Mon, 7 Jul 2025 19:13:15 GMT Subject: RFR: 8361519: Obsolete Unicode Scalar Value link in Character class Message-ID: Refining the description of "Unicode Scalar Value" in the `Character` class. The original description referenced the outdated Unicode 3.1 specification, which previously included the U+xxxx notation but no longer does. Updated the reference to point to the Unicode glossary, which defines the term more accurately. Additionally, replaced the obsolete `@spec` link to Unicode 3.1.0 with a reference to the current Unicode Character Database. ------------- Commit messages: - initial commit Changes: https://git.openjdk.org/jdk/pull/26169/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26169&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8361519 Stats: 6 lines in 1 file changed: 0 ins; 2 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/26169.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26169/head:pull/26169 PR: https://git.openjdk.org/jdk/pull/26169 From iris at openjdk.org Mon Jul 7 19:30:40 2025 From: iris at openjdk.org (Iris Clark) Date: Mon, 7 Jul 2025 19:30:40 GMT Subject: RFR: 8361519: Obsolete Unicode Scalar Value link in Character class In-Reply-To: References: Message-ID: On Mon, 7 Jul 2025 19:08:22 GMT, Naoto Sato wrote: > Refining the description of "Unicode Scalar Value" in the `Character` class. > The original description referenced the outdated Unicode 3.1 specification, which previously included the U+xxxx notation but no longer does. Updated the reference to point to the Unicode glossary, which defines the term more accurately. Additionally, replaced the obsolete `@spec` link to Unicode 3.1.0 with a reference to the current Unicode Character Database. Looks good. Since this appears to be the only reference to Unicode 3.1.0 in the repo, this change should drop the line referencing "Unicode 3.1.0" in the list of external specifications, e.g.: https://download.java.net/java/early_access/jdk26/docs/api/external-specs.html ------------- Marked as reviewed by iris (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26169#pullrequestreview-2995055834 From naoto at openjdk.org Mon Jul 7 20:24:21 2025 From: naoto at openjdk.org (Naoto Sato) Date: Mon, 7 Jul 2025 20:24:21 GMT Subject: RFR: 8361519: Obsolete Unicode Scalar Value link in Character class [v2] In-Reply-To: References: Message-ID: > Refining the description of "Unicode Scalar Value" in the `Character` class. > The original description referenced the outdated Unicode 3.1 specification, which previously included the U+xxxx notation but no longer does. Updated the reference to point to the Unicode glossary, which defines the term more accurately. Additionally, replaced the obsolete `@spec` link to Unicode 3.1.0 with a reference to the current Unicode Character Database. Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: Some more Unicode related spec clean up ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26169/files - new: https://git.openjdk.org/jdk/pull/26169/files/44cf51fa..69089cbc Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26169&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26169&range=00-01 Stats: 7 lines in 1 file changed: 0 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/26169.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26169/head:pull/26169 PR: https://git.openjdk.org/jdk/pull/26169 From iris at openjdk.org Mon Jul 7 20:37:38 2025 From: iris at openjdk.org (Iris Clark) Date: Mon, 7 Jul 2025 20:37:38 GMT Subject: RFR: 8361519: Obsolete Unicode Scalar Value link in Character class [v2] In-Reply-To: References: Message-ID: <5C6YrFFpsog2GZHoVNYRi_6J9cHeKSxYaaXKUdX7Pnw=.891f3c24-5ae3-409a-ab06-098500034f1d@github.com> On Mon, 7 Jul 2025 20:24:21 GMT, Naoto Sato wrote: >> Refining the description of "Unicode Scalar Value" in the `Character` class. >> The original description referenced the outdated Unicode 3.1 specification, which previously included the U+xxxx notation but no longer does. Updated the reference to point to the Unicode glossary, which defines the term more accurately. Additionally, replaced the obsolete `@spec` link to Unicode 3.1.0 with a reference to the current Unicode Character Database. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Some more Unicode related spec clean up Marked as reviewed by iris (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26169#pullrequestreview-2995201943 From duke at openjdk.org Mon Jul 7 22:03:51 2025 From: duke at openjdk.org (duke) Date: Mon, 7 Jul 2025 22:03:51 GMT Subject: Withdrawn: 8355938: Addressed rare lost unpark bug 8074773 by pre-loading LockSupport.class In-Reply-To: References: Message-ID: On Tue, 29 Apr 2025 17:02:38 GMT, kabutz wrote: > In 2015, Google discovered a rare disastrous classloading bug in first call to LockSupport.park() that occurred in the AppClassLoader using the Java 7 ConcurrentHashMap, which used ReentrantLock for the synchronization. > > Since then, the recommended fix for this bug seems to be this code snippet in any class that directly calls LockSupport.park(): > > > static { > // Prevent rare disastrous classloading in first call to LockSupport.park. > // See: https://bugs.openjdk.java.net/browse/JDK-8074773 > Class ensureLoaded = LockSupport.class; > } > > > Since the bug was logged, we have seen new classes in the JDK that call LockSupport.park(), but that do not have this code snippet. For example: > > sun.nio.ch.Poller > jdk.internal.misc.ThreadFlock > java.util.concurrent.ThreadPerTaskExecutor > > It should probably also be in: > > java.util.concurrent.Exchanger > > Considering how hard this bug is to detect and solve, it would probably be safer to add the code snippet into these newer classes. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/24952 From rriggs at openjdk.org Mon Jul 7 22:20:45 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Mon, 7 Jul 2025 22:20:45 GMT Subject: [jdk25] Integrated: 8354872: Clarify java.lang.Process resource cleanup In-Reply-To: References: Message-ID: <_wb5geiCD8EHh1mi6wCwBSfJ43hqtxY7l2ifEhUFd-U=.4463188e-d82c-43f5-9e10-674e70a140df@github.com> On Mon, 7 Jul 2025 18:29:34 GMT, Roger Riggs wrote: > Identical doc-only backport to jdk 25. Already approved in the CSR. This pull request has now been integrated. Changeset: 3e93b98b Author: Roger Riggs URL: https://git.openjdk.org/jdk/commit/3e93b98baf2a53d2d142e9f0ca9af8d99023ffaf Stats: 185 lines in 2 files changed: 99 ins; 7 del; 79 mod 8354872: Clarify java.lang.Process resource cleanup Reviewed-by: iris Backport-of: afb4a1be9e5dc2a9c0d812f5a36717c9f82241a9 ------------- PR: https://git.openjdk.org/jdk/pull/26168 From almatvee at openjdk.org Mon Jul 7 22:22:48 2025 From: almatvee at openjdk.org (Alexander Matveev) Date: Mon, 7 Jul 2025 22:22:48 GMT Subject: Withdrawn: 8351073: [macos] jpackage produces invalid Java runtime DMG bundles In-Reply-To: <3yeVu8eRZYmZws7PjfdCFJhW-bLtpel7CsO05pzKij4=.00fce839-a35a-456e-9414-68a51dd2bee1@github.com> References: <3yeVu8eRZYmZws7PjfdCFJhW-bLtpel7CsO05pzKij4=.00fce839-a35a-456e-9414-68a51dd2bee1@github.com> Message-ID: <3ymhD6h97muzFy92YlQ_-54IzHKQCESqV2oQtHQqkBg=.452454c4-9c49-4cb4-b403-ca6169467fca@github.com> On Tue, 20 May 2025 00:47:09 GMT, Alexander Matveev wrote: > Fixed jpackage to produce valid Java runtimes based on description below: > > Definitions: > > - JDK bundle defined as bundle which contains "Contents/Home", "Contents/MacOS/libjli.dylib" and "Contents/Info.plist". > - Signed JDK bundle contains all files as JDK bundle + "Contents/_CodeSignature". > - JDK image defined as content of "Contents/Home". > - Signed JDK image does not exist, since it cannot be signed as bundle. > > jpackage output based on input: > > 1. "--runtime-image" points to unsigned JDK bundle and --mac-sign is not provided: > - jpackage will copy all files as is from provided path and run ad-hoc codesign. > > 2. "--runtime-image" points to unsigned JDK bundle and --mac-sign is provided: > - jpackage will copy all files as is from provided path and run codesign with appropriate certificate based on same logic as we do for application image. > > 3. "--runtime-image" points to signed JDK bundle and --mac-sign is not provided: > - jpackage will copy all files as is from provided path including "Contents/_CodeSignature" to preserve signing. > > 4. "--runtime-image" points to signed JDK bundle and --mac-sign is provided: > - jpackage will copy all files as is from provided path including "Contents/_CodeSignature" and will re-sign bundle with appropriate certificate. > > 5. "--runtime-image" points to JDK image and --mac-sign is not provided: > - jpackage will check for libjli.dylib presence in "lib" folder. > - Create JDK bundle by putting all files from provided path to "Contents/Home", libjli.dylib from "lib" to "Contents/MacOS/libjli.dylib" and create default "Contents/Info.plist" similar to what we do for runtime in application image. > - Ad-hoc signing will done. > > 6. "--runtime-image" points to JDK image and --mac-sign is provided: > - 2 first steps from 5 and certificate signing will be done. > > Additional changes: > - The bundle's top directory name will have the ".jdk" suffix. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/25314 From almatvee at openjdk.org Mon Jul 7 22:23:55 2025 From: almatvee at openjdk.org (Alexander Matveev) Date: Mon, 7 Jul 2025 22:23:55 GMT Subject: RFR: 8351073: [macos] jpackage produces invalid Java runtime DMG bundles Message-ID: Re-submission of https://github.com/openjdk/jdk/pull/25314 after merge conflict was resolved. Old PR will be closed. All comments are addressed from old PR. Merge conflict was significant, so it is like new fix. Fixed jpackage to produce valid Java runtimes based on description below: Definitions: - JDK bundle defined as bundle which contains "Contents/Home", "Contents/MacOS/libjli.dylib" and "Contents/Info.plist". - Signed JDK bundle contains all files as JDK bundle + "Contents/_CodeSignature". - JDK image defined as content of "Contents/Home". - Signed JDK image does not exist, since it cannot be signed as bundle. jpackage output based on input: 1. "--runtime-image" points to unsigned JDK bundle and --mac-sign is not provided: - jpackage will copy all files as is from provided path and run ad-hoc codesign. 2. "--runtime-image" points to unsigned JDK bundle and --mac-sign is provided: - jpackage will copy all files as is from provided path and run codesign with appropriate certificate based on same logic as we do for application image. 3. "--runtime-image" points to signed JDK bundle and --mac-sign is not provided: - jpackage will copy all files as is from provided path including "Contents/_CodeSignature" to preserve signing. 4. "--runtime-image" points to signed JDK bundle and --mac-sign is provided: - jpackage will copy all files as is from provided path including "Contents/_CodeSignature" and will re-sign bundle with appropriate certificate. 5. "--runtime-image" points to JDK image and --mac-sign is not provided: - jpackage will check for libjli.dylib presence in "lib" folder. - Create JDK bundle by putting all files from provided path to "Contents/Home", libjli.dylib from "lib" to "Contents/MacOS/libjli.dylib" and create default "Contents/Info.plist" similar to what we do for runtime in application image. - Ad-hoc signing will done. 6. "--runtime-image" points to JDK image and --mac-sign is provided: - 2 first steps from 5 and certificate signing will be done. Additional changes: - The bundle's top directory name will have the ".jdk" suffix. ------------- Commit messages: - 8351073: [macos] jpackage produces invalid Java runtime DMG bundles Changes: https://git.openjdk.org/jdk/pull/26173/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26173&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8351073 Stats: 563 lines in 17 files changed: 529 ins; 5 del; 29 mod Patch: https://git.openjdk.org/jdk/pull/26173.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26173/head:pull/26173 PR: https://git.openjdk.org/jdk/pull/26173 From mik3hall at gmail.com Mon Jul 7 22:52:22 2025 From: mik3hall at gmail.com (Michael Hall) Date: Mon, 7 Jul 2025 17:52:22 -0500 Subject: RFR: 8351073: [macos] jpackage produces invalid Java runtime DMG bundles In-Reply-To: References: Message-ID: What is the .jdk extension preceded by? A normal system jdk is like jdk-23.jdk Maybe something like jpkg-23.jdk to indicate the source of the jre image is jpakcage? Also ensuring it doesn?t conflict with a normally distributed one. > On Jul 7, 2025, at 5:23?PM, Alexander Matveev wrote: > > Additional changes: > - The bundle's top directory name will have the ".jdk" suffix. -------------- next part -------------- An HTML attachment was scrubbed... URL: From almatvee at openjdk.org Mon Jul 7 23:20:08 2025 From: almatvee at openjdk.org (Alexander Matveev) Date: Mon, 7 Jul 2025 23:20:08 GMT Subject: RFR: 8351073: [macos] jpackage produces invalid Java runtime DMG bundles [v2] In-Reply-To: References: Message-ID: > Re-submission of https://github.com/openjdk/jdk/pull/25314 after merge conflict was resolved. Old PR will be closed. > > All comments are addressed from old PR. Merge conflict was significant, so it is like new fix. > > Fixed jpackage to produce valid Java runtimes based on description below: > > Definitions: > > - JDK bundle defined as bundle which contains "Contents/Home", "Contents/MacOS/libjli.dylib" and "Contents/Info.plist". > - Signed JDK bundle contains all files as JDK bundle + "Contents/_CodeSignature". > - JDK image defined as content of "Contents/Home". > - Signed JDK image does not exist, since it cannot be signed as bundle. > > jpackage output based on input: > > 1. "--runtime-image" points to unsigned JDK bundle and --mac-sign is not provided: > - jpackage will copy all files as is from provided path and run ad-hoc codesign. > > 2. "--runtime-image" points to unsigned JDK bundle and --mac-sign is provided: > - jpackage will copy all files as is from provided path and run codesign with appropriate certificate based on same logic as we do for application image. > > 3. "--runtime-image" points to signed JDK bundle and --mac-sign is not provided: > - jpackage will copy all files as is from provided path including "Contents/_CodeSignature" to preserve signing. > > 4. "--runtime-image" points to signed JDK bundle and --mac-sign is provided: > - jpackage will copy all files as is from provided path including "Contents/_CodeSignature" and will re-sign bundle with appropriate certificate. > > 5. "--runtime-image" points to JDK image and --mac-sign is not provided: > - jpackage will check for libjli.dylib presence in "lib" folder. > - Create JDK bundle by putting all files from provided path to "Contents/Home", libjli.dylib from "lib" to "Contents/MacOS/libjli.dylib" and create default "Contents/Info.plist" similar to what we do for runtime in application image. > - Ad-hoc signing will done. > > 6. "--runtime-image" points to JDK image and --mac-sign is provided: > - 2 first steps from 5 and certificate signing will be done. > > Additional changes: > - The bundle's top directory name will have the ".jdk" suffix. Alexander Matveev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: - Merge remote-tracking branch 'upstream/master' into JDK-8351073-2 - 8351073: [macos] jpackage produces invalid Java runtime DMG bundles ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26173/files - new: https://git.openjdk.org/jdk/pull/26173/files/d880fcf7..72a1e3a9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26173&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26173&range=00-01 Stats: 28484 lines in 1050 files changed: 13783 ins; 9199 del; 5502 mod Patch: https://git.openjdk.org/jdk/pull/26173.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26173/head:pull/26173 PR: https://git.openjdk.org/jdk/pull/26173 From almatvee at openjdk.org Mon Jul 7 23:20:08 2025 From: almatvee at openjdk.org (Alexander Matveev) Date: Mon, 7 Jul 2025 23:20:08 GMT Subject: RFR: 8351073: [macos] jpackage produces invalid Java runtime DMG bundles In-Reply-To: References: Message-ID: On Mon, 7 Jul 2025 22:54:32 GMT, Michael Hall wrote: > What is the .jdk extension preceded by? {NAME}-{VERSION}.jdk, where {NAME} is value of `--name` and {VERSION} is value of `--version`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26173#issuecomment-3046781194 From liach at openjdk.org Mon Jul 7 23:29:15 2025 From: liach at openjdk.org (Chen Liang) Date: Mon, 7 Jul 2025 23:29:15 GMT Subject: RFR: 8361526: Synchronize ClassFile API verifier with hotspot Message-ID: The class file API verifier seems to be based off a version of hotspot verifier before Mar 3 2021. We are thus missing a few patches in the hotspot verifier: [JDK-8350029](https://bugs.openjdk.org/browse/JDK-8350029) [JDK-8340110](https://bugs.openjdk.org/browse/JDK-8340110) [JDK-8330606](https://bugs.openjdk.org/browse/JDK-8330606) [JDK-8314295](https://bugs.openjdk.org/browse/JDK-8314295) [JDK-8270398](https://bugs.openjdk.org/browse/JDK-8270398) [JDK-8267118](https://bugs.openjdk.org/browse/JDK-8267118) [JDK-8262368](https://bugs.openjdk.org/browse/JDK-8262368) [JDK-8272096](https://bugs.openjdk.org/browse/JDK-8272096) [JDK-8349923](https://bugs.openjdk.org/browse/JDK-8349923) Synchronization allows the ClassFile API verifier to catch up with upcoming verification changes for Valhalla strict fields as well. Testing: select javac tests and classfile tests, running tier 1-3 ------------- Commit messages: - File was created on windows - Year - More sync - Fix bad sync - Merge branch 'master' of https://github.com/openjdk/jdk into fix/cf-verify-sync - Sync classfile verifier wip Changes: https://git.openjdk.org/jdk/pull/26174/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26174&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8361526 Stats: 276 lines in 9 files changed: 139 ins; 25 del; 112 mod Patch: https://git.openjdk.org/jdk/pull/26174.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26174/head:pull/26174 PR: https://git.openjdk.org/jdk/pull/26174 From missa at openjdk.org Mon Jul 7 23:36:39 2025 From: missa at openjdk.org (Mohamed Issa) Date: Mon, 7 Jul 2025 23:36:39 GMT Subject: RFR: 8360559: Optimize Math.sinh for x86 64 bit platforms In-Reply-To: References: Message-ID: On Mon, 7 Jul 2025 18:03:54 GMT, Joe Darcy wrote: > A large fraction of floating-point numbers are in the [-2^(-28), 2^(-28)] range where there is a performance degradation with the new implementation. > > What is the expected distribution of arguments to sinh? I don't know about an expected distribution of distribution of arguments to sinh. From glancing through research papers though, I get the sense that the [-2^(-28), 2^(-28)] range isn't used all that much. A couple of papers showing this are linked below. 1. [An Analysis of the Hyperbolic Bid Stacking Technique's Use in Modeling Power Prices](https://dl.acm.org/doi/10.1145/3640115.3640182) 2. [Experimental Validation of a 3GPP compliant 5G-based Positioning System](https://dl.acm.org/doi/10.1145/3636534.3697324) I think the [-2^(-28), 2^(-28)] range isn't all that interesting for sinh anyway as it just returns the input itself. So, I doubt any applications are relying all that heavily on it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26152#issuecomment-3046818744 From asemenyuk at openjdk.org Mon Jul 7 23:46:40 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Mon, 7 Jul 2025 23:46:40 GMT Subject: RFR: 8351073: [macos] jpackage produces invalid Java runtime DMG bundles [v2] In-Reply-To: References: Message-ID: On Mon, 7 Jul 2025 23:20:08 GMT, Alexander Matveev wrote: >> Re-submission of https://github.com/openjdk/jdk/pull/25314 after merge conflict was resolved. Old PR will be closed. >> >> All comments are addressed from old PR. Merge conflict was significant, so it is like new fix. >> >> Fixed jpackage to produce valid Java runtimes based on description below: >> >> Definitions: >> >> - JDK bundle defined as bundle which contains "Contents/Home", "Contents/MacOS/libjli.dylib" and "Contents/Info.plist". >> - Signed JDK bundle contains all files as JDK bundle + "Contents/_CodeSignature". >> - JDK image defined as content of "Contents/Home". >> - Signed JDK image does not exist, since it cannot be signed as bundle. >> >> jpackage output based on input: >> >> 1. "--runtime-image" points to unsigned JDK bundle and --mac-sign is not provided: >> - jpackage will copy all files as is from provided path and run ad-hoc codesign. >> >> 2. "--runtime-image" points to unsigned JDK bundle and --mac-sign is provided: >> - jpackage will copy all files as is from provided path and run codesign with appropriate certificate based on same logic as we do for application image. >> >> 3. "--runtime-image" points to signed JDK bundle and --mac-sign is not provided: >> - jpackage will copy all files as is from provided path including "Contents/_CodeSignature" to preserve signing. >> >> 4. "--runtime-image" points to signed JDK bundle and --mac-sign is provided: >> - jpackage will copy all files as is from provided path including "Contents/_CodeSignature" and will re-sign bundle with appropriate certificate. >> >> 5. "--runtime-image" points to JDK image and --mac-sign is not provided: >> - jpackage will check for libjli.dylib presence in "lib" folder. >> - Create JDK bundle by putting all files from provided path to "Contents/Home", libjli.dylib from "lib" to "Contents/MacOS/libjli.dylib" and create default "Contents/Info.plist" similar to what we do for runtime in application image. >> - Ad-hoc signing will done. >> >> 6. "--runtime-image" points to JDK image and --mac-sign is provided: >> - 2 first steps from 5 and certificate signing will be done. >> >> Additional changes: >> - The bundle's top directory name will have the ".jdk" suffix. > > Alexander Matveev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: > > - Merge remote-tracking branch 'upstream/master' into JDK-8351073-2 > - 8351073: [macos] jpackage produces invalid Java runtime DMG bundles src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/model/MacPackage.java line 38: > 36: default AppImageLayout appImageLayout() { > 37: if (isRuntimeInstaller()) { > 38: return RuntimeLayout.DEFAULT; Why is this change? It looks wrong. The layout of the output bundle should have the "Contents" folder. This is how it was before the change. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26173#discussion_r2191203928 From missa at openjdk.org Mon Jul 7 23:47:38 2025 From: missa at openjdk.org (Mohamed Issa) Date: Mon, 7 Jul 2025 23:47:38 GMT Subject: RFR: 8360559: Optimize Math.sinh for x86 64 bit platforms In-Reply-To: References: Message-ID: On Mon, 7 Jul 2025 18:01:26 GMT, Joe Darcy wrote: > Are there plans for a cosh intrinsic as follow-up work? There was a previous effort to intrinsify tanh. Yes, the intention is to have cosh as next math intrinsic. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26152#issuecomment-3046847281 From asemenyuk at openjdk.org Mon Jul 7 23:50:44 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Mon, 7 Jul 2025 23:50:44 GMT Subject: RFR: 8351073: [macos] jpackage produces invalid Java runtime DMG bundles [v2] In-Reply-To: References: Message-ID: On Mon, 7 Jul 2025 23:20:08 GMT, Alexander Matveev wrote: >> Re-submission of https://github.com/openjdk/jdk/pull/25314 after merge conflict was resolved. Old PR will be closed. >> >> All comments are addressed from old PR. Merge conflict was significant, so it is like new fix. >> >> Fixed jpackage to produce valid Java runtimes based on description below: >> >> Definitions: >> >> - JDK bundle defined as bundle which contains "Contents/Home", "Contents/MacOS/libjli.dylib" and "Contents/Info.plist". >> - Signed JDK bundle contains all files as JDK bundle + "Contents/_CodeSignature". >> - JDK image defined as content of "Contents/Home". >> - Signed JDK image does not exist, since it cannot be signed as bundle. >> >> jpackage output based on input: >> >> 1. "--runtime-image" points to unsigned JDK bundle and --mac-sign is not provided: >> - jpackage will copy all files as is from provided path and run ad-hoc codesign. >> >> 2. "--runtime-image" points to unsigned JDK bundle and --mac-sign is provided: >> - jpackage will copy all files as is from provided path and run codesign with appropriate certificate based on same logic as we do for application image. >> >> 3. "--runtime-image" points to signed JDK bundle and --mac-sign is not provided: >> - jpackage will copy all files as is from provided path including "Contents/_CodeSignature" to preserve signing. >> >> 4. "--runtime-image" points to signed JDK bundle and --mac-sign is provided: >> - jpackage will copy all files as is from provided path including "Contents/_CodeSignature" and will re-sign bundle with appropriate certificate. >> >> 5. "--runtime-image" points to JDK image and --mac-sign is not provided: >> - jpackage will check for libjli.dylib presence in "lib" folder. >> - Create JDK bundle by putting all files from provided path to "Contents/Home", libjli.dylib from "lib" to "Contents/MacOS/libjli.dylib" and create default "Contents/Info.plist" similar to what we do for runtime in application image. >> - Ad-hoc signing will done. >> >> 6. "--runtime-image" points to JDK image and --mac-sign is provided: >> - 2 first steps from 5 and certificate signing will be done. >> >> Additional changes: >> - The bundle's top directory name will have the ".jdk" suffix. > > Alexander Matveev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: > > - Merge remote-tracking branch 'upstream/master' into JDK-8351073-2 > - 8351073: [macos] jpackage produces invalid Java runtime DMG bundles src/jdk.jpackage/share/classes/jdk/jpackage/internal/model/Application.java line 101: > 99: */ > 100: Optional runtimeImage(); > 101: What is "the source directory of this application"? Why is the method that returns a path to the source directory called `runtimeImage()`? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26173#discussion_r2191208111 From missa at openjdk.org Mon Jul 7 23:55:39 2025 From: missa at openjdk.org (Mohamed Issa) Date: Mon, 7 Jul 2025 23:55:39 GMT Subject: RFR: 8360559: Optimize Math.sinh for x86 64 bit platforms In-Reply-To: References: Message-ID: On Mon, 7 Jul 2025 04:48:18 GMT, Florian Weimer wrote: > Isn't this effectively a libm benchmark (where the `sinh` implementation resides)? Please include the libm version for reference here. Thanks. I'm not sure which libm version you're referring to. The only current sinh benchmark I'm aware of is in MathBench.java, and the benchmarks in SinhPerf.java didn't exist until now. Could you clarify? ------------- PR Comment: https://git.openjdk.org/jdk/pull/26152#issuecomment-3046866329 From asemenyuk at openjdk.org Mon Jul 7 23:58:40 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Mon, 7 Jul 2025 23:58:40 GMT Subject: RFR: 8351073: [macos] jpackage produces invalid Java runtime DMG bundles [v2] In-Reply-To: References: Message-ID: On Mon, 7 Jul 2025 23:20:08 GMT, Alexander Matveev wrote: >> Re-submission of https://github.com/openjdk/jdk/pull/25314 after merge conflict was resolved. Old PR will be closed. >> >> All comments are addressed from old PR. Merge conflict was significant, so it is like new fix. >> >> Fixed jpackage to produce valid Java runtimes based on description below: >> >> Definitions: >> >> - JDK bundle defined as bundle which contains "Contents/Home", "Contents/MacOS/libjli.dylib" and "Contents/Info.plist". >> - Signed JDK bundle contains all files as JDK bundle + "Contents/_CodeSignature". >> - JDK image defined as content of "Contents/Home". >> - Signed JDK image does not exist, since it cannot be signed as bundle. >> >> jpackage output based on input: >> >> 1. "--runtime-image" points to unsigned JDK bundle and --mac-sign is not provided: >> - jpackage will copy all files as is from provided path and run ad-hoc codesign. >> >> 2. "--runtime-image" points to unsigned JDK bundle and --mac-sign is provided: >> - jpackage will copy all files as is from provided path and run codesign with appropriate certificate based on same logic as we do for application image. >> >> 3. "--runtime-image" points to signed JDK bundle and --mac-sign is not provided: >> - jpackage will copy all files as is from provided path including "Contents/_CodeSignature" to preserve signing. >> >> 4. "--runtime-image" points to signed JDK bundle and --mac-sign is provided: >> - jpackage will copy all files as is from provided path including "Contents/_CodeSignature" and will re-sign bundle with appropriate certificate. >> >> 5. "--runtime-image" points to JDK image and --mac-sign is not provided: >> - jpackage will check for libjli.dylib presence in "lib" folder. >> - Create JDK bundle by putting all files from provided path to "Contents/Home", libjli.dylib from "lib" to "Contents/MacOS/libjli.dylib" and create default "Contents/Info.plist" similar to what we do for runtime in application image. >> - Ad-hoc signing will done. >> >> 6. "--runtime-image" points to JDK image and --mac-sign is provided: >> - 2 first steps from 5 and certificate signing will be done. >> >> Additional changes: >> - The bundle's top directory name will have the ".jdk" suffix. > > Alexander Matveev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: > > - Merge remote-tracking branch 'upstream/master' into JDK-8351073-2 > - 8351073: [macos] jpackage produces invalid Java runtime DMG bundles test/jdk/tools/jpackage/helpers/jdk/jpackage/test/JPackageCommand.java line 974: > 972: // on macOS. On macOS runtime image will be signed ad-hoc or with > 973: // real certificate when creating runtime installers. > 974: return !(cmd.isRuntime() && TKit.isOSX()); I guess, the directory referenced from the `--runtime-image` option will not be signed if it is a JDK image, not a JDK bundle. So this switch turns off verification in cases when the verification should be done. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26173#discussion_r2191214905 From asemenyuk at openjdk.org Tue Jul 8 00:07:40 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Tue, 8 Jul 2025 00:07:40 GMT Subject: RFR: 8351073: [macos] jpackage produces invalid Java runtime DMG bundles [v2] In-Reply-To: References: Message-ID: On Mon, 7 Jul 2025 23:20:08 GMT, Alexander Matveev wrote: >> Re-submission of https://github.com/openjdk/jdk/pull/25314 after merge conflict was resolved. Old PR will be closed. >> >> All comments are addressed from old PR. Merge conflict was significant, so it is like new fix. >> >> Fixed jpackage to produce valid Java runtimes based on description below: >> >> Definitions: >> >> - JDK bundle defined as bundle which contains "Contents/Home", "Contents/MacOS/libjli.dylib" and "Contents/Info.plist". >> - Signed JDK bundle contains all files as JDK bundle + "Contents/_CodeSignature". >> - JDK image defined as content of "Contents/Home". >> - Signed JDK image does not exist, since it cannot be signed as bundle. >> >> jpackage output based on input: >> >> 1. "--runtime-image" points to unsigned JDK bundle and --mac-sign is not provided: >> - jpackage will copy all files as is from provided path and run ad-hoc codesign. >> >> 2. "--runtime-image" points to unsigned JDK bundle and --mac-sign is provided: >> - jpackage will copy all files as is from provided path and run codesign with appropriate certificate based on same logic as we do for application image. >> >> 3. "--runtime-image" points to signed JDK bundle and --mac-sign is not provided: >> - jpackage will copy all files as is from provided path including "Contents/_CodeSignature" to preserve signing. >> >> 4. "--runtime-image" points to signed JDK bundle and --mac-sign is provided: >> - jpackage will copy all files as is from provided path including "Contents/_CodeSignature" and will re-sign bundle with appropriate certificate. >> >> 5. "--runtime-image" points to JDK image and --mac-sign is not provided: >> - jpackage will check for libjli.dylib presence in "lib" folder. >> - Create JDK bundle by putting all files from provided path to "Contents/Home", libjli.dylib from "lib" to "Contents/MacOS/libjli.dylib" and create default "Contents/Info.plist" similar to what we do for runtime in application image. >> - Ad-hoc signing will done. >> >> 6. "--runtime-image" points to JDK image and --mac-sign is provided: >> - 2 first steps from 5 and certificate signing will be done. >> >> Additional changes: >> - The bundle's top directory name will have the ".jdk" suffix. > > Alexander Matveev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: > > - Merge remote-tracking branch 'upstream/master' into JDK-8351073-2 > - 8351073: [macos] jpackage produces invalid Java runtime DMG bundles src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacBaseInstallerBundler.java line 80: > 78: if (!isRuntimeImageJDKBundle(runtimeImage) > 79: && !isRuntimeImageJDKImage(runtimeImage)) { > 80: throw new ConfigException( 1. Can be simplified: throw new ConfigException( I18N.format("message.runtime-image-invalid", runtimeImage), I18N.getString("message.runtime-image-invalid.advice")); 2. This validation should be a part of `MacPackageBuilder.create()`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26173#discussion_r2191220588 From asemenyuk at openjdk.org Tue Jul 8 00:11:40 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Tue, 8 Jul 2025 00:11:40 GMT Subject: RFR: 8351073: [macos] jpackage produces invalid Java runtime DMG bundles [v2] In-Reply-To: References: Message-ID: On Mon, 7 Jul 2025 23:20:08 GMT, Alexander Matveev wrote: >> Re-submission of https://github.com/openjdk/jdk/pull/25314 after merge conflict was resolved. Old PR will be closed. >> >> All comments are addressed from old PR. Merge conflict was significant, so it is like new fix. >> >> Fixed jpackage to produce valid Java runtimes based on description below: >> >> Definitions: >> >> - JDK bundle defined as bundle which contains "Contents/Home", "Contents/MacOS/libjli.dylib" and "Contents/Info.plist". >> - Signed JDK bundle contains all files as JDK bundle + "Contents/_CodeSignature". >> - JDK image defined as content of "Contents/Home". >> - Signed JDK image does not exist, since it cannot be signed as bundle. >> >> jpackage output based on input: >> >> 1. "--runtime-image" points to unsigned JDK bundle and --mac-sign is not provided: >> - jpackage will copy all files as is from provided path and run ad-hoc codesign. >> >> 2. "--runtime-image" points to unsigned JDK bundle and --mac-sign is provided: >> - jpackage will copy all files as is from provided path and run codesign with appropriate certificate based on same logic as we do for application image. >> >> 3. "--runtime-image" points to signed JDK bundle and --mac-sign is not provided: >> - jpackage will copy all files as is from provided path including "Contents/_CodeSignature" to preserve signing. >> >> 4. "--runtime-image" points to signed JDK bundle and --mac-sign is provided: >> - jpackage will copy all files as is from provided path including "Contents/_CodeSignature" and will re-sign bundle with appropriate certificate. >> >> 5. "--runtime-image" points to JDK image and --mac-sign is not provided: >> - jpackage will check for libjli.dylib presence in "lib" folder. >> - Create JDK bundle by putting all files from provided path to "Contents/Home", libjli.dylib from "lib" to "Contents/MacOS/libjli.dylib" and create default "Contents/Info.plist" similar to what we do for runtime in application image. >> - Ad-hoc signing will done. >> >> 6. "--runtime-image" points to JDK image and --mac-sign is provided: >> - 2 first steps from 5 and certificate signing will be done. >> >> Additional changes: >> - The bundle's top directory name will have the ".jdk" suffix. > > Alexander Matveev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: > > - Merge remote-tracking branch 'upstream/master' into JDK-8351073-2 > - 8351073: [macos] jpackage produces invalid Java runtime DMG bundles src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacBaseInstallerBundler.java line 120: > 118: return IOUtils.exists(jli); > 119: } catch (IOException | NoSuchElementException ex) { > 120: Log.verbose(ex); So if jpackage doesn't know if the given path is a JDK image or a JDK bundle, it will proceed with packaging anyway. This doesn't look right. In general, most, if not all, of the existing constructions like: } catch (Exception ex) { Log.verbose(ex); ... } are wrong. Let's not add new ones. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26173#discussion_r2191226153 From asemenyuk at openjdk.org Tue Jul 8 00:17:39 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Tue, 8 Jul 2025 00:17:39 GMT Subject: RFR: 8351073: [macos] jpackage produces invalid Java runtime DMG bundles [v2] In-Reply-To: References: Message-ID: On Mon, 7 Jul 2025 23:20:08 GMT, Alexander Matveev wrote: >> Re-submission of https://github.com/openjdk/jdk/pull/25314 after merge conflict was resolved. Old PR will be closed. >> >> All comments are addressed from old PR. Merge conflict was significant, so it is like new fix. >> >> Fixed jpackage to produce valid Java runtimes based on description below: >> >> Definitions: >> >> - JDK bundle defined as bundle which contains "Contents/Home", "Contents/MacOS/libjli.dylib" and "Contents/Info.plist". >> - Signed JDK bundle contains all files as JDK bundle + "Contents/_CodeSignature". >> - JDK image defined as content of "Contents/Home". >> - Signed JDK image does not exist, since it cannot be signed as bundle. >> >> jpackage output based on input: >> >> 1. "--runtime-image" points to unsigned JDK bundle and --mac-sign is not provided: >> - jpackage will copy all files as is from provided path and run ad-hoc codesign. >> >> 2. "--runtime-image" points to unsigned JDK bundle and --mac-sign is provided: >> - jpackage will copy all files as is from provided path and run codesign with appropriate certificate based on same logic as we do for application image. >> >> 3. "--runtime-image" points to signed JDK bundle and --mac-sign is not provided: >> - jpackage will copy all files as is from provided path including "Contents/_CodeSignature" to preserve signing. >> >> 4. "--runtime-image" points to signed JDK bundle and --mac-sign is provided: >> - jpackage will copy all files as is from provided path including "Contents/_CodeSignature" and will re-sign bundle with appropriate certificate. >> >> 5. "--runtime-image" points to JDK image and --mac-sign is not provided: >> - jpackage will check for libjli.dylib presence in "lib" folder. >> - Create JDK bundle by putting all files from provided path to "Contents/Home", libjli.dylib from "lib" to "Contents/MacOS/libjli.dylib" and create default "Contents/Info.plist" similar to what we do for runtime in application image. >> - Ad-hoc signing will done. >> >> 6. "--runtime-image" points to JDK image and --mac-sign is provided: >> - 2 first steps from 5 and certificate signing will be done. >> >> Additional changes: >> - The bundle's top directory name will have the ".jdk" suffix. > > Alexander Matveev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: > > - Merge remote-tracking branch 'upstream/master' into JDK-8351073-2 > - 8351073: [macos] jpackage produces invalid Java runtime DMG bundles src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacApplicationBuilder.java line 184: > 182: } > 183: > 184: public String validatedBundleIdentifier() throws ConfigException { This method is private on purpose. It should not be used outside of the MacApplicationBuilder class. If you need to get the valid bundle identifier, create MacApplication instance and call `MacApplication.bundleIdentifier()` on it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26173#discussion_r2191232153 From asemenyuk at openjdk.org Tue Jul 8 00:32:40 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Tue, 8 Jul 2025 00:32:40 GMT Subject: RFR: 8351073: [macos] jpackage produces invalid Java runtime DMG bundles [v2] In-Reply-To: References: Message-ID: On Mon, 7 Jul 2025 23:20:08 GMT, Alexander Matveev wrote: >> Re-submission of https://github.com/openjdk/jdk/pull/25314 after merge conflict was resolved. Old PR will be closed. >> >> All comments are addressed from old PR. Merge conflict was significant, so it is like new fix. >> >> Fixed jpackage to produce valid Java runtimes based on description below: >> >> Definitions: >> >> - JDK bundle defined as bundle which contains "Contents/Home", "Contents/MacOS/libjli.dylib" and "Contents/Info.plist". >> - Signed JDK bundle contains all files as JDK bundle + "Contents/_CodeSignature". >> - JDK image defined as content of "Contents/Home". >> - Signed JDK image does not exist, since it cannot be signed as bundle. >> >> jpackage output based on input: >> >> 1. "--runtime-image" points to unsigned JDK bundle and --mac-sign is not provided: >> - jpackage will copy all files as is from provided path and run ad-hoc codesign. >> >> 2. "--runtime-image" points to unsigned JDK bundle and --mac-sign is provided: >> - jpackage will copy all files as is from provided path and run codesign with appropriate certificate based on same logic as we do for application image. >> >> 3. "--runtime-image" points to signed JDK bundle and --mac-sign is not provided: >> - jpackage will copy all files as is from provided path including "Contents/_CodeSignature" to preserve signing. >> >> 4. "--runtime-image" points to signed JDK bundle and --mac-sign is provided: >> - jpackage will copy all files as is from provided path including "Contents/_CodeSignature" and will re-sign bundle with appropriate certificate. >> >> 5. "--runtime-image" points to JDK image and --mac-sign is not provided: >> - jpackage will check for libjli.dylib presence in "lib" folder. >> - Create JDK bundle by putting all files from provided path to "Contents/Home", libjli.dylib from "lib" to "Contents/MacOS/libjli.dylib" and create default "Contents/Info.plist" similar to what we do for runtime in application image. >> - Ad-hoc signing will done. >> >> 6. "--runtime-image" points to JDK image and --mac-sign is provided: >> - 2 first steps from 5 and certificate signing will be done. >> >> Additional changes: >> - The bundle's top directory name will have the ".jdk" suffix. > > Alexander Matveev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: > > - Merge remote-tracking branch 'upstream/master' into JDK-8351073-2 > - 8351073: [macos] jpackage produces invalid Java runtime DMG bundles Changes requested by asemenyuk (Reviewer). src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/model/MacPackage.java line 76: > 74: return !Files.exists(p); > 75: } > 76: } Default interface methods should operate on values returned by other interface methods. These new functions involve filesystem operations. They probably don't belong to the interface. test/jdk/tools/jpackage/macosx/SigningRuntimeImagePackageTest.java line 65: > 63: * always allowed access to this keychain for user which runs test. > 64: * note: > 65: * "jpackage.openjdk.java.net" can be over-ridden by systerm property systerm -> system ------------- PR Review: https://git.openjdk.org/jdk/pull/26173#pullrequestreview-2995628866 PR Review Comment: https://git.openjdk.org/jdk/pull/26173#discussion_r2191242414 PR Review Comment: https://git.openjdk.org/jdk/pull/26173#discussion_r2191243843 From asemenyuk at openjdk.org Tue Jul 8 00:44:41 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Tue, 8 Jul 2025 00:44:41 GMT Subject: RFR: 8351073: [macos] jpackage produces invalid Java runtime DMG bundles [v2] In-Reply-To: References: Message-ID: <19xKrPQKXJ273i03KCYPSxiYAUQGNVTm49cP2VkMkHk=.7080a74d-34da-4a2d-b844-6cce78782989@github.com> On Mon, 7 Jul 2025 23:20:08 GMT, Alexander Matveev wrote: >> Re-submission of https://github.com/openjdk/jdk/pull/25314 after merge conflict was resolved. Old PR will be closed. >> >> All comments are addressed from old PR. Merge conflict was significant, so it is like new fix. >> >> Fixed jpackage to produce valid Java runtimes based on description below: >> >> Definitions: >> >> - JDK bundle defined as bundle which contains "Contents/Home", "Contents/MacOS/libjli.dylib" and "Contents/Info.plist". >> - Signed JDK bundle contains all files as JDK bundle + "Contents/_CodeSignature". >> - JDK image defined as content of "Contents/Home". >> - Signed JDK image does not exist, since it cannot be signed as bundle. >> >> jpackage output based on input: >> >> 1. "--runtime-image" points to unsigned JDK bundle and --mac-sign is not provided: >> - jpackage will copy all files as is from provided path and run ad-hoc codesign. >> >> 2. "--runtime-image" points to unsigned JDK bundle and --mac-sign is provided: >> - jpackage will copy all files as is from provided path and run codesign with appropriate certificate based on same logic as we do for application image. >> >> 3. "--runtime-image" points to signed JDK bundle and --mac-sign is not provided: >> - jpackage will copy all files as is from provided path including "Contents/_CodeSignature" to preserve signing. >> >> 4. "--runtime-image" points to signed JDK bundle and --mac-sign is provided: >> - jpackage will copy all files as is from provided path including "Contents/_CodeSignature" and will re-sign bundle with appropriate certificate. >> >> 5. "--runtime-image" points to JDK image and --mac-sign is not provided: >> - jpackage will check for libjli.dylib presence in "lib" folder. >> - Create JDK bundle by putting all files from provided path to "Contents/Home", libjli.dylib from "lib" to "Contents/MacOS/libjli.dylib" and create default "Contents/Info.plist" similar to what we do for runtime in application image. >> - Ad-hoc signing will done. >> >> 6. "--runtime-image" points to JDK image and --mac-sign is provided: >> - 2 first steps from 5 and certificate signing will be done. >> >> Additional changes: >> - The bundle's top directory name will have the ".jdk" suffix. > > Alexander Matveev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: > > - Merge remote-tracking branch 'upstream/master' into JDK-8351073-2 > - 8351073: [macos] jpackage produces invalid Java runtime DMG bundles test/jdk/tools/jpackage/macosx/SigningRuntimeImagePackageTest.java line 134: > 132: } > 133: > 134: private static Path getRuntimeImagePath(boolean useJDKBundle, The name of the function is misleading. It doesn't get the runtime image. It creates it. test/jdk/tools/jpackage/macosx/SigningRuntimeImagePackageTest.java line 188: > 186: > 187: MacHelper.withExplodedDmg(dummyCMD, dmgImage -> { > 188: if (dmgImage.endsWith(dummyCMD.name() + ".jdk")) { Can this test ever return `false`? test/jdk/tools/jpackage/macosx/SigningRuntimeImagePackageTest.java line 189: > 187: MacHelper.withExplodedDmg(dummyCMD, dmgImage -> { > 188: if (dmgImage.endsWith(dummyCMD.name() + ".jdk")) { > 189: Executor.of("cp", "-R") Why noit use `FileUtils.copyRecursive()`? test/jdk/tools/jpackage/macosx/SigningRuntimeImagePackageTest.java line 222: > 220: SigningBase.CertIndex JDKBundleCert, > 221: SigningBase.CertIndex signCert) throws Exception { > 222: final int JDKBundleCertIndex = JDKBundleCert.value(); `JDKBundleCertIndex` -> `jdkBundleCertIndex`? test/jdk/tools/jpackage/macosx/SigningRuntimeImagePackageTest.java line 231: > 229: > 230: new PackageTest() > 231: .forTypes(PackageType.MAC) `.forTypes(PackageType.MAC)` is redundant. The test will only be executed on macOS ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26173#discussion_r2191253506 PR Review Comment: https://git.openjdk.org/jdk/pull/26173#discussion_r2191248838 PR Review Comment: https://git.openjdk.org/jdk/pull/26173#discussion_r2191250266 PR Review Comment: https://git.openjdk.org/jdk/pull/26173#discussion_r2191251656 PR Review Comment: https://git.openjdk.org/jdk/pull/26173#discussion_r2191252636 From asemenyuk at openjdk.org Tue Jul 8 00:51:40 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Tue, 8 Jul 2025 00:51:40 GMT Subject: RFR: 8351073: [macos] jpackage produces invalid Java runtime DMG bundles [v2] In-Reply-To: References: Message-ID: On Mon, 7 Jul 2025 23:20:08 GMT, Alexander Matveev wrote: >> Re-submission of https://github.com/openjdk/jdk/pull/25314 after merge conflict was resolved. Old PR will be closed. >> >> All comments are addressed from old PR. Merge conflict was significant, so it is like new fix. >> >> Fixed jpackage to produce valid Java runtimes based on description below: >> >> Definitions: >> >> - JDK bundle defined as bundle which contains "Contents/Home", "Contents/MacOS/libjli.dylib" and "Contents/Info.plist". >> - Signed JDK bundle contains all files as JDK bundle + "Contents/_CodeSignature". >> - JDK image defined as content of "Contents/Home". >> - Signed JDK image does not exist, since it cannot be signed as bundle. >> >> jpackage output based on input: >> >> 1. "--runtime-image" points to unsigned JDK bundle and --mac-sign is not provided: >> - jpackage will copy all files as is from provided path and run ad-hoc codesign. >> >> 2. "--runtime-image" points to unsigned JDK bundle and --mac-sign is provided: >> - jpackage will copy all files as is from provided path and run codesign with appropriate certificate based on same logic as we do for application image. >> >> 3. "--runtime-image" points to signed JDK bundle and --mac-sign is not provided: >> - jpackage will copy all files as is from provided path including "Contents/_CodeSignature" to preserve signing. >> >> 4. "--runtime-image" points to signed JDK bundle and --mac-sign is provided: >> - jpackage will copy all files as is from provided path including "Contents/_CodeSignature" and will re-sign bundle with appropriate certificate. >> >> 5. "--runtime-image" points to JDK image and --mac-sign is not provided: >> - jpackage will check for libjli.dylib presence in "lib" folder. >> - Create JDK bundle by putting all files from provided path to "Contents/Home", libjli.dylib from "lib" to "Contents/MacOS/libjli.dylib" and create default "Contents/Info.plist" similar to what we do for runtime in application image. >> - Ad-hoc signing will done. >> >> 6. "--runtime-image" points to JDK image and --mac-sign is provided: >> - 2 first steps from 5 and certificate signing will be done. >> >> Additional changes: >> - The bundle's top directory name will have the ".jdk" suffix. > > Alexander Matveev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: > > - Merge remote-tracking branch 'upstream/master' into JDK-8351073-2 > - 8351073: [macos] jpackage produces invalid Java runtime DMG bundles test/jdk/tools/jpackage/macosx/SigningRuntimeImagePackageTest.java line 180: > 178: ex.execute(); > 179: > 180: JPackageCommand dummyCMD = new JPackageCommand(); Why do you need a `dummyCMD`? You can configure a normal JPackageCommand command: var cmd = new JPackageCommand().useToolProvider(true).dumpOutput(true).addArguments(...); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26173#discussion_r2191258695 From asemenyuk at openjdk.org Tue Jul 8 00:55:43 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Tue, 8 Jul 2025 00:55:43 GMT Subject: RFR: 8351073: [macos] jpackage produces invalid Java runtime DMG bundles [v2] In-Reply-To: References: Message-ID: On Mon, 7 Jul 2025 23:20:08 GMT, Alexander Matveev wrote: >> Re-submission of https://github.com/openjdk/jdk/pull/25314 after merge conflict was resolved. Old PR will be closed. >> >> All comments are addressed from old PR. Merge conflict was significant, so it is like new fix. >> >> Fixed jpackage to produce valid Java runtimes based on description below: >> >> Definitions: >> >> - JDK bundle defined as bundle which contains "Contents/Home", "Contents/MacOS/libjli.dylib" and "Contents/Info.plist". >> - Signed JDK bundle contains all files as JDK bundle + "Contents/_CodeSignature". >> - JDK image defined as content of "Contents/Home". >> - Signed JDK image does not exist, since it cannot be signed as bundle. >> >> jpackage output based on input: >> >> 1. "--runtime-image" points to unsigned JDK bundle and --mac-sign is not provided: >> - jpackage will copy all files as is from provided path and run ad-hoc codesign. >> >> 2. "--runtime-image" points to unsigned JDK bundle and --mac-sign is provided: >> - jpackage will copy all files as is from provided path and run codesign with appropriate certificate based on same logic as we do for application image. >> >> 3. "--runtime-image" points to signed JDK bundle and --mac-sign is not provided: >> - jpackage will copy all files as is from provided path including "Contents/_CodeSignature" to preserve signing. >> >> 4. "--runtime-image" points to signed JDK bundle and --mac-sign is provided: >> - jpackage will copy all files as is from provided path including "Contents/_CodeSignature" and will re-sign bundle with appropriate certificate. >> >> 5. "--runtime-image" points to JDK image and --mac-sign is not provided: >> - jpackage will check for libjli.dylib presence in "lib" folder. >> - Create JDK bundle by putting all files from provided path to "Contents/Home", libjli.dylib from "lib" to "Contents/MacOS/libjli.dylib" and create default "Contents/Info.plist" similar to what we do for runtime in application image. >> - Ad-hoc signing will done. >> >> 6. "--runtime-image" points to JDK image and --mac-sign is provided: >> - 2 first steps from 5 and certificate signing will be done. >> >> Additional changes: >> - The bundle's top directory name will have the ".jdk" suffix. > > Alexander Matveev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: > > - Merge remote-tracking branch 'upstream/master' into JDK-8351073-2 > - 8351073: [macos] jpackage produces invalid Java runtime DMG bundles test/jdk/tools/jpackage/share/ErrorTest.java line 637: > 635: .addArgs("--runtime-image", Token.INVALID_MAC_JDK_BUNDLE.token()) > 636: .error("message.runtime-image-invalid", JPackageCommand.cannedArgument(cmd -> { > 637: return Path.of(cmd.getArgumentValue("--runtime-image")).toAbsolutePath(); Why do we need an absolute path in error messages? Wouldn't it make more sense to have the value of `--runtime-image` parameter as is in error messages? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26173#discussion_r2191261053 From asemenyuk at openjdk.org Tue Jul 8 01:03:52 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Tue, 8 Jul 2025 01:03:52 GMT Subject: RFR: 8351073: [macos] jpackage produces invalid Java runtime DMG bundles [v2] In-Reply-To: References: Message-ID: On Mon, 7 Jul 2025 23:20:08 GMT, Alexander Matveev wrote: >> Re-submission of https://github.com/openjdk/jdk/pull/25314 after merge conflict was resolved. Old PR will be closed. >> >> All comments are addressed from old PR. Merge conflict was significant, so it is like new fix. >> >> Fixed jpackage to produce valid Java runtimes based on description below: >> >> Definitions: >> >> - JDK bundle defined as bundle which contains "Contents/Home", "Contents/MacOS/libjli.dylib" and "Contents/Info.plist". >> - Signed JDK bundle contains all files as JDK bundle + "Contents/_CodeSignature". >> - JDK image defined as content of "Contents/Home". >> - Signed JDK image does not exist, since it cannot be signed as bundle. >> >> jpackage output based on input: >> >> 1. "--runtime-image" points to unsigned JDK bundle and --mac-sign is not provided: >> - jpackage will copy all files as is from provided path and run ad-hoc codesign. >> >> 2. "--runtime-image" points to unsigned JDK bundle and --mac-sign is provided: >> - jpackage will copy all files as is from provided path and run codesign with appropriate certificate based on same logic as we do for application image. >> >> 3. "--runtime-image" points to signed JDK bundle and --mac-sign is not provided: >> - jpackage will copy all files as is from provided path including "Contents/_CodeSignature" to preserve signing. >> >> 4. "--runtime-image" points to signed JDK bundle and --mac-sign is provided: >> - jpackage will copy all files as is from provided path including "Contents/_CodeSignature" and will re-sign bundle with appropriate certificate. >> >> 5. "--runtime-image" points to JDK image and --mac-sign is not provided: >> - jpackage will check for libjli.dylib presence in "lib" folder. >> - Create JDK bundle by putting all files from provided path to "Contents/Home", libjli.dylib from "lib" to "Contents/MacOS/libjli.dylib" and create default "Contents/Info.plist" similar to what we do for runtime in application image. >> - Ad-hoc signing will done. >> >> 6. "--runtime-image" points to JDK image and --mac-sign is provided: >> - 2 first steps from 5 and certificate signing will be done. >> >> Additional changes: >> - The bundle's top directory name will have the ".jdk" suffix. > > Alexander Matveev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: > > - Merge remote-tracking branch 'upstream/master' into JDK-8351073-2 > - 8351073: [macos] jpackage produces invalid Java runtime DMG bundles test/jdk/tools/jpackage/share/ErrorTest.java line 98: > 96: // Missing "Contents/MacOS/libjli.dylib" > 97: try { > 98: final Path runtimePath = TKit.createTempDirectory("invalidJDKBundle"); The name "invalid-jdk-bundle" fits better in dash-case naming scheme for path names in jpackage tests. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26173#discussion_r2191267584 From asemenyuk at openjdk.org Tue Jul 8 01:08:40 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Tue, 8 Jul 2025 01:08:40 GMT Subject: RFR: 8351073: [macos] jpackage produces invalid Java runtime DMG bundles [v2] In-Reply-To: References: Message-ID: <3UY0AddcQaqsoR6CqIV-2umUboVxbaCirghaeS5PQxo=.fee06abf-df37-493e-9639-6548855c1dc2@github.com> On Mon, 7 Jul 2025 23:20:08 GMT, Alexander Matveev wrote: >> Re-submission of https://github.com/openjdk/jdk/pull/25314 after merge conflict was resolved. Old PR will be closed. >> >> All comments are addressed from old PR. Merge conflict was significant, so it is like new fix. >> >> Fixed jpackage to produce valid Java runtimes based on description below: >> >> Definitions: >> >> - JDK bundle defined as bundle which contains "Contents/Home", "Contents/MacOS/libjli.dylib" and "Contents/Info.plist". >> - Signed JDK bundle contains all files as JDK bundle + "Contents/_CodeSignature". >> - JDK image defined as content of "Contents/Home". >> - Signed JDK image does not exist, since it cannot be signed as bundle. >> >> jpackage output based on input: >> >> 1. "--runtime-image" points to unsigned JDK bundle and --mac-sign is not provided: >> - jpackage will copy all files as is from provided path and run ad-hoc codesign. >> >> 2. "--runtime-image" points to unsigned JDK bundle and --mac-sign is provided: >> - jpackage will copy all files as is from provided path and run codesign with appropriate certificate based on same logic as we do for application image. >> >> 3. "--runtime-image" points to signed JDK bundle and --mac-sign is not provided: >> - jpackage will copy all files as is from provided path including "Contents/_CodeSignature" to preserve signing. >> >> 4. "--runtime-image" points to signed JDK bundle and --mac-sign is provided: >> - jpackage will copy all files as is from provided path including "Contents/_CodeSignature" and will re-sign bundle with appropriate certificate. >> >> 5. "--runtime-image" points to JDK image and --mac-sign is not provided: >> - jpackage will check for libjli.dylib presence in "lib" folder. >> - Create JDK bundle by putting all files from provided path to "Contents/Home", libjli.dylib from "lib" to "Contents/MacOS/libjli.dylib" and create default "Contents/Info.plist" similar to what we do for runtime in application image. >> - Ad-hoc signing will done. >> >> 6. "--runtime-image" points to JDK image and --mac-sign is provided: >> - 2 first steps from 5 and certificate signing will be done. >> >> Additional changes: >> - The bundle's top directory name will have the ".jdk" suffix. > > Alexander Matveev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: > > - Merge remote-tracking branch 'upstream/master' into JDK-8351073-2 > - 8351073: [macos] jpackage produces invalid Java runtime DMG bundles src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/resources/RuntimeBundle-Info.plist.template line 1: > 1: What is the origin of this file? src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/resources/RuntimeBundle-Info.plist.template line 6: > 4: > 5: CFBundleDevelopmentRegion > 6: English I'm surprised there is no standard way to override this default value. Is it not important? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26173#discussion_r2191272155 PR Review Comment: https://git.openjdk.org/jdk/pull/26173#discussion_r2191271018 From asemenyuk at openjdk.org Tue Jul 8 01:15:47 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Tue, 8 Jul 2025 01:15:47 GMT Subject: RFR: 8351073: [macos] jpackage produces invalid Java runtime DMG bundles [v2] In-Reply-To: References: Message-ID: <8puqNFN9LtsrDe6xF4EmRPBrT-CR3IRcOS62YFVwZD8=.7613bce6-badf-4664-baf7-67c94037d7b7@github.com> On Mon, 7 Jul 2025 23:20:08 GMT, Alexander Matveev wrote: >> Re-submission of https://github.com/openjdk/jdk/pull/25314 after merge conflict was resolved. Old PR will be closed. >> >> All comments are addressed from old PR. Merge conflict was significant, so it is like new fix. >> >> Fixed jpackage to produce valid Java runtimes based on description below: >> >> Definitions: >> >> - JDK bundle defined as bundle which contains "Contents/Home", "Contents/MacOS/libjli.dylib" and "Contents/Info.plist". >> - Signed JDK bundle contains all files as JDK bundle + "Contents/_CodeSignature". >> - JDK image defined as content of "Contents/Home". >> - Signed JDK image does not exist, since it cannot be signed as bundle. >> >> jpackage output based on input: >> >> 1. "--runtime-image" points to unsigned JDK bundle and --mac-sign is not provided: >> - jpackage will copy all files as is from provided path and run ad-hoc codesign. >> >> 2. "--runtime-image" points to unsigned JDK bundle and --mac-sign is provided: >> - jpackage will copy all files as is from provided path and run codesign with appropriate certificate based on same logic as we do for application image. >> >> 3. "--runtime-image" points to signed JDK bundle and --mac-sign is not provided: >> - jpackage will copy all files as is from provided path including "Contents/_CodeSignature" to preserve signing. >> >> 4. "--runtime-image" points to signed JDK bundle and --mac-sign is provided: >> - jpackage will copy all files as is from provided path including "Contents/_CodeSignature" and will re-sign bundle with appropriate certificate. >> >> 5. "--runtime-image" points to JDK image and --mac-sign is not provided: >> - jpackage will check for libjli.dylib presence in "lib" folder. >> - Create JDK bundle by putting all files from provided path to "Contents/Home", libjli.dylib from "lib" to "Contents/MacOS/libjli.dylib" and create default "Contents/Info.plist" similar to what we do for runtime in application image. >> - Ad-hoc signing will done. >> >> 6. "--runtime-image" points to JDK image and --mac-sign is provided: >> - 2 first steps from 5 and certificate signing will be done. >> >> Additional changes: >> - The bundle's top directory name will have the ".jdk" suffix. > > Alexander Matveev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: > > - Merge remote-tracking branch 'upstream/master' into JDK-8351073-2 > - 8351073: [macos] jpackage produces invalid Java runtime DMG bundles src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacPackagingPipeline.java line 311: > 309: } > 310: > 311: private static void sign(AppImageBuildEnv env) throws IOException { I don't understand why individual signing functions are needed for the runtime and application bundles. They look identical to me. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26173#discussion_r2191279722 From asemenyuk at openjdk.org Tue Jul 8 01:25:42 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Tue, 8 Jul 2025 01:25:42 GMT Subject: RFR: 8351073: [macos] jpackage produces invalid Java runtime DMG bundles [v2] In-Reply-To: References: Message-ID: <_jJCDxm7G2TtaxeCPJFhENFZfFM5Ach8bBu9F6q0YZ8=.9c4ca1a8-5c2c-4a23-9c18-09dc53ff3493@github.com> On Mon, 7 Jul 2025 23:20:08 GMT, Alexander Matveev wrote: >> Re-submission of https://github.com/openjdk/jdk/pull/25314 after merge conflict was resolved. Old PR will be closed. >> >> All comments are addressed from old PR. Merge conflict was significant, so it is like new fix. >> >> Fixed jpackage to produce valid Java runtimes based on description below: >> >> Definitions: >> >> - JDK bundle defined as bundle which contains "Contents/Home", "Contents/MacOS/libjli.dylib" and "Contents/Info.plist". >> - Signed JDK bundle contains all files as JDK bundle + "Contents/_CodeSignature". >> - JDK image defined as content of "Contents/Home". >> - Signed JDK image does not exist, since it cannot be signed as bundle. >> >> jpackage output based on input: >> >> 1. "--runtime-image" points to unsigned JDK bundle and --mac-sign is not provided: >> - jpackage will copy all files as is from provided path and run ad-hoc codesign. >> >> 2. "--runtime-image" points to unsigned JDK bundle and --mac-sign is provided: >> - jpackage will copy all files as is from provided path and run codesign with appropriate certificate based on same logic as we do for application image. >> >> 3. "--runtime-image" points to signed JDK bundle and --mac-sign is not provided: >> - jpackage will copy all files as is from provided path including "Contents/_CodeSignature" to preserve signing. >> >> 4. "--runtime-image" points to signed JDK bundle and --mac-sign is provided: >> - jpackage will copy all files as is from provided path including "Contents/_CodeSignature" and will re-sign bundle with appropriate certificate. >> >> 5. "--runtime-image" points to JDK image and --mac-sign is not provided: >> - jpackage will check for libjli.dylib presence in "lib" folder. >> - Create JDK bundle by putting all files from provided path to "Contents/Home", libjli.dylib from "lib" to "Contents/MacOS/libjli.dylib" and create default "Contents/Info.plist" similar to what we do for runtime in application image. >> - Ad-hoc signing will done. >> >> 6. "--runtime-image" points to JDK image and --mac-sign is provided: >> - 2 first steps from 5 and certificate signing will be done. >> >> Additional changes: >> - The bundle's top directory name will have the ".jdk" suffix. > > Alexander Matveev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: > > - Merge remote-tracking branch 'upstream/master' into JDK-8351073-2 > - 8351073: [macos] jpackage produces invalid Java runtime DMG bundles src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacPackagingPipeline.java line 313: > 311: } > 312: > 313: private static void writeRuntimeBundleInfoPlist(MacApplication app, BuildEnv env, Path runtimeRootDirectory) throws IOException { This function is almost a duplicate of writeRuntimeInfoPlist(). They can be merged together with branching: if (app.asApplicationLayout().isPresent()) { // This is application bundle } else { // This is runtime bundle } ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26173#discussion_r2191288800 From jwaters at openjdk.org Tue Jul 8 01:30:08 2025 From: jwaters at openjdk.org (Julian Waters) Date: Tue, 8 Jul 2025 01:30:08 GMT Subject: Integrated: 8342682: Errors related to unused code on Windows after 8339120 in dt_shmem jdwp security and jpackage In-Reply-To: References: Message-ID: <-TK5ziYVLfu1MOHf70wFHbnT7bhXhOq0mXLI4HOphJE=.37fea4b0-0383-4e9d-baf6-60f437ac92d1@github.com> On Mon, 21 Oct 2024 14:34:30 GMT, Julian Waters wrote: > After 8339120, gcc began catching many different instances of unused code in the Windows specific codebase. Some of these seem to be bugs. I've taken the effort to mark out all the relevant globals and locals that trigger the unused warnings and addressed all of them by commenting out the code as appropriate. I am confident that in many cases this simplistic approach of commenting out code does not fix the underlying issue, and the warning actually found a bug that should be fixed. In these instances, I will be aiming to fix these bugs with help from reviewers, so I recommend anyone reviewing who knows more about the code than I do to see whether there is indeed a bug that needs fixing in a different way than what I did This pull request has now been integrated. Changeset: 563a3358 Author: Julian Waters URL: https://git.openjdk.org/jdk/commit/563a3358f6f1ecff816318cbb32376487365c1fa Stats: 8 lines in 4 files changed: 2 ins; 3 del; 3 mod 8342682: Errors related to unused code on Windows after 8339120 in dt_shmem jdwp security and jpackage Reviewed-by: cjplummer, asemenyuk, almatvee ------------- PR: https://git.openjdk.org/jdk/pull/21616 From jwaters at openjdk.org Tue Jul 8 01:32:52 2025 From: jwaters at openjdk.org (Julian Waters) Date: Tue, 8 Jul 2025 01:32:52 GMT Subject: RFR: 8342868: Errors related to unused code on Windows after 8339120 in core libs [v2] In-Reply-To: References: Message-ID: On Thu, 31 Oct 2024 05:43:11 GMT, Julian Waters wrote: >> After 8339120, gcc began catching many different instances of unused code in the Windows specific codebase. Some of these seem to be bugs. I've taken the effort to mark out all the relevant globals and locals that trigger the unused warnings and addressed all of them by commenting out the code as appropriate. I am confident that in many cases this simplistic approach of commenting out code does not fix the underlying issue, and the warning actually found a bug that should be fixed. In these instances, I will be aiming to fix these bugs with help from reviewers, so I recommend anyone reviewing who knows more about the code than I do to see whether there is indeed a bug that needs fixing in a different way than what I did > > Julian Waters has updated the pull request incrementally with one additional commit since the last revision: > > Remove the got local Sorry for waiting so long. It's become clear that I won't be able to get awt and accessibility up to speed for a long time, so I will go ahead with this one first ------------- PR Comment: https://git.openjdk.org/jdk/pull/21654#issuecomment-3047051283 From jwaters at openjdk.org Tue Jul 8 01:32:52 2025 From: jwaters at openjdk.org (Julian Waters) Date: Tue, 8 Jul 2025 01:32:52 GMT Subject: Integrated: 8342868: Errors related to unused code on Windows after 8339120 in core libs In-Reply-To: References: Message-ID: On Wed, 23 Oct 2024 04:40:50 GMT, Julian Waters wrote: > After 8339120, gcc began catching many different instances of unused code in the Windows specific codebase. Some of these seem to be bugs. I've taken the effort to mark out all the relevant globals and locals that trigger the unused warnings and addressed all of them by commenting out the code as appropriate. I am confident that in many cases this simplistic approach of commenting out code does not fix the underlying issue, and the warning actually found a bug that should be fixed. In these instances, I will be aiming to fix these bugs with help from reviewers, so I recommend anyone reviewing who knows more about the code than I do to see whether there is indeed a bug that needs fixing in a different way than what I did This pull request has now been integrated. Changeset: bbc5c98b Author: Julian Waters URL: https://git.openjdk.org/jdk/commit/bbc5c98b144014a0423d666f74c4a5a15b08a7c2 Stats: 19 lines in 4 files changed: 9 ins; 0 del; 10 mod 8342868: Errors related to unused code on Windows after 8339120 in core libs Reviewed-by: naoto, jlu ------------- PR: https://git.openjdk.org/jdk/pull/21654 From dholmes at openjdk.org Tue Jul 8 01:51:47 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 8 Jul 2025 01:51:47 GMT Subject: RFR: 8342868: Errors related to unused code on Windows after 8339120 in core libs [v2] In-Reply-To: References: Message-ID: On Tue, 8 Jul 2025 01:28:04 GMT, Julian Waters wrote: >> Julian Waters has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove the got local > > Sorry for waiting so long. It's become clear that I won't be able to get awt and accessibility up to speed for a long time, so I will go ahead with this one first @TheShermanTanker the commented out code really should have been deleted, not just left commented out. Please file anpther JBS issue to have this cleaned up so it is not forgotten. Thanks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21654#issuecomment-3047084740 From xgong at openjdk.org Tue Jul 8 01:55:41 2025 From: xgong at openjdk.org (Xiaohong Gong) Date: Tue, 8 Jul 2025 01:55:41 GMT Subject: RFR: 8359419: AArch64: Relax min vector length to 32-bit for short vectors [v3] In-Reply-To: <0XcbEZkrW7fvJhPwQPP1UtT9aC3_OnT7sjoiHo0fOuQ=.1ec5ae91-55cb-4d8b-9e91-44ec02e63747@github.com> References: <7VTRz_XqYBSdQ54n7ADzTzYADZjDbgBw6XuW0jehSLI=.24d18b87-4553-47ab-8065-d92fbb5700ae@github.com> <5H0NP8vFqCDf1JgHIDee3WrYRbJ6koj5wQsxEGTW8nI=.87d74c6a-54b3-45cc-a972-c4350d5e2acf@github.com> <0XcbEZkrW7fvJhPwQPP1UtT9aC3_OnT7sjoiHo0fOuQ=.1ec5ae91-55cb-4d8b-9e91-44ec02e63747@github.com> Message-ID: On Mon, 7 Jul 2025 06:59:20 GMT, Xiaohong Gong wrote: >> Have you measured the performance of this micro-benchmark on NEON machine? >> https://github.com/openjdk/jdk/blob/f2d2eef988c57cc9f6194a8fd5b2b422035ee68f/test/micro/org/openjdk/bench/vm/compiler/TypeVectorOperations.java#L251-L256 >> >> We added an limitation only for `int` before: >> https://github.com/openjdk/jdk/blob/f2d2eef988c57cc9f6194a8fd5b2b422035ee68f/src/hotspot/cpu/aarch64/aarch64_vector.ad#L131-L134 >> >> Perhaps we also need to impose a similar limitation on `short` if the same regression occurs. > >> Have you measured the performance of this micro-benchmark on NEON machine? >> >> https://github.com/openjdk/jdk/blob/f2d2eef988c57cc9f6194a8fd5b2b422035ee68f/test/micro/org/openjdk/bench/vm/compiler/TypeVectorOperations.java#L251-L256 >> >> We added an limitation only for `int` before: >> >> https://github.com/openjdk/jdk/blob/f2d2eef988c57cc9f6194a8fd5b2b422035ee68f/src/hotspot/cpu/aarch64/aarch64_vector.ad#L131-L134 >> >> Perhaps we also need to impose a similar limitation on `short` if the same regression occurs. > > Good catch, and thanks so much for your input @fg1417 ! I will test the performance and disable auto-vectorization for double to short casting if the performance has regression. > >> https://github.com/openjdk/jdk/blob/f2d2eef988c57cc9f6194a8fd5b2b422035ee68f/test/hotspot/jtreg/compiler/vectorization/runner/ArrayTypeConvertTest.java#L388-L392 > > Actually I didn't change the min vector size for `char` vectors in this patch. Relaxing `short` vectors to 32-bit is to support the vector cast for Vector API, and there is no `char` species in it. Do you think it's better to do the same change for `char` as well? This will just benefit auto-vectorization. > Hi @XiaohongGong, is there any way we can implement 2HF -> 2S and 2S -> 2HF in these match rules ? > > https://github.com/openjdk/jdk/blob/f2d2eef988c57cc9f6194a8fd5b2b422035ee68f/src/hotspot/cpu/aarch64/aarch64_vector.ad#L4697 > > https://github.com/openjdk/jdk/blob/f2d2eef988c57cc9f6194a8fd5b2b422035ee68f/src/hotspot/cpu/aarch64/aarch64_vector.ad#L4679 > > The `fcvtn` and `fcvtl` instructions do not support these arrangements. I was wondering if there is any other way we can implement these by any chance? Do you mean `2HF -> 2F` and `2F -> 2HF` ? Yes, it does not support the 32-bit arrangements. Vector conversion is a kind of lanewise vector operation. For such cases, we usually use the same arrangements with 64-bit vector size for 32-bit ones. That means we can reuse the `T4H` and `T4S` to implement it. Hence, current match rules can cover the conversions between `2HF` and `2F`. Consider there is no such conversion cases in Vector API, I didn't change the comment in the match rules. I think this may benefit auto-vectorization. Currently, do we have cases that can match these rules with SLP? ------------- PR Comment: https://git.openjdk.org/jdk/pull/26057#issuecomment-3047091009 From xgong at openjdk.org Tue Jul 8 01:58:45 2025 From: xgong at openjdk.org (Xiaohong Gong) Date: Tue, 8 Jul 2025 01:58:45 GMT Subject: RFR: 8359419: AArch64: Relax min vector length to 32-bit for short vectors [v3] In-Reply-To: References: <7VTRz_XqYBSdQ54n7ADzTzYADZjDbgBw6XuW0jehSLI=.24d18b87-4553-47ab-8065-d92fbb5700ae@github.com> <5H0NP8vFqCDf1JgHIDee3WrYRbJ6koj5wQsxEGTW8nI=.87d74c6a-54b3-45cc-a972-c4350d5e2acf@github.com> <0XcbEZkrW7fvJhPwQPP1UtT9aC3_OnT7sjoiHo0fOuQ=.1ec5ae91-55cb-4d8b-9e91-44ec02e63747@github.com> Message-ID: <0vdCJFYxCI6hFnTL6rm3oKQcPuuIR2EbuyAOa0muqcw=.d5c249cb-9bf0-415d-ab22-de7387d8d8d1@github.com> On Mon, 7 Jul 2025 13:23:15 GMT, Fei Gao wrote: > > > https://github.com/openjdk/jdk/blob/f2d2eef988c57cc9f6194a8fd5b2b422035ee68f/test/hotspot/jtreg/compiler/vectorization/runner/ArrayTypeConvertTest.java#L388-L392 > > > > > > Actually I didn't change the min vector size for `char` vectors in this patch. Relaxing `short` vectors to 32-bit is to support the vector cast for Vector API, and there is no `char` species in it. Do you think it's better to do the same change for `char` as well? This will just benefit auto-vectorization. > > Hi @XiaohongGong thanks for asking. In many auto-vectorization cases involving `char`, the vector elements are represented using `T_SHORT` as the `BasicType`, rather than `T_CHAR`. > > This is because, in Java, operands of subword types are always promoted to `int` before any arithmetic operation. As a result, when handling a node like `ConvD2I`, we don?t initially know its actual subword type. Later, the SuperWord phase propagates a narrowed integer type backward to help determine the correct subword type. See: > > https://github.com/openjdk/jdk/blob/f2d2eef988c57cc9f6194a8fd5b2b422035ee68f/src/hotspot/share/opto/superword.cpp#L2551-L2558 > > Since SuperWord assigns `T_SHORT` to `StoreC` early on > > https://github.com/openjdk/jdk/blob/f2d2eef988c57cc9f6194a8fd5b2b422035ee68f/src/hotspot/share/opto/superword.cpp#L2646-L2650 > > > the entire propagation chain tends to use `T_SHORT` as well. > This applies to most operations, with the exception of a few like `RShiftI`, `Abs`, and `ReverseBytesI`, which are handled separately. > > So your change already benefits many char-related vectorization cases like `convertDoubleToChar` above. That?s why we can safely relax the IR condition mentioned earlier. Thanks for your input! It's really helpful to me. Does this mean it always use `T_SHORT` for char vectors in SLP? If so, it's safe that we do not need to consider `T_CHAR` in vector IRs in backend? ------------- PR Comment: https://git.openjdk.org/jdk/pull/26057#issuecomment-3047094924 From yujige at gmail.com Tue Jul 8 02:26:24 2025 From: yujige at gmail.com (Jige Yu) Date: Mon, 7 Jul 2025 19:26:24 -0700 Subject: Question about mapConcurrent() Behavior and Happens-Before Guarantees In-Reply-To: References: Message-ID: Thanks for the quick reply, Viktor! On Mon, Jul 7, 2025 at 2:35?AM Viktor Klang wrote: > Hi Jige, > > >Initially, I thought this design choice might provide a strong > happens-before guarantee. My assumption was that an application catching a > RuntimeException would be able to *observe all side effects* from the > virtual threads, even though this practice is generally discouraged. This > seemed like a potentially significant advantage, outweighing the risk of a > virtual thread failing to respond to interruption or responding slowly. > > Unless explicitly stated in the API contract, no such guarantees should be > presumed to exist. > I understand that explicit API contracts are what matters. My concern, however, is that even if the API contract explicitly states *no* happens-before guarantee upon an unchecked exception, this behavior would still be a significant deviation from established visibility standards in other JDK APIs. For instance, both *parallel streams* and Future.get() provide a happens-before guarantee upon completion (or exceptional completion in the case of Future.get()). So users will most likely take it for granted. If mapConcurrent() were to *not* offer this, it would potentially be the *first blocking JDK API that doesn't honor happens-before* in such a scenario. This inconsistency would likely be surprising and potentially confusing to users who have come to expect this behavior in concurrent programming constructs within the JDK. > > > As for general resource-management in Stream, I have contemplated designs > for Gatherer (and Collector) to be able to participate in the onClose > actions, but there's a lot of ground to cover to ensure correct ordering > and sufficiently-encompassing of cleanup action execution. > Yeah. I agree that hooking into onClose() could provide a more reliable mechanism for cleanup. My primary concern though, is the change it imposes on the call-site contract. Requiring all users of mapConcurrent() to adopt a try-with-resources syntax, while ideal for correctness, introduces a burden and is more subject to users forgetting to do so, potentially leading to resource leaks. My previously proposed collectingAndThen(toList(), list -> list.stream().gather(mapConcurrent())) idea, on the other hand, avoids this call-site contract change. Being a collector, it needs to first consume the input, similar to how most Collectors operate. So it might be a less intrusive path to ensure proper resource handling without altering usage patterns. > > Cheers, > ? > > > *Viktor Klang* > Software Architect, Java Platform Group > Oracle > ------------------------------ > *From:* core-libs-dev on behalf of Jige > Yu > *Sent:* Thursday, 3 July 2025 16:36 > *To:* core-libs-dev at openjdk.org > *Subject:* Question about mapConcurrent() Behavior and Happens-Before > Guarantees > > > Hi JDK Core Devs, > > I'm writing to you today with a question about the behavior of > mapConcurrent() and its interaction with unchecked exceptions. I've been > experimenting with the API and observed that mapConcurrent() blocks and > joins all virtual threads upon an unchecked exception before propagating it. > > Initially, I thought this design choice might provide a strong > happens-before guarantee. My assumption was that an application catching a > RuntimeException would be able to *observe all side effects* from the > virtual threads, even though this practice is generally discouraged. This > seemed like a potentially significant advantage, outweighing the risk of a > virtual thread failing to respond to interruption or responding slowly. > > However, I've since realized that mapConcurrent() cannot fully guarantee > a strong happens-before relationship when an unchecked exception occurs > *somewhere* in the stream pipeline. While it can block and wait for > exceptions thrown by the mapper function or downstream operations, it > appears unable to intercept unchecked exceptions *thrown by an upstream* > source. > > Consider a scenario with two input elements: if the first element starts a > virtual thread, and then the second element causes an unchecked exception > from the upstream *before* reaching the gather() call, the virtual thread > initiated by the first element would not be interrupted. This makes the > "happens-before" guarantee quite nuanced in practice. > > This brings me to my core questions: > > 1. > > Is providing a happens-before guarantee upon an unchecked exception a > design goal for mapConcurrent()? > 2. > > If not, would it be more desirable to *not* join on virtual threads > when unchecked exceptions occur? This would allow the application code to > catch the exception sooner and avoid the risk of being blocked indefinitely. > > Thank you for your time and insights. > > Best regards, > > Ben Yu > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jpai at openjdk.org Tue Jul 8 04:22:48 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 8 Jul 2025 04:22:48 GMT Subject: RFR: 8342868: Errors related to unused code on Windows after 8339120 in core libs [v2] In-Reply-To: References: Message-ID: On Thu, 31 Oct 2024 05:43:11 GMT, Julian Waters wrote: >> After 8339120, gcc began catching many different instances of unused code in the Windows specific codebase. Some of these seem to be bugs. I've taken the effort to mark out all the relevant globals and locals that trigger the unused warnings and addressed all of them by commenting out the code as appropriate. I am confident that in many cases this simplistic approach of commenting out code does not fix the underlying issue, and the warning actually found a bug that should be fixed. In these instances, I will be aiming to fix these bugs with help from reviewers, so I recommend anyone reviewing who knows more about the code than I do to see whether there is indeed a bug that needs fixing in a different way than what I did > > Julian Waters has updated the pull request incrementally with one additional commit since the last revision: > > Remove the got local > Since your change was applied there have been 3762 commits pushed to the master branch It's usually risky to be integrating a PR which is so far behind the master branch, without first merging the latest changes and running the tier tests. In this case it hasn't caused any failures in the tier testing so far. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21654#issuecomment-3047304336 From jpai at openjdk.org Tue Jul 8 05:01:40 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 8 Jul 2025 05:01:40 GMT Subject: RFR: 8361426: (ref) Remove jdk.internal.ref.Cleaner In-Reply-To: References: Message-ID: On Sat, 5 Jul 2025 00:05:39 GMT, Kim Barrett wrote: > Please review this change that removes the class jdk.internal.ref.Cleaner. > It is no longer used after JDK-8344332. > > Testing: mach5 tier1-3 This looks OK to me and matches with what was discussed about this in a recent PR https://github.com/openjdk/jdk/pull/25289#discussion_r2172727041. It would be good to get another review for this before integrating. ------------- Marked as reviewed by jpai (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26141#pullrequestreview-2995976614 From jpai at openjdk.org Tue Jul 8 05:06:39 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 8 Jul 2025 05:06:39 GMT Subject: RFR: 8346884: Add since checker test to jdk.editpad In-Reply-To: References: Message-ID: On Tue, 3 Jun 2025 10:09:44 GMT, Nizar Benalla wrote: > Please review this patch to add a new test to check `@since` tags in the `jdk.editpad` module. > > TIA This looks OK to me. ------------- Marked as reviewed by jpai (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25613#pullrequestreview-2995985317 From jpai at openjdk.org Tue Jul 8 05:16:39 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 8 Jul 2025 05:16:39 GMT Subject: RFR: 8351354: Enhance java -XshowSettings:security:tls to show enabled TLS groups and signature algorithms In-Reply-To: References: Message-ID: <84bqpOT-0Mvgqr3173feXu3KGIdl3RIFMK9Kxrr3w1Q=.2bf8673e-1bc1-4c7f-a01a-f2ff51f9cc48@github.com> On Thu, 3 Apr 2025 18:47:43 GMT, Matthew Donovan wrote: > In this PR I added TLS groups and signature algorithms to the output of the show settings flag. The values are printed in a single column, like the cipher suites. There can be a lot of values so putting on a single line is ugly. I tried putting them in columns, but it is hard to read. Hello Matthew, In recent times we have been adding more of these configuration debugging into the -XshowSettings option. I'm unusure to what extent this option should be advertized or used for gathering such details of the runtime. Would this be more suitable to be done as a `jcmd` command? Something like a `jcmd VM.security_configuration`? To me, that feels like a more natural place to be adding support for details like these. More so because I think it's very rare for applications to be launching the JVM with the `-XshowSettings` option. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24424#issuecomment-3047385294 From jpai at openjdk.org Tue Jul 8 05:20:39 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 8 Jul 2025 05:20:39 GMT Subject: RFR: 8358627: tools/sincechecker/modules/java.base/JavaBaseCheckSince.java fails with JDK 26 In-Reply-To: References: Message-ID: On Tue, 17 Jun 2025 15:22:24 GMT, Nizar Benalla wrote: > Once https://bugs.openjdk.org/browse/JDK-8358769 is resolved, JavaBaseCheckSince no longer needs to be problemlisted. Hello Nizar, if I understand correctly, this problem listing can be removed and the PR integrated once the merge conflicts are resolved in this PR? ------------- PR Comment: https://git.openjdk.org/jdk/pull/25855#issuecomment-3047392332 From duke at openjdk.org Tue Jul 8 06:00:38 2025 From: duke at openjdk.org (erifan) Date: Tue, 8 Jul 2025 06:00:38 GMT Subject: RFR: 8354242: VectorAPI: combine vector not operation with compare [v10] In-Reply-To: References: Message-ID: > This patch optimizes the following patterns: > For integer types: > > (XorV (VectorMaskCmp src1 src2 cond) (Replicate -1)) > => (VectorMaskCmp src1 src2 ncond) > (XorVMask (VectorMaskCmp src1 src2 cond) (MaskAll m1)) > => (VectorMaskCmp src1 src2 ncond) > > cond can be eq, ne, le, ge, lt, gt, ule, uge, ult and ugt, ncond is the negative comparison of cond. > > For float and double types: > > (XorV (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (Replicate -1)) > => (VectorMaskCast (VectorMaskCmp src1 src2 ncond)) > (XorVMask (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (MaskAll m1)) > => (VectorMaskCast (VectorMaskCmp src1 src2 ncond)) > > cond can be eq or ne. > > Benchmarks on Nvidia Grace machine with 128-bit SVE2: With option `-XX:UseSVE=2`: > > Benchmark Unit Before Score Error After Score Error Uplift > testCompareEQMaskNotByte ops/s 7912127.225 2677.289518 10266136.26 8955.008548 1.29 > testCompareEQMaskNotDouble ops/s 884737.6799 446.963779 1179760.772 448.031844 1.33 > testCompareEQMaskNotFloat ops/s 1765045.787 682.332214 2359520.803 896.305743 1.33 > testCompareEQMaskNotInt ops/s 1787221.411 977.743935 2353952.519 960.069976 1.31 > testCompareEQMaskNotLong ops/s 895297.1974 673.44808 1178449.02 323.804205 1.31 > testCompareEQMaskNotShort ops/s 3339987.002 3415.2226 4712761.965 2110.862053 1.41 > testCompareGEMaskNotByte ops/s 7907615.16 4094.243652 10251646.9 9486.699831 1.29 > testCompareGEMaskNotInt ops/s 1683738.958 4233.813092 2352855.205 1251.952546 1.39 > testCompareGEMaskNotLong ops/s 854496.1561 8594.598885 1177811.493 521.1229 1.37 > testCompareGEMaskNotShort ops/s 3341860.309 1578.975338 4714008.434 1681.10365 1.41 > testCompareGTMaskNotByte ops/s 7910823.674 2993.367032 10245063.58 9774.75138 1.29 > testCompareGTMaskNotInt ops/s 1673393.928 3153.099431 2353654.521 1190.848583 1.4 > testCompareGTMaskNotLong ops/s 849405.9159 2432.858159 1177952.041 359.96413 1.38 > testCompareGTMaskNotShort ops/s 3339509.141 3339.976585 4711442.496 2673.364893 1.41 > testCompareLEMaskNotByte ops/s 7911340.004 3114.69191 10231626.5 27134.20035 1.29 > testCompareLEMaskNotInt ops/s 1675812.113 1340.969885 2353255.341 1452.4522 1.4 > testCompareLEMaskNotLong ops/s 848862.8036 6564.841731 1177763.623 539.290106 1.38 > testCompareLEMaskNotShort ops/s 3324951.54 2380.29473 4712116.251 1544.559684 1.41 > testCompareLTMaskNotByte ops/s 7910390.844 2630.861436 10239567.69 6487.441672 1.29 > testCompareLTMaskNotInt ops/s 1672180.09 995.238142 2353757.863 853.774734 1.4 > testCompareLTMaskNotLong ops/s 856502.26... erifan has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 17 additional commits since the last revision: - Align indentation - Merge branch 'master' into JDK-8354242 - Address more comments ATT. - Merge branch 'master' into JDK-8354242 - Support negating unsigned comparison for BoolTest::mask Added a static method `negate_mask(mask btm)` into BoolTest class to negate both signed and unsigned comparison. - Addressed some review comments - Merge branch 'master' into JDK-8354242 - Refactor the JTReg tests for compare.xor(maskAll) Also made a bit change to support pattern `VectorMask.fromLong()`. - Merge branch 'master' into JDK-8354242 - Refactor code Add a new function XorVNode::Ideal_XorV_VectorMaskCmp to do this optimization, making the code more modular. - ... and 7 more: https://git.openjdk.org/jdk/compare/c2a2adc8...db78dc43 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24674/files - new: https://git.openjdk.org/jdk/pull/24674/files/5ebdc572..db78dc43 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24674&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24674&range=08-09 Stats: 9269 lines in 462 files changed: 4528 ins; 2873 del; 1868 mod Patch: https://git.openjdk.org/jdk/pull/24674.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24674/head:pull/24674 PR: https://git.openjdk.org/jdk/pull/24674 From duke at openjdk.org Tue Jul 8 06:00:39 2025 From: duke at openjdk.org (erifan) Date: Tue, 8 Jul 2025 06:00:39 GMT Subject: RFR: 8354242: VectorAPI: combine vector not operation with compare [v9] In-Reply-To: References: Message-ID: On Mon, 7 Jul 2025 09:32:42 GMT, erifan wrote: >> src/hotspot/share/opto/vectornode.cpp line 2243: >> >>> 2241: !VectorNode::is_all_ones_vector(in2)) { >>> 2242: return nullptr; >>> 2243: } >> >> Suggestion: >> >> if (in1->Opcode() != Op_VectorMaskCmp || >> in1->outcnt() != 1 || >> !(in1->as_VectorMaskCmp())->predicate_can_be_negated() || >> !VectorNode::is_all_ones_vector(in2)) { >> return nullptr; >> } >> >> Indentation for clarity. >> >> Currently, you exiting if one of these is the case: >> 1. Not `MaskCmp` >> 2. More than one use >> 3. predicate cannot be negated AND the vector is all ones. Can you explain this condition? Do you have tests for cases: >> - predicate negatable and vector not all ones >> - predircate not negatable and vector not all ones >> - predicate negatable and vector all ones >> - predicate not negatable and vectors all ones >> >> Why do you guard against `VectorNode::is_all_ones_vector(in2)` at all? >> >> The condition for 3. is easy to get wrong, so good testing is important here :) > > The current testing status for the conditions you listed: >> 1. Not MaskCmp. > > **No test for it, tested locally**, Because I think this condition is too straightforward. > >> 2. More than one use. > > **Tested**, see `VectorMaskCompareNotTest.java line 1118`. > >> predicate negatable and vector not all ones. > > **Tested**, see `VectorMaskCompareNotTest.java line 1126`. > >> predicate not negatable and vector not all ones. > > **No test for it**, because we have tests for `predicate not negatable` or `vector not all ones`. If either is `false`, return nullptr. > >> predicate negatable and vector all ones. > > **A lot of tests for it**. For example `VectorMaskCompareNotTest.java line 1014`. > >> predicate not negatable and vectors all ones. > > **Tested**, see `VectorMaskCompareNotTest.java line 1222`. > Indentation for clarity. Done. I think we have enough negative tests. Please take a look at this PR, thanks~ ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24674#discussion_r2191550171 From bkilambi at openjdk.org Tue Jul 8 08:16:39 2025 From: bkilambi at openjdk.org (Bhavana Kilambi) Date: Tue, 8 Jul 2025 08:16:39 GMT Subject: RFR: 8359419: AArch64: Relax min vector length to 32-bit for short vectors [v3] In-Reply-To: <0vdCJFYxCI6hFnTL6rm3oKQcPuuIR2EbuyAOa0muqcw=.d5c249cb-9bf0-415d-ab22-de7387d8d8d1@github.com> References: <7VTRz_XqYBSdQ54n7ADzTzYADZjDbgBw6XuW0jehSLI=.24d18b87-4553-47ab-8065-d92fbb5700ae@github.com> <5H0NP8vFqCDf1JgHIDee3WrYRbJ6koj5wQsxEGTW8nI=.87d74c6a-54b3-45cc-a972-c4350d5e2acf@github.com> <0XcbEZkrW7fvJhPwQPP1UtT9aC3_OnT7sjoiHo0fOuQ=.1ec5ae91-55cb-4d8b-9e91-44ec02e63747@github.com> <0vdCJFYxCI6hFnTL6rm3oKQcPuuIR2EbuyAOa0muqcw=.d5c249cb-9bf0-415d-ab22-de7387d8d8d1@github.com> Message-ID: On Tue, 8 Jul 2025 01:55:55 GMT, Xiaohong Gong wrote: >>> > https://github.com/openjdk/jdk/blob/f2d2eef988c57cc9f6194a8fd5b2b422035ee68f/test/hotspot/jtreg/compiler/vectorization/runner/ArrayTypeConvertTest.java#L388-L392 >>> >>> Actually I didn't change the min vector size for `char` vectors in this patch. Relaxing `short` vectors to 32-bit is to support the vector cast for Vector API, and there is no `char` species in it. Do you think it's better to do the same change for `char` as well? This will just benefit auto-vectorization. >> >> Hi @XiaohongGong thanks for asking. In many auto-vectorization cases involving `char`, the vector elements are represented using `T_SHORT` as the `BasicType`, rather than `T_CHAR`. >> >> This is because, in Java, operands of subword types are always promoted to `int` before any arithmetic operation. As a result, when handling a node like `ConvD2I`, we don?t initially know its actual subword type. Later, the SuperWord phase propagates a narrowed integer type backward to help determine the correct subword type. See: >> https://github.com/openjdk/jdk/blob/f2d2eef988c57cc9f6194a8fd5b2b422035ee68f/src/hotspot/share/opto/superword.cpp#L2551-L2558 >> >> Since SuperWord assigns `T_SHORT` to `StoreC` early on https://github.com/openjdk/jdk/blob/f2d2eef988c57cc9f6194a8fd5b2b422035ee68f/src/hotspot/share/opto/superword.cpp#L2646-L2650 >> the entire propagation chain tends to use `T_SHORT` as well. >> >> This applies to most operations, with the exception of a few like `RShiftI`, `Abs`, and `ReverseBytesI`, which are handled separately. >> >> So your change already benefits many char-related vectorization cases like `convertDoubleToChar` above. That?s why we can safely relax the IR condition mentioned earlier. > >> > > https://github.com/openjdk/jdk/blob/f2d2eef988c57cc9f6194a8fd5b2b422035ee68f/test/hotspot/jtreg/compiler/vectorization/runner/ArrayTypeConvertTest.java#L388-L392 >> > >> > >> > Actually I didn't change the min vector size for `char` vectors in this patch. Relaxing `short` vectors to 32-bit is to support the vector cast for Vector API, and there is no `char` species in it. Do you think it's better to do the same change for `char` as well? This will just benefit auto-vectorization. >> >> Hi @XiaohongGong thanks for asking. In many auto-vectorization cases involving `char`, the vector elements are represented using `T_SHORT` as the `BasicType`, rather than `T_CHAR`. >> >> This is because, in Java, operands of subword types are always promoted to `int` before any arithmetic operation. As a result, when handling a node like `ConvD2I`, we don?t initially know its actual subword type. Later, the SuperWord phase propagates a narrowed integer type backward to help determine the correct subword type. See: >> >> https://github.com/openjdk/jdk/blob/f2d2eef988c57cc9f6194a8fd5b2b422035ee68f/src/hotspot/share/opto/superword.cpp#L2551-L2558 >> >> Since SuperWord assigns `T_SHORT` to `StoreC` early on >> >> https://github.com/openjdk/jdk/blob/f2d2eef988c57cc9f6194a8fd5b2b422035ee68f/src/hotspot/share/opto/superword.cpp#L2646-L2650 >> >> >> the entire propagation chain tends to use `T_SHORT` as well. >> This applies to most operations, with the exception of a few like `RShiftI`, `Abs`, and `ReverseBytesI`, which are handled separately. >> >> So your change already benefits many char-related vectorization cases like `convertDoubleToChar` above. That?s why we can safely relax the IR condition mentioned earlier. > > Thanks for your input! It's really helpful to me. Does this mean it always use `T_SHORT` for char vectors in SLP? If so, it's safe that we do not need to consider `T_CHAR` in vector IRs in backend? > > Hi @XiaohongGong, is there any way we can implement 2HF -> 2S and 2S -> 2HF in these match rules ? > > https://github.com/openjdk/jdk/blob/f2d2eef988c57cc9f6194a8fd5b2b422035ee68f/src/hotspot/cpu/aarch64/aarch64_vector.ad#L4697 > > > > https://github.com/openjdk/jdk/blob/f2d2eef988c57cc9f6194a8fd5b2b422035ee68f/src/hotspot/cpu/aarch64/aarch64_vector.ad#L4679 > > > > The `fcvtn` and `fcvtl` instructions do not support these arrangements. I was wondering if there is any other way we can implement these by any chance? > > Do you mean `2HF -> 2F` and `2F -> 2HF` ? > > Yes, it does not support the 32-bit arrangements. Vector conversion is a kind of lanewise vector operation. For such cases, we usually use the same arrangements with 64-bit vector size for 32-bit ones. That means we can reuse the `T4H` and `T4S` to implement it. Hence, current match rules can cover the conversions between `2HF` and `2F`. > > Consider there is no such conversion cases in Vector API, I didn't change the comment in the match rules. I think this may benefit auto-vectorization. Currently, do we have cases that can match these rules with SLP? Sorry yes I meant 2HF <-> 2F. Yes, currently there are no such cases in VectorAPI as we do not support Float16 Vectors yet but this will benefit autovectorization cases. I think in this case this may also benefit 2D <-> 2HF as well (eventually we might add support for D <-> HF as well). Yes we have some JTREG tests that match these rules currently like - `test/hotspot/jtreg/compiler/vectorization/TestFloat16VectorConvChain.java`, `test/hotspot/jtreg/compiler/vectorization/TestFloatConversionsVector.java`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26057#issuecomment-3047838866 From fgao at openjdk.org Tue Jul 8 08:21:41 2025 From: fgao at openjdk.org (Fei Gao) Date: Tue, 8 Jul 2025 08:21:41 GMT Subject: RFR: 8359419: AArch64: Relax min vector length to 32-bit for short vectors [v3] In-Reply-To: <0vdCJFYxCI6hFnTL6rm3oKQcPuuIR2EbuyAOa0muqcw=.d5c249cb-9bf0-415d-ab22-de7387d8d8d1@github.com> References: <7VTRz_XqYBSdQ54n7ADzTzYADZjDbgBw6XuW0jehSLI=.24d18b87-4553-47ab-8065-d92fbb5700ae@github.com> <5H0NP8vFqCDf1JgHIDee3WrYRbJ6koj5wQsxEGTW8nI=.87d74c6a-54b3-45cc-a972-c4350d5e2acf@github.com> <0XcbEZkrW7fvJhPwQPP1UtT9aC3_OnT7sjoiHo0fOuQ=.1ec5ae91-55cb-4d8b-9e91-44ec02e63747@github.com> <0vdCJFYxCI6hFnTL6rm3oKQcPuuIR2EbuyAOa0muqcw=.d5c249cb-9bf0-415d-ab22-de7387d8d8d1@github.com> Message-ID: On Tue, 8 Jul 2025 01:55:55 GMT, Xiaohong Gong wrote: > > > > https://github.com/openjdk/jdk/blob/f2d2eef988c57cc9f6194a8fd5b2b422035ee68f/test/hotspot/jtreg/compiler/vectorization/runner/ArrayTypeConvertTest.java#L388-L392 > > > > > > > > > Actually I didn't change the min vector size for `char` vectors in this patch. Relaxing `short` vectors to 32-bit is to support the vector cast for Vector API, and there is no `char` species in it. Do you think it's better to do the same change for `char` as well? This will just benefit auto-vectorization. > > > > > > Hi @XiaohongGong thanks for asking. In many auto-vectorization cases involving `char`, the vector elements are represented using `T_SHORT` as the `BasicType`, rather than `T_CHAR`. > > This is because, in Java, operands of subword types are always promoted to `int` before any arithmetic operation. As a result, when handling a node like `ConvD2I`, we don?t initially know its actual subword type. Later, the SuperWord phase propagates a narrowed integer type backward to help determine the correct subword type. See: > > https://github.com/openjdk/jdk/blob/f2d2eef988c57cc9f6194a8fd5b2b422035ee68f/src/hotspot/share/opto/superword.cpp#L2551-L2558 > > > > Since SuperWord assigns `T_SHORT` to `StoreC` early on > > https://github.com/openjdk/jdk/blob/f2d2eef988c57cc9f6194a8fd5b2b422035ee68f/src/hotspot/share/opto/superword.cpp#L2646-L2650 > > > > the entire propagation chain tends to use `T_SHORT` as well. > > This applies to most operations, with the exception of a few like `RShiftI`, `Abs`, and `ReverseBytesI`, which are handled separately. > > So your change already benefits many char-related vectorization cases like `convertDoubleToChar` above. That?s why we can safely relax the IR condition mentioned earlier. > > Thanks for your input! It's really helpful to me. Does this mean it always use `T_SHORT` for char vectors in SLP? If so, it's safe that we do not need to consider `T_CHAR` in vector IRs in backend? No, we don't always use `T_SHORT` for char vectors. As mentioned earlier, for operations like `RShiftI`, `Abs`, and `ReverseBytesI`, the compiler needs to preserve the higher-order bits of the first operand. Therefore, SuperWord still needs to assign them precise subword types. See: https://github.com/openjdk/jdk/blob/f2d2eef988c57cc9f6194a8fd5b2b422035ee68f/src/hotspot/share/opto/superword.cpp#L2583-L2589 ------------- PR Comment: https://git.openjdk.org/jdk/pull/26057#issuecomment-3047853525 From asotona at openjdk.org Tue Jul 8 08:36:48 2025 From: asotona at openjdk.org (Adam Sotona) Date: Tue, 8 Jul 2025 08:36:48 GMT Subject: RFR: 8361526: Synchronize ClassFile API verifier with hotspot In-Reply-To: References: Message-ID: On Mon, 7 Jul 2025 23:21:58 GMT, Chen Liang wrote: > The class file API verifier seems to be based off a version of hotspot verifier before Mar 3 2021. We are thus missing a few patches in the hotspot verifier: > [JDK-8350029](https://bugs.openjdk.org/browse/JDK-8350029) [JDK-8340110](https://bugs.openjdk.org/browse/JDK-8340110) [JDK-8330606](https://bugs.openjdk.org/browse/JDK-8330606) [JDK-8314295](https://bugs.openjdk.org/browse/JDK-8314295) [JDK-8270398](https://bugs.openjdk.org/browse/JDK-8270398) [JDK-8267118](https://bugs.openjdk.org/browse/JDK-8267118) [JDK-8262368](https://bugs.openjdk.org/browse/JDK-8262368) [JDK-8272096](https://bugs.openjdk.org/browse/JDK-8272096) [JDK-8349923](https://bugs.openjdk.org/browse/JDK-8349923) > > Synchronization allows the ClassFile API verifier to catch up with upcoming verification changes for Valhalla strict fields as well. > > Testing: select javac tests and classfile tests, running tier 1-3 Nice update, looks good to me. ------------- Marked as reviewed by asotona (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26174#pullrequestreview-2996564822 From epeter at openjdk.org Tue Jul 8 08:59:44 2025 From: epeter at openjdk.org (Emanuel Peter) Date: Tue, 8 Jul 2025 08:59:44 GMT Subject: RFR: 8354242: VectorAPI: combine vector not operation with compare [v9] In-Reply-To: References: Message-ID: On Tue, 8 Jul 2025 05:56:58 GMT, erifan wrote: >> The current testing status for the conditions you listed: >>> 1. Not MaskCmp. >> >> **No test for it, tested locally**, Because I think this condition is too straightforward. >> >>> 2. More than one use. >> >> **Tested**, see `VectorMaskCompareNotTest.java line 1118`. >> >>> predicate negatable and vector not all ones. >> >> **Tested**, see `VectorMaskCompareNotTest.java line 1126`. >> >>> predicate not negatable and vector not all ones. >> >> **No test for it**, because we have tests for `predicate not negatable` or `vector not all ones`. If either is `false`, return nullptr. >> >>> predicate negatable and vector all ones. >> >> **A lot of tests for it**. For example `VectorMaskCompareNotTest.java line 1014`. >> >>> predicate not negatable and vectors all ones. >> >> **Tested**, see `VectorMaskCompareNotTest.java line 1222`. > >> Indentation for clarity. > > Done. > > I think we have enough negative tests. Please take a look at this PR, thanks~ Thanks for your answers @erifan ! Can you please answer these as well? > predicate cannot be negated AND the vector is all ones. Can you explain this condition? A code comment would be helpful for this case. I'm a little bit struggling to understand the bracket/negation here. > Why do you guard against VectorNode::is_all_ones_vector(in2) at all? Is this necessary? Why? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24674#discussion_r2191900155 From xgong at openjdk.org Tue Jul 8 09:03:42 2025 From: xgong at openjdk.org (Xiaohong Gong) Date: Tue, 8 Jul 2025 09:03:42 GMT Subject: RFR: 8359419: AArch64: Relax min vector length to 32-bit for short vectors [v3] In-Reply-To: References: <7VTRz_XqYBSdQ54n7ADzTzYADZjDbgBw6XuW0jehSLI=.24d18b87-4553-47ab-8065-d92fbb5700ae@github.com> <5H0NP8vFqCDf1JgHIDee3WrYRbJ6koj5wQsxEGTW8nI=.87d74c6a-54b3-45cc-a972-c4350d5e2acf@github.com> <0XcbEZkrW7fvJhPwQPP1UtT9aC3_OnT7sjoiHo0fOuQ=.1ec5ae91-55cb-4d8b-9e91-44ec02e63747@github.com> <0vdCJFYxCI6hFnTL6rm3oKQcPuuIR2EbuyAOa0muqcw=.d5c249cb-9bf0-415d-ab22-de7387d8d8d1@github.com> Message-ID: On Tue, 8 Jul 2025 08:18:57 GMT, Fei Gao wrote: > > > > > https://github.com/openjdk/jdk/blob/f2d2eef988c57cc9f6194a8fd5b2b422035ee68f/test/hotspot/jtreg/compiler/vectorization/runner/ArrayTypeConvertTest.java#L388-L392 > > > > > > > > > > > > Actually I didn't change the min vector size for `char` vectors in this patch. Relaxing `short` vectors to 32-bit is to support the vector cast for Vector API, and there is no `char` species in it. Do you think it's better to do the same change for `char` as well? This will just benefit auto-vectorization. > > > > > > > > > Hi @XiaohongGong thanks for asking. In many auto-vectorization cases involving `char`, the vector elements are represented using `T_SHORT` as the `BasicType`, rather than `T_CHAR`. > > > This is because, in Java, operands of subword types are always promoted to `int` before any arithmetic operation. As a result, when handling a node like `ConvD2I`, we don?t initially know its actual subword type. Later, the SuperWord phase propagates a narrowed integer type backward to help determine the correct subword type. See: > > > https://github.com/openjdk/jdk/blob/f2d2eef988c57cc9f6194a8fd5b2b422035ee68f/src/hotspot/share/opto/superword.cpp#L2551-L2558 > > > > > > Since SuperWord assigns `T_SHORT` to `StoreC` early on > > > https://github.com/openjdk/jdk/blob/f2d2eef988c57cc9f6194a8fd5b2b422035ee68f/src/hotspot/share/opto/superword.cpp#L2646-L2650 > > > > > > the entire propagation chain tends to use `T_SHORT` as well. > > > This applies to most operations, with the exception of a few like `RShiftI`, `Abs`, and `ReverseBytesI`, which are handled separately. > > > So your change already benefits many char-related vectorization cases like `convertDoubleToChar` above. That?s why we can safely relax the IR condition mentioned earlier. > > > > > > Thanks for your input! It's really helpful to me. Does this mean it always use `T_SHORT` for char vectors in SLP? If so, it's safe that we do not need to consider `T_CHAR` in vector IRs in backend? > > No, we don't always use `T_SHORT` for char vectors. As mentioned earlier, for operations like `RShiftI`, `Abs`, and `ReverseBytesI`, the compiler needs to preserve the higher-order bits of the first operand. Therefore, SuperWord still needs to assign them precise subword types. See: > > https://github.com/openjdk/jdk/blob/f2d2eef988c57cc9f6194a8fd5b2b422035ee68f/src/hotspot/share/opto/superword.cpp#L2583-L2589 Yes, I see. Thanks! What I mean is for cases that SLP will use the subword types, it will be actually `T_SHORT` for `T_CHAR` then? ------------- PR Comment: https://git.openjdk.org/jdk/pull/26057#issuecomment-3047998283 From xgong at openjdk.org Tue Jul 8 09:09:43 2025 From: xgong at openjdk.org (Xiaohong Gong) Date: Tue, 8 Jul 2025 09:09:43 GMT Subject: RFR: 8359419: AArch64: Relax min vector length to 32-bit for short vectors [v3] In-Reply-To: References: <7VTRz_XqYBSdQ54n7ADzTzYADZjDbgBw6XuW0jehSLI=.24d18b87-4553-47ab-8065-d92fbb5700ae@github.com> <5H0NP8vFqCDf1JgHIDee3WrYRbJ6koj5wQsxEGTW8nI=.87d74c6a-54b3-45cc-a972-c4350d5e2acf@github.com> <0XcbEZkrW7fvJhPwQPP1UtT9aC3_OnT7sjoiHo0fOuQ=.1ec5ae91-55cb-4d8b-9e91-44ec02e63747@github.com> <0vdCJFYxCI6hFnTL6rm3oKQcPuuIR2EbuyAOa0muqcw=.d5c249cb-9bf0-415d-ab22-de7387d8d8d1@github.com> Message-ID: <1bwEx4HAqqmfw9DrslwrZH1cYfIKi-5p9AgelJrIB94=.f46dd942-2102-4fd3-adfd-7f7ec3c3dbc0@github.com> On Tue, 8 Jul 2025 09:00:53 GMT, Xiaohong Gong wrote: >>> > > > https://github.com/openjdk/jdk/blob/f2d2eef988c57cc9f6194a8fd5b2b422035ee68f/test/hotspot/jtreg/compiler/vectorization/runner/ArrayTypeConvertTest.java#L388-L392 >>> > > >>> > > >>> > > Actually I didn't change the min vector size for `char` vectors in this patch. Relaxing `short` vectors to 32-bit is to support the vector cast for Vector API, and there is no `char` species in it. Do you think it's better to do the same change for `char` as well? This will just benefit auto-vectorization. >>> > >>> > >>> > Hi @XiaohongGong thanks for asking. In many auto-vectorization cases involving `char`, the vector elements are represented using `T_SHORT` as the `BasicType`, rather than `T_CHAR`. >>> > This is because, in Java, operands of subword types are always promoted to `int` before any arithmetic operation. As a result, when handling a node like `ConvD2I`, we don?t initially know its actual subword type. Later, the SuperWord phase propagates a narrowed integer type backward to help determine the correct subword type. See: >>> > https://github.com/openjdk/jdk/blob/f2d2eef988c57cc9f6194a8fd5b2b422035ee68f/src/hotspot/share/opto/superword.cpp#L2551-L2558 >>> > >>> > Since SuperWord assigns `T_SHORT` to `StoreC` early on >>> > https://github.com/openjdk/jdk/blob/f2d2eef988c57cc9f6194a8fd5b2b422035ee68f/src/hotspot/share/opto/superword.cpp#L2646-L2650 >>> > >>> > the entire propagation chain tends to use `T_SHORT` as well. >>> > This applies to most operations, with the exception of a few like `RShiftI`, `Abs`, and `ReverseBytesI`, which are handled separately. >>> > So your change already benefits many char-related vectorization cases like `convertDoubleToChar` above. That?s why we can safely relax the IR condition mentioned earlier. >>> >>> Thanks for your input! It's really helpful to me. Does this mean it always use `T_SHORT` for char vectors in SLP? If so, it's safe that we do not need to consider `T_CHAR` in vector IRs in backend? >> >> No, we don't always use `T_SHORT` for char vectors. As mentioned earlier, for operations like `RShiftI`, `Abs`, and `ReverseBytesI`, the compiler needs to preserve the higher-order bits of the first operand. Therefore, SuperWord still needs to assign them precise subword types. See: >> https://github.com/openjdk/jdk/blob/f2d2eef988c57cc9f6194a8fd5b2b422035ee68f/src/hotspot/share/opto/superword.cpp#L2583-L2589 > >> > > > > https://github.com/openjdk/jdk/blob/f2d2eef988c57cc9f6194a8fd5b2b422035ee68f/test/hotspot/jtreg/compiler/vectorization/runner/ArrayTypeConvertTest.java#L388-L392 >> > > > >> > > > >> > > > Actually I didn't change the min vector size for `char` vectors in this patch. Relaxing `short` vectors to 32-bit is to support the vector cast for Vector API, and there is no `char` species in it. Do you think it's better to do the same change for `char` as well? This will just benefit auto-vectorization. >> > > >> > > >> > > Hi @XiaohongGong thanks for asking. In many auto-vectorization cases involving `char`, the vector elements are represented using `T_SHORT` as the `BasicType`, rather than `T_CHAR`. >> > > This is because, in Java, operands of subword types are always promoted to `int` before any arithmetic operation. As a result, when handling a node like `ConvD2I`, we don?t initially know its actual subword type. Later, the SuperWord phase propagates a narrowed integer type backward to help determine the correct subword type. See: >> > > https://github.com/openjdk/jdk/blob/f2d2eef988c57cc9f6194a8fd5b2b422035ee68f/src/hotspot/share/opto/superword.cpp#L2551-L2558 >> > > >> > > Since SuperWord assigns `T_SHORT` to `StoreC` early on >> > > https://github.com/openjdk/jdk/blob/f2d2eef988c57cc9f6194a8fd5b2b422035ee68f/src/hotspot/share/opto/superword.cpp#L2646-L2650 >> > > >> > > the entire propagation chain tends to use `T_SHORT` as well. >> > > This applies to most operations, with the exception of a few like `RShiftI`, `Abs`, and `ReverseBytesI`, which are handled separately. >> > > So your change already benefits many char-related vectorization cases like `convertDoubleToChar` above. That?s why we can safely relax the IR condition mentioned earlier. >> > >> > >> > Thanks for your input! It's really helpful to me. Does this mean it always use `T_SHORT` for char vectors in SLP? If so, it's safe that we do not need to consider `T_CHAR` in vector IRs in backend? >> >> No, we don't always use `T_SHORT` for char vectors. As mentioned earlier, for operations like `RShiftI`, `Abs`, and `ReverseBytesI`, the compiler needs to preserve the higher-order bits of the first operand. Therefore, SuperWord still needs to assign them precise subword types. See: >> >> https://github.com/openjdk/jdk/blob/f2d2eef988c57cc9f6194a8fd5b2b422035ee68f/src/hotspot/share/opto/superword.cpp#L2583-L2589 > > Yes, I see. Thanks! What I mean is for cases that SLP will use the subword types, it will be actu... > > > Hi @XiaohongGong, is there any way we can implement 2HF -> 2S and 2S -> 2HF in these match rules ? > > > https://github.com/openjdk/jdk/blob/f2d2eef988c57cc9f6194a8fd5b2b422035ee68f/src/hotspot/cpu/aarch64/aarch64_vector.ad#L4697 > > > > > > https://github.com/openjdk/jdk/blob/f2d2eef988c57cc9f6194a8fd5b2b422035ee68f/src/hotspot/cpu/aarch64/aarch64_vector.ad#L4679 > > > > > > The `fcvtn` and `fcvtl` instructions do not support these arrangements. I was wondering if there is any other way we can implement these by any chance? > > > > > > Do you mean `2HF -> 2F` and `2F -> 2HF` ? > > Yes, it does not support the 32-bit arrangements. Vector conversion is a kind of lanewise vector operation. For such cases, we usually use the same arrangements with 64-bit vector size for 32-bit ones. That means we can reuse the `T4H` and `T4S` to implement it. Hence, current match rules can cover the conversions between `2HF` and `2F`. > > Consider there is no such conversion cases in Vector API, I didn't change the comment in the match rules. I think this may benefit auto-vectorization. Currently, do we have cases that can match these rules with SLP? > > Sorry yes I meant 2HF <-> 2F. Yes, currently there are no such cases in VectorAPI as we do not support Float16 Vectors yet but this will benefit autovectorization cases. I think in this case this may also benefit 2D <-> 2HF as well (eventually we might add support for D <-> HF as well). Yes we have some JTREG tests that match these rules currently like - `test/hotspot/jtreg/compiler/vectorization/TestFloat16VectorConvChain.java`, `test/hotspot/jtreg/compiler/vectorization/TestFloatConversionsVector.java`. Thanks! So per my understanding, things that I just need is updating comment (e.g. `// 4HF to 4F`) of rules like `vcvtHFtoF`, right? For conversions between double and HF, we do not need any new rules as it will be actually `double -> float -> HF`, right? ------------- PR Comment: https://git.openjdk.org/jdk/pull/26057#issuecomment-3048019109 From aph at openjdk.org Tue Jul 8 09:15:43 2025 From: aph at openjdk.org (Andrew Haley) Date: Tue, 8 Jul 2025 09:15:43 GMT Subject: RFR: 8361497: Scoped Values: orElse and orElseThrow do not access the cache In-Reply-To: <-wBBj6wgMQayipWS3L3-L5ItuUX0OeHcjQR22tci3pg=.a340f85a-683b-40e5-9cec-afa62efe11fb@github.com> References: <-wBBj6wgMQayipWS3L3-L5ItuUX0OeHcjQR22tci3pg=.a340f85a-683b-40e5-9cec-afa62efe11fb@github.com> Message-ID: On Mon, 7 Jul 2025 16:33:22 GMT, Chen Liang wrote: > Can `get` and `slowGet` be refactored to use this `findBinding` too? Not really, no. Inlining is critical here, and `get()` is written in this way for efficiency of generated code. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26164#issuecomment-3048039047 From viktor.klang at oracle.com Tue Jul 8 09:34:26 2025 From: viktor.klang at oracle.com (Viktor Klang) Date: Tue, 8 Jul 2025 09:34:26 +0000 Subject: [External] : Re: Question about mapConcurrent() Behavior and Happens-Before Guarantees In-Reply-To: References: Message-ID: >I understand that explicit API contracts are what matters. My concern, however, is that even if the API contract explicitly states no happens-before guarantee upon an unchecked exception, this behavior would still be a significant deviation from established visibility standards in other JDK APIs. Would you mind clariying exactly what you mean here?what happens-before completion/exception? Cheers, ? Viktor Klang Software Architect, Java Platform Group Oracle ________________________________ From: Jige Yu Sent: Tuesday, 8 July 2025 04:26 To: Viktor Klang Cc: core-libs-dev at openjdk.org Subject: [External] : Re: Question about mapConcurrent() Behavior and Happens-Before Guarantees Thanks for the quick reply, Viktor! On Mon, Jul 7, 2025 at 2:35?AM Viktor Klang > wrote: Hi Jige, >Initially, I thought this design choice might provide a strong happens-before guarantee. My assumption was that an application catching a RuntimeException would be able to observe all side effects from the virtual threads, even though this practice is generally discouraged. This seemed like a potentially significant advantage, outweighing the risk of a virtual thread failing to respond to interruption or responding slowly. Unless explicitly stated in the API contract, no such guarantees should be presumed to exist. I understand that explicit API contracts are what matters. My concern, however, is that even if the API contract explicitly states no happens-before guarantee upon an unchecked exception, this behavior would still be a significant deviation from established visibility standards in other JDK APIs. For instance, both parallel streams and Future.get() provide a happens-before guarantee upon completion (or exceptional completion in the case of Future.get()). So users will most likely take it for granted. If mapConcurrent() were to not offer this, it would potentially be the first blocking JDK API that doesn't honor happens-before in such a scenario. This inconsistency would likely be surprising and potentially confusing to users who have come to expect this behavior in concurrent programming constructs within the JDK. As for general resource-management in Stream, I have contemplated designs for Gatherer (and Collector) to be able to participate in the onClose actions, but there's a lot of ground to cover to ensure correct ordering and sufficiently-encompassing of cleanup action execution. Yeah. I agree that hooking into onClose() could provide a more reliable mechanism for cleanup. My primary concern though, is the change it imposes on the call-site contract. Requiring all users of mapConcurrent() to adopt a try-with-resources syntax, while ideal for correctness, introduces a burden and is more subject to users forgetting to do so, potentially leading to resource leaks. My previously proposed collectingAndThen(toList(), list -> list.stream().gather(mapConcurrent())) idea, on the other hand, avoids this call-site contract change. Being a collector, it needs to first consume the input, similar to how most Collectors operate. So it might be a less intrusive path to ensure proper resource handling without altering usage patterns. Cheers, ? Viktor Klang Software Architect, Java Platform Group Oracle ________________________________ From: core-libs-dev > on behalf of Jige Yu > Sent: Thursday, 3 July 2025 16:36 To: core-libs-dev at openjdk.org > Subject: Question about mapConcurrent() Behavior and Happens-Before Guarantees Hi JDK Core Devs, I'm writing to you today with a question about the behavior of mapConcurrent() and its interaction with unchecked exceptions. I've been experimenting with the API and observed that mapConcurrent() blocks and joins all virtual threads upon an unchecked exception before propagating it. Initially, I thought this design choice might provide a strong happens-before guarantee. My assumption was that an application catching a RuntimeException would be able to observe all side effects from the virtual threads, even though this practice is generally discouraged. This seemed like a potentially significant advantage, outweighing the risk of a virtual thread failing to respond to interruption or responding slowly. However, I've since realized that mapConcurrent() cannot fully guarantee a strong happens-before relationship when an unchecked exception occurs somewhere in the stream pipeline. While it can block and wait for exceptions thrown by the mapper function or downstream operations, it appears unable to intercept unchecked exceptions thrown by an upstream source. Consider a scenario with two input elements: if the first element starts a virtual thread, and then the second element causes an unchecked exception from the upstream before reaching the gather() call, the virtual thread initiated by the first element would not be interrupted. This makes the "happens-before" guarantee quite nuanced in practice. This brings me to my core questions: 1. Is providing a happens-before guarantee upon an unchecked exception a design goal for mapConcurrent()? 2. If not, would it be more desirable to not join on virtual threads when unchecked exceptions occur? This would allow the application code to catch the exception sooner and avoid the risk of being blocked indefinitely. Thank you for your time and insights. Best regards, Ben Yu -------------- next part -------------- An HTML attachment was scrubbed... URL: From duke at openjdk.org Tue Jul 8 09:51:45 2025 From: duke at openjdk.org (erifan) Date: Tue, 8 Jul 2025 09:51:45 GMT Subject: RFR: 8354242: VectorAPI: combine vector not operation with compare [v9] In-Reply-To: References: Message-ID: On Tue, 8 Jul 2025 08:56:44 GMT, Emanuel Peter wrote: > predicate cannot be negated AND the vector is all ones. Can you explain this condition? Ok, I'll add a comment for it. > Why do you guard against VectorNode::is_all_ones_vector(in2) at all? Because one of the nodes in the supported patterns by this PR needs to be `MaskAll` or `Replicate`. And this function `VectorNode::is_all_ones_vector` just meets our check for `MaskAll` and `Replicate`. Actually I don't quite understand your question. I have two understandings: 1. Not all nodes that `VectorNode::is_all_ones_vector` returns true are `MaskAll` or `Replicate`, but other nodes that do not meet the conditions. 2. Here, it does not need to be a vector with every bit 1, it only needs to be an `all true` mask. Which one do you mean? Or something else? Thanks~ ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24674#discussion_r2192019309 From duke at openjdk.org Tue Jul 8 10:23:43 2025 From: duke at openjdk.org (erifan) Date: Tue, 8 Jul 2025 10:23:43 GMT Subject: RFR: 8354242: VectorAPI: combine vector not operation with compare [v9] In-Reply-To: References: Message-ID: On Tue, 8 Jul 2025 09:49:30 GMT, erifan wrote: >> Thanks for your answers @erifan ! >> >> Can you please answer these as well? >> >>> predicate cannot be negated AND the vector is all ones. Can you explain this condition? >> >> A code comment would be helpful for this case. I'm a little bit struggling to understand the bracket/negation here. >> >>> Why do you guard against VectorNode::is_all_ones_vector(in2) at all? >> >> Is this necessary? Why? > >> predicate cannot be negated AND the vector is all ones. Can you explain this condition? > > Ok, I'll add a comment for it. > >> Why do you guard against VectorNode::is_all_ones_vector(in2) at all? > > Because one of the nodes in the supported patterns by this PR needs to be `MaskAll` or `Replicate`. And this function `VectorNode::is_all_ones_vector` just meets our check for `MaskAll` and `Replicate`. Actually I don't quite understand your question. I have two understandings: > 1. Not all nodes that `VectorNode::is_all_ones_vector` returns true are `MaskAll` or `Replicate`, but other nodes that do not meet the conditions. > 2. Here, it does not need to be a vector with every bit 1, it only needs to be an `all true` mask. > > Which one do you mean? Or something else? Thanks~ The purpose of this PR is optimizing the following kinds of patterns: XXXVector va, vb; va.compare(EQ, vb).not() And the generated IR of `va.compare(EQ, vb).not()` is `(XorVMask (VectorMaskCmp va vb EQ) (MaskAll -1))`. On platforms like aarch64 NEON, `MaskAll` is `Replicate`. And `MaskAll` and `Replicate` are both all ones vectors, so we do this check `VectorNode::is_all_ones_vector(in2)` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24674#discussion_r2192087590 From fgao at openjdk.org Tue Jul 8 10:36:50 2025 From: fgao at openjdk.org (Fei Gao) Date: Tue, 8 Jul 2025 10:36:50 GMT Subject: RFR: 8359419: AArch64: Relax min vector length to 32-bit for short vectors [v3] In-Reply-To: References: <7VTRz_XqYBSdQ54n7ADzTzYADZjDbgBw6XuW0jehSLI=.24d18b87-4553-47ab-8065-d92fbb5700ae@github.com> <5H0NP8vFqCDf1JgHIDee3WrYRbJ6koj5wQsxEGTW8nI=.87d74c6a-54b3-45cc-a972-c4350d5e2acf@github.com> <0XcbEZkrW7fvJhPwQPP1UtT9aC3_OnT7sjoiHo0fOuQ=.1ec5ae91-55cb-4d8b-9e91-44ec02e63747@github.com> <0vdCJFYxCI6hFnTL6rm3oKQcPuuIR2EbuyAOa0muqcw=.d5c249cb-9bf0-415d-ab22-de7387d8d8d1@github.com> Message-ID: On Tue, 8 Jul 2025 09:00:53 GMT, Xiaohong Gong wrote: > > > > > > https://github.com/openjdk/jdk/blob/f2d2eef988c57cc9f6194a8fd5b2b422035ee68f/test/hotspot/jtreg/compiler/vectorization/runner/ArrayTypeConvertTest.java#L388-L392 > > > > > > > > > > > > > > > Actually I didn't change the min vector size for `char` vectors in this patch. Relaxing `short` vectors to 32-bit is to support the vector cast for Vector API, and there is no `char` species in it. Do you think it's better to do the same change for `char` as well? This will just benefit auto-vectorization. > > > > > > > > > > > > Hi @XiaohongGong thanks for asking. In many auto-vectorization cases involving `char`, the vector elements are represented using `T_SHORT` as the `BasicType`, rather than `T_CHAR`. > > > > This is because, in Java, operands of subword types are always promoted to `int` before any arithmetic operation. As a result, when handling a node like `ConvD2I`, we don?t initially know its actual subword type. Later, the SuperWord phase propagates a narrowed integer type backward to help determine the correct subword type. See: > > > > https://github.com/openjdk/jdk/blob/f2d2eef988c57cc9f6194a8fd5b2b422035ee68f/src/hotspot/share/opto/superword.cpp#L2551-L2558 > > > > > > > > Since SuperWord assigns `T_SHORT` to `StoreC` early on > > > > https://github.com/openjdk/jdk/blob/f2d2eef988c57cc9f6194a8fd5b2b422035ee68f/src/hotspot/share/opto/superword.cpp#L2646-L2650 > > > > > > > > the entire propagation chain tends to use `T_SHORT` as well. > > > > This applies to most operations, with the exception of a few like `RShiftI`, `Abs`, and `ReverseBytesI`, which are handled separately. > > > > So your change already benefits many char-related vectorization cases like `convertDoubleToChar` above. That?s why we can safely relax the IR condition mentioned earlier. > > > > > > > > > Thanks for your input! It's really helpful to me. Does this mean it always use `T_SHORT` for char vectors in SLP? If so, it's safe that we do not need to consider `T_CHAR` in vector IRs in backend? > > > > > > No, we don't always use `T_SHORT` for char vectors. As mentioned earlier, for operations like `RShiftI`, `Abs`, and `ReverseBytesI`, the compiler needs to preserve the higher-order bits of the first operand. Therefore, SuperWord still needs to assign them precise subword types. See: > > https://github.com/openjdk/jdk/blob/f2d2eef988c57cc9f6194a8fd5b2b422035ee68f/src/hotspot/share/opto/superword.cpp#L2583-L2589 > > Yes, I see. Thanks! What I mean is for cases that SLP will use the subword types, it will be actually `T_SHORT` for `T_CHAR` then? >From my side, the cases where SLP uses subword types can be roughly categorized into two groups: 1. Cases where the compiler doesn?t need to preserve the higher-order bits ? in these, SuperWord will use `T_SHORT` instead of `T_CHAR`. 2. Cases where the compiler does need to preserve the higher-order bits, like `RShiftI`, `Abs`, and `ReverseBytesI` ? in these, `T_CHAR` is still used. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26057#issuecomment-3048334299 From bkilambi at openjdk.org Tue Jul 8 10:57:40 2025 From: bkilambi at openjdk.org (Bhavana Kilambi) Date: Tue, 8 Jul 2025 10:57:40 GMT Subject: RFR: 8359419: AArch64: Relax min vector length to 32-bit for short vectors [v3] In-Reply-To: <1bwEx4HAqqmfw9DrslwrZH1cYfIKi-5p9AgelJrIB94=.f46dd942-2102-4fd3-adfd-7f7ec3c3dbc0@github.com> References: <7VTRz_XqYBSdQ54n7ADzTzYADZjDbgBw6XuW0jehSLI=.24d18b87-4553-47ab-8065-d92fbb5700ae@github.com> <5H0NP8vFqCDf1JgHIDee3WrYRbJ6koj5wQsxEGTW8nI=.87d74c6a-54b3-45cc-a972-c4350d5e2acf@github.com> <0XcbEZkrW7fvJhPwQPP1UtT9aC3_OnT7sjoiHo0fOuQ=.1ec5ae91-55cb-4d8b-9e91-44ec02e63747@github.com> <0vdCJFYxCI6hFnTL6rm3oKQcPuuIR2EbuyAOa0muqcw=.d5c249cb-9bf0-415d-ab22-de7387d8d8d1@github.com> <1bwEx4HAqqmfw9DrslwrZH1cYfIKi-5p9AgelJrIB94=.f46dd942-2102-4fd3-adfd-7f7ec3c3dbc0@github.com> Message-ID: On Tue, 8 Jul 2025 09:07:00 GMT, Xiaohong Gong wrote: > > > > Hi @XiaohongGong, is there any way we can implement 2HF -> 2S and 2S -> 2HF in these match rules ? > > > > https://github.com/openjdk/jdk/blob/f2d2eef988c57cc9f6194a8fd5b2b422035ee68f/src/hotspot/cpu/aarch64/aarch64_vector.ad#L4697 > > > > > > > > https://github.com/openjdk/jdk/blob/f2d2eef988c57cc9f6194a8fd5b2b422035ee68f/src/hotspot/cpu/aarch64/aarch64_vector.ad#L4679 > > > > > > > > The `fcvtn` and `fcvtl` instructions do not support these arrangements. I was wondering if there is any other way we can implement these by any chance? > > > > > > > > > Do you mean `2HF -> 2F` and `2F -> 2HF` ? > > > Yes, it does not support the 32-bit arrangements. Vector conversion is a kind of lanewise vector operation. For such cases, we usually use the same arrangements with 64-bit vector size for 32-bit ones. That means we can reuse the `T4H` and `T4S` to implement it. Hence, current match rules can cover the conversions between `2HF` and `2F`. > > > Consider there is no such conversion cases in Vector API, I didn't change the comment in the match rules. I think this may benefit auto-vectorization. Currently, do we have cases that can match these rules with SLP? > > > > > > Sorry yes I meant 2HF <-> 2F. Yes, currently there are no such cases in VectorAPI as we do not support Float16 Vectors yet but this will benefit autovectorization cases. I think in this case this may also benefit 2D <-> 2HF as well (eventually we might add support for D <-> HF as well). Yes we have some JTREG tests that match these rules currently like - `test/hotspot/jtreg/compiler/vectorization/TestFloat16VectorConvChain.java`, `test/hotspot/jtreg/compiler/vectorization/TestFloatConversionsVector.java`. > > Thanks! So per my understanding, things that I just need is updating comment (e.g. `// 4HF to 4F`) of rules like `vcvtHFtoF`, right? For conversions between double and HF, we do not need any new rules as it will be actually `double -> float -> HF`, right? Yes please and also for `4F to 4HF` case for `vcvtF2HF`. Thanks! As for the double to half float conversion - yes with the current infrastructure it would be ConvD2F -> ConvF2HF which will be autovectorized to generate corresponding vector nodes. Sooner or later, support for ConvD2HF (and its vectorized version) might be added upstream (support already available in `lworld+fp16` branch of Valhalla here - https://github.com/openjdk/valhalla/blob/0ed65b9a63405e950c411835120f0f36e326aaaa/src/hotspot/cpu/aarch64/aarch64_vector.ad#L4535). You do not have to add any new rules now for this case. I was just hinting at possible D<->HF implementation in the future. As the max vector length was 64bits, I did not add any implementation for Neon vcvtD2HF or vcvtHF2D in Valhalla. Maybe we can do two `fcvtl/fcvtn` to convert D to F and then F to HF for this specific case but we can think about that later :) ------------- PR Comment: https://git.openjdk.org/jdk/pull/26057#issuecomment-3048404345 From kbarrett at openjdk.org Tue Jul 8 11:26:39 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 8 Jul 2025 11:26:39 GMT Subject: RFR: 8361426: (ref) Remove jdk.internal.ref.Cleaner In-Reply-To: References: Message-ID: On Tue, 8 Jul 2025 04:59:04 GMT, Jaikiran Pai wrote: >> Please review this change that removes the class jdk.internal.ref.Cleaner. >> It is no longer used after JDK-8344332. >> >> Testing: mach5 tier1-3 > > This looks OK to me and matches with what was discussed about this in a recent PR https://github.com/openjdk/jdk/pull/25289#discussion_r2172727041. > > It would be good to get another review for this before integrating. @jaikiran requested another reviewer, so ------------- PR Comment: https://git.openjdk.org/jdk/pull/26141#issuecomment-3048506399 From jwaters at openjdk.org Tue Jul 8 11:30:53 2025 From: jwaters at openjdk.org (Julian Waters) Date: Tue, 8 Jul 2025 11:30:53 GMT Subject: RFR: 8342868: Errors related to unused code on Windows after 8339120 in core libs [v2] In-Reply-To: References: Message-ID: On Tue, 8 Jul 2025 04:20:32 GMT, Jaikiran Pai wrote: > > Since your change was applied there have been 3762 commits pushed to the master branch > > It's usually risky to be integrating a PR which is so far behind the master branch, without first merging the latest changes and running the tier tests. In this case it hasn't caused any failures in the tier testing so far. I'll keep that in mind next time I'm submitting another Pull Request. Fortunately in this case the code touched was dead code and in an area that isn't touched often, so shouldn't cause major issues ------------- PR Comment: https://git.openjdk.org/jdk/pull/21654#issuecomment-3048519346 From jwaters at openjdk.org Tue Jul 8 11:36:01 2025 From: jwaters at openjdk.org (Julian Waters) Date: Tue, 8 Jul 2025 11:36:01 GMT Subject: RFR: 8342868: Errors related to unused code on Windows after 8339120 in core libs [v2] In-Reply-To: References: Message-ID: On Tue, 8 Jul 2025 01:49:14 GMT, David Holmes wrote: >> Sorry for waiting so long. It's become clear that I won't be able to get awt and accessibility up to speed for a long time, so I will go ahead with this one first > > @TheShermanTanker the commented out code really should have been deleted, not just left commented out. Please file anpther JBS issue to have this cleaned up so it is not forgotten. Thanks. @dholmes-ora Sorry about that. Here's the issue as was requested: https://bugs.openjdk.org/browse/JDK-8361593 ------------- PR Comment: https://git.openjdk.org/jdk/pull/21654#issuecomment-3048532200 From epeter at openjdk.org Tue Jul 8 11:45:51 2025 From: epeter at openjdk.org (Emanuel Peter) Date: Tue, 8 Jul 2025 11:45:51 GMT Subject: RFR: 8354242: VectorAPI: combine vector not operation with compare [v10] In-Reply-To: References: Message-ID: On Tue, 8 Jul 2025 06:00:38 GMT, erifan wrote: >> This patch optimizes the following patterns: >> For integer types: >> >> (XorV (VectorMaskCmp src1 src2 cond) (Replicate -1)) >> => (VectorMaskCmp src1 src2 ncond) >> (XorVMask (VectorMaskCmp src1 src2 cond) (MaskAll m1)) >> => (VectorMaskCmp src1 src2 ncond) >> >> cond can be eq, ne, le, ge, lt, gt, ule, uge, ult and ugt, ncond is the negative comparison of cond. >> >> For float and double types: >> >> (XorV (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (Replicate -1)) >> => (VectorMaskCast (VectorMaskCmp src1 src2 ncond)) >> (XorVMask (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (MaskAll m1)) >> => (VectorMaskCast (VectorMaskCmp src1 src2 ncond)) >> >> cond can be eq or ne. >> >> Benchmarks on Nvidia Grace machine with 128-bit SVE2: With option `-XX:UseSVE=2`: >> >> Benchmark Unit Before Score Error After Score Error Uplift >> testCompareEQMaskNotByte ops/s 7912127.225 2677.289518 10266136.26 8955.008548 1.29 >> testCompareEQMaskNotDouble ops/s 884737.6799 446.963779 1179760.772 448.031844 1.33 >> testCompareEQMaskNotFloat ops/s 1765045.787 682.332214 2359520.803 896.305743 1.33 >> testCompareEQMaskNotInt ops/s 1787221.411 977.743935 2353952.519 960.069976 1.31 >> testCompareEQMaskNotLong ops/s 895297.1974 673.44808 1178449.02 323.804205 1.31 >> testCompareEQMaskNotShort ops/s 3339987.002 3415.2226 4712761.965 2110.862053 1.41 >> testCompareGEMaskNotByte ops/s 7907615.16 4094.243652 10251646.9 9486.699831 1.29 >> testCompareGEMaskNotInt ops/s 1683738.958 4233.813092 2352855.205 1251.952546 1.39 >> testCompareGEMaskNotLong ops/s 854496.1561 8594.598885 1177811.493 521.1229 1.37 >> testCompareGEMaskNotShort ops/s 3341860.309 1578.975338 4714008.434 1681.10365 1.41 >> testCompareGTMaskNotByte ops/s 7910823.674 2993.367032 10245063.58 9774.75138 1.29 >> testCompareGTMaskNotInt ops/s 1673393.928 3153.099431 2353654.521 1190.848583 1.4 >> testCompareGTMaskNotLong ops/s 849405.9159 2432.858159 1177952.041 359.96413 1.38 >> testCompareGTMaskNotShort ops/s 3339509.141 3339.976585 4711442.496 2673.364893 1.41 >> testCompareLEMaskNotByte ops/s 7911340.004 3114.69191 10231626.5 27134.20035 1.29 >> testCompareLEMaskNotInt ops/s 1675812.113 1340.969885 2353255.341 1452.4522 1.4 >> testCompareLEMaskNotLong ops/s 848862.8036 6564.841731 1177763.623 539.290106 1.38 >> testCompareLEMaskNotShort ops/s 3324951.54 2380.29473 4712116.251 1544.559684 1.41 >> testCompareLTMaskNotByte ops/s 7910390.844 2630.861436 10239567.69 6487.441672 1.29 >> testCompareLTMaskNotInt ops/s 16721... > > erifan has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 17 additional commits since the last revision: > > - Align indentation > - Merge branch 'master' into JDK-8354242 > - Address more comments > > ATT. > - Merge branch 'master' into JDK-8354242 > - Support negating unsigned comparison for BoolTest::mask > > Added a static method `negate_mask(mask btm)` into BoolTest class to > negate both signed and unsigned comparison. > - Addressed some review comments > - Merge branch 'master' into JDK-8354242 > - Refactor the JTReg tests for compare.xor(maskAll) > > Also made a bit change to support pattern `VectorMask.fromLong()`. > - Merge branch 'master' into JDK-8354242 > - Refactor code > > Add a new function XorVNode::Ideal_XorV_VectorMaskCmp to do this > optimization, making the code more modular. > - ... and 7 more: https://git.openjdk.org/jdk/compare/f1740382...db78dc43 src/hotspot/share/opto/vectornode.cpp line 2241: > 2239: in1->outcnt() != 1 || > 2240: !(in1->as_VectorMaskCmp())->predicate_can_be_negated() || > 2241: !VectorNode::is_all_ones_vector(in2)) { Suggestion: !in1->as_VectorMaskCmp()->predicate_can_be_negated() || !VectorNode::is_all_ones_vector(in2)) { Remove the indentation again, and the superfluous brackets too ;) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24674#discussion_r2192263236 From epeter at openjdk.org Tue Jul 8 11:45:52 2025 From: epeter at openjdk.org (Emanuel Peter) Date: Tue, 8 Jul 2025 11:45:52 GMT Subject: RFR: 8354242: VectorAPI: combine vector not operation with compare [v9] In-Reply-To: References: Message-ID: On Tue, 8 Jul 2025 10:21:03 GMT, erifan wrote: >>> predicate cannot be negated AND the vector is all ones. Can you explain this condition? >> >> Ok, I'll add a comment for it. >> >>> Why do you guard against VectorNode::is_all_ones_vector(in2) at all? >> >> Because one of the nodes in the supported patterns by this PR needs to be `MaskAll` or `Replicate`. And this function `VectorNode::is_all_ones_vector` just meets our check for `MaskAll` and `Replicate`. Actually I don't quite understand your question. I have two understandings: >> 1. Not all nodes that `VectorNode::is_all_ones_vector` returns true are `MaskAll` or `Replicate`, but other nodes that do not meet the conditions. >> 2. Here, it does not need to be a vector with every bit 1, it only needs to be an `all true` mask. >> >> Which one do you mean? Or something else? Thanks~ > > The purpose of this PR is optimizing the following kinds of patterns: > > XXXVector va, vb; > va.compare(EQ, vb).not() > > And the generated IR of `va.compare(EQ, vb).not()` is `(XorVMask (VectorMaskCmp va vb EQ) (MaskAll -1))`. On platforms like aarch64 NEON, `MaskAll` is `Replicate`. And `MaskAll` and `Replicate` are both all ones vectors, so we do this check `VectorNode::is_all_ones_vector(in2)` Oh wow, my bad. I misunderstood the brackets! Instead of: !(in1->as_VectorMaskCmp())->predicate_can_be_negated() || !VectorNode::is_all_ones_vector(in2)) { I read: !(in1->as_VectorMaskCmp()->predicate_can_be_negated() || !VectorNode::is_all_ones_vector(in2))) { That confused me a lot... absolutely my bad. Well actually then my indentation suggestion was terrible! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24674#discussion_r2192261081 From epeter at openjdk.org Tue Jul 8 11:45:52 2025 From: epeter at openjdk.org (Emanuel Peter) Date: Tue, 8 Jul 2025 11:45:52 GMT Subject: RFR: 8354242: VectorAPI: combine vector not operation with compare [v9] In-Reply-To: References: Message-ID: <2UzxnawLUtlwIr5aaEdTfn4OEMt_z1HTfAaDBHCeZFU=.a70d1360-574a-4ca9-adae-7dec030ed2b7@github.com> On Tue, 8 Jul 2025 11:41:01 GMT, Emanuel Peter wrote: >> The purpose of this PR is optimizing the following kinds of patterns: >> >> XXXVector va, vb; >> va.compare(EQ, vb).not() >> >> And the generated IR of `va.compare(EQ, vb).not()` is `(XorVMask (VectorMaskCmp va vb EQ) (MaskAll -1))`. On platforms like aarch64 NEON, `MaskAll` is `Replicate`. And `MaskAll` and `Replicate` are both all ones vectors, so we do this check `VectorNode::is_all_ones_vector(in2)` > > Oh wow, my bad. I misunderstood the brackets! > > Instead of: > > !(in1->as_VectorMaskCmp())->predicate_can_be_negated() || > !VectorNode::is_all_ones_vector(in2)) { > > I read: > > !(in1->as_VectorMaskCmp()->predicate_can_be_negated() || > !VectorNode::is_all_ones_vector(in2))) { > > That confused me a lot... absolutely my bad. > > Well actually then my indentation suggestion was terrible! I made a new suggestion below. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24674#discussion_r2192263852 From liach at openjdk.org Tue Jul 8 12:13:38 2025 From: liach at openjdk.org (Chen Liang) Date: Tue, 8 Jul 2025 12:13:38 GMT Subject: RFR: 8361497: Scoped Values: orElse and orElseThrow do not access the cache In-Reply-To: References: Message-ID: On Mon, 7 Jul 2025 16:13:08 GMT, Andrew Haley wrote: > Neither `ScopedValue.orElse` nor `ScopedValue.orElseThrow` consult the cache when searching for a binding. Neither do they update the cache when a binding is found. > While this issue does not affect spec compliance, it is surprising to users that `x.orElse(other)` should be slower than `x.isBound ? x.get() : other`. True, we might have to split another copy for orElse if it turns out critical too. Hope future generic specialization may allow separate inlining. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26164#issuecomment-3048671710 From dfuchs at openjdk.org Tue Jul 8 14:04:56 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Tue, 8 Jul 2025 14:04:56 GMT Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API [v11] In-Reply-To: References: Message-ID: <65DK7poRj3Nq1jUsA160afGm-D4M7eT3fSJJovdTGmA=.29c6f258-8972-4fe3-a56f-a4f2abbcbaa6@github.com> > Hi, > > Please find here a PR for the implementation of [JEP 517: HTTP/3 for the HTTP Client API](https://openjdk.org/jeps/517). > > The CSR can be viewed at [JDK-8350588: Implement JEP 517: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588) > > This JEP proposes to enhance the HttpClient implementation to support HTTP/3. > It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider. Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 550 commits: - merge latest changes from master branch - http3: fix new HttpHeadersBuilder constructor - qpack - optimize processing of decoder instruction exceptions - http3/quic: update the code to use the newly introduced jdk.internal.net.http.Origin - Avoid speculating about the future in TODOs - http3: rename PacketSpaceManager::isAcknowledging to PacketSpaceManager::trackAcknowledgement - merge latest changes from master branch - http3: fix typo in UniStreamPair.java - WriterQueue may leak before the constructor completes - Limit the number of retries in H3UserInfoTest - ... and 540 more: https://git.openjdk.org/jdk/compare/7b255b8a...f0a4fd3d ------------- Changes: https://git.openjdk.org/jdk/pull/24751/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24751&range=10 Stats: 105048 lines in 471 files changed: 102218 ins; 1335 del; 1495 mod Patch: https://git.openjdk.org/jdk/pull/24751.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24751/head:pull/24751 PR: https://git.openjdk.org/jdk/pull/24751 From dclarke at openjdk.org Tue Jul 8 14:36:24 2025 From: dclarke at openjdk.org (Darragh Clarke) Date: Tue, 8 Jul 2025 14:36:24 GMT Subject: RFR: 8360025: (se) Convert kqueue Selector Implementation to use FFM APIs Message-ID: This PR aims to Panamize the Java Kqueue implementation, This is based on the work that was previously shared in https://github.com/openjdk/jdk/pull/22307 , The main change since then is that this branch takes advantage of the changes made in https://github.com/openjdk/jdk/pull/25043 to allow for better performance during errno handling. These changes feature a lot of Jextract generated files, though alterations have been made in relation to Errno handling and performance improvements. I will update this description soon to include performance metrics on a few microbenchmarks, though currently it's roughly 2% to 3% slower with the changes, which is somewhat expected, though there are still a few ideas of possible performance improvements that could be tried. Any suggestions or comments in that area are more than welcome however. ------------- Commit messages: - feedback - general cleanup - small refactoring - Performance - implementing feedback - removed unrelated change - merge master into branch - panamization of kqueue Changes: https://git.openjdk.org/jdk/pull/25546/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25546&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8360025 Stats: 1489 lines in 14 files changed: 1306 ins; 121 del; 62 mod Patch: https://git.openjdk.org/jdk/pull/25546.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25546/head:pull/25546 PR: https://git.openjdk.org/jdk/pull/25546 From pminborg at openjdk.org Tue Jul 8 14:36:25 2025 From: pminborg at openjdk.org (Per Minborg) Date: Tue, 8 Jul 2025 14:36:25 GMT Subject: RFR: 8360025: (se) Convert kqueue Selector Implementation to use FFM APIs In-Reply-To: References: Message-ID: <6NSMDqRy9CiytH25pQDGergFr8o7ofTDKe0151cIi3M=.a92d424e-5ee6-4945-9a7d-3a56f8545c7e@github.com> On Fri, 30 May 2025 12:00:28 GMT, Darragh Clarke wrote: > This PR aims to Panamize the Java Kqueue implementation, This is based on the work that was previously shared in https://github.com/openjdk/jdk/pull/22307 , The main change since then is that this branch takes advantage of the changes made in https://github.com/openjdk/jdk/pull/25043 to allow for better performance during errno handling. > > These changes feature a lot of Jextract generated files, though alterations have been made in relation to Errno handling and performance improvements. > > I will update this description soon to include performance metrics on a few microbenchmarks, though currently it's roughly 2% to 3% slower with the changes, which is somewhat expected, though there are still a few ideas of possible performance improvements that could be tried. Any suggestions or comments in that area are more than welcome however. Some of the files are missing a blank line at the end. src/java.base/macosx/classes/jdk/internal/ffi/generated/BindingUtils.java line 45: > 43: public static final AddressLayout C_POINTER = ValueLayout.ADDRESS > 44: .withTargetLayout(MemoryLayout.sequenceLayout(Long.MAX_VALUE, JAVA_BYTE)); > 45: public static final ValueLayout.OfLong C_LONG = ValueLayout.JAVA_LONG; This is `int` on Windows. So, we could perhaps use `Linker.nativeLinker().canonicalLayouts().get("long")` here? "size_t" and "wchar_t" are other canonical layouts that may differ across platforms. src/java.base/macosx/classes/jdk/internal/ffi/generated/kqueue/kqueue_h.java line 260: > 258: * } > 259: */ > 260: public static int kevent64(int kq, MemorySegment changelist, int nchanges, MemorySegment eventlist, int nevents, int flags, MemorySegment timeout) { Is this method ever used? src/java.base/macosx/classes/jdk/internal/ffi/generated/kqueue/kqueue_h.java line 261: > 259: */ > 260: public static int kevent64(int kq, MemorySegment changelist, int nchanges, MemorySegment eventlist, int nevents, int flags, MemorySegment timeout) { > 261: var adapted$ = kevent64.ADAPTED; Why do we do this intermediary step? What is the reason for bringing `kevent64.ADAPTED` on the stack, as it is only used once? I know this is a pattern of jextract's. src/java.base/macosx/classes/jdk/internal/ffi/generated/kqueue/kqueue_h.java line 263: > 261: var adapted$ = kevent64.ADAPTED; > 262: try { > 263: if (FFMUtils.TRACE_DOWNCALLS) { I wonder what the price of this `if` branch might be (if any)? The javac compiler probably sees the `public static final boolean TRACE_DOWNCALLS = false;` as constant foldable and can eliminate the code at compile time. src/java.base/macosx/classes/sun/nio/ch/KQueue.java line 44: > 42: */ > 43: > 44: class KQueue { This class could be `final` src/java.base/macosx/classes/sun/nio/ch/KQueue.java line 63: > 61: > 62: // filters > 63: static final int EVFILT_READ = kqueue_h.EVFILT_READ(); Could we remove these constants and use `kqueue_h` constants directly? src/java.base/macosx/classes/sun/nio/ch/KQueue.java line 121: > 119: kqfd, keventMS, 1, NULL, > 120: 0, NULL); > 121: } while ((result == -1)); Is there a constant for this magic `-1`? src/java.base/macosx/classes/sun/nio/ch/KQueue.java line 147: > 145: nevents, tsp); > 146: if (result < 0) { > 147: if (result == errno_h.EINTR()) { Shouldn't this be `result == -errno_h.EINTR()` instead? ------------- PR Comment: https://git.openjdk.org/jdk/pull/25546#issuecomment-2987207196 PR Review Comment: https://git.openjdk.org/jdk/pull/25546#discussion_r2156432012 PR Review Comment: https://git.openjdk.org/jdk/pull/25546#discussion_r2121817152 PR Review Comment: https://git.openjdk.org/jdk/pull/25546#discussion_r2121808733 PR Review Comment: https://git.openjdk.org/jdk/pull/25546#discussion_r2121802519 PR Review Comment: https://git.openjdk.org/jdk/pull/25546#discussion_r2121817810 PR Review Comment: https://git.openjdk.org/jdk/pull/25546#discussion_r2156409376 PR Review Comment: https://git.openjdk.org/jdk/pull/25546#discussion_r2121812502 PR Review Comment: https://git.openjdk.org/jdk/pull/25546#discussion_r2121782927 From dclarke at openjdk.org Tue Jul 8 14:36:25 2025 From: dclarke at openjdk.org (Darragh Clarke) Date: Tue, 8 Jul 2025 14:36:25 GMT Subject: RFR: 8360025: (se) Convert kqueue Selector Implementation to use FFM APIs In-Reply-To: <6NSMDqRy9CiytH25pQDGergFr8o7ofTDKe0151cIi3M=.a92d424e-5ee6-4945-9a7d-3a56f8545c7e@github.com> References: <6NSMDqRy9CiytH25pQDGergFr8o7ofTDKe0151cIi3M=.a92d424e-5ee6-4945-9a7d-3a56f8545c7e@github.com> Message-ID: On Thu, 19 Jun 2025 08:19:55 GMT, Per Minborg wrote: >> This PR aims to Panamize the Java Kqueue implementation, This is based on the work that was previously shared in https://github.com/openjdk/jdk/pull/22307 , The main change since then is that this branch takes advantage of the changes made in https://github.com/openjdk/jdk/pull/25043 to allow for better performance during errno handling. >> >> These changes feature a lot of Jextract generated files, though alterations have been made in relation to Errno handling and performance improvements. >> >> I will update this description soon to include performance metrics on a few microbenchmarks, though currently it's roughly 2% to 3% slower with the changes, which is somewhat expected, though there are still a few ideas of possible performance improvements that could be tried. Any suggestions or comments in that area are more than welcome however. > > src/java.base/macosx/classes/jdk/internal/ffi/generated/BindingUtils.java line 45: > >> 43: public static final AddressLayout C_POINTER = ValueLayout.ADDRESS >> 44: .withTargetLayout(MemoryLayout.sequenceLayout(Long.MAX_VALUE, JAVA_BYTE)); >> 45: public static final ValueLayout.OfLong C_LONG = ValueLayout.JAVA_LONG; > > This is `int` on Windows. So, we could perhaps use `Linker.nativeLinker().canonicalLayouts().get("long")` here? "size_t" and "wchar_t" are other canonical layouts that may differ across platforms. I think this is a good idea and would allow us to make BindingUtils shared, Though I wonder if it's best to move BindingUtils to be shared, or if its worth merging it into FFMUtils. I'd favour the second option > src/java.base/macosx/classes/jdk/internal/ffi/generated/kqueue/kqueue_h.java line 263: > >> 261: var adapted$ = kevent64.ADAPTED; >> 262: try { >> 263: if (FFMUtils.TRACE_DOWNCALLS) { > > I wonder what the price of this `if` branch might be (if any)? The javac compiler probably sees the > > `public static final boolean TRACE_DOWNCALLS = false;` as constant foldable and can eliminate the code at compile time. I think that's a good question, I can do some testing with it removed to see if theres any gain to be had ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25546#discussion_r2159147090 PR Review Comment: https://git.openjdk.org/jdk/pull/25546#discussion_r2140347487 From alanb at openjdk.org Tue Jul 8 14:36:26 2025 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 8 Jul 2025 14:36:26 GMT Subject: RFR: 8360025: (se) Convert kqueue Selector Implementation to use FFM APIs In-Reply-To: References: Message-ID: On Fri, 30 May 2025 12:00:28 GMT, Darragh Clarke wrote: > This PR aims to Panamize the Java Kqueue implementation, This is based on the work that was previously shared in https://github.com/openjdk/jdk/pull/22307 , The main change since then is that this branch takes advantage of the changes made in https://github.com/openjdk/jdk/pull/25043 to allow for better performance during errno handling. > > These changes feature a lot of Jextract generated files, though alterations have been made in relation to Errno handling and performance improvements. > > I will update this description soon to include performance metrics on a few microbenchmarks, though currently it's roughly 2% to 3% slower with the changes, which is somewhat expected, though there are still a few ideas of possible performance improvements that could be tried. Any suggestions or comments in that area are more than welcome however. src/java.base/macosx/classes/sun/nio/ch/KQueue.java line 124: > 122: kqfd, keventMS, 1, NULL, > 123: 0, NULL); > 124: } while ((result == KQUEUE_ERROR_VALUE)); The only case where the syscall should be restarted is EINTR. src/java.base/macosx/classes/sun/nio/ch/KQueue.java line 152: > 150: return IOStatus.INTERRUPTED; > 151: } else { > 152: throw new IOException("kqueue_poll failed"); The syscall is "kqueue" rather than "kqueue_poll". src/java.base/macosx/classes/sun/nio/ch/KQueuePoller.java line 41: > 39: private final int filter; > 40: private final int maxEvents; > 41: private final MemorySegment pollArrayRegions; This is a poll array so I think very confusing to see "Regions" in the name. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25546#discussion_r2166376862 PR Review Comment: https://git.openjdk.org/jdk/pull/25546#discussion_r2166377830 PR Review Comment: https://git.openjdk.org/jdk/pull/25546#discussion_r2166368230 From liach at openjdk.org Tue Jul 8 14:36:26 2025 From: liach at openjdk.org (Chen Liang) Date: Tue, 8 Jul 2025 14:36:26 GMT Subject: RFR: 8360025: (se) Convert kqueue Selector Implementation to use FFM APIs In-Reply-To: References: Message-ID: On Fri, 30 May 2025 12:00:28 GMT, Darragh Clarke wrote: > This PR aims to Panamize the Java Kqueue implementation, This is based on the work that was previously shared in https://github.com/openjdk/jdk/pull/22307 , The main change since then is that this branch takes advantage of the changes made in https://github.com/openjdk/jdk/pull/25043 to allow for better performance during errno handling. > > These changes feature a lot of Jextract generated files, though alterations have been made in relation to Errno handling and performance improvements. > > I will update this description soon to include performance metrics on a few microbenchmarks, though currently it's roughly 2% to 3% slower with the changes, which is somewhat expected, though there are still a few ideas of possible performance improvements that could be tried. Any suggestions or comments in that area are more than welcome however. src/java.base/share/classes/jdk/internal/ffi/util/FFMUtils.java line 26: > 24: */ > 25: > 26: package jdk.internal.ffi.util; If this is some general ffm utils for using ffm, you can put it in jdk.internal.foreign. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25546#discussion_r2117042413 From pminborg at openjdk.org Tue Jul 8 14:36:26 2025 From: pminborg at openjdk.org (Per Minborg) Date: Tue, 8 Jul 2025 14:36:26 GMT Subject: RFR: 8360025: (se) Convert kqueue Selector Implementation to use FFM APIs In-Reply-To: References: Message-ID: On Sat, 31 May 2025 02:07:40 GMT, Chen Liang wrote: >> This PR aims to Panamize the Java Kqueue implementation, This is based on the work that was previously shared in https://github.com/openjdk/jdk/pull/22307 , The main change since then is that this branch takes advantage of the changes made in https://github.com/openjdk/jdk/pull/25043 to allow for better performance during errno handling. >> >> These changes feature a lot of Jextract generated files, though alterations have been made in relation to Errno handling and performance improvements. >> >> I will update this description soon to include performance metrics on a few microbenchmarks, though currently it's roughly 2% to 3% slower with the changes, which is somewhat expected, though there are still a few ideas of possible performance improvements that could be tried. Any suggestions or comments in that area are more than welcome however. > > src/java.base/share/classes/jdk/internal/ffi/util/FFMUtils.java line 26: > >> 24: */ >> 25: >> 26: package jdk.internal.ffi.util; > > If this is some general ffm utils for using ffm, you can put it in jdk.internal.foreign. These methods are only intended to be used for "panamization" and are not for general use. So, this is the reason we propose to have them here. But maybe some of them might be of general interest? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25546#discussion_r2121790738 From vklang at openjdk.org Tue Jul 8 14:45:41 2025 From: vklang at openjdk.org (Viktor Klang) Date: Tue, 8 Jul 2025 14:45:41 GMT Subject: RFR: 8361426: (ref) Remove jdk.internal.ref.Cleaner In-Reply-To: References: Message-ID: On Sat, 5 Jul 2025 00:05:39 GMT, Kim Barrett wrote: > Please review this change that removes the class jdk.internal.ref.Cleaner. > It is no longer used after JDK-8344332. > > Testing: mach5 tier1-3 Thanks Kim! ------------- Marked as reviewed by vklang (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26141#pullrequestreview-2997977942 From alanb at openjdk.org Tue Jul 8 15:10:41 2025 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 8 Jul 2025 15:10:41 GMT Subject: RFR: 8360025: (se) Convert kqueue Selector Implementation to use FFM APIs In-Reply-To: References: Message-ID: On Fri, 30 May 2025 12:00:28 GMT, Darragh Clarke wrote: > This PR aims to Panamize the Java Kqueue implementation, This is based on the work that was previously shared in https://github.com/openjdk/jdk/pull/22307 , The main change since then is that this branch takes advantage of the changes made in https://github.com/openjdk/jdk/pull/25043 to allow for better performance during errno handling. > > These changes feature a lot of Jextract generated files, though alterations have been made in relation to Errno handling and performance improvements. > > I will update this description soon to include performance metrics on a few microbenchmarks, though currently it's roughly 2% to 3% slower with the changes, which is somewhat expected, though there are still a few ideas of possible performance improvements that could be tried. Any suggestions or comments in that area are more than welcome however. I plan to review this but may be a week or two before I can get to it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25546#issuecomment-3049334858 From nbenalla at openjdk.org Tue Jul 8 15:50:41 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Tue, 8 Jul 2025 15:50:41 GMT Subject: RFR: 8358627: tools/sincechecker/modules/java.base/JavaBaseCheckSince.java fails with JDK 26 In-Reply-To: References: Message-ID: On Tue, 8 Jul 2025 05:18:31 GMT, Jaikiran Pai wrote: >> Once https://bugs.openjdk.org/browse/JDK-8358769 is resolved, JavaBaseCheckSince no longer needs to be problemlisted. > > Hello Nizar, if I understand correctly, this problem listing can be removed and the PR integrated once the merge conflicts are resolved in this PR? @jaikiran Correct, I intended to fix [JDK-8354921](https://bugs.openjdk.org/browse/JDK-8354921) in the same PR but I haven't gotten to fix it yet. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25855#issuecomment-3049466391 From duke at openjdk.org Tue Jul 8 16:35:40 2025 From: duke at openjdk.org (ExE Boss) Date: Tue, 8 Jul 2025 16:35:40 GMT Subject: RFR: 8361526: Synchronize ClassFile API verifier with hotspot In-Reply-To: References: Message-ID: On Mon, 7 Jul 2025 23:21:58 GMT, Chen Liang wrote: > The class file API verifier seems to be based off a version of hotspot verifier before Mar 3 2021. We are thus missing a few patches in the hotspot verifier: > [JDK-8350029](https://bugs.openjdk.org/browse/JDK-8350029) [JDK-8340110](https://bugs.openjdk.org/browse/JDK-8340110) [JDK-8330606](https://bugs.openjdk.org/browse/JDK-8330606) [JDK-8314295](https://bugs.openjdk.org/browse/JDK-8314295) [JDK-8270398](https://bugs.openjdk.org/browse/JDK-8270398) [JDK-8267118](https://bugs.openjdk.org/browse/JDK-8267118) [JDK-8262368](https://bugs.openjdk.org/browse/JDK-8262368) [JDK-8272096](https://bugs.openjdk.org/browse/JDK-8272096) [JDK-8349923](https://bugs.openjdk.org/browse/JDK-8349923) > > Synchronization allows the ClassFile API verifier to catch up with upcoming verification changes for Valhalla strict fields as well. > > Testing: select javac tests and classfile tests, running tier 1-3 src/java.base/share/classes/jdk/internal/classfile/impl/verifier/VerifierImpl.java line 143: > 141: // 8330606 Not applicable here > 142: return true; > 143: } It?s?good?that `ClassFile::verify(?)` will?now?verify these?types. - https://github.com/openjdk/jdk/pull/19826#pullrequestreview-2382543361 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26174#discussion_r2192958389 From liach at openjdk.org Tue Jul 8 17:03:38 2025 From: liach at openjdk.org (Chen Liang) Date: Tue, 8 Jul 2025 17:03:38 GMT Subject: RFR: 8361526: Synchronize ClassFile API verifier with hotspot In-Reply-To: References: Message-ID: On Tue, 8 Jul 2025 16:28:45 GMT, ExE Boss wrote: >> The class file API verifier seems to be based off a version of hotspot verifier before Mar 3 2021. We are thus missing a few patches in the hotspot verifier: >> [JDK-8350029](https://bugs.openjdk.org/browse/JDK-8350029) [JDK-8340110](https://bugs.openjdk.org/browse/JDK-8340110) [JDK-8330606](https://bugs.openjdk.org/browse/JDK-8330606) [JDK-8314295](https://bugs.openjdk.org/browse/JDK-8314295) [JDK-8270398](https://bugs.openjdk.org/browse/JDK-8270398) [JDK-8267118](https://bugs.openjdk.org/browse/JDK-8267118) [JDK-8262368](https://bugs.openjdk.org/browse/JDK-8262368) [JDK-8272096](https://bugs.openjdk.org/browse/JDK-8272096) [JDK-8349923](https://bugs.openjdk.org/browse/JDK-8349923) >> >> Synchronization allows the ClassFile API verifier to catch up with upcoming verification changes for Valhalla strict fields as well. >> >> Testing: select javac tests and classfile tests, running tier 1-3 > > src/java.base/share/classes/jdk/internal/classfile/impl/verifier/VerifierImpl.java line 143: > >> 141: // 8330606 Not applicable here >> 142: return true; >> 143: } > > It?s?good?that `ClassFile::verify(?)` will?now?verify these?types. > > - https://github.com/openjdk/jdk/pull/19826#pullrequestreview-2382543361 True, I thought you created a bugs.java.com issue but I couldn't find it; anyways now VerifierSelfTest should cover cover these classes. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26174#discussion_r2193023020 From naoto at openjdk.org Tue Jul 8 17:16:43 2025 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 8 Jul 2025 17:16:43 GMT Subject: RFR: 8361519: Obsolete Unicode Scalar Value link in Character class [v2] In-Reply-To: References: Message-ID: On Mon, 7 Jul 2025 20:24:21 GMT, Naoto Sato wrote: >> Refining the description of "Unicode Scalar Value" in the `Character` class. >> The original description referenced the outdated Unicode 3.1 specification, which previously included the U+xxxx notation but no longer does. Updated the reference to point to the Unicode glossary, which defines the term more accurately. Additionally, replaced the obsolete `@spec` link to Unicode 3.1.0 with a reference to the current Unicode Character Database. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Some more Unicode related spec clean up Thanks for the review! ------------- PR Comment: https://git.openjdk.org/jdk/pull/26169#issuecomment-3049711897 From naoto at openjdk.org Tue Jul 8 17:16:44 2025 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 8 Jul 2025 17:16:44 GMT Subject: Integrated: 8361519: Obsolete Unicode Scalar Value link in Character class In-Reply-To: References: Message-ID: On Mon, 7 Jul 2025 19:08:22 GMT, Naoto Sato wrote: > Refining the description of "Unicode Scalar Value" in the `Character` class. > The original description referenced the outdated Unicode 3.1 specification, which previously included the U+xxxx notation but no longer does. Updated the reference to point to the Unicode glossary, which defines the term more accurately. Additionally, replaced the obsolete `@spec` link to Unicode 3.1.0 with a reference to the current Unicode Character Database. This pull request has now been integrated. Changeset: 5850bf44 Author: Naoto Sato URL: https://git.openjdk.org/jdk/commit/5850bf4488ea336c3dd4eafbefb8ade330e2f76a Stats: 13 lines in 2 files changed: 0 ins; 2 del; 11 mod 8361519: Obsolete Unicode Scalar Value link in Character class Reviewed-by: iris ------------- PR: https://git.openjdk.org/jdk/pull/26169 From liach at openjdk.org Tue Jul 8 17:20:34 2025 From: liach at openjdk.org (Chen Liang) Date: Tue, 8 Jul 2025 17:20:34 GMT Subject: RFR: 8360163: Create annotations to mark dumping method handles and runtime setup required classes [v10] In-Reply-To: References: Message-ID: > I have updated this patch to avoid a redundant `runtimeSetup` annotation - we have agreed that the requirement for setup is a side effect of initialization, and such methods in AOTCI classes must be automatically recognized. This latest revision implements that model. > > I intentionally avoided handling Class and ClassLoader `resetArchivedStates` and `MethodType::assemblySetup` - we talked about a generic `assemblyCleanup` method, but I did not find out where is the best place to call such a method in the assembly phase. We cna handle this in a subsequent patch. > > In particular, please review the new AOT.md design document - I split it from the AOTCI annotation to prevent jamming; we can put general AOT information there when we have more AOT-specific annotations. > > --- > > Old description: > Currently, the list of classes that have interdependencies and those that need runtimeSetup are maintained in a hardcoded list in CDS. This makes it risky for core library developers as they might introduce new interdependencies and observe CDS to fail. By moving the mechanism of these lists to core library annotations as a first step, we can gradually expose the AOT contracts as program semantics described by internal annotations, and also helps us to explore how we can expose these functionalities to the public later. Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 23 commits: - Merge branch 'master' of https://github.com/openjdk/jdk into exp/cds-mh-anno - Reviews - Documentation - Don't fail for patching tests - Remove design document from code - Some more from reviews - Reviewed the diff on github - Stage - Missed comment updates - Mark AbstractMap due to CHM - ... and 13 more: https://git.openjdk.org/jdk/compare/85331943...574273a6 ------------- Changes: https://git.openjdk.org/jdk/pull/25922/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25922&range=09 Stats: 453 lines in 38 files changed: 280 ins; 150 del; 23 mod Patch: https://git.openjdk.org/jdk/pull/25922.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25922/head:pull/25922 PR: https://git.openjdk.org/jdk/pull/25922 From liach at openjdk.org Tue Jul 8 17:25:41 2025 From: liach at openjdk.org (Chen Liang) Date: Tue, 8 Jul 2025 17:25:41 GMT Subject: RFR: 8361300: Document exceptions for Unsafe offset methods [v4] In-Reply-To: References: Message-ID: On Thu, 3 Jul 2025 18:41:27 GMT, Chen Liang wrote: >> Unsafe throws IAE for misusing static vs instance fields, and it's revealed that AtomicXxxFieldUpdaters are using this mechanism to reject static fields. This is not a good practice, but we can at least document this so we don't accidentally introduce problems. > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > Test to verify observed internal unsafe behaviors I think from our discussions, there is nothing else to change for this patch. Please correct me if my understanding is wrong, and if it isn't, I hope someone can hop in and leave a review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25945#issuecomment-3049735188 From iklam at openjdk.org Tue Jul 8 17:25:41 2025 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 8 Jul 2025 17:25:41 GMT Subject: RFR: 8360163: Create annotations to mark dumping method handles and runtime setup required classes [v10] In-Reply-To: References: Message-ID: On Tue, 8 Jul 2025 17:20:34 GMT, Chen Liang wrote: >> I have updated this patch to avoid a redundant `runtimeSetup` annotation - we have agreed that the requirement for setup is a side effect of initialization, and such methods in AOTCI classes must be automatically recognized. This latest revision implements that model. >> >> I intentionally avoided handling Class and ClassLoader `resetArchivedStates` and `MethodType::assemblySetup` - we talked about a generic `assemblyCleanup` method, but I did not find out where is the best place to call such a method in the assembly phase. We cna handle this in a subsequent patch. >> >> In particular, please review the new AOT.md design document - I split it from the AOTCI annotation to prevent jamming; we can put general AOT information there when we have more AOT-specific annotations. >> >> --- >> >> Old description: >> Currently, the list of classes that have interdependencies and those that need runtimeSetup are maintained in a hardcoded list in CDS. This makes it risky for core library developers as they might introduce new interdependencies and observe CDS to fail. By moving the mechanism of these lists to core library annotations as a first step, we can gradually expose the AOT contracts as program semantics described by internal annotations, and also helps us to explore how we can expose these functionalities to the public later. > > Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 23 commits: > > - Merge branch 'master' of https://github.com/openjdk/jdk into exp/cds-mh-anno > - Reviews > - Documentation > - Don't fail for patching tests > - Remove design document from code > - Some more from reviews > - Reviewed the diff on github > - Stage > - Missed comment updates > - Mark AbstractMap due to CHM > - ... and 13 more: https://git.openjdk.org/jdk/compare/85331943...574273a6 LGTM. ------------- Marked as reviewed by iklam (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25922#pullrequestreview-2998513542 From alanb at openjdk.org Tue Jul 8 18:02:42 2025 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 8 Jul 2025 18:02:42 GMT Subject: RFR: 8361300: Document exceptions for Unsafe offset methods [v4] In-Reply-To: <3stoVvRmIX7pk8ehqJSYzQwDu2MgQHPnezsoCgEo9Xo=.64f6a467-d0eb-47be-993d-e64a53a7e442@github.com> References: <3stoVvRmIX7pk8ehqJSYzQwDu2MgQHPnezsoCgEo9Xo=.64f6a467-d0eb-47be-993d-e64a53a7e442@github.com> Message-ID: On Mon, 7 Jul 2025 12:06:54 GMT, Chen Liang wrote: >> @AlanBateman Yeah, I think that makes sense?IIRC it's been that way in practice since forever, but making it clear in documentation seems like the right thing to do. > > Tracked in 8360541; I think we can implement in a separate patch. Don't know if this is worth backporting to MRs. Ah yes, I'd forgotten I created this issue to track clarifying the spec. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25945#discussion_r2193129843 From alanb at openjdk.org Tue Jul 8 18:06:39 2025 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 8 Jul 2025 18:06:39 GMT Subject: RFR: 8361497: Scoped Values: orElse and orElseThrow do not access the cache In-Reply-To: References: Message-ID: <_mO-m_nW9KXKJl99YILs4QTPxrHaDc0vqV2bJaCJtWU=.c9b5e047-ba11-42c2-8059-e32ac34bea3f@github.com> On Mon, 7 Jul 2025 16:13:08 GMT, Andrew Haley wrote: > Neither `ScopedValue.orElse` nor `ScopedValue.orElseThrow` consult the cache when searching for a binding. Neither do they update the cache when a binding is found. > While this issue does not affect spec compliance, it is surprising to users that `x.orElse(other)` should be slower than `x.isBound ? x.get() : other`. I did a first pass over this and I think it's okay. I'll do a second pass over it tomorrow. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26164#issuecomment-3049846551 From dl at openjdk.org Tue Jul 8 18:10:38 2025 From: dl at openjdk.org (Doug Lea) Date: Tue, 8 Jul 2025 18:10:38 GMT Subject: RFR: 8361300: Document exceptions for Unsafe offset methods [v4] In-Reply-To: References: <3stoVvRmIX7pk8ehqJSYzQwDu2MgQHPnezsoCgEo9Xo=.64f6a467-d0eb-47be-993d-e64a53a7e442@github.com> Message-ID: On Tue, 8 Jul 2025 17:59:32 GMT, Alan Bateman wrote: >> Tracked in 8360541; I think we can implement in a separate patch. Don't know if this is worth backporting to MRs. > > Ah yes, I'd forgotten I created this issue to track clarifying the spec. Sure, the clarification is long past being useful (since people should be using VarHandles) but why not. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25945#discussion_r2193143824 From liach at openjdk.org Tue Jul 8 18:50:54 2025 From: liach at openjdk.org (Chen Liang) Date: Tue, 8 Jul 2025 18:50:54 GMT Subject: RFR: 8361615: CodeBuilder::parameterSlot throws undocumented IOOBE Message-ID: In a recent inspection of all methods that accept an `int` argument in the Class-File API, I noticed this method that validates its argument but did not document the validation. The behavior is to throw IOOBE. We can simply document this behavior and enhance existing tests to verify exceptional behaviors in addition to anticipated outputs. This is doc plus test only, so should be eligible for backport regardless of priority. A CSR will be created to track this new assertion in the spec. Testing: jdk/jdk/classfile/BuilderParamTest.java ------------- Commit messages: - 8361615: CodeBuilder::parameterSlot throws undocumented IOOBE Changes: https://git.openjdk.org/jdk/pull/26200/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26200&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8361615 Stats: 10 lines in 2 files changed: 9 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/26200.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26200/head:pull/26200 PR: https://git.openjdk.org/jdk/pull/26200 From lancea at openjdk.org Tue Jul 8 18:57:40 2025 From: lancea at openjdk.org (Lance Andersen) Date: Tue, 8 Jul 2025 18:57:40 GMT Subject: RFR: 8360122: Fix java.sql\Connection.java indentation [v5] In-Reply-To: <_YDKPqPvEXlcYuTlaYEiXd9JHJeYmjZMt2fMOOK1QAY=.f29c7bff-9c72-4347-beda-7c4a186190ee@github.com> References: <0UfkXxOmp7jsEH0cPOPBDoh8osWoz6Jp6A8jLh-CmDE=.57a3938f-ba6d-48ee-9caf-ecd3c10678cb@github.com> <_YDKPqPvEXlcYuTlaYEiXd9JHJeYmjZMt2fMOOK1QAY=.f29c7bff-9c72-4347-beda-7c4a186190ee@github.com> Message-ID: On Thu, 3 Jul 2025 01:44:27 GMT, simon wrote: >> src/java.sql/share/classes/java/sql/Connection.java line 303: >> >>> 301: //====================================================================== >>> 302: // Advanced features: >>> 303: >> >> Why was this removed as this is not format related > > It was just a suggestion, but it?s not really related to the main change. I can undo it if you think it?s appropriate Please revert this change ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25925#discussion_r2193230255 From kbarrett at openjdk.org Tue Jul 8 19:52:46 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 8 Jul 2025 19:52:46 GMT Subject: RFR: 8361426: (ref) Remove jdk.internal.ref.Cleaner In-Reply-To: References: Message-ID: On Tue, 8 Jul 2025 04:59:04 GMT, Jaikiran Pai wrote: >> Please review this change that removes the class jdk.internal.ref.Cleaner. >> It is no longer used after JDK-8344332. >> >> Testing: mach5 tier1-3 > > This looks OK to me and matches with what was discussed about this in a recent PR https://github.com/openjdk/jdk/pull/25289#discussion_r2172727041. > > It would be good to get another review for this before integrating. Thanks for reviews @jaikiran and @viktorklang-ora ------------- PR Comment: https://git.openjdk.org/jdk/pull/26141#issuecomment-3050120839 From kbarrett at openjdk.org Tue Jul 8 19:52:47 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 8 Jul 2025 19:52:47 GMT Subject: Integrated: 8361426: (ref) Remove jdk.internal.ref.Cleaner In-Reply-To: References: Message-ID: On Sat, 5 Jul 2025 00:05:39 GMT, Kim Barrett wrote: > Please review this change that removes the class jdk.internal.ref.Cleaner. > It is no longer used after JDK-8344332. > > Testing: mach5 tier1-3 This pull request has now been integrated. Changeset: 117f0b40 Author: Kim Barrett URL: https://git.openjdk.org/jdk/commit/117f0b4051b37d6e639799c5f6add3e2aec8e200 Stats: 233 lines in 3 files changed: 0 ins; 232 del; 1 mod 8361426: (ref) Remove jdk.internal.ref.Cleaner Reviewed-by: jpai, vklang ------------- PR: https://git.openjdk.org/jdk/pull/26141 From liach at openjdk.org Tue Jul 8 20:24:54 2025 From: liach at openjdk.org (Chen Liang) Date: Tue, 8 Jul 2025 20:24:54 GMT Subject: RFR: 8361614: Missing sub-int value validation in the Class-File API Message-ID: In the `class` file format, a lot of the values are `u1` or `u2`; the Class-File API consistently model them with `int`. However, the API does not, in general, validate that int values passed to the factory methods are not out of the bounds as defined in the class file format. This patch proposes to add such validation for factory methods accepting such more narrow data, prepared by examining all `int`-accepting methods in the Class-File API. I expect this to have a small compatibility impact - besides the -1 for the minor version, there is no other places where most significant bits are ever meaningful, and I special cased it and consistently fail fast for all other OOB values, which always mean programmer errors. A CSR will be created soon as well. ------------- Commit messages: - 8361614: Missing sub-int value validation in the Class-File API Changes: https://git.openjdk.org/jdk/pull/26201/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26201&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8361614 Stats: 543 lines in 33 files changed: 439 ins; 57 del; 47 mod Patch: https://git.openjdk.org/jdk/pull/26201.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26201/head:pull/26201 PR: https://git.openjdk.org/jdk/pull/26201 From liach at openjdk.org Tue Jul 8 20:28:23 2025 From: liach at openjdk.org (Chen Liang) Date: Tue, 8 Jul 2025 20:28:23 GMT Subject: RFR: 8361614: Missing sub-int value validation in the Class-File API [v2] In-Reply-To: References: Message-ID: > In the `class` file format, a lot of the values are `u1` or `u2`; the Class-File API consistently model them with `int`. However, the API does not, in general, validate that int values passed to the factory methods are not out of the bounds as defined in the class file format. This patch proposes to add such validation for factory methods accepting such more narrow data, prepared by examining all `int`-accepting methods in the Class-File API. > > I expect this to have a small compatibility impact - besides the -1 for the minor version, there is no other places where most significant bits are ever meaningful, and I special cased it and consistently fail fast for all other OOB values, which always mean programmer errors. > > A CSR will be created soon as well. Chen Liang has updated the pull request incrementally with one additional commit since the last revision: Fix style ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26201/files - new: https://git.openjdk.org/jdk/pull/26201/files/74fd977d..67aa74ae Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26201&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26201&range=00-01 Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/26201.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26201/head:pull/26201 PR: https://git.openjdk.org/jdk/pull/26201 From duke at openjdk.org Tue Jul 8 20:45:20 2025 From: duke at openjdk.org (simon) Date: Tue, 8 Jul 2025 20:45:20 GMT Subject: RFR: 8360122: Fix java.sql\Connection.java indentation [v6] In-Reply-To: References: Message-ID: > 8360122: Refine formatting of Connection.java interface > > --------- > ### Progress > - [ ] Change must be properly reviewed (1 review required, with at least 1 [Reviewer](https://openjdk.org/bylaws#reviewer)) > - [x] Change must not contain extraneous whitespace > - [x] Commit message must refer to an issue > > > > ### Reviewing >

    Using git > > Checkout this PR locally: \ > `$ git fetch https://git.openjdk.org/jdk.git pull/25925/head:pull/25925` \ > `$ git checkout pull/25925` > > Update a local copy of the PR: \ > `$ git checkout pull/25925` \ > `$ git pull https://git.openjdk.org/jdk.git pull/25925/head` > >
    >
    Using Skara CLI tools > > Checkout this PR locally: \ > `$ git pr checkout 25925` > > View PR using the GUI difftool: \ > `$ git pr show -t 25925` > >
    >
    Using diff file > > Download this PR as a diff file: \ > https://git.openjdk.org/jdk/pull/25925.diff > >
    >
    Using Webrev > > [Link to Webrev Comment](https://git.openjdk.org/jdk/pull/25925#issuecomment-2993856738) >
    simon has updated the pull request incrementally with one additional commit since the last revision: 8360122: reversed wrongful removal of comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25925/files - new: https://git.openjdk.org/jdk/pull/25925/files/c14699a8..69c84daa Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25925&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25925&range=04-05 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/25925.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25925/head:pull/25925 PR: https://git.openjdk.org/jdk/pull/25925 From duke at openjdk.org Tue Jul 8 20:45:20 2025 From: duke at openjdk.org (simon) Date: Tue, 8 Jul 2025 20:45:20 GMT Subject: RFR: 8360122: Fix java.sql\Connection.java indentation [v3] In-Reply-To: References: <0UfkXxOmp7jsEH0cPOPBDoh8osWoz6Jp6A8jLh-CmDE=.57a3938f-ba6d-48ee-9caf-ecd3c10678cb@github.com> <_YDKPqPvEXlcYuTlaYEiXd9JHJeYmjZMt2fMOOK1QAY=.f29c7bff-9c72-4347-beda-7c4a186190ee@github.com> Message-ID: On Tue, 8 Jul 2025 18:53:08 GMT, Lance Andersen wrote: >> It was just a suggestion, but it?s not really related to the main change. I can undo it if you think it?s appropriate > > Please revert this change Fixed ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25925#discussion_r2193408909 From xgong at openjdk.org Wed Jul 9 01:23:44 2025 From: xgong at openjdk.org (Xiaohong Gong) Date: Wed, 9 Jul 2025 01:23:44 GMT Subject: RFR: 8359419: AArch64: Relax min vector length to 32-bit for short vectors [v3] In-Reply-To: References: <7VTRz_XqYBSdQ54n7ADzTzYADZjDbgBw6XuW0jehSLI=.24d18b87-4553-47ab-8065-d92fbb5700ae@github.com> <5H0NP8vFqCDf1JgHIDee3WrYRbJ6koj5wQsxEGTW8nI=.87d74c6a-54b3-45cc-a972-c4350d5e2acf@github.com> <0XcbEZkrW7fvJhPwQPP1UtT9aC3_OnT7sjoiHo0fOuQ=.1ec5ae91-55cb-4d8b-9e91-44ec02e63747@github.com> <0vdCJFYxCI6hFnTL6rm3oKQcPuuIR2EbuyAOa0muqcw=.d5c249cb-9bf0-415d-ab22-de7387d8d8d1@github.com> Message-ID: On Tue, 8 Jul 2025 10:33:50 GMT, Fei Gao wrote: > > > > > > > https://github.com/openjdk/jdk/blob/f2d2eef988c57cc9f6194a8fd5b2b422035ee68f/test/hotspot/jtreg/compiler/vectorization/runner/ArrayTypeConvertTest.java#L388-L392 > > > > > > > > > > > > > > > > > > Actually I didn't change the min vector size for `char` vectors in this patch. Relaxing `short` vectors to 32-bit is to support the vector cast for Vector API, and there is no `char` species in it. Do you think it's better to do the same change for `char` as well? This will just benefit auto-vectorization. > > > > > > > > > > > > > > > Hi @XiaohongGong thanks for asking. In many auto-vectorization cases involving `char`, the vector elements are represented using `T_SHORT` as the `BasicType`, rather than `T_CHAR`. > > > > > This is because, in Java, operands of subword types are always promoted to `int` before any arithmetic operation. As a result, when handling a node like `ConvD2I`, we don?t initially know its actual subword type. Later, the SuperWord phase propagates a narrowed integer type backward to help determine the correct subword type. See: > > > > > https://github.com/openjdk/jdk/blob/f2d2eef988c57cc9f6194a8fd5b2b422035ee68f/src/hotspot/share/opto/superword.cpp#L2551-L2558 > > > > > > > > > > Since SuperWord assigns `T_SHORT` to `StoreC` early on > > > > > https://github.com/openjdk/jdk/blob/f2d2eef988c57cc9f6194a8fd5b2b422035ee68f/src/hotspot/share/opto/superword.cpp#L2646-L2650 > > > > > > > > > > the entire propagation chain tends to use `T_SHORT` as well. > > > > > This applies to most operations, with the exception of a few like `RShiftI`, `Abs`, and `ReverseBytesI`, which are handled separately. > > > > > So your change already benefits many char-related vectorization cases like `convertDoubleToChar` above. That?s why we can safely relax the IR condition mentioned earlier. > > > > > > > > > > > > Thanks for your input! It's really helpful to me. Does this mean it always use `T_SHORT` for char vectors in SLP? If so, it's safe that we do not need to consider `T_CHAR` in vector IRs in backend? > > > > > > > > > No, we don't always use `T_SHORT` for char vectors. As mentioned earlier, for operations like `RShiftI`, `Abs`, and `ReverseBytesI`, the compiler needs to preserve the higher-order bits of the first operand. Therefore, SuperWord still needs to assign them precise subword types. See: > > > https://github.com/openjdk/jdk/blob/f2d2eef988c57cc9f6194a8fd5b2b422035ee68f/src/hotspot/share/opto/superword.cpp#L2583-L2589 > > > > > > Yes, I see. Thanks! What I mean is for cases that SLP will use the subword types, it will be actually `T_SHORT` for `T_CHAR` then? > > From my side, the cases where SLP uses subword types can be roughly categorized into two groups: > > 1. Cases where the compiler doesn?t need to preserve the higher-order bits ? in these, SuperWord will use `T_SHORT` instead of `T_CHAR`. > 2. Cases where the compiler does need to preserve the higher-order bits, like `RShiftI`, `Abs`, and `ReverseBytesI` ? in these, `T_CHAR` is still used. Thanks for your explanation! I'v updated the ad file and jtreg tests in latest commit. Could you please take a look at again? ------------- PR Comment: https://git.openjdk.org/jdk/pull/26057#issuecomment-3050732618 From xgong at openjdk.org Wed Jul 9 01:23:43 2025 From: xgong at openjdk.org (Xiaohong Gong) Date: Wed, 9 Jul 2025 01:23:43 GMT Subject: RFR: 8359419: AArch64: Relax min vector length to 32-bit for short vectors [v4] In-Reply-To: References: Message-ID: > ### Background > On AArch64, the minimum vector length supported is 64-bit for basic types, except for `byte` and `boolean` (32-bit and 16-bit respectively to match special Vector API features). This limitation prevents intrinsification of vector type conversions between `short` and wider types (e.g. `long/double`) in Vector API when the entire vector length is within 128 bits, resulting in degraded performance for such conversions. > > For example, type conversions between `ShortVector.SPECIES_128` and `LongVector.SPECIES_128` are not supported on AArch64 NEON and SVE architectures with 128-bit max vector size. This occurs because the compiler would need to generate a vector with 2 short elements, resulting in a 32-bit vector size. > > To intrinsify such type conversion APIs, we need to relax the min vector length constraint from 64-bit to 32-bit for short vectors. > > ### Impact Analysis > #### 1. Vector types > Vectors only with `short` element types will be affected, as we just supported 32-bit `short` vectors in this change. > > #### 2. Vector API > No impact on Vector API or the vector-specific nodes. The minimum vector shape at API level remains 64-bit. It's not possible to generate a final vector IR with 32-bit vector size. Type conversions may generate intermediate 32-bit vectors, but they will be resized or cast to vectors with at least 64-bit length. > > #### 3. Auto-vectorization > Enables vectorization of cases containing only 2 `short` lanes, with significant performance improvements. Since we have supported 32-bit vectors for `byte` type for a long time, extending this to `short` did not introduce additional risks. > > #### 4. Codegen of vector nodes > NEON doesn't support 32-bit SIMD instructions, so we use 64-bit instructions instead. For lanewise operations, this is safe because the higher half bits can be ignored. > > Details: > - Lanewise vector operations are unaffected as explained above. > - NEON supports vector load/store instructions with 32-bit vector size, which we already use in relevant IRs (shared by SVE). > - Cross-lane operations like reduction may be affected, potentially causing incorrect results for `min/max/mul/and` reductions. The min vector size for such operations should remain 64-bit. We've added assertions in match rules. Since it's currently not possible to generate such reductions (Vector API minimum is 64-bit, and SLP doesn't support subword type reductions), we maintain the status quo. However, adding an explicit vector size check in `match_rule_s... Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision: Disable auto-vectorization of double to short conversion for NEON and update tests ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26057/files - new: https://git.openjdk.org/jdk/pull/26057/files/dfda42a3..7fdc357a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26057&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26057&range=02-03 Stats: 53 lines in 4 files changed: 35 ins; 0 del; 18 mod Patch: https://git.openjdk.org/jdk/pull/26057.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26057/head:pull/26057 PR: https://git.openjdk.org/jdk/pull/26057 From xgong at openjdk.org Wed Jul 9 01:23:43 2025 From: xgong at openjdk.org (Xiaohong Gong) Date: Wed, 9 Jul 2025 01:23:43 GMT Subject: RFR: 8359419: AArch64: Relax min vector length to 32-bit for short vectors [v3] In-Reply-To: <1bwEx4HAqqmfw9DrslwrZH1cYfIKi-5p9AgelJrIB94=.f46dd942-2102-4fd3-adfd-7f7ec3c3dbc0@github.com> References: <7VTRz_XqYBSdQ54n7ADzTzYADZjDbgBw6XuW0jehSLI=.24d18b87-4553-47ab-8065-d92fbb5700ae@github.com> <5H0NP8vFqCDf1JgHIDee3WrYRbJ6koj5wQsxEGTW8nI=.87d74c6a-54b3-45cc-a972-c4350d5e2acf@github.com> <0XcbEZkrW7fvJhPwQPP1UtT9aC3_OnT7sjoiHo0fOuQ=.1ec5ae91-55cb-4d8b-9e91-44ec02e63747@github.com> <0vdCJFYxCI6hFnTL6rm3oKQcPuuIR2EbuyAOa0muqcw=.d5c249cb-9bf0-415d-ab22-de7387d8d8d1@github.com> <1bwEx4HAqqmfw9DrslwrZH1cYfIKi-5p9AgelJrIB94=.f46dd942-2102-4fd3-adfd-7f7ec3c3dbc0@github.com> Message-ID: On Tue, 8 Jul 2025 09:07:00 GMT, Xiaohong Gong wrote: >>> > > > > https://github.com/openjdk/jdk/blob/f2d2eef988c57cc9f6194a8fd5b2b422035ee68f/test/hotspot/jtreg/compiler/vectorization/runner/ArrayTypeConvertTest.java#L388-L392 >>> > > > >>> > > > >>> > > > Actually I didn't change the min vector size for `char` vectors in this patch. Relaxing `short` vectors to 32-bit is to support the vector cast for Vector API, and there is no `char` species in it. Do you think it's better to do the same change for `char` as well? This will just benefit auto-vectorization. >>> > > >>> > > >>> > > Hi @XiaohongGong thanks for asking. In many auto-vectorization cases involving `char`, the vector elements are represented using `T_SHORT` as the `BasicType`, rather than `T_CHAR`. >>> > > This is because, in Java, operands of subword types are always promoted to `int` before any arithmetic operation. As a result, when handling a node like `ConvD2I`, we don?t initially know its actual subword type. Later, the SuperWord phase propagates a narrowed integer type backward to help determine the correct subword type. See: >>> > > https://github.com/openjdk/jdk/blob/f2d2eef988c57cc9f6194a8fd5b2b422035ee68f/src/hotspot/share/opto/superword.cpp#L2551-L2558 >>> > > >>> > > Since SuperWord assigns `T_SHORT` to `StoreC` early on >>> > > https://github.com/openjdk/jdk/blob/f2d2eef988c57cc9f6194a8fd5b2b422035ee68f/src/hotspot/share/opto/superword.cpp#L2646-L2650 >>> > > >>> > > the entire propagation chain tends to use `T_SHORT` as well. >>> > > This applies to most operations, with the exception of a few like `RShiftI`, `Abs`, and `ReverseBytesI`, which are handled separately. >>> > > So your change already benefits many char-related vectorization cases like `convertDoubleToChar` above. That?s why we can safely relax the IR condition mentioned earlier. >>> > >>> > >>> > Thanks for your input! It's really helpful to me. Does this mean it always use `T_SHORT` for char vectors in SLP? If so, it's safe that we do not need to consider `T_CHAR` in vector IRs in backend? >>> >>> No, we don't always use `T_SHORT` for char vectors. As mentioned earlier, for operations like `RShiftI`, `Abs`, and `ReverseBytesI`, the compiler needs to preserve the higher-order bits of the first operand. Therefore, SuperWord still needs to assign them precise subword types. See: >>> >>> https://github.com/openjdk/jdk/blob/f2d2eef988c57cc9f6194a8fd5b2b422035ee68f/src/hotspot/share/opto/superword.cpp#L2583-L2589 >> >> Yes, I see. Thanks! What I mean is for cases that SLP will use the sub... > >> > > Hi @XiaohongGong, is there any way we can implement 2HF -> 2S and 2S -> 2HF in these match rules ? >> > > https://github.com/openjdk/jdk/blob/f2d2eef988c57cc9f6194a8fd5b2b422035ee68f/src/hotspot/cpu/aarch64/aarch64_vector.ad#L4697 >> > > >> > > https://github.com/openjdk/jdk/blob/f2d2eef988c57cc9f6194a8fd5b2b422035ee68f/src/hotspot/cpu/aarch64/aarch64_vector.ad#L4679 >> > > >> > > The `fcvtn` and `fcvtl` instructions do not support these arrangements. I was wondering if there is any other way we can implement these by any chance? >> > >> > >> > Do you mean `2HF -> 2F` and `2F -> 2HF` ? >> > Yes, it does not support the 32-bit arrangements. Vector conversion is a kind of lanewise vector operation. For such cases, we usually use the same arrangements with 64-bit vector size for 32-bit ones. That means we can reuse the `T4H` and `T4S` to implement it. Hence, current match rules can cover the conversions between `2HF` and `2F`. >> > Consider there is no such conversion cases in Vector API, I didn't change the comment in the match rules. I think this may benefit auto-vectorization. Currently, do we have cases that can match these rules with SLP? >> >> Sorry yes I meant 2HF <-> 2F. Yes, currently there are no such cases in VectorAPI as we do not support Float16 Vectors yet but this will benefit autovectorization cases. I think in this case this may also benefit 2D <-> 2HF as well (eventually we might add support for D <-> HF as well). Yes we have some JTREG tests that match these rules currently like - `test/hotspot/jtreg/compiler/vectorization/TestFloat16VectorConvChain.java`, `test/hotspot/jtreg/compiler/vectorization/TestFloatConversionsVector.java`. > > Thanks! So per my understanding, things that I just need is updating comment (e.g. `// 4HF to 4F`) of rules like `vcvtHFtoF`, right? For conversions between double and HF, we do not need any new rules as it will be actually `double -> float -> HF`, right? > > > > > Hi @XiaohongGong, is there any way we can implement 2HF -> 2S and 2S -> 2HF in these match rules ? > > > > > https://github.com/openjdk/jdk/blob/f2d2eef988c57cc9f6194a8fd5b2b422035ee68f/src/hotspot/cpu/aarch64/aarch64_vector.ad#L4697 > > > > > > > > > > https://github.com/openjdk/jdk/blob/f2d2eef988c57cc9f6194a8fd5b2b422035ee68f/src/hotspot/cpu/aarch64/aarch64_vector.ad#L4679 > > > > > > > > > > The `fcvtn` and `fcvtl` instructions do not support these arrangements. I was wondering if there is any other way we can implement these by any chance? > > > > > > > > > > > > Do you mean `2HF -> 2F` and `2F -> 2HF` ? > > > > Yes, it does not support the 32-bit arrangements. Vector conversion is a kind of lanewise vector operation. For such cases, we usually use the same arrangements with 64-bit vector size for 32-bit ones. That means we can reuse the `T4H` and `T4S` to implement it. Hence, current match rules can cover the conversions between `2HF` and `2F`. > > > > Consider there is no such conversion cases in Vector API, I didn't change the comment in the match rules. I think this may benefit auto-vectorization. Currently, do we have cases that can match these rules with SLP? > > > > > > > > > Sorry yes I meant 2HF <-> 2F. Yes, currently there are no such cases in VectorAPI as we do not support Float16 Vectors yet but this will benefit autovectorization cases. I think in this case this may also benefit 2D <-> 2HF as well (eventually we might add support for D <-> HF as well). Yes we have some JTREG tests that match these rules currently like - `test/hotspot/jtreg/compiler/vectorization/TestFloat16VectorConvChain.java`, `test/hotspot/jtreg/compiler/vectorization/TestFloatConversionsVector.java`. > > > > > > Thanks! So per my understanding, things that I just need is updating comment (e.g. `// 4HF to 4F`) of rules like `vcvtHFtoF`, right? For conversions between double and HF, we do not need any new rules as it will be actually `double -> float -> HF`, right? > > Yes please and also for `4F to 4HF` case for `vcvtF2HF`. Thanks! > > As for the double to half float conversion - yes with the current infrastructure it would be ConvD2F -> ConvF2HF which will be autovectorized to generate corresponding vector nodes. Sooner or later, support for ConvD2HF (and its vectorized version) might be added upstream (support already available in `lworld+fp16` branch of Valhalla here - https://github.com/openjdk/valhalla/blob/0ed65b9a63405e950c411835120f0f36e326aaaa/src/hotspot/cpu/aarch64/aarch64_vector.ad#L4535). You do not have to add any new rules now for this case. I was just hinting at possible D<->HF implementation in the future. As the max vector length was 64bits, I did not add any implementation for Neon vcvtD2HF or vcvtHF2D in Valhalla. Maybe we can do two `fcvtl/fcvtn` to convert D to F and then F to HF for this specific case but we can think about that later :) Make sense to me. The latest change has been updated together with the relative jtreg tests. Would you mind taking another look at it? Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/26057#issuecomment-3050730818 From xgong at openjdk.org Wed Jul 9 01:26:44 2025 From: xgong at openjdk.org (Xiaohong Gong) Date: Wed, 9 Jul 2025 01:26:44 GMT Subject: RFR: 8359419: AArch64: Relax min vector length to 32-bit for short vectors [v3] In-Reply-To: References: <7VTRz_XqYBSdQ54n7ADzTzYADZjDbgBw6XuW0jehSLI=.24d18b87-4553-47ab-8065-d92fbb5700ae@github.com> <5H0NP8vFqCDf1JgHIDee3WrYRbJ6koj5wQsxEGTW8nI=.87d74c6a-54b3-45cc-a972-c4350d5e2acf@github.com> <0XcbEZkrW7fvJhPwQPP1UtT9aC3_OnT7sjoiHo0fOuQ=.1ec5ae91-55cb-4d8b-9e91-44ec02e63747@github.com> <0vdCJFYxCI6hFnTL6rm3oKQcPuuIR2EbuyAOa0muqcw=.d5c249cb-9bf0-415d-ab22-de7387d8d8d1@github.com> Message-ID: <1Zh7gvEryldv1xZZWYETiDjUzK_i1ea4H6U1EFEoeZU=.ef8296ca-f14f-4f4a-98c0-3b6b6d0721ed@github.com> On Tue, 8 Jul 2025 10:33:50 GMT, Fei Gao wrote: >>> > > > > https://github.com/openjdk/jdk/blob/f2d2eef988c57cc9f6194a8fd5b2b422035ee68f/test/hotspot/jtreg/compiler/vectorization/runner/ArrayTypeConvertTest.java#L388-L392 >>> > > > >>> > > > >>> > > > Actually I didn't change the min vector size for `char` vectors in this patch. Relaxing `short` vectors to 32-bit is to support the vector cast for Vector API, and there is no `char` species in it. Do you think it's better to do the same change for `char` as well? This will just benefit auto-vectorization. >>> > > >>> > > >>> > > Hi @XiaohongGong thanks for asking. In many auto-vectorization cases involving `char`, the vector elements are represented using `T_SHORT` as the `BasicType`, rather than `T_CHAR`. >>> > > This is because, in Java, operands of subword types are always promoted to `int` before any arithmetic operation. As a result, when handling a node like `ConvD2I`, we don?t initially know its actual subword type. Later, the SuperWord phase propagates a narrowed integer type backward to help determine the correct subword type. See: >>> > > https://github.com/openjdk/jdk/blob/f2d2eef988c57cc9f6194a8fd5b2b422035ee68f/src/hotspot/share/opto/superword.cpp#L2551-L2558 >>> > > >>> > > Since SuperWord assigns `T_SHORT` to `StoreC` early on >>> > > https://github.com/openjdk/jdk/blob/f2d2eef988c57cc9f6194a8fd5b2b422035ee68f/src/hotspot/share/opto/superword.cpp#L2646-L2650 >>> > > >>> > > the entire propagation chain tends to use `T_SHORT` as well. >>> > > This applies to most operations, with the exception of a few like `RShiftI`, `Abs`, and `ReverseBytesI`, which are handled separately. >>> > > So your change already benefits many char-related vectorization cases like `convertDoubleToChar` above. That?s why we can safely relax the IR condition mentioned earlier. >>> > >>> > >>> > Thanks for your input! It's really helpful to me. Does this mean it always use `T_SHORT` for char vectors in SLP? If so, it's safe that we do not need to consider `T_CHAR` in vector IRs in backend? >>> >>> No, we don't always use `T_SHORT` for char vectors. As mentioned earlier, for operations like `RShiftI`, `Abs`, and `ReverseBytesI`, the compiler needs to preserve the higher-order bits of the first operand. Therefore, SuperWord still needs to assign them precise subword types. See: >>> >>> https://github.com/openjdk/jdk/blob/f2d2eef988c57cc9f6194a8fd5b2b422035ee68f/src/hotspot/share/opto/superword.cpp#L2583-L2589 >> >> Yes, I see. Thanks! What I mean is for cases that SLP will use the sub... > >> > > > > > https://github.com/openjdk/jdk/blob/f2d2eef988c57cc9f6194a8fd5b2b422035ee68f/test/hotspot/jtreg/compiler/vectorization/runner/ArrayTypeConvertTest.java#L388-L392 >> > > > > >> > > > > >> > > > > Actually I didn't change the min vector size for `char` vectors in this patch. Relaxing `short` vectors to 32-bit is to support the vector cast for Vector API, and there is no `char` species in it. Do you think it's better to do the same change for `char` as well? This will just benefit auto-vectorization. >> > > > >> > > > >> > > > Hi @XiaohongGong thanks for asking. In many auto-vectorization cases involving `char`, the vector elements are represented using `T_SHORT` as the `BasicType`, rather than `T_CHAR`. >> > > > This is because, in Java, operands of subword types are always promoted to `int` before any arithmetic operation. As a result, when handling a node like `ConvD2I`, we don?t initially know its actual subword type. Later, the SuperWord phase propagates a narrowed integer type backward to help determine the correct subword type. See: >> > > > https://github.com/openjdk/jdk/blob/f2d2eef988c57cc9f6194a8fd5b2b422035ee68f/src/hotspot/share/opto/superword.cpp#L2551-L2558 >> > > > >> > > > Since SuperWord assigns `T_SHORT` to `StoreC` early on >> > > > https://github.com/openjdk/jdk/blob/f2d2eef988c57cc9f6194a8fd5b2b422035ee68f/src/hotspot/share/opto/superword.cpp#L2646-L2650 >> > > > >> > > > the entire propagation chain tends to use `T_SHORT` as well. >> > > > This applies to most operations, with the exception of a few like `RShiftI`, `Abs`, and `ReverseBytesI`, which are handled separately. >> > > > So your change already benefits many char-related vectorization cases like `convertDoubleToChar` above. That?s why we can safely relax the IR condition mentioned earlier. >> > > >> > > >> > > Thanks for your input! It's really helpful to me. Does this mean it always use `T_SHORT` for char vectors in SLP? If so, it's safe that we do not need to consider `T_CHAR` in vector IRs in backend? >> > >> > >> > No, we don't always use `T_SHORT` for char vectors. As mentioned earlier, for operations like `RShiftI`, `Abs`, and `ReverseBytesI`, the compiler needs to preserve the higher-order bits of the first operand. Therefore, SuperWord still needs to assign them precise subword types. See: >> > https://github.com/openjdk/jdk/blob/f2d2eef988c57cc9f6194a8fd5b2b422035ee68f/src/hotspot/share/opto/superword.cpp#L2583-L2589 >> >> Yes, I see. Thanks! What I mean is for cases th... @fg1417 , there is performance regression of `D -> S` on NEON for SLP. I'v disabled the case in latest change. And here is the performance data of JMH `TypeVectorOperations` on Grace (the 128-bit SVE machine) and N1 (NEON) respectively: Grace: Benchmark COUNT Mode Unit Before After Ratio TypeVectorOperationsSuperWord.convertD2S 512 avgt ns/op 155.667433 123.222497 1.26 TypeVectorOperationsSuperWord.convertD2S 2048 avgt ns/op 622.262384 489.336020 1.27 TypeVectorOperationsSuperWord.convertL2S 512 avgt ns/op 93.173939 63.557134 1.46 TypeVectorOperationsSuperWord.convertL2S 2048 avgt ns/op 365.287938 239.726941 1.52 TypeVectorOperationsSuperWord.convertS2D 512 avgt ns/op 157.096344 147.560047 1.06 TypeVectorOperationsSuperWord.convertS2D 2048 avgt ns/op 627.039963 614.748559 1.01 TypeVectorOperationsSuperWord.convertS2L 512 avgt ns/op 111.752970 108.629240 1.02 TypeVectorOperationsSuperWord.convertS2L 2048 avgt ns/op 441.312737 441.088523 1.00 N1: Benchmark COUNT Mode Unit Before After Ratio TypeVectorOperationsSuperWord.convertD2S 512 avgt ns/op 215.353528 214.769884 1.00 TypeVectorOperationsSuperWord.convertD2S 2048 avgt ns/op 958.428871 952.922855 1.00 TypeVectorOperationsSuperWord.convertL2S 512 avgt ns/op 158.000190 142.647209 1.10 TypeVectorOperationsSuperWord.convertL2S 2048 avgt ns/op 612.525835 532.023419 1.15 TypeVectorOperationsSuperWord.convertS2D 512 avgt ns/op 209.993363 210.466401 0.99 TypeVectorOperationsSuperWord.convertS2D 2048 avgt ns/op 819.181052 803.601170 1.01 TypeVectorOperationsSuperWord.convertS2L 512 avgt ns/op 217.848273 182.680450 1.19 TypeVectorOperationsSuperWord.convertS2L 2048 avgt ns/op 858.031089 695.502377 1.23 ------------- PR Comment: https://git.openjdk.org/jdk/pull/26057#issuecomment-3050738693 From liach at openjdk.org Wed Jul 9 03:37:52 2025 From: liach at openjdk.org (Chen Liang) Date: Wed, 9 Jul 2025 03:37:52 GMT Subject: RFR: 8361526: Synchronize ClassFile API verifier with hotspot In-Reply-To: References: Message-ID: On Mon, 7 Jul 2025 23:21:58 GMT, Chen Liang wrote: > The class file API verifier seems to be based off a version of hotspot verifier before Mar 3 2021. We are thus missing a few patches in the hotspot verifier: > [JDK-8350029](https://bugs.openjdk.org/browse/JDK-8350029) [JDK-8340110](https://bugs.openjdk.org/browse/JDK-8340110) [JDK-8330606](https://bugs.openjdk.org/browse/JDK-8330606) [JDK-8314295](https://bugs.openjdk.org/browse/JDK-8314295) [JDK-8270398](https://bugs.openjdk.org/browse/JDK-8270398) [JDK-8267118](https://bugs.openjdk.org/browse/JDK-8267118) [JDK-8262368](https://bugs.openjdk.org/browse/JDK-8262368) [JDK-8272096](https://bugs.openjdk.org/browse/JDK-8272096) [JDK-8349923](https://bugs.openjdk.org/browse/JDK-8349923) > > Synchronization allows the ClassFile API verifier to catch up with upcoming verification changes for Valhalla strict fields as well. > > Testing: select javac tests and classfile tests, running tier 1-3 Thanks for the reviews! I can move on to support strict fields in the valhalla ClassFile API verifier now. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26174#issuecomment-3050993770 From liach at openjdk.org Wed Jul 9 03:37:52 2025 From: liach at openjdk.org (Chen Liang) Date: Wed, 9 Jul 2025 03:37:52 GMT Subject: Integrated: 8361526: Synchronize ClassFile API verifier with hotspot In-Reply-To: References: Message-ID: On Mon, 7 Jul 2025 23:21:58 GMT, Chen Liang wrote: > The class file API verifier seems to be based off a version of hotspot verifier before Mar 3 2021. We are thus missing a few patches in the hotspot verifier: > [JDK-8350029](https://bugs.openjdk.org/browse/JDK-8350029) [JDK-8340110](https://bugs.openjdk.org/browse/JDK-8340110) [JDK-8330606](https://bugs.openjdk.org/browse/JDK-8330606) [JDK-8314295](https://bugs.openjdk.org/browse/JDK-8314295) [JDK-8270398](https://bugs.openjdk.org/browse/JDK-8270398) [JDK-8267118](https://bugs.openjdk.org/browse/JDK-8267118) [JDK-8262368](https://bugs.openjdk.org/browse/JDK-8262368) [JDK-8272096](https://bugs.openjdk.org/browse/JDK-8272096) [JDK-8349923](https://bugs.openjdk.org/browse/JDK-8349923) > > Synchronization allows the ClassFile API verifier to catch up with upcoming verification changes for Valhalla strict fields as well. > > Testing: select javac tests and classfile tests, running tier 1-3 This pull request has now been integrated. Changeset: e2c5d035 Author: Chen Liang URL: https://git.openjdk.org/jdk/commit/e2c5d035468d530888fc95f8664410742e65f21f Stats: 276 lines in 9 files changed: 139 ins; 25 del; 112 mod 8361526: Synchronize ClassFile API verifier with hotspot Reviewed-by: asotona ------------- PR: https://git.openjdk.org/jdk/pull/26174 From duke at openjdk.org Wed Jul 9 06:08:33 2025 From: duke at openjdk.org (erifan) Date: Wed, 9 Jul 2025 06:08:33 GMT Subject: RFR: 8354242: VectorAPI: combine vector not operation with compare [v11] In-Reply-To: References: Message-ID: > This patch optimizes the following patterns: > For integer types: > > (XorV (VectorMaskCmp src1 src2 cond) (Replicate -1)) > => (VectorMaskCmp src1 src2 ncond) > (XorVMask (VectorMaskCmp src1 src2 cond) (MaskAll m1)) > => (VectorMaskCmp src1 src2 ncond) > > cond can be eq, ne, le, ge, lt, gt, ule, uge, ult and ugt, ncond is the negative comparison of cond. > > For float and double types: > > (XorV (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (Replicate -1)) > => (VectorMaskCast (VectorMaskCmp src1 src2 ncond)) > (XorVMask (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (MaskAll m1)) > => (VectorMaskCast (VectorMaskCmp src1 src2 ncond)) > > cond can be eq or ne. > > Benchmarks on Nvidia Grace machine with 128-bit SVE2: With option `-XX:UseSVE=2`: > > Benchmark Unit Before Score Error After Score Error Uplift > testCompareEQMaskNotByte ops/s 7912127.225 2677.289518 10266136.26 8955.008548 1.29 > testCompareEQMaskNotDouble ops/s 884737.6799 446.963779 1179760.772 448.031844 1.33 > testCompareEQMaskNotFloat ops/s 1765045.787 682.332214 2359520.803 896.305743 1.33 > testCompareEQMaskNotInt ops/s 1787221.411 977.743935 2353952.519 960.069976 1.31 > testCompareEQMaskNotLong ops/s 895297.1974 673.44808 1178449.02 323.804205 1.31 > testCompareEQMaskNotShort ops/s 3339987.002 3415.2226 4712761.965 2110.862053 1.41 > testCompareGEMaskNotByte ops/s 7907615.16 4094.243652 10251646.9 9486.699831 1.29 > testCompareGEMaskNotInt ops/s 1683738.958 4233.813092 2352855.205 1251.952546 1.39 > testCompareGEMaskNotLong ops/s 854496.1561 8594.598885 1177811.493 521.1229 1.37 > testCompareGEMaskNotShort ops/s 3341860.309 1578.975338 4714008.434 1681.10365 1.41 > testCompareGTMaskNotByte ops/s 7910823.674 2993.367032 10245063.58 9774.75138 1.29 > testCompareGTMaskNotInt ops/s 1673393.928 3153.099431 2353654.521 1190.848583 1.4 > testCompareGTMaskNotLong ops/s 849405.9159 2432.858159 1177952.041 359.96413 1.38 > testCompareGTMaskNotShort ops/s 3339509.141 3339.976585 4711442.496 2673.364893 1.41 > testCompareLEMaskNotByte ops/s 7911340.004 3114.69191 10231626.5 27134.20035 1.29 > testCompareLEMaskNotInt ops/s 1675812.113 1340.969885 2353255.341 1452.4522 1.4 > testCompareLEMaskNotLong ops/s 848862.8036 6564.841731 1177763.623 539.290106 1.38 > testCompareLEMaskNotShort ops/s 3324951.54 2380.29473 4712116.251 1544.559684 1.41 > testCompareLTMaskNotByte ops/s 7910390.844 2630.861436 10239567.69 6487.441672 1.29 > testCompareLTMaskNotInt ops/s 1672180.09 995.238142 2353757.863 853.774734 1.4 > testCompareLTMaskNotLong ops/s 856502.26... erifan has updated the pull request incrementally with one additional commit since the last revision: Update the code comment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24674/files - new: https://git.openjdk.org/jdk/pull/24674/files/db78dc43..04142a19 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24674&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24674&range=09-10 Stats: 6 lines in 1 file changed: 3 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/24674.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24674/head:pull/24674 PR: https://git.openjdk.org/jdk/pull/24674 From duke at openjdk.org Wed Jul 9 06:18:48 2025 From: duke at openjdk.org (erifan) Date: Wed, 9 Jul 2025 06:18:48 GMT Subject: RFR: 8354242: VectorAPI: combine vector not operation with compare [v10] In-Reply-To: References: Message-ID: On Tue, 8 Jul 2025 11:42:02 GMT, Emanuel Peter wrote: >> erifan has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 17 additional commits since the last revision: >> >> - Align indentation >> - Merge branch 'master' into JDK-8354242 >> - Address more comments >> >> ATT. >> - Merge branch 'master' into JDK-8354242 >> - Support negating unsigned comparison for BoolTest::mask >> >> Added a static method `negate_mask(mask btm)` into BoolTest class to >> negate both signed and unsigned comparison. >> - Addressed some review comments >> - Merge branch 'master' into JDK-8354242 >> - Refactor the JTReg tests for compare.xor(maskAll) >> >> Also made a bit change to support pattern `VectorMask.fromLong()`. >> - Merge branch 'master' into JDK-8354242 >> - Refactor code >> >> Add a new function XorVNode::Ideal_XorV_VectorMaskCmp to do this >> optimization, making the code more modular. >> - ... and 7 more: https://git.openjdk.org/jdk/compare/04bd77d0...db78dc43 > > src/hotspot/share/opto/vectornode.cpp line 2241: > >> 2239: in1->outcnt() != 1 || >> 2240: !(in1->as_VectorMaskCmp())->predicate_can_be_negated() || >> 2241: !VectorNode::is_all_ones_vector(in2)) { > > Suggestion: > > !in1->as_VectorMaskCmp()->predicate_can_be_negated() || > !VectorNode::is_all_ones_vector(in2)) { > > Remove the indentation again, and the superfluous brackets too ;) Done ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24674#discussion_r2194130835 From duke at openjdk.org Wed Jul 9 06:18:48 2025 From: duke at openjdk.org (erifan) Date: Wed, 9 Jul 2025 06:18:48 GMT Subject: RFR: 8354242: VectorAPI: combine vector not operation with compare [v9] In-Reply-To: <2UzxnawLUtlwIr5aaEdTfn4OEMt_z1HTfAaDBHCeZFU=.a70d1360-574a-4ca9-adae-7dec030ed2b7@github.com> References: <2UzxnawLUtlwIr5aaEdTfn4OEMt_z1HTfAaDBHCeZFU=.a70d1360-574a-4ca9-adae-7dec030ed2b7@github.com> Message-ID: On Tue, 8 Jul 2025 11:42:18 GMT, Emanuel Peter wrote: >> Oh wow, my bad. I misunderstood the brackets! >> >> Instead of: >> >> !(in1->as_VectorMaskCmp())->predicate_can_be_negated() || >> !VectorNode::is_all_ones_vector(in2)) { >> >> I read: >> >> !(in1->as_VectorMaskCmp()->predicate_can_be_negated() || >> !VectorNode::is_all_ones_vector(in2))) { >> >> That confused me a lot... absolutely my bad. >> >> Well actually then my indentation suggestion was terrible! > > I made a new suggestion below. > A code comment would be helpful for this case. I updated the comment above the code a bit. As for why predicate need to be negatable, it's straightforward, the key of this optimization is to change predicate condition into negative predicate condition. And in `predicate_can_be_negated`, there's a comment explaining when predicate can't be negated. > I made a new suggestion below. Done. > That confused me a lot... absolutely my bad. Well actually then my indentation suggestion was terrible! No problem. I'm a newbie in the JDK community, so generally I think your suggestions are valuable.Thanks for your review! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24674#discussion_r2194130234 From egahlin at openjdk.org Wed Jul 9 08:27:26 2025 From: egahlin at openjdk.org (Erik Gahlin) Date: Wed, 9 Jul 2025 08:27:26 GMT Subject: RFR: 8361640: JFR: RandomAccessFile::readLine emits events for each character Message-ID: Could I have a review of the change that prevents RandomAccessFile::readLine from emitting an event per character? This leads to unnecessary overhead, both with or without JFR enabled. Testing: tier1 + jdk/jdk/jfr Thanks Erik ------------- Commit messages: - Remove mistakenly added file - Initial Changes: https://git.openjdk.org/jdk/pull/26210/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26210&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8361640 Stats: 21 lines in 1 file changed: 19 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/26210.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26210/head:pull/26210 PR: https://git.openjdk.org/jdk/pull/26210 From fgao at openjdk.org Wed Jul 9 09:01:49 2025 From: fgao at openjdk.org (Fei Gao) Date: Wed, 9 Jul 2025 09:01:49 GMT Subject: RFR: 8359419: AArch64: Relax min vector length to 32-bit for short vectors [v4] In-Reply-To: References: Message-ID: On Wed, 9 Jul 2025 01:23:43 GMT, Xiaohong Gong wrote: >> ### Background >> On AArch64, the minimum vector length supported is 64-bit for basic types, except for `byte` and `boolean` (32-bit and 16-bit respectively to match special Vector API features). This limitation prevents intrinsification of vector type conversions between `short` and wider types (e.g. `long/double`) in Vector API when the entire vector length is within 128 bits, resulting in degraded performance for such conversions. >> >> For example, type conversions between `ShortVector.SPECIES_128` and `LongVector.SPECIES_128` are not supported on AArch64 NEON and SVE architectures with 128-bit max vector size. This occurs because the compiler would need to generate a vector with 2 short elements, resulting in a 32-bit vector size. >> >> To intrinsify such type conversion APIs, we need to relax the min vector length constraint from 64-bit to 32-bit for short vectors. >> >> ### Impact Analysis >> #### 1. Vector types >> Vectors only with `short` element types will be affected, as we just supported 32-bit `short` vectors in this change. >> >> #### 2. Vector API >> No impact on Vector API or the vector-specific nodes. The minimum vector shape at API level remains 64-bit. It's not possible to generate a final vector IR with 32-bit vector size. Type conversions may generate intermediate 32-bit vectors, but they will be resized or cast to vectors with at least 64-bit length. >> >> #### 3. Auto-vectorization >> Enables vectorization of cases containing only 2 `short` lanes, with significant performance improvements. Since we have supported 32-bit vectors for `byte` type for a long time, extending this to `short` did not introduce additional risks. >> >> #### 4. Codegen of vector nodes >> NEON doesn't support 32-bit SIMD instructions, so we use 64-bit instructions instead. For lanewise operations, this is safe because the higher half bits can be ignored. >> >> Details: >> - Lanewise vector operations are unaffected as explained above. >> - NEON supports vector load/store instructions with 32-bit vector size, which we already use in relevant IRs (shared by SVE). >> - Cross-lane operations like reduction may be affected, potentially causing incorrect results for `min/max/mul/and` reductions. The min vector size for such operations should remain 64-bit. We've added assertions in match rules. Since it's currently not possible to generate such reductions (Vector API minimum is 64-bit, and SLP doesn't support subword type reductions), we maintain the status quo. However, addin... > > Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision: > > Disable auto-vectorization of double to short conversion for NEON and update tests @XiaohongGong Thanks for testing it, and also for your update ? much appreciated! ------------- Marked as reviewed by fgao (Committer). PR Review: https://git.openjdk.org/jdk/pull/26057#pullrequestreview-3000660649 From alanb at openjdk.org Wed Jul 9 09:04:38 2025 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 9 Jul 2025 09:04:38 GMT Subject: RFR: 8361640: JFR: RandomAccessFile::readLine emits events for each character In-Reply-To: References: Message-ID: On Wed, 9 Jul 2025 05:45:01 GMT, Erik Gahlin wrote: > Testing: tier1 + jdk/jdk/jfr The tests for this area are in tier2 (not tier1). I think we'll need to see if a test can be added as it's way too easy to refactor this code and re-introduce the issue. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26210#issuecomment-3051782421 PR Comment: https://git.openjdk.org/jdk/pull/26210#issuecomment-3051784996 From xgong at openjdk.org Wed Jul 9 09:09:41 2025 From: xgong at openjdk.org (Xiaohong Gong) Date: Wed, 9 Jul 2025 09:09:41 GMT Subject: RFR: 8359419: AArch64: Relax min vector length to 32-bit for short vectors [v4] In-Reply-To: References: Message-ID: On Wed, 9 Jul 2025 01:23:43 GMT, Xiaohong Gong wrote: >> ### Background >> On AArch64, the minimum vector length supported is 64-bit for basic types, except for `byte` and `boolean` (32-bit and 16-bit respectively to match special Vector API features). This limitation prevents intrinsification of vector type conversions between `short` and wider types (e.g. `long/double`) in Vector API when the entire vector length is within 128 bits, resulting in degraded performance for such conversions. >> >> For example, type conversions between `ShortVector.SPECIES_128` and `LongVector.SPECIES_128` are not supported on AArch64 NEON and SVE architectures with 128-bit max vector size. This occurs because the compiler would need to generate a vector with 2 short elements, resulting in a 32-bit vector size. >> >> To intrinsify such type conversion APIs, we need to relax the min vector length constraint from 64-bit to 32-bit for short vectors. >> >> ### Impact Analysis >> #### 1. Vector types >> Vectors only with `short` element types will be affected, as we just supported 32-bit `short` vectors in this change. >> >> #### 2. Vector API >> No impact on Vector API or the vector-specific nodes. The minimum vector shape at API level remains 64-bit. It's not possible to generate a final vector IR with 32-bit vector size. Type conversions may generate intermediate 32-bit vectors, but they will be resized or cast to vectors with at least 64-bit length. >> >> #### 3. Auto-vectorization >> Enables vectorization of cases containing only 2 `short` lanes, with significant performance improvements. Since we have supported 32-bit vectors for `byte` type for a long time, extending this to `short` did not introduce additional risks. >> >> #### 4. Codegen of vector nodes >> NEON doesn't support 32-bit SIMD instructions, so we use 64-bit instructions instead. For lanewise operations, this is safe because the higher half bits can be ignored. >> >> Details: >> - Lanewise vector operations are unaffected as explained above. >> - NEON supports vector load/store instructions with 32-bit vector size, which we already use in relevant IRs (shared by SVE). >> - Cross-lane operations like reduction may be affected, potentially causing incorrect results for `min/max/mul/and` reductions. The min vector size for such operations should remain 64-bit. We've added assertions in match rules. Since it's currently not possible to generate such reductions (Vector API minimum is 64-bit, and SLP doesn't support subword type reductions), we maintain the status quo. However, addin... > > Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision: > > Disable auto-vectorization of double to short conversion for NEON and update tests Hi @eme64 , could you please help take a look at this patch especially the test part since most of the tests are SLP related? It will be helpful if you could also help trigger a testing for it. Thanks for your time! ------------- PR Comment: https://git.openjdk.org/jdk/pull/26057#issuecomment-3051800402 From epeter at openjdk.org Wed Jul 9 09:16:44 2025 From: epeter at openjdk.org (Emanuel Peter) Date: Wed, 9 Jul 2025 09:16:44 GMT Subject: RFR: 8359419: AArch64: Relax min vector length to 32-bit for short vectors [v4] In-Reply-To: References: Message-ID: On Wed, 9 Jul 2025 09:06:44 GMT, Xiaohong Gong wrote: >> Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision: >> >> Disable auto-vectorization of double to short conversion for NEON and update tests > > Hi @eme64 , could you please help take a look at this patch especially the test part since most of the tests are SLP related? It will be helpful if you could also help trigger a testing for it. Thanks for your time! @XiaohongGong I would love to review and test, but I'm about to go on vacation and will only be back in August. I've pinged some others internally, and hope someone will pick this up! ------------- PR Comment: https://git.openjdk.org/jdk/pull/26057#issuecomment-3051824198 From xgong at openjdk.org Wed Jul 9 09:19:42 2025 From: xgong at openjdk.org (Xiaohong Gong) Date: Wed, 9 Jul 2025 09:19:42 GMT Subject: RFR: 8359419: AArch64: Relax min vector length to 32-bit for short vectors [v4] In-Reply-To: References: Message-ID: On Wed, 9 Jul 2025 09:06:44 GMT, Xiaohong Gong wrote: >> Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision: >> >> Disable auto-vectorization of double to short conversion for NEON and update tests > > Hi @eme64 , could you please help take a look at this patch especially the test part since most of the tests are SLP related? It will be helpful if you could also help trigger a testing for it. Thanks for your time! > @XiaohongGong I would love to review and test, but I'm about to go on vacation and will only be back in August. I've pinged some others internally, and hope someone will pick this up! Thanks a lot for the help! Sounds good to me and have a good holiday! ------------- PR Comment: https://git.openjdk.org/jdk/pull/26057#issuecomment-3051835903 From asotona at openjdk.org Wed Jul 9 09:54:47 2025 From: asotona at openjdk.org (Adam Sotona) Date: Wed, 9 Jul 2025 09:54:47 GMT Subject: RFR: 8361615: CodeBuilder::parameterSlot throws undocumented IOOBE In-Reply-To: References: Message-ID: On Tue, 8 Jul 2025 18:46:00 GMT, Chen Liang wrote: > In a recent inspection of all methods that accept an `int` argument in the Class-File API, I noticed this method that validates its argument but did not document the validation. The behavior is to throw IOOBE. We can simply document this behavior and enhance existing tests to verify exceptional behaviors in addition to anticipated outputs. > > This is doc plus test only, so should be eligible for backport regardless of priority. A CSR will be created to track this new assertion in the spec. > > Testing: jdk/jdk/classfile/BuilderParamTest.java Looks good to me. ------------- Marked as reviewed by asotona (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26200#pullrequestreview-3000846353 From asotona at openjdk.org Wed Jul 9 10:10:37 2025 From: asotona at openjdk.org (Adam Sotona) Date: Wed, 9 Jul 2025 10:10:37 GMT Subject: RFR: 8361614: Missing sub-int value validation in the Class-File API [v2] In-Reply-To: References: Message-ID: On Tue, 8 Jul 2025 20:28:23 GMT, Chen Liang wrote: >> In the `class` file format, a lot of the values are `u1` or `u2`; the Class-File API consistently model them with `int`. However, the API does not, in general, validate that int values passed to the factory methods are not out of the bounds as defined in the class file format. This patch proposes to add such validation for factory methods accepting such more narrow data, prepared by examining all `int`-accepting methods in the Class-File API. >> >> I expect this to have a small compatibility impact - besides the -1 for the minor version, there is no other places where most significant bits are ever meaningful, and I special cased it and consistently fail fast for all other OOB values, which always mean programmer errors. >> >> A CSR will be created soon as well. > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > Fix style Nice summary fix of the validation. ------------- Marked as reviewed by asotona (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26201#pullrequestreview-3000909266 From bkilambi at openjdk.org Wed Jul 9 10:45:46 2025 From: bkilambi at openjdk.org (Bhavana Kilambi) Date: Wed, 9 Jul 2025 10:45:46 GMT Subject: RFR: 8359419: AArch64: Relax min vector length to 32-bit for short vectors [v4] In-Reply-To: References: Message-ID: On Wed, 9 Jul 2025 01:23:43 GMT, Xiaohong Gong wrote: >> ### Background >> On AArch64, the minimum vector length supported is 64-bit for basic types, except for `byte` and `boolean` (32-bit and 16-bit respectively to match special Vector API features). This limitation prevents intrinsification of vector type conversions between `short` and wider types (e.g. `long/double`) in Vector API when the entire vector length is within 128 bits, resulting in degraded performance for such conversions. >> >> For example, type conversions between `ShortVector.SPECIES_128` and `LongVector.SPECIES_128` are not supported on AArch64 NEON and SVE architectures with 128-bit max vector size. This occurs because the compiler would need to generate a vector with 2 short elements, resulting in a 32-bit vector size. >> >> To intrinsify such type conversion APIs, we need to relax the min vector length constraint from 64-bit to 32-bit for short vectors. >> >> ### Impact Analysis >> #### 1. Vector types >> Vectors only with `short` element types will be affected, as we just supported 32-bit `short` vectors in this change. >> >> #### 2. Vector API >> No impact on Vector API or the vector-specific nodes. The minimum vector shape at API level remains 64-bit. It's not possible to generate a final vector IR with 32-bit vector size. Type conversions may generate intermediate 32-bit vectors, but they will be resized or cast to vectors with at least 64-bit length. >> >> #### 3. Auto-vectorization >> Enables vectorization of cases containing only 2 `short` lanes, with significant performance improvements. Since we have supported 32-bit vectors for `byte` type for a long time, extending this to `short` did not introduce additional risks. >> >> #### 4. Codegen of vector nodes >> NEON doesn't support 32-bit SIMD instructions, so we use 64-bit instructions instead. For lanewise operations, this is safe because the higher half bits can be ignored. >> >> Details: >> - Lanewise vector operations are unaffected as explained above. >> - NEON supports vector load/store instructions with 32-bit vector size, which we already use in relevant IRs (shared by SVE). >> - Cross-lane operations like reduction may be affected, potentially causing incorrect results for `min/max/mul/and` reductions. The min vector size for such operations should remain 64-bit. We've added assertions in match rules. Since it's currently not possible to generate such reductions (Vector API minimum is 64-bit, and SLP doesn't support subword type reductions), we maintain the status quo. However, addin... > > Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision: > > Disable auto-vectorization of double to short conversion for NEON and update tests Thanks for making the changes. Looks good to me. ------------- Marked as reviewed by bkilambi (Author). PR Review: https://git.openjdk.org/jdk/pull/26057#pullrequestreview-3001022247 From dlunden at openjdk.org Wed Jul 9 11:11:51 2025 From: dlunden at openjdk.org (Daniel =?UTF-8?B?THVuZMOpbg==?=) Date: Wed, 9 Jul 2025 11:11:51 GMT Subject: RFR: 8359419: AArch64: Relax min vector length to 32-bit for short vectors [v4] In-Reply-To: References: Message-ID: On Wed, 9 Jul 2025 09:17:13 GMT, Xiaohong Gong wrote: >> Hi @eme64 , could you please help take a look at this patch especially the test part since most of the tests are SLP related? It will be helpful if you could also help trigger a testing for it. Thanks for your time! > >> @XiaohongGong I would love to review and test, but I'm about to go on vacation and will only be back in August. I've pinged some others internally, and hope someone will pick this up! > > Thanks a lot for the help! Sounds good to me and have a good holiday! @XiaohongGong I'll run some tests and have a look at the changes as well (@eme64 asked me). I'll get back to you shortly! ------------- PR Comment: https://git.openjdk.org/jdk/pull/26057#issuecomment-3052222395 From viktor.klang at oracle.com Wed Jul 9 11:51:57 2025 From: viktor.klang at oracle.com (Viktor Klang) Date: Wed, 9 Jul 2025 11:51:57 +0000 Subject: [External] : Re: Should mapConcurrent() respect time order instead of input order? In-Reply-To: References: Message-ID: Hi Ben, Glad to hear that you were able to construct a custom Gatherer which meets your needs! Cheers, ? Viktor Klang Software Architect, Java Platform Group Oracle ________________________________ From: Jige Yu Sent: Tuesday, 1 July 2025 06:55 To: Viktor Klang Cc: core-libs-dev at openjdk.org Subject: Re: [External] : Re: Should mapConcurrent() respect time order instead of input order? Hi Viktor, Thanks again for encouraging me to give it a try with an alternative mapConcurrently() gatherer. I've completed the experiment and have some interesting results to share. As we discussed earlier, the current mapConcurrent()'s spec to maintain encounter order creates limitations for certain use cases where optimizing concurrency is more important. Specifically, for scenarios like a race() operation (taking the first successful result from N candidates) or long-running heartbeat/monitoring tasks with sibling operations, the encounter-order preservation can lead to the gatherer halting or tasks not getting a chance to execute. I've implemented an experimental mapConcurrently() gatherer that drops the requirement of maintaining encounter order. I then set up a test case involving a simulated heartbeat task, designed to highlight the issue. The results confirmed my hypothesis: ________________________________ Experiment Findings * The existing mapConcurrent() indeed halts when faced with a heartbeat task that doesn't exit (but keeps running until other operations are complete), will halt by operations beyond maxConcurrency from ever being run due to the maxConcurrency limit and the need to preserve order. * The alternative mapConcurrently() gatherer runs just fine under the same conditions, demonstrating that removing the encounter-order requirement allows all tasks to execute concurrently and independently, without being blocked by earlier, slower operations, or halt. ________________________________ This experiment demonstrates the potential benefits of an unordered mapConcurrently() gatherer for specific high-concurrency, non-blocking use cases. It could significantly broaden the applicability of gatherers for scenarios where throughput and responsiveness are prioritized over strict ordering. Best regards, Ben Yu On Mon, Jun 9, 2025 at 1:49?AM Viktor Klang > wrote: Hi Jige, Yes, let's see what developers need. ? In the meantime, I want to reiterate that it is possible to build what you're asking for, outside of the JDK. To gather experience, feedback, and ultimately decide if the feature is worthwhile. Cheers, ? Viktor Klang Software Architect, Java Platform Group Oracle ________________________________ From: Jige Yu > Sent: Sunday, 8 June 2025 07:39 To: Viktor Klang > Cc: core-libs-dev at openjdk.org > Subject: Re: [External] : Re: Should mapConcurrent() respect time order instead of input order? Hi Viktor, Thank you for pointing to the spec. You are absolutely right, that is the documented behavior. My feedback is aimed directly at questioning that specific design choice within the specification. My perspective is that the benefit of preserving stream ordering may be outweighed by the significant trade-offs it introduces?namely, the potential for surprising performance behavior (like reduced throughput or task starvation) and the loss of flexibility for implementing common concurrent patterns like race semantics. I understand if the design for the current release is finalized, but I believe this feedback is relevant for the ongoing evolution of the API. Best regards, On Wed, Jun 4, 2025 at 11:22?AM Viktor Klang > wrote: >Ultimately, the question is whether mapConcurrent() should be optimized primarily for preserving input sequence, or for enabling maximum throughput and flexibility in concurrent scenarios, including efficient "first-to-finish" patterns. The answer to that is clear in the specification for the operation: ?This operation preserves the ordering of the stream.? - http://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/util/stream/Gatherers.html#mapConcurrent(int,java.util.function.Function) Cheers, ? Viktor Klang Software Architect, Java Platform Group Oracle ________________________________ From: Jige Yu > Sent: Wednesday, 4 June 2025 18:18 To: Viktor Klang > Cc: core-libs-dev at openjdk.org > Subject: Re: [External] : Re: Should mapConcurrent() respect time order instead of input order? Hi Viktor, Thank you for the detailed explanation and the links to the Javadoc for findFirst() and limit(). You're absolutely correct in your characterization of these operations ? they are indeed concerned with encounter order, and parallel execution doesn't inherently change that unless the stream is explicitly unordered. I want to clarify a few of my points that I didn't explain clearly (see below). On Wed, Jun 4, 2025 at 7:38?AM Viktor Klang > wrote: Hi Jige, First of all?you're most welcome. Thanks for your insightful questions. >Temptation for Race Semantics: The beauty of mapConcurrent() integrating with the Stream API means developers will naturally be drawn to use it for race-like scenarios. Operations like findFirst() or limit(N) to get the first few completed results are very intuitive combinations. It's important to distinguish between spatial (encounter) order and temporal (availability) order. If we look at `Stream::findFirst()` we see: ?Returns an Optional describing the first element of this stream, or an empty Optional if the stream is empty. If the stream has no encounter order, then any element may be returned.? - https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/util/stream/Stream.html#findFirst() And if we look at `Stream::limit(long)` we see: ?While limit() is generally a cheap operation on sequential stream pipelines, it can be quite expensive on ordered parallel pipelines, especially for large values of maxSize, since limit(n) is constrained to return not just any n elements, but the first n elements in the encounter order. ? (emphasis mine) - https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/util/stream/Stream.html#limit(long) So, we can conclude that "first" and "limit" are about encounter order, and we can conclude that the presence of parallel does not change that?only "unorderedness" may change that. My apologies if my previous example using findFirst() wasn't as clear as it could have been. I'd like to clarify how I see the interaction with mapConcurrent() playing out: 1. mapConcurrent()'s Influence on Encounter Order: When I mentioned using findFirst() (or limit()) for race semantics, the implicit assumption was how mapConcurrent() would feed elements into these terminal operations. The "encounter order" that findFirst() sees is precisely what mapConcurrent() emits. If mapConcurrent() emits results strictly according to input order, then findFirst() will respect that. However, if an unordered mapConcurrent() were to emit results in their temporal order of completion, then findFirst() would naturally pick the first one that actually finished, effectively achieving a race. My point is that mapConcurrent() is in a position to define the encounter order that downstream operations like findFirst() will act upon. The surprise isn't with findFirst()'s definition, but with how a strictly ordered mapConcurrent() might prevent it from being used effectively for "first-to-finish" logic. 2. The Role of findAny(): You're right that my example using findFirst() was more nuanced than I intuitively assumed. A developer well-versed in the Stream API nuances might indeed opt for findAny() to implement race semantics, especially given its Javadoc explicitly mentioning suitability for "maximal performance in parallel operations." findAny() is designed to return any element, which aligns well with picking the temporally first available result from an unordered concurrent process. 3. Aligning Spec with Intuition: My broader concern is about the intuitive use of these powerful new tools. If mapConcurrent() maintains strict input ordering, it's a perfectly valid and understandable specification by itself. However, the potential for surprise arises when developers, especially those less acquainted with every fine print of stream ordering, attempt to combine mapConcurrent() with findFirst() or findAny() to build common concurrent utilities like a race. They might intuitively expect that "concurrent mapping" followed by "find first/any" would yield the result that completes earliest. While developers should read all related documentation, there's also a design ideal where the API's behavior aligns closely with reasonable developer intuition, especially for common patterns. An unordered mapConcurrent() (or an option for it) would, in my view, better support this intuitive use for race-like patterns. Whereas, I have my doubts that developers commonly would intuitively assume a concurrent operation to stick to strict ordering (it's not what we are used to in most concurrent or multil-threading scenarios) Ultimately, the question is whether mapConcurrent() should be optimized primarily for preserving input sequence, or for enabling maximum throughput and flexibility in concurrent scenarios, including efficient "first-to-finish" patterns. >Surprise for Race Semantics Users: Following from the above, it could be surprising for developers when they realize that the inherent input ordering of mapConcurrent() means it's not optimized for these race scenarios. The expectation would be that findFirst() returns as soon as any task completes, but ordering can delay this if an earlier task (in input order) is slower. This should be addressed above. >Ordering Assumption in Concurrency: My experience is that ordering is not typically a default assumption when dealing with operations explicitly marked as "parallel" or "concurrent." For instance, Stream.forEach() on a parallel stream does not guarantee encounter order, presumably for performance reasons ? a similar trade-off to what's being discussed for mapConcurrent(). Developers often consult documentation for ordering guarantees in concurrent contexts rather than assuming them. This should also be addressed above. >Expectation of "True" Concurrency: When I see an API like mapConcurrent(maxConcurrency, mapper), my mental model is that if maxConcurrency permits, new tasks should be initiated as soon as a slot is free. This is interesting, because this is how mapConcurrent used to work. It only placed the limit of concurrent work in progress and not work not yet possible to propagate downstream. This was changed, because a delayed initial (in encounter order) item may let subsequent (completed) work queue up indefinitely. So in conclusion, there's still room for a different take on "mapConcurrentReorder" (name of course left up to the reader), and the good news is that such a Gatherer can be implemented, evaluated, hardened, etc outside of the JDK?and potentially some day something like it ends up in the JDK. Your mention of a potential mapConcurrentReorder() also brings to mind a thought about API consistency with existing Stream conventions. We see patterns like Stream.forEach() (which for parallel streams doesn't guarantee encounter order, prioritizing performance) versus Stream.forEachOrdered() (which explicitly enforces it). If mapConcurrent() were to follow a similar naming convention, it might suggest that the base mapConcurrent() itself would be the version optimized for throughput (and thus potentially unordered by default), while a hypothetical mapConcurrentOrdered() would be the variant explicitly providing the strict ordering guarantee. This is an observation on how naming might align with established JDK patterns to intuitively guide user expectations about the default behavior. This naturally leads to the inherent challenge in designing such an API. It seems we're trying to balance three desirable, but sometimes conflicting, goals: 1. Strict Encounter Ordering: Results are emitted in the same order as the input elements. 2. Bounded Memory Buffering: Avoid out-of-memory errors by not letting completed but un-emitted results queue up indefinitely. 3. Optimized (True) Concurrency: If maxConcurrency is set (e.g., to N), the system strives to have N tasks actively running whenever there are pending input elements and available concurrency slots, rather than being stalled by a slow-to-complete but earlier-in-sequence task. It appears that achieving all three simultaneously is not possible, and a compromise must be made. From my perspective: * Goal #2 (Bounded Memory) is non-negotiable; OOM situations are generally unacceptable. * Goal #3 (Optimized Concurrency) feels fundamental to an API named mapConcurrent(). Users will likely expect it to maximize the concurrent execution of tasks up to the specified limit. Deviations from this, often necessitated by strict adherence to Goal #1, can lead to surprises. * Goal #1 (Strict Ordering), while a "nice-to-have" and sometimes beneficial, might not always align with common developer intuition for operations explicitly labeled "concurrent," especially if it compromises true concurrency. As discussed, ordering can often be reintroduced by the caller if specifically needed. The current implementation understandably prioritizes #1 (Ordering) and #2 (Bounded Memory). However, this prioritization can lead to situations where #3 (Optimized Concurrency) is not fully realized, which can be counter-intuitive. I've already mentioned the race scenario. Consider another example where this becomes particularly evident. Imagine a scenario with a long-running task (e.g., for periodic monitoring) combined with a stream of other "real" tasks: Java // Main tasks List> realTasks = ... ; // A long-running monitoring task Callable longRunningMonitoringTask = () -> { while (!allRealTasksSeemDone()) { // Simplified condition System.out.println("Monitoring..."); Thread.sleep(5000); } return null; }; Stream> allTasks = Stream.concat( Stream.of(longRunningMonitoringTask), realTasks.stream().map(task -> (Callable) task) ); allTasks .gather(Gatherers.mapConcurrent(MAX_CONCURRENCY, callable -> callable.call())) .forEach(result -> { /* output results */ }); The longRunningMonitoringTask would usually be the first element, with the current strictly ordered behavior, it would occupy one of the MAX_CONCURRENCY slots. and as soon as MAX_CONCURRENCY tasks are executed, completed or not, all subsequent realTasks (beyond the first one) would be starved, unable to even start until the longRunningMonitoringTask completes?which is never. This creates a deadlock or significant processing delay that would likely surprise a developer expecting tasks to proceed concurrently up to the maxConcurrency limit. An implementation more aligned with the "base name implies throughput" idea (as per the forEach analogy) would likely handle this more gracefully by letting tasks run truly concurrently without an implicit ordering dependency. This reinforces my belief that an alternative gatherer, or a default behavior for mapConcurrent() that prioritizes concurrency (as the name mapConcurrent might suggest to many, akin to forEach), could be very valuable. I understand this might be something that evolves outside the JDK initially, and I appreciate you highlighting that path. Thanks again for the continued discussion and the transparency about the design choices. Best regards, Cheers, ? Viktor Klang Software Architect, Java Platform Group Oracle ________________________________ From: Jige Yu > Sent: Wednesday, 4 June 2025 16:20 To: Viktor Klang > Cc: core-libs-dev at openjdk.org > Subject: Re: [External] : Re: Should mapConcurrent() respect time order instead of input order? Hi Viktor, Thank you for sharing that the general feedback on mapConcurrent() has been positive and for the insights into the ongoing enhancements, especially around interruption handling and work-in-progress tracking. To clarify my own position, I am also extremely enthusiastic about the mapConcurrent() API overall. It offers an elegant and straightforward way to manage homogenous, I/O-intensive concurrent tasks within a structured concurrency model, which is a significant improvement and a much-needed addition. My feedback on ordering is aimed at maximizing its potential. I'd like to elaborate on a few specific scenarios and expectations that inform my perspective on the ordering: 1. Temptation for Race Semantics: The beauty of mapConcurrent() integrating with the Stream API means developers will naturally be drawn to use it for race-like scenarios. Operations like findFirst() or limit(N) to get the first few completed results are very intuitive combinations. For example: Java // Hypothetical use case: find the fastest responding service Optional fastestResult = serviceUrls.stream() .gather(Gatherers.mapConcurrent(MAX_CONCURRENCY, url -> fetch(url))) .findFirst(); 2. Surprise for Race Semantics Users: Following from the above, it could be surprising for developers when they realize that the inherent input ordering of mapConcurrent() means it's not optimized for these race scenarios. The expectation would be that findFirst() returns as soon as any task completes, but ordering can delay this if an earlier task (in input order) is slower. 3. Ordering Assumption in Concurrency: My experience is that ordering is not typically a default assumption when dealing with operations explicitly marked as "parallel" or "concurrent." For instance, Stream.forEach() on a parallel stream does not guarantee encounter order, presumably for performance reasons ? a similar trade-off to what's being discussed for mapConcurrent(). Developers often consult documentation for ordering guarantees in concurrent contexts rather than assuming them. 4. Expectation of "True" Concurrency: When I see an API like mapConcurrent(maxConcurrency, mapper), my mental model is that if maxConcurrency permits, new tasks should be initiated as soon as a slot is free. For example, with maxConcurrency=2: * Task 1 starts. * Task 2 starts. * If Task 2 finishes while Task 1 is still running, I would expect Task 3 to run concurrently alongside task 1, because the max concurrency is 2, not 1. The current ordered behavior, where Task 3 might have to wait for Task 1 to complete before its result can be processed (even if Task 3 itself could have started and finished), can feel a bit counterintuitive to the notion of maximizing concurrency up to the specified limit. It almost feels like not a "max concurrency", but "max buffer size". These points are offered to highlight potential areas where the current default could lead to subtle surprises or suboptimal performance for useful concurrent patterns. Thanks again for the open discussion and for your work on these valuable additions to the JDK. Best regards, On Tue, Jun 3, 2025 at 2:13?AM Viktor Klang > wrote: The general feedback received thus far has been primarily positive. There have been a few behavior-related enhancements over the previews to better handle interruption (there's still room to improve there, as per our concurrent conversation) as well as some improvements to work-in-progress tracking. It will be interesting to see which Gatherer-based operations will be devised by Java developers in the future. Cheers, ? Viktor Klang Software Architect, Java Platform Group Oracle ________________________________ From: Jige Yu > Sent: Monday, 2 June 2025 18:54 To: Viktor Klang > Cc: core-libs-dev at openjdk.org > Subject: Re: [External] : Re: Should mapConcurrent() respect time order instead of input order? Hi Viktor, Thanks for your reply and for sharing your experience regarding user preferences. I appreciate that perspective. You're right, if an unordered version of mapConcurrent proves to be widely beneficial and is implemented and adopted by the community, it could certainly make a strong case for future inclusion in the JDK. I wanted to clarify a nuance regarding user preference that I might not have articulated clearly before. If the question is simply "ordered or unordered?", in isolation, I can see why many, myself included, might lean towards "ordered" as a general preference. However, the decision becomes more complex when the associated trade-offs are considered. If the question were phrased more like, "Do you prefer an ordered mapConcurrent by default, even if it entails potential performance overhead and limitations for certain use cases like race() operations, versus an unordered version that offers higher throughput and broader applicability in such scenarios?" my (and perhaps others') answer might differ. The perceived cost versus benefit of ordering changes significantly when these factors are explicit. My initial suggestion stemmed from the belief that the performance and flexibility gains of an unordered approach for I/O-bound tasks would, in many practical situations, outweigh the convenience of default ordering, especially since ordering can be reintroduced relatively easily, and explicitly, when needed. Thanks again for the discussion. Best regards, On Mon, Jun 2, 2025 at 8:51?AM Viktor Klang > wrote: >My perspective is that strict adherence to input order for mapConcurrent() might not be the most common or beneficial default behavior for users. If there is indeed a majority who would benefit from an unordered version of mapConcurrent (my experience is that the majority prefer ordered) then, since it is possible to implement such a Gatherer outside of the JDK, this is something which will be constructed, widely used, and someone will then propose to add something similar to the JDK. >While re-implementing the gatherer is a possibility, the existing implementation is non-trivial, and creating a custom, robust alternative represents a significant undertaking. The existing version needs to maintain order, which adds to the complexity of the implementation. Implementing an unordered version would likely look different. I'd definitely encourage taking the opportunity to attempt to implement it. Cheers, ? Viktor Klang Software Architect, Java Platform Group Oracle ________________________________ From: Jige Yu > Sent: Monday, 2 June 2025 17:05 To: Viktor Klang > Cc: core-libs-dev at openjdk.org > Subject: Re: [External] : Re: Should mapConcurrent() respect time order instead of input order? Thank you for your response and for considering my feedback on the mapConcurrent() gatherer. I understand and respect that the final decision rests with the JDK maintainers. I would like to offer a couple of further points for consideration. My perspective is that strict adherence to input order for mapConcurrent() might not be the most common or beneficial default behavior for users. I'd be very interested to see any research or data that suggests otherwise, as that would certainly inform my understanding. From my experience, a more common need is for higher throughput in I/O-intensive operations. The ability to support use cases like race()?where the first successfully completed operation determines the outcome?also seems like a valuable capability that is currently infeasible due to the ordering constraint. As I see it, if a developer specifically requires the input order to be preserved, this can be achieved with relative ease by applying a subsequent sorting operation. For instance: .gather(mapConcurrent(...)) .sorted(Comparator.comparing(Result::getInputSequenceId)) The primary challenge in these scenarios is typically the efficient fan-out and execution of concurrent tasks, not the subsequent sorting of results. Conversely, as you've noted, there isn't a straightforward way to modify the current default ordered behavior to achieve the higher throughput or race() semantics that an unordered approach would naturally provide. While re-implementing the gatherer is a possibility, the existing implementation is non-trivial, and creating a custom, robust alternative represents a significant undertaking. My hope was that an unordered option could be a valuable addition to the standard library, benefiting a wider range of developers. Thank you again for your time and consideration. On Mon, Jun 2, 2025 at 7:48?AM Viktor Klang > wrote: >Even if it by default preserves input order, when I explicitly called stream.unordered(), could mapConcurrent() respect that and in return achieve higher throughput with support for race? The Gatherer doesn't know whether the Stream is unordered or ordered. The operation should be semantically equivalent anyway. Cheers, ? Viktor Klang Software Architect, Java Platform Group Oracle ________________________________ From: Jige Yu > Sent: Monday, 2 June 2025 16:29 To: Viktor Klang >; core-libs-dev at openjdk.org > Subject: [External] : Re: Should mapConcurrent() respect time order instead of input order? Sorry. Forgot to copy to the mailing list. On Mon, Jun 2, 2025 at 7:27?AM Jige Yu > wrote: Thanks Viktor! I was thinking from my own experience that I wouldn't have automatically assumed that a concurrent fanout library would by default preserve input order. And I think wanting high throughput with real-life utilities like race would be more commonly useful. But I could be wrong. Regardless, mapConcurrent() can do both, no? Even if it by default preserves input order, when I explicitly called stream.unordered(), could mapConcurrent() respect that and in return achieve higher throughput with support for race? On Mon, Jun 2, 2025 at 2:33?AM Viktor Klang > wrote: Hi! In a similar vein to the built-in Collectors, the built-in Gatherers provide solutions to common stream-related problems, but also, they also serve as "inspiration" for developers for what is possible to implement using Gatherers. If someone, for performance reasons, and with a use-case which does not require encounter-order, want to take advantage of that combination of circumstances, it is definitely possible to implement your own Gatherer which has that behavior. Cheers, ? Viktor Klang Software Architect, Java Platform Group Oracle ________________________________ From: core-libs-dev > on behalf of Jige Yu > Sent: Sunday, 1 June 2025 21:08 To: core-libs-dev at openjdk.org > Subject: Should mapConcurrent() respect time order instead of input order? It seems like for most people, input order isn't that important for concurrent work, and concurrent results being in non-deterministic order is often expected. If mapConcurrent() just respect output encounter order: It'll be able to achieve higher throughput if an early task is slow, For example, with concurrency=2, and if the first task takes 10 minutes to run, mapConcurrent() would only be able to process 2 tasks within the first 10 minutes; whereas with encounter order, the first task being slow doesn't block the 3rd - 100th elements from being processed and output. mapConcurrent() can be used to implement useful concurrent semantics, for example to support race semantics. Imagine if I need to send request to 10 candidate backends and take whichever that succeeds first, I'd be able to do: backends.stream() .gather(mapConcurrent( backend -> { try { return backend.fetchOrder(); } catch (RpcException e) { return null; // failed to fetch but not fatal } }) .filter(Objects::notNull) .findFirst(); // first success then cancel the rest Cheers, -------------- next part -------------- An HTML attachment was scrubbed... URL: From liach at openjdk.org Wed Jul 9 13:25:22 2025 From: liach at openjdk.org (Chen Liang) Date: Wed, 9 Jul 2025 13:25:22 GMT Subject: RFR: 8360163: Replace hard-coded checks with AOTRuntimeSetup and AOTSafeClassInitializer [v11] In-Reply-To: References: Message-ID: > I have updated this patch to avoid a redundant `runtimeSetup` annotation - we have agreed that the requirement for setup is a side effect of initialization, and such methods in AOTCI classes must be automatically recognized. This latest revision implements that model. > > I intentionally avoided handling Class and ClassLoader `resetArchivedStates` and `MethodType::assemblySetup` - we talked about a generic `assemblyCleanup` method, but I did not find out where is the best place to call such a method in the assembly phase. We cna handle this in a subsequent patch. > > In particular, please review the new AOT.md design document - I split it from the AOTCI annotation to prevent jamming; we can put general AOT information there when we have more AOT-specific annotations. > > --- > > Old description: > Currently, the list of classes that have interdependencies and those that need runtimeSetup are maintained in a hardcoded list in CDS. This makes it risky for core library developers as they might introduce new interdependencies and observe CDS to fail. By moving the mechanism of these lists to core library annotations as a first step, we can gradually expose the AOT contracts as program semantics described by internal annotations, and also helps us to explore how we can expose these functionalities to the public later. Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 24 commits: - Merge branch 'master' of https://github.com/openjdk/jdk into exp/cds-mh-anno - Merge branch 'master' of https://github.com/openjdk/jdk into exp/cds-mh-anno - Reviews - Documentation - Don't fail for patching tests - Remove design document from code - Some more from reviews - Reviewed the diff on github - Stage - Missed comment updates - ... and 14 more: https://git.openjdk.org/jdk/compare/a201be85...d2dd466b ------------- Changes: https://git.openjdk.org/jdk/pull/25922/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25922&range=10 Stats: 453 lines in 38 files changed: 280 ins; 150 del; 23 mod Patch: https://git.openjdk.org/jdk/pull/25922.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25922/head:pull/25922 PR: https://git.openjdk.org/jdk/pull/25922 From egahlin at openjdk.org Wed Jul 9 13:43:38 2025 From: egahlin at openjdk.org (Erik Gahlin) Date: Wed, 9 Jul 2025 13:43:38 GMT Subject: RFR: 8361640: JFR: RandomAccessFile::readLine emits events for each character In-Reply-To: References: Message-ID: On Wed, 9 Jul 2025 09:01:52 GMT, Alan Bateman wrote: > I think we'll need to see if a test can be added as it's way too easy to refactor this code and re-introduce the issue. I'm planning a follow-up PR that will check the top frame. Here's the draft: https://github.com/openjdk/jdk/pull/26211 That test will count the number of events also, so it can detect if the code is refactored. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26210#issuecomment-3052718528 From nbenalla at openjdk.org Wed Jul 9 13:51:49 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Wed, 9 Jul 2025 13:51:49 GMT Subject: RFR: 8346884: Add since checker test to jdk.editpad In-Reply-To: References: Message-ID: On Tue, 3 Jun 2025 10:09:44 GMT, Nizar Benalla wrote: > Please review this patch to add a new test to check `@since` tags in the `jdk.editpad` module. > > TIA Thanks for the review Jaikiran. This passes on all platforms in our CI ------------- PR Comment: https://git.openjdk.org/jdk/pull/25613#issuecomment-3052749566 From nbenalla at openjdk.org Wed Jul 9 13:51:50 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Wed, 9 Jul 2025 13:51:50 GMT Subject: Integrated: 8346884: Add since checker test to jdk.editpad In-Reply-To: References: Message-ID: On Tue, 3 Jun 2025 10:09:44 GMT, Nizar Benalla wrote: > Please review this patch to add a new test to check `@since` tags in the `jdk.editpad` module. > > TIA This pull request has now been integrated. Changeset: 7daf9813 Author: Nizar Benalla URL: https://git.openjdk.org/jdk/commit/7daf9813c0617ea97d95bf326eac1758e40cddd6 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod 8346884: Add since checker test to jdk.editpad Reviewed-by: jpai ------------- PR: https://git.openjdk.org/jdk/pull/25613 From duke at openjdk.org Wed Jul 9 15:30:13 2025 From: duke at openjdk.org (Darragh Conway) Date: Wed, 9 Jul 2025 15:30:13 GMT Subject: RFR: 8360411: [TEST] open/test/jdk/java/io/File/MaxPathLength.java Refactor extract method to encapsulate Windows specific test logic Message-ID: Refactored extract method to encapsulate Windows specific test logic ------------- Commit messages: - 8360411:[TEST] open/test/jdk/java/io/File/MaxPathLength.java Refactor extract method to encapsulate Windows specific Changes: https://git.openjdk.org/jdk/pull/26193/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26193&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8360411 Stats: 20 lines in 1 file changed: 11 ins; 7 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/26193.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26193/head:pull/26193 PR: https://git.openjdk.org/jdk/pull/26193 From myankelevich at openjdk.org Wed Jul 9 15:30:13 2025 From: myankelevich at openjdk.org (Mikhail Yankelevich) Date: Wed, 9 Jul 2025 15:30:13 GMT Subject: RFR: 8360411: [TEST] open/test/jdk/java/io/File/MaxPathLength.java Refactor extract method to encapsulate Windows specific test logic In-Reply-To: References: Message-ID: <_2lC8mmCVHe3H3Rx3-whw2W_Lnqf1o4fljII_lH9lks=.e645e94a-30b9-4b5a-93f8-a20d8e15069a@github.com> On Tue, 8 Jul 2025 16:10:17 GMT, Darragh Conway wrote: > Refactored extract method to encapsulate Windows specific test logic Looks good, just a minor comment test/jdk/java/io/File/MaxPathLength.java line 200: > 198: String name = fileName; > 199: while (name.length() < MAX_LENGTH) { > 200: testLongPath (20, name, false); Nitpick: do you think there is a need for a space before the `(`? Looks odd imo. But as the whole file uses this, I'm fine with you leaving this as is test/jdk/java/io/File/MaxPathLength.java line 202: > 200: testLongPath (20, name, false); > 201: testLongPath (20, name, true); > 202: name = getNextName(name); Name doesn't seem to be used after. Do you think it might be beneficial to add an assert here to check if the result is the same as expected ? Same applies to the main method ------------- PR Review: https://git.openjdk.org/jdk/pull/26193#pullrequestreview-2998367222 PR Review Comment: https://git.openjdk.org/jdk/pull/26193#discussion_r2192969397 PR Review Comment: https://git.openjdk.org/jdk/pull/26193#discussion_r2192993404 From duke at openjdk.org Wed Jul 9 15:30:13 2025 From: duke at openjdk.org (Darragh Conway) Date: Wed, 9 Jul 2025 15:30:13 GMT Subject: RFR: 8360411: [TEST] open/test/jdk/java/io/File/MaxPathLength.java Refactor extract method to encapsulate Windows specific test logic In-Reply-To: <_2lC8mmCVHe3H3Rx3-whw2W_Lnqf1o4fljII_lH9lks=.e645e94a-30b9-4b5a-93f8-a20d8e15069a@github.com> References: <_2lC8mmCVHe3H3Rx3-whw2W_Lnqf1o4fljII_lH9lks=.e645e94a-30b9-4b5a-93f8-a20d8e15069a@github.com> Message-ID: On Tue, 8 Jul 2025 16:34:47 GMT, Mikhail Yankelevich wrote: >> Refactored extract method to encapsulate Windows specific test logic > > test/jdk/java/io/File/MaxPathLength.java line 200: > >> 198: String name = fileName; >> 199: while (name.length() < MAX_LENGTH) { >> 200: testLongPath (20, name, false); > > Nitpick: do you think there is a need for a space before the `(`? Looks odd imo. But as the whole file uses this, I'm fine with you leaving this as is Yeah, was just being coherent > test/jdk/java/io/File/MaxPathLength.java line 202: > >> 200: testLongPath (20, name, false); >> 201: testLongPath (20, name, true); >> 202: name = getNextName(name); > > Name doesn't seem to be used after. Do you think it might be beneficial to add an assert here to check if the result is the same as expected ? > Same applies to the main method I agree it would be beneficial. Would this be a valid assert to add after those while loops? `assert name.length() >= MAX_LENGTH : "Unexpected final name length: " + name.length();` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26193#discussion_r2194837326 PR Review Comment: https://git.openjdk.org/jdk/pull/26193#discussion_r2194858448 From bpb at openjdk.org Wed Jul 9 16:18:47 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 9 Jul 2025 16:18:47 GMT Subject: Integrated: 8358533: Improve performance of java.io.Reader.readAllLines In-Reply-To: References: Message-ID: On Wed, 18 Jun 2025 00:04:37 GMT, Brian Burkhalter wrote: > Replaces the implementation `readAllCharsAsString().lines().toList()` with reading into a temporary `char` array which is then processed to detect line terminators and copy non-terminating characters into strings which are added to the list. This pull request has now been integrated. Changeset: 6e203384 Author: Brian Burkhalter URL: https://git.openjdk.org/jdk/commit/6e203384f8777fc55081065b128bd2b0ba074729 Stats: 208 lines in 3 files changed: 192 ins; 10 del; 6 mod 8358533: Improve performance of java.io.Reader.readAllLines Reviewed-by: rriggs, sherman ------------- PR: https://git.openjdk.org/jdk/pull/25863 From iklam at openjdk.org Wed Jul 9 16:21:42 2025 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 9 Jul 2025 16:21:42 GMT Subject: RFR: 8360163: Replace hard-coded checks with AOTRuntimeSetup and AOTSafeClassInitializer [v11] In-Reply-To: References: Message-ID: On Wed, 9 Jul 2025 13:25:22 GMT, Chen Liang wrote: >> I have updated this patch to avoid a redundant `runtimeSetup` annotation - we have agreed that the requirement for setup is a side effect of initialization, and such methods in AOTCI classes must be automatically recognized. This latest revision implements that model. >> >> I intentionally avoided handling Class and ClassLoader `resetArchivedStates` and `MethodType::assemblySetup` - we talked about a generic `assemblyCleanup` method, but I did not find out where is the best place to call such a method in the assembly phase. We cna handle this in a subsequent patch. >> >> In particular, please review the new AOT.md design document - I split it from the AOTCI annotation to prevent jamming; we can put general AOT information there when we have more AOT-specific annotations. >> >> --- >> >> Old description: >> Currently, the list of classes that have interdependencies and those that need runtimeSetup are maintained in a hardcoded list in CDS. This makes it risky for core library developers as they might introduce new interdependencies and observe CDS to fail. By moving the mechanism of these lists to core library annotations as a first step, we can gradually expose the AOT contracts as program semantics described by internal annotations, and also helps us to explore how we can expose these functionalities to the public later. > > Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 24 commits: > > - Merge branch 'master' of https://github.com/openjdk/jdk into exp/cds-mh-anno > - Merge branch 'master' of https://github.com/openjdk/jdk into exp/cds-mh-anno > - Reviews > - Documentation > - Don't fail for patching tests > - Remove design document from code > - Some more from reviews > - Reviewed the diff on github > - Stage > - Missed comment updates > - ... and 14 more: https://git.openjdk.org/jdk/compare/a201be85...d2dd466b Marked as reviewed by iklam (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25922#pullrequestreview-3002212362 From egahlin at openjdk.org Wed Jul 9 17:16:37 2025 From: egahlin at openjdk.org (Erik Gahlin) Date: Wed, 9 Jul 2025 17:16:37 GMT Subject: RFR: 8361640: JFR: RandomAccessFile::readLine emits events for each character In-Reply-To: References: Message-ID: On Wed, 9 Jul 2025 09:01:00 GMT, Alan Bateman wrote: > > Testing: tier1 + jdk/jdk/jfr > > The tests for this area are in tier2 (not tier1). I ran tier2. It was fine. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26210#issuecomment-3053405518 From bpb at openjdk.org Wed Jul 9 18:10:14 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 9 Jul 2025 18:10:14 GMT Subject: RFR: 8361587: AssertionError in File.listFiles() when path is empty and -esa is enabled Message-ID: Changes to address `File.listFiles` invoked on an empty path. This fixes an oversight in #22821. ------------- Commit messages: - 8361587: AssertionError in File.listFiles() when path is empty and -esa is enabled Changes: https://git.openjdk.org/jdk/pull/26224/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26224&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8361587 Stats: 24 lines in 3 files changed: 22 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/26224.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26224/head:pull/26224 PR: https://git.openjdk.org/jdk/pull/26224 From alanb at openjdk.org Wed Jul 9 18:19:40 2025 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 9 Jul 2025 18:19:40 GMT Subject: RFR: 8361587: AssertionError in File.listFiles() when path is empty and -esa is enabled In-Reply-To: References: Message-ID: On Wed, 9 Jul 2025 18:04:08 GMT, Brian Burkhalter wrote: > Changes to address `File.listFiles` invoked on an empty path. This fixes an oversight in #22821. test/jdk/java/io/File/EmptyPath.java line 216: > 214: List ioNames = > 215: Arrays.asList(files).stream().map(f -> f.toString()).toList(); > 216: Set ioSet = new HashSet(ioNames); You can simplify this by collecting into the set, e.g. Set ioSet = Arrays.stream(files) .map(File::getName) .collect(Collectors.toSet()); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26224#discussion_r2195697480 From myankelevich at openjdk.org Wed Jul 9 18:23:41 2025 From: myankelevich at openjdk.org (Mikhail Yankelevich) Date: Wed, 9 Jul 2025 18:23:41 GMT Subject: RFR: 8360411: [TEST] open/test/jdk/java/io/File/MaxPathLength.java Refactor extract method to encapsulate Windows specific test logic In-Reply-To: References: <_2lC8mmCVHe3H3Rx3-whw2W_Lnqf1o4fljII_lH9lks=.e645e94a-30b9-4b5a-93f8-a20d8e15069a@github.com> Message-ID: On Wed, 9 Jul 2025 12:11:10 GMT, Darragh Conway wrote: >> test/jdk/java/io/File/MaxPathLength.java line 202: >> >>> 200: testLongPath (20, name, false); >>> 201: testLongPath (20, name, true); >>> 202: name = getNextName(name); >> >> Name doesn't seem to be used after. Do you think it might be beneficial to add an assert here to check if the result is the same as expected ? >> Same applies to the main method > > I agree it would be beneficial. > > Would this be a valid assert to add after those while loops? > > `assert name.length() >= MAX_LENGTH : "Unexpected final name length: " + name.length();` After a second look, I can see that the `name` is used in the while loops. My bad, sorry. The test is increasing the `name` length in `getNextName`, so it increases in each iteration. The test logic itself is in `testLongPath` and checks if the name is valid. So, in my opinion, checking the value of the name after the while loop probably will not be beneficial ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26193#discussion_r2195703732 From duke at openjdk.org Wed Jul 9 18:25:40 2025 From: duke at openjdk.org (Johannes =?UTF-8?B?RMO2Ymxlcg==?=) Date: Wed, 9 Jul 2025 18:25:40 GMT Subject: RFR: 8361587: AssertionError in File.listFiles() when path is empty and -esa is enabled In-Reply-To: References: Message-ID: On Wed, 9 Jul 2025 18:04:08 GMT, Brian Burkhalter wrote: > Changes to address `File.listFiles` invoked on an empty path. This fixes an oversight in #22821. test/jdk/java/io/File/EmptyPath.java line 212: > 210: File[] files = f.listFiles(); > 211: for (File file : files) > 212: assertTrue(f.toString().indexOf(File.separatorChar) == -1); Suggestion: `assertEquals(-1, f.toString().indexOf(File.separatorChar));` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26224#discussion_r2195706810 From bpb at openjdk.org Wed Jul 9 18:35:54 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 9 Jul 2025 18:35:54 GMT Subject: RFR: 8361587: AssertionError in File.listFiles() when path is empty and -esa is enabled [v2] In-Reply-To: References: Message-ID: > Changes to address `File.listFiles` invoked on an empty path. This fixes an oversight in #22821. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8361587: Clean up listFiles sub-test per suggestions ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26224/files - new: https://git.openjdk.org/jdk/pull/26224/files/d7d180ff..76b4439c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26224&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26224&range=00-01 Stats: 10 lines in 1 file changed: 3 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/26224.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26224/head:pull/26224 PR: https://git.openjdk.org/jdk/pull/26224 From bpb at openjdk.org Wed Jul 9 18:35:54 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 9 Jul 2025 18:35:54 GMT Subject: RFR: 8361587: AssertionError in File.listFiles() when path is empty and -esa is enabled [v2] In-Reply-To: References: Message-ID: On Wed, 9 Jul 2025 18:22:51 GMT, Johannes D?bler wrote: >> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: >> >> 8361587: Clean up listFiles sub-test per suggestions > > test/jdk/java/io/File/EmptyPath.java line 212: > >> 210: File[] files = f.listFiles(); >> 211: for (File file : files) >> 212: assertTrue(f.toString().indexOf(File.separatorChar) == -1); > > Suggestion: `assertEquals(-1, f.toString().indexOf(File.separatorChar));` So changed in 76b4439. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26224#discussion_r2195723588 From bpb at openjdk.org Wed Jul 9 18:35:54 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 9 Jul 2025 18:35:54 GMT Subject: RFR: 8361587: AssertionError in File.listFiles() when path is empty and -esa is enabled [v2] In-Reply-To: References: Message-ID: On Wed, 9 Jul 2025 18:16:44 GMT, Alan Bateman wrote: >> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: >> >> 8361587: Clean up listFiles sub-test per suggestions > > test/jdk/java/io/File/EmptyPath.java line 216: > >> 214: List ioNames = >> 215: Arrays.asList(files).stream().map(f -> f.toString()).toList(); >> 216: Set ioSet = new HashSet(ioNames); > > You can simplify this by collecting into the set, e.g. > > Set ioSet = Arrays.stream(files) > .map(File::getName) > .collect(Collectors.toSet()); So changed in 76b4439. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26224#discussion_r2195723230 From naoto at openjdk.org Wed Jul 9 18:43:48 2025 From: naoto at openjdk.org (Naoto Sato) Date: Wed, 9 Jul 2025 18:43:48 GMT Subject: RFR: 8361717: Refactor Collections.emptyList() in Locale related classes Message-ID: <5o7ommmTBTXH9udy76qajqgUNSF89aiQ4ptsebC3v3o=.01b18594-1798-41a7-972f-15572d6b4ace@github.com> Replaced Collections.emptyList() with List.of() as part of refactoring. This was discussed in the context of investigating a CDS-related issue (https://bugs.openjdk.org/browse/JDK-8357281?focusedId=14796714&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14796714). Although the root cause was ultimately determined to be user error, modernizing the code by using List.of() is still a desirable improvement ------------- Commit messages: - initial commit Changes: https://git.openjdk.org/jdk/pull/26225/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26225&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8361717 Stats: 5 lines in 2 files changed: 0 ins; 2 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/26225.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26225/head:pull/26225 PR: https://git.openjdk.org/jdk/pull/26225 From bpb at openjdk.org Wed Jul 9 18:54:38 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 9 Jul 2025 18:54:38 GMT Subject: RFR: 8361717: Refactor Collections.emptyList() in Locale related classes In-Reply-To: <5o7ommmTBTXH9udy76qajqgUNSF89aiQ4ptsebC3v3o=.01b18594-1798-41a7-972f-15572d6b4ace@github.com> References: <5o7ommmTBTXH9udy76qajqgUNSF89aiQ4ptsebC3v3o=.01b18594-1798-41a7-972f-15572d6b4ace@github.com> Message-ID: On Wed, 9 Jul 2025 18:39:40 GMT, Naoto Sato wrote: > Replaced Collections.emptyList() with List.of() as part of refactoring. This was discussed in the context of investigating a CDS-related issue (https://bugs.openjdk.org/browse/JDK-8357281?focusedId=14796714&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14796714). Although the root cause was ultimately determined to be user error, modernizing the code by using List.of() is still a desirable improvement Looks fine. ------------- Marked as reviewed by bpb (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26225#pullrequestreview-3002724026 From jlu at openjdk.org Wed Jul 9 18:57:38 2025 From: jlu at openjdk.org (Justin Lu) Date: Wed, 9 Jul 2025 18:57:38 GMT Subject: RFR: 8361717: Refactor Collections.emptyList() in Locale related classes In-Reply-To: <5o7ommmTBTXH9udy76qajqgUNSF89aiQ4ptsebC3v3o=.01b18594-1798-41a7-972f-15572d6b4ace@github.com> References: <5o7ommmTBTXH9udy76qajqgUNSF89aiQ4ptsebC3v3o=.01b18594-1798-41a7-972f-15572d6b4ace@github.com> Message-ID: On Wed, 9 Jul 2025 18:39:40 GMT, Naoto Sato wrote: > Replaced Collections.emptyList() with List.of() as part of refactoring. This was discussed in the context of investigating a CDS-related issue (https://bugs.openjdk.org/browse/JDK-8357281?focusedId=14796714&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14796714). Although the root cause was ultimately determined to be user error, modernizing the code by using List.of() is still a desirable improvement Looks good. Thanks for fixing this. ------------- Marked as reviewed by jlu (Committer). PR Review: https://git.openjdk.org/jdk/pull/26225#pullrequestreview-3002729901 From lancea at openjdk.org Wed Jul 9 19:02:42 2025 From: lancea at openjdk.org (Lance Andersen) Date: Wed, 9 Jul 2025 19:02:42 GMT Subject: RFR: 8360122: Fix java.sql\Connection.java indentation [v6] In-Reply-To: References: Message-ID: On Tue, 8 Jul 2025 20:45:20 GMT, simon wrote: >> 8360122: Refine formatting of Connection.java interface >> >> --------- >> ### Progress >> - [x] Change must be properly reviewed (1 review required, with at least 1 [Reviewer](https://openjdk.org/bylaws#reviewer)) >> - [x] Change must not contain extraneous whitespace >> - [x] Commit message must refer to an issue >> >> >> >> ### Reviewing >>
    Using git >> >> Checkout this PR locally: \ >> `$ git fetch https://git.openjdk.org/jdk.git pull/25925/head:pull/25925` \ >> `$ git checkout pull/25925` >> >> Update a local copy of the PR: \ >> `$ git checkout pull/25925` \ >> `$ git pull https://git.openjdk.org/jdk.git pull/25925/head` >> >>
    >>
    Using Skara CLI tools >> >> Checkout this PR locally: \ >> `$ git pr checkout 25925` >> >> View PR using the GUI difftool: \ >> `$ git pr show -t 25925` >> >>
    >>
    Using diff file >> >> Download this PR as a diff file: \ >> https://git.openjdk.org/jdk/pull/25925.diff >> >>
    >>
    Using Webrev >> >> [Link to Webrev Comment](https://git.openjdk.org/jdk/pull/25925#issuecomment-2993856738) >>
    > > simon has updated the pull request incrementally with one additional commit since the last revision: > > 8360122: reversed wrongful removal of comments The changes are OK. ------------- Marked as reviewed by lancea (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25925#pullrequestreview-3002741321 From duke at openjdk.org Wed Jul 9 19:11:39 2025 From: duke at openjdk.org (Johannes =?UTF-8?B?RMO2Ymxlcg==?=) Date: Wed, 9 Jul 2025 19:11:39 GMT Subject: RFR: 8361717: Refactor Collections.emptyList() in Locale related classes In-Reply-To: <5o7ommmTBTXH9udy76qajqgUNSF89aiQ4ptsebC3v3o=.01b18594-1798-41a7-972f-15572d6b4ace@github.com> References: <5o7ommmTBTXH9udy76qajqgUNSF89aiQ4ptsebC3v3o=.01b18594-1798-41a7-972f-15572d6b4ace@github.com> Message-ID: On Wed, 9 Jul 2025 18:39:40 GMT, Naoto Sato wrote: > modernizing the code by using List.of() is still a desirable improvement except that `Collections.emptyList()` and `List.of()` unfortunately have different tolerance to calls `List.indexOf(null)` and `List.contains(null)`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26225#issuecomment-3053718956 From liach at openjdk.org Wed Jul 9 19:30:40 2025 From: liach at openjdk.org (Chen Liang) Date: Wed, 9 Jul 2025 19:30:40 GMT Subject: RFR: 8361717: Refactor Collections.emptyList() in Locale related classes In-Reply-To: <5o7ommmTBTXH9udy76qajqgUNSF89aiQ4ptsebC3v3o=.01b18594-1798-41a7-972f-15572d6b4ace@github.com> References: <5o7ommmTBTXH9udy76qajqgUNSF89aiQ4ptsebC3v3o=.01b18594-1798-41a7-972f-15572d6b4ace@github.com> Message-ID: On Wed, 9 Jul 2025 18:39:40 GMT, Naoto Sato wrote: > Replaced Collections.emptyList() with List.of() as part of refactoring. This was discussed in the context of investigating a CDS-related issue (https://bugs.openjdk.org/browse/JDK-8357281?focusedId=14796714&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14796714). Although the root cause was ultimately determined to be user error, modernizing the code by using List.of() is still a desirable improvement Both lists aren't returned to users, so their null-hostile contains behavior has no impact. ------------- Marked as reviewed by liach (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26225#pullrequestreview-3002824059 From liach at openjdk.org Wed Jul 9 19:32:48 2025 From: liach at openjdk.org (Chen Liang) Date: Wed, 9 Jul 2025 19:32:48 GMT Subject: RFR: 8361615: CodeBuilder::parameterSlot throws undocumented IOOBE In-Reply-To: References: Message-ID: On Tue, 8 Jul 2025 18:46:00 GMT, Chen Liang wrote: > In a recent inspection of all methods that accept an `int` argument in the Class-File API, I noticed this method that validates its argument but did not document the validation. The behavior is to throw IOOBE. We can simply document this behavior and enhance existing tests to verify exceptional behaviors in addition to anticipated outputs. > > This is doc plus test only, so should be eligible for backport regardless of priority. A CSR will be created to track this new assertion in the spec. > > Testing: jdk/jdk/classfile/BuilderParamTest.java Thanks for the reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/26200#issuecomment-3053765498 From liach at openjdk.org Wed Jul 9 19:32:48 2025 From: liach at openjdk.org (Chen Liang) Date: Wed, 9 Jul 2025 19:32:48 GMT Subject: Integrated: 8361615: CodeBuilder::parameterSlot throws undocumented IOOBE In-Reply-To: References: Message-ID: <_5mCZRadhFZlFEn_9JNQcBO4WRKslhGFSXhjmjbsF5I=.66c88c6f-308e-4734-898c-b5b1a5be2852@github.com> On Tue, 8 Jul 2025 18:46:00 GMT, Chen Liang wrote: > In a recent inspection of all methods that accept an `int` argument in the Class-File API, I noticed this method that validates its argument but did not document the validation. The behavior is to throw IOOBE. We can simply document this behavior and enhance existing tests to verify exceptional behaviors in addition to anticipated outputs. > > This is doc plus test only, so should be eligible for backport regardless of priority. A CSR will be created to track this new assertion in the spec. > > Testing: jdk/jdk/classfile/BuilderParamTest.java This pull request has now been integrated. Changeset: c9bea773 Author: Chen Liang URL: https://git.openjdk.org/jdk/commit/c9bea77342672715f8f720d7311d66c2b3ac9f8a Stats: 10 lines in 2 files changed: 9 ins; 0 del; 1 mod 8361615: CodeBuilder::parameterSlot throws undocumented IOOBE Reviewed-by: asotona ------------- PR: https://git.openjdk.org/jdk/pull/26200 From liach at openjdk.org Wed Jul 9 19:38:41 2025 From: liach at openjdk.org (Chen Liang) Date: Wed, 9 Jul 2025 19:38:41 GMT Subject: RFR: 8361717: Refactor Collections.emptyList() in Locale related classes In-Reply-To: <5o7ommmTBTXH9udy76qajqgUNSF89aiQ4ptsebC3v3o=.01b18594-1798-41a7-972f-15572d6b4ace@github.com> References: <5o7ommmTBTXH9udy76qajqgUNSF89aiQ4ptsebC3v3o=.01b18594-1798-41a7-972f-15572d6b4ace@github.com> Message-ID: On Wed, 9 Jul 2025 18:39:40 GMT, Naoto Sato wrote: > Replaced Collections.emptyList() with List.of() as part of refactoring. This was discussed in the context of investigating a CDS-related issue (https://bugs.openjdk.org/browse/JDK-8357281?focusedId=14796714&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14796714). Although the root cause was ultimately determined to be user error, modernizing the code by using List.of() is still a desirable improvement An effort #25922 exists to make the AOT/CDS requirements more obvious to core libraries. Hope we can have this easier down the road. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26225#issuecomment-3053781110 From liach at openjdk.org Wed Jul 9 19:38:51 2025 From: liach at openjdk.org (Chen Liang) Date: Wed, 9 Jul 2025 19:38:51 GMT Subject: [jdk25] RFR: 8361615: CodeBuilder::parameterSlot throws undocumented IOOBE Message-ID: Hi all, This pull request contains a backport of commit [c9bea773](https://github.com/openjdk/jdk/commit/c9bea77342672715f8f720d7311d66c2b3ac9f8a) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. #26200 The commit being backported was authored by Chen Liang on 9 Jul 2025 and was reviewed by Adam Sotona. This is doc and test only, so eligible for RDP backports. Thanks! ------------- Commit messages: - Backport c9bea77342672715f8f720d7311d66c2b3ac9f8a Changes: https://git.openjdk.org/jdk/pull/26226/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26226&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8361615 Stats: 10 lines in 2 files changed: 9 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/26226.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26226/head:pull/26226 PR: https://git.openjdk.org/jdk/pull/26226 From liach at openjdk.org Wed Jul 9 19:39:47 2025 From: liach at openjdk.org (Chen Liang) Date: Wed, 9 Jul 2025 19:39:47 GMT Subject: RFR: 8361615: CodeBuilder::parameterSlot throws undocumented IOOBE In-Reply-To: References: Message-ID: On Tue, 8 Jul 2025 18:46:00 GMT, Chen Liang wrote: > In a recent inspection of all methods that accept an `int` argument in the Class-File API, I noticed this method that validates its argument but did not document the validation. The behavior is to throw IOOBE. We can simply document this behavior and enhance existing tests to verify exceptional behaviors in addition to anticipated outputs. > > This is doc plus test only, so should be eligible for backport regardless of priority. A CSR will be created to track this new assertion in the spec. > > Testing: jdk/jdk/classfile/BuilderParamTest.java Opened PR #26226 for backport to JDK 25. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26200#issuecomment-3053782525 From duke at openjdk.org Wed Jul 9 19:40:44 2025 From: duke at openjdk.org (simon) Date: Wed, 9 Jul 2025 19:40:44 GMT Subject: RFR: 8360122: Fix java.sql\Connection.java indentation [v6] In-Reply-To: References: Message-ID: On Wed, 9 Jul 2025 18:59:49 GMT, Lance Andersen wrote: > The changes are OK. Great, @LanceAndersen! Thanks for reviewing. ? Can you integrate it when you think it is appropriate? I guess I do not have permission to do it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25925#issuecomment-3053780918 From liach at openjdk.org Wed Jul 9 19:40:44 2025 From: liach at openjdk.org (Chen Liang) Date: Wed, 9 Jul 2025 19:40:44 GMT Subject: RFR: 8360122: Fix java.sql\Connection.java indentation [v6] In-Reply-To: References: Message-ID: On Wed, 9 Jul 2025 19:35:54 GMT, simon wrote: > Can you integrate it when you think it is appropriate? I guess I do not have permission to do it. They are done with GitHub comments parsed by bots, so if there is a line: > /integrate in a comment from you, the bot will integrate this patch (by marking this ready for a committer sponsor) ------------- PR Comment: https://git.openjdk.org/jdk/pull/25925#issuecomment-3053786183 From duke at openjdk.org Wed Jul 9 19:45:44 2025 From: duke at openjdk.org (simon) Date: Wed, 9 Jul 2025 19:45:44 GMT Subject: RFR: 8360122: Fix java.sql\Connection.java indentation [v6] In-Reply-To: References: Message-ID: <91eSLp7wiGrcC3geQYPFJlCVGBHmNj5KrK1lffyJ_YQ=.933a1269-216b-4cff-820c-1760803e09f2@github.com> On Wed, 9 Jul 2025 19:38:21 GMT, Chen Liang wrote: >>> The changes are OK. >> >> Great, @LanceAndersen! Thanks for reviewing. ? >> >> Can you integrate it when you think it is appropriate? I guess I do not have permission to do it. > >> Can you integrate it when you think it is appropriate? I guess I do not have permission to do it. > > They are done with GitHub comments parsed by bots, so if there is a line: > >> /integrate > > in a comment from you, the bot will integrate this patch (by marking this ready for a committer sponsor) Got it, @liach! Thanks ?! I'm doing right now! ------------- PR Comment: https://git.openjdk.org/jdk/pull/25925#issuecomment-3053794210 From duke at openjdk.org Wed Jul 9 19:45:45 2025 From: duke at openjdk.org (duke) Date: Wed, 9 Jul 2025 19:45:45 GMT Subject: RFR: 8360122: Fix java.sql\Connection.java indentation [v6] In-Reply-To: References: Message-ID: On Tue, 8 Jul 2025 20:45:20 GMT, simon wrote: >> 8360122: Refine formatting of Connection.java interface >> >> --------- >> ### Progress >> - [x] Change must be properly reviewed (1 review required, with at least 1 [Reviewer](https://openjdk.org/bylaws#reviewer)) >> - [x] Change must not contain extraneous whitespace >> - [x] Commit message must refer to an issue >> >> >> >> ### Reviewing >>
    Using git >> >> Checkout this PR locally: \ >> `$ git fetch https://git.openjdk.org/jdk.git pull/25925/head:pull/25925` \ >> `$ git checkout pull/25925` >> >> Update a local copy of the PR: \ >> `$ git checkout pull/25925` \ >> `$ git pull https://git.openjdk.org/jdk.git pull/25925/head` >> >>
    >>
    Using Skara CLI tools >> >> Checkout this PR locally: \ >> `$ git pr checkout 25925` >> >> View PR using the GUI difftool: \ >> `$ git pr show -t 25925` >> >>
    >>
    Using diff file >> >> Download this PR as a diff file: \ >> https://git.openjdk.org/jdk/pull/25925.diff >> >>
    >>
    Using Webrev >> >> [Link to Webrev Comment](https://git.openjdk.org/jdk/pull/25925#issuecomment-2993856738) >>
    > > simon has updated the pull request incrementally with one additional commit since the last revision: > > 8360122: reversed wrongful removal of comments @gustavosimon Your change (at version 69c84daa7c9b6bdb23e8c13b9a6154efa59a885b) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25925#issuecomment-3053795635 From liach at openjdk.org Wed Jul 9 19:57:52 2025 From: liach at openjdk.org (Chen Liang) Date: Wed, 9 Jul 2025 19:57:52 GMT Subject: RFR: 8360122: Fix java.sql\Connection.java indentation [v6] In-Reply-To: References: Message-ID: On Tue, 8 Jul 2025 20:45:20 GMT, simon wrote: >> 8360122: Refine formatting of Connection.java interface >> >> --------- >> ### Progress >> - [x] Change must be properly reviewed (1 review required, with at least 1 [Reviewer](https://openjdk.org/bylaws#reviewer)) >> - [x] Change must not contain extraneous whitespace >> - [x] Commit message must refer to an issue >> >> >> >> ### Reviewing >>
    Using git >> >> Checkout this PR locally: \ >> `$ git fetch https://git.openjdk.org/jdk.git pull/25925/head:pull/25925` \ >> `$ git checkout pull/25925` >> >> Update a local copy of the PR: \ >> `$ git checkout pull/25925` \ >> `$ git pull https://git.openjdk.org/jdk.git pull/25925/head` >> >>
    >>
    Using Skara CLI tools >> >> Checkout this PR locally: \ >> `$ git pr checkout 25925` >> >> View PR using the GUI difftool: \ >> `$ git pr show -t 25925` >> >>
    >>
    Using diff file >> >> Download this PR as a diff file: \ >> https://git.openjdk.org/jdk/pull/25925.diff >> >>
    >>
    Using Webrev >> >> [Link to Webrev Comment](https://git.openjdk.org/jdk/pull/25925#issuecomment-2993856738) >>
    > > simon has updated the pull request incrementally with one additional commit since the last revision: > > 8360122: reversed wrongful removal of comments Marked as reviewed by liach (Reviewer). Looks good on a final check. ------------- PR Review: https://git.openjdk.org/jdk/pull/25925#pullrequestreview-3002889048 PR Comment: https://git.openjdk.org/jdk/pull/25925#issuecomment-3053822369 From duke at openjdk.org Wed Jul 9 19:57:53 2025 From: duke at openjdk.org (simon) Date: Wed, 9 Jul 2025 19:57:53 GMT Subject: Integrated: 8360122: Fix java.sql\Connection.java indentation In-Reply-To: References: Message-ID: On Sun, 22 Jun 2025 01:13:26 GMT, simon wrote: > 8360122: Refine formatting of Connection.java interface > > --------- > ### Progress > - [x] Change must be properly reviewed (1 review required, with at least 1 [Reviewer](https://openjdk.org/bylaws#reviewer)) > - [x] Change must not contain extraneous whitespace > - [x] Commit message must refer to an issue > > > > ### Reviewing >
    Using git > > Checkout this PR locally: \ > `$ git fetch https://git.openjdk.org/jdk.git pull/25925/head:pull/25925` \ > `$ git checkout pull/25925` > > Update a local copy of the PR: \ > `$ git checkout pull/25925` \ > `$ git pull https://git.openjdk.org/jdk.git pull/25925/head` > >
    >
    Using Skara CLI tools > > Checkout this PR locally: \ > `$ git pr checkout 25925` > > View PR using the GUI difftool: \ > `$ git pr show -t 25925` > >
    >
    Using diff file > > Download this PR as a diff file: \ > https://git.openjdk.org/jdk/pull/25925.diff > >
    >
    Using Webrev > > [Link to Webrev Comment](https://git.openjdk.org/jdk/pull/25925#issuecomment-2993856738) >
    This pull request has now been integrated. Changeset: 0f7808f3 Author: Gustavo Simon Committer: Chen Liang URL: https://git.openjdk.org/jdk/commit/0f7808f333556eed2a1381e5f9f67765ec3694f1 Stats: 238 lines in 1 file changed: 46 ins; 59 del; 133 mod 8360122: Fix java.sql\Connection.java indentation Reviewed-by: liach, lancea ------------- PR: https://git.openjdk.org/jdk/pull/25925 From duke at openjdk.org Wed Jul 9 19:59:43 2025 From: duke at openjdk.org (Benjamin Peterson) Date: Wed, 9 Jul 2025 19:59:43 GMT Subject: RFR: 8348828: Windows dll loading now resolves symlinks [v4] In-Reply-To: <-mnTMxvetLwkde03sxvgoVHtnNrrBEUWHwoXuf6wRqA=.94d9759b-a2d9-4eff-afb0-562892b14c15@github.com> References: <-mnTMxvetLwkde03sxvgoVHtnNrrBEUWHwoXuf6wRqA=.94d9759b-a2d9-4eff-afb0-562892b14c15@github.com> Message-ID: On Fri, 9 May 2025 17:42:14 GMT, Benjamin Peterson wrote: >> Deep in the bowels of `System.loadLibrary`, `File.getCanonicalPath()` is called on the target library file before it is passed to the system library loading APIs. In JDK-8003887, `File.getCanonicalPath` was altered to resolve symlinks on Windows. This had unintended consequences for passing a symlink to `System.loadLibrary` on Windows. The underlying Windows `LoadLibrary` API inspects the file name passed to it and adds a `.dll` extension if the it is not already present. Thus, if `System.loadLibrary` was given a symlink to a file and that file didn't have a `.dll` extension, `LoadLibrary` try to load nonexistent file and fail. >> >> Fix this problem by appending a `.` to library paths after canonicalization on Windows. This trailing dot inhibits `LoadLibrary`'s own appending behavior. > > Benjamin Peterson has updated the pull request with a new target base 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: > > - switch platform helper to be mapToNativeLibraryName > - Merge remote-tracking branch 'upstream/master' into nativelibraries-fix > - fix spelling > - new approach: append . to file name on Windows > - 8348828: Windows dll loading now resolves symlinks Any thoughts on the approach we landed on now? ------------- PR Comment: https://git.openjdk.org/jdk/pull/24694#issuecomment-3053827761 From liach at openjdk.org Wed Jul 9 21:20:11 2025 From: liach at openjdk.org (Chen Liang) Date: Wed, 9 Jul 2025 21:20:11 GMT Subject: RFR: 8361102: java.lang.classfile.CodeBuilder.branch(Opcode op, Label target) doesn't throw IllegalArgumentException - if op is not of Opcode.Kind.BRANCH Message-ID: Currently, DirectCodeBuilder is erroneously missing argument checks for a few of its override methods that take arguments such as Opcode and the array size for multianewarray and the switches, which would write something before throwing an exception. We correct these problems and verify with some tests. Note: Other Label-writing methods resolve their label eagerly so they are not (yet) problematic. ------------- Commit messages: - Test refresh - 8361102: java.lang.classfile.CodeBuilder.branch(Opcode op, Label target) doesn't throw IllegalArgumentException - if op is not of Opcode.Kind.BRANCH Changes: https://git.openjdk.org/jdk/pull/26229/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26229&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8361102 Stats: 171 lines in 5 files changed: 120 ins; 27 del; 24 mod Patch: https://git.openjdk.org/jdk/pull/26229.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26229/head:pull/26229 PR: https://git.openjdk.org/jdk/pull/26229 From bpb at openjdk.org Wed Jul 9 21:57:56 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 9 Jul 2025 21:57:56 GMT Subject: RFR: 8361587: AssertionError in File.listFiles() when path is empty and -esa is enabled [v3] In-Reply-To: References: Message-ID: > Changes to address `File.listFiles` invoked on an empty path. This fixes an oversight in #22821. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8361587: Expand test coverage of File methods ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26224/files - new: https://git.openjdk.org/jdk/pull/26224/files/76b4439c..afaa9329 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26224&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26224&range=01-02 Stats: 50 lines in 1 file changed: 50 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/26224.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26224/head:pull/26224 PR: https://git.openjdk.org/jdk/pull/26224 From igraves at openjdk.org Wed Jul 9 22:52:58 2025 From: igraves at openjdk.org (Ian Graves) Date: Wed, 9 Jul 2025 22:52:58 GMT Subject: RFR: 8358768: [vectorapi] Make VectorOperators.SUADD an Associative [v2] In-Reply-To: References: Message-ID: > Adding SUADD an associative operation in the Vector API. Saturated addition on fixed-width unsigned integers is provably associative. Ian Graves has updated the pull request incrementally with one additional commit since the last revision: Adding masked associative tests ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26099/files - new: https://git.openjdk.org/jdk/pull/26099/files/0abdd644..6c8d8952 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26099&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26099&range=00-01 Stats: 1522 lines in 34 files changed: 1522 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/26099.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26099/head:pull/26099 PR: https://git.openjdk.org/jdk/pull/26099 From sspitsyn at openjdk.org Thu Jul 10 01:17:33 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 10 Jul 2025 01:17:33 GMT Subject: RFR: 8358890: VM option -XX:AllowRedefinitionToAddDeleteMethods should be obsoleted then expired Message-ID: The VM option -XX:AllowRedefinitionToAddDeleteMethods was added in JDK 13 as a temporary backward compatibility flag under JDK-8192936 and was immediately marked as Deprecate. The fix is to obsolete this option in JDK 26 and expire in JDK 27. There are two concerns which may require some negotiation with the Runtime (@coleenp @dcubed-ojdk @dholmes-ora) and SQE (@lmesnik) teams: - Class redefinition/retransformation can impact lambda expressions which are supported with private methods - Many tests depend on this VM option and are being removed. I'm not sure if it is okay to completely remove those e may want another way to handle this (e.g. problem-listing the impacted tests for now). Testing: - mach5 tiers 1-6 are good - may need to run mach5 tiers > 6 ------------- Commit messages: - 8358890: VM option -XX:AllowRedefinitionToAddDeleteMethods should be obsoleted then expired Changes: https://git.openjdk.org/jdk/pull/26232/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26232&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8358890 Stats: 1851 lines in 36 files changed: 0 ins; 1825 del; 26 mod Patch: https://git.openjdk.org/jdk/pull/26232.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26232/head:pull/26232 PR: https://git.openjdk.org/jdk/pull/26232 From xgong at openjdk.org Thu Jul 10 01:42:40 2025 From: xgong at openjdk.org (Xiaohong Gong) Date: Thu, 10 Jul 2025 01:42:40 GMT Subject: RFR: 8359419: AArch64: Relax min vector length to 32-bit for short vectors [v4] In-Reply-To: References: Message-ID: On Wed, 9 Jul 2025 09:17:13 GMT, Xiaohong Gong wrote: >> Hi @eme64 , could you please help take a look at this patch especially the test part since most of the tests are SLP related? It will be helpful if you could also help trigger a testing for it. Thanks for your time! > >> @XiaohongGong I would love to review and test, but I'm about to go on vacation and will only be back in August. I've pinged some others internally, and hope someone will pick this up! > > Thanks a lot for the help! Sounds good to me and have a good holiday! > @XiaohongGong I'll run some tests and have a look at the changes as well (@eme64 asked me). I'll get back to you shortly! Thanks so much for your help! ------------- PR Comment: https://git.openjdk.org/jdk/pull/26057#issuecomment-3054907351 From xgong at openjdk.org Thu Jul 10 01:42:41 2025 From: xgong at openjdk.org (Xiaohong Gong) Date: Thu, 10 Jul 2025 01:42:41 GMT Subject: RFR: 8359419: AArch64: Relax min vector length to 32-bit for short vectors [v4] In-Reply-To: References: Message-ID: On Wed, 9 Jul 2025 10:43:07 GMT, Bhavana Kilambi wrote: > Thanks for making the changes. Looks good to me. Thanks a lot for your review! ------------- PR Comment: https://git.openjdk.org/jdk/pull/26057#issuecomment-3054908101 From sspitsyn at openjdk.org Thu Jul 10 03:12:27 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 10 Jul 2025 03:12:27 GMT Subject: RFR: 8358890: VM option -XX:AllowRedefinitionToAddDeleteMethods should be obsoleted then expired [v2] In-Reply-To: References: Message-ID: > The VM option -XX:AllowRedefinitionToAddDeleteMethods was added in JDK 13 as a temporary backward compatibility flag under JDK-8192936 and was immediately marked as Deprecate. The fix is to obsolete this option in JDK 26 and expire in JDK 27. > > TBD: Need to submit a related CSR. > > There are two concerns which may require some negotiation with the Runtime (@coleenp @dcubed-ojdk @dholmes-ora) and SQE (@lmesnik) teams: > - Class redefinition/retransformation can impact lambda expressions which are supported with private methods > - Many tests depend on this VM option and are being removed. I'm not sure if it is okay to completely remove those e may want another way to handle this (e.g. problem-listing the impacted tests for now). > > Testing: > - mach5 tiers 1-6 are good > - may need to run mach5 tiers > 6 Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: corrected one assert message ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26232/files - new: https://git.openjdk.org/jdk/pull/26232/files/a7bceacb..a8358402 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26232&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26232&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/26232.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26232/head:pull/26232 PR: https://git.openjdk.org/jdk/pull/26232 From darcy at openjdk.org Thu Jul 10 04:54:37 2025 From: darcy at openjdk.org (Joe Darcy) Date: Thu, 10 Jul 2025 04:54:37 GMT Subject: RFR: 8360559: Optimize Math.sinh for x86 64 bit platforms In-Reply-To: References: Message-ID: On Mon, 7 Jul 2025 03:05:15 GMT, Mohamed Issa wrote: > The goal of this PR is to implement an x86_64 intrinsic for java.lang.Math.sinh() using libm. There is a new set of micro-benchmarks are included to check the performance of specific input value ranges to help prevent regressions in the future. > > The command to run all range specific micro-benchmarks is posted below. > > `make test TEST="micro:SinhPerf.SinhPerfRanges"` > > The results of all tests posted below were captured with an [Intel? Xeon 8488C](https://advisor.cloudzero.com/aws/ec2/r7i.metal-24xl) using [OpenJDK v26-b4](https://github.com/openjdk/jdk/releases/tag/jdk-26%2B4) as the baseline version. > > For performance data collected with the new built in range micro-benchmark, see the table below. Each result is the mean of 8 individual runs, and the input ranges used match those from the original Java implementation. Overall, the intrinsic provides an an average uplift of 64% when input values fall into the middle three ranges where heavy computation is required. However, very small inputs and very large inputs show drops of 74% and 66% respectively. > > | Input range(s) | Baseline throughput (ops/ms) | Intrinsic throughput (ops/ms) | Speedup | > | :------------------------------------: | :-------------------------------: | :--------------------------------: | :--------: | > | [-2^(-28), 2^(-28)] | 844160 | 216029 | 0.26x | > | [-22, -2^(-28)], [2^(-28), 22] | 81662 | 157351 | 1.93x | > | [-709.78, -22], [22, 709.78] | 119075 | 167635 | 1.41x | > | [-710.48, -709.78], [709.78, 710.48] | 111636 | 177125 | 1.59x | > | (-INF, -710.48], [710.48, INF) | 959296 | 313839 | 0.33x | > > Finally, the `jtreg:test/jdk/java/lang/Math/HyperbolicTests.java` test passed with the changes. What is the accuracy of the algorithm in ulps (units the last place)? The java.lang.Math specification has max error and various other accuracy requirements any implementation must meet. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26152#issuecomment-3055484802 From cstein at openjdk.org Thu Jul 10 05:39:38 2025 From: cstein at openjdk.org (Christian Stein) Date: Thu, 10 Jul 2025 05:39:38 GMT Subject: RFR: 8361717: Refactor Collections.emptyList() in Locale related classes In-Reply-To: <5o7ommmTBTXH9udy76qajqgUNSF89aiQ4ptsebC3v3o=.01b18594-1798-41a7-972f-15572d6b4ace@github.com> References: <5o7ommmTBTXH9udy76qajqgUNSF89aiQ4ptsebC3v3o=.01b18594-1798-41a7-972f-15572d6b4ace@github.com> Message-ID: On Wed, 9 Jul 2025 18:39:40 GMT, Naoto Sato wrote: > Replaced Collections.emptyList() with List.of() as part of refactoring. This was discussed in the context of investigating a CDS-related issue (https://bugs.openjdk.org/browse/JDK-8357281?focusedId=14796714&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14796714). Although the root cause was ultimately determined to be user error, modernizing the code by using List.of() is still a desirable improvement Marked as reviewed by cstein (Committer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26225#pullrequestreview-3004002450 From dholmes at openjdk.org Thu Jul 10 07:23:40 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 10 Jul 2025 07:23:40 GMT Subject: RFR: 8358890: VM option -XX:AllowRedefinitionToAddDeleteMethods should be obsoleted then expired [v2] In-Reply-To: References: Message-ID: On Thu, 10 Jul 2025 03:12:27 GMT, Serguei Spitsyn wrote: >> The VM option -XX:AllowRedefinitionToAddDeleteMethods was added in JDK 13 as a temporary backward compatibility flag under JDK-8192936 and was immediately marked as Deprecate. The fix is to obsolete this option in JDK 26 and expire in JDK 27. >> >> TBD: Need to submit a related CSR. >> >> There are two concerns which may require some negotiation with the Runtime (@coleenp @dcubed-ojdk @dholmes-ora) and SQE (@lmesnik) teams: >> - Class redefinition/retransformation can impact lambda expressions which are supported with private methods >> - Many tests depend on this VM option and are being removed. I'm not sure if it is okay to completely remove those e may want another way to handle this (e.g. problem-listing the impacted tests for now). >> >> Testing: >> - mach5 tiers 1-6 are good >> - may need to run mach5 tiers > 6 > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > corrected one assert message This involved a lot more code than I had envisaged. The test situation seems problematic as it suggests to me that we have required functionality (redefine a method containing a lambda expression) that is not possible without the flag. And it seems this flag is also being used in the wild e.g. https://blog.picnic.nl/embracing-java-17-heres-what-we-learned-69779d95fdf2 > As of Java 16, JDK internals are strongly encapsulated by default ([JEP 396](https://openjdk.java.net/jeps/396)). These and other changes mean that some dependencies now [require](https://github.com/reactor/BlockHound/issues/33) additional JVM flags such as --add-opens and -XX:+AllowRedefinitionToAddDeleteMethods to function properly. We updated our shared build system such that teams can configure these flags in a single place, ensuring that test and production runtimes remain in sync. With more info in https://github.com/reactor/BlockHound/issues/33 So I am quite concerned that this "workaround" has become entrenched. src/hotspot/share/prims/jvmtiRedefineClasses.cpp line 4053: > 4051: } > 4052: > 4053: void VM_RedefineClasses::compute_matching_methods() { I can't see that this method actually still does anything useful. ?? src/hotspot/share/runtime/arguments.cpp line 525: > 523: // -------------- Deprecated Flags -------------- > 524: // --- Non-alias flags - sorted by obsolete_in then expired_in: > 525: { "AllowRedefinitionToAddDeleteMethods", JDK_Version::jdk(13), JDK_Version::jdk(26), JDK_Version::jdk(27) }, Please move this line to before line 535 (ParallelRefProcEnabled) so that we are sorted on obsolete_in as required. ------------- PR Review: https://git.openjdk.org/jdk/pull/26232#pullrequestreview-3004272187 PR Review Comment: https://git.openjdk.org/jdk/pull/26232#discussion_r2196808392 PR Review Comment: https://git.openjdk.org/jdk/pull/26232#discussion_r2196813023 From fweimer at openjdk.org Thu Jul 10 10:07:38 2025 From: fweimer at openjdk.org (Florian Weimer) Date: Thu, 10 Jul 2025 10:07:38 GMT Subject: RFR: 8360559: Optimize Math.sinh for x86 64 bit platforms In-Reply-To: References: Message-ID: On Mon, 7 Jul 2025 23:53:14 GMT, Mohamed Issa wrote: > I'm not sure which libm version you're referring to. The only current sinh benchmark I'm aware of is in MathBench.java, and the benchmarks in SinhPerf.java didn't exist until now. Could you clarify? I didn't notice the code you ported over from the Intel math library at first. I assumed ?libm? referred to the system libm version. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26152#issuecomment-3056706410 From liach at openjdk.org Thu Jul 10 12:58:55 2025 From: liach at openjdk.org (Chen Liang) Date: Thu, 10 Jul 2025 12:58:55 GMT Subject: RFR: 8361842: Validate input in both Java and C++ for java.lang.StringCoding intrinsics In-Reply-To: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com> References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com> Message-ID: On Thu, 26 Jun 2025 10:48:37 GMT, Volkan Yazici wrote: > Validate input in `java.lang.StringCoding` intrinsic Java wrappers, improve their documentation, enhance the checks in the associated C++ methods, and adapt them to cause VM crash on invalid input. > > ## Implementation notes > > The goal of the associated umbrella issue [JDK-8156534](https://bugs.openjdk.org/browse/JDK-8156534) is to, for `java.lang.String*` classes, > > 1. Move `@IntrinsicCandidate`-annotated `public` methods1 (in Java code) to `private` ones, and wrap them with a `public` ["front door" method](https://github.com/openjdk/jdk/pull/24982#discussion_r2087493446) > 2. Since we moved the `@IntrinsicCandidate` annotation to a new method, intrinsic mappings ? i.e., associated `do_intrinsic()` calls in `vmIntrinsics.hpp` ? need to be updated too > 3. Add necessary input validation (range, null, etc.) checks to the newly created public front door method > 4. Place all input validation checks in the intrinsic code (add if missing!) behind a `VerifyIntrinsicChecks` VM flag > > Following preliminary work needs to be carried out as well: > > 1. Add a new `VerifyIntrinsicChecks` VM flag > 2. Update `generate_string_range_check` to produce a `HaltNode`. That is, crash the VM if `VerifyIntrinsicChecks` is set and a Java wrapper fails to spot an invalid input. > > 1 `@IntrinsicCandidate`-annotated constructors are not subject to this change, since they are a special case. > > ## Functional and performance tests > > - `tier1` (which includes `test/hotspot/jtreg/compiler/intrinsics/string`) passes on several platforms. Further tiers will be executed after integrating reviewer feedback. > > - Performance impact is still actively monitored using `test/micro/org/openjdk/bench/java/lang/String{En,De}code.java`, among other tests. If you have suggestions on benchmarks, please share in the comments. > > ## Verification of the VM crash > > I've tested the VM crash scenario as follows: > > 1. Created the following test program: > > public class StrIntri { > public static void main(String[] args) { > Exception lastException = null; > for (int i = 0; i < 1_000_000; i++) { > try { > jdk.internal.access.SharedSecrets.getJavaLangAccess().countPositives(new byte[]{1,2,3}, 2, 5); > } catch (Exception exception) { > lastException = exception; > } > } > if (lastException != null) { > lastException.printStackTrace(); > } else { > System.out.println("completed"); > } > } > } > > 2. Comp... src/java.base/share/classes/java/lang/StringCoding.java line 93: > 91: public static int countPositives(byte[] ba, int off, int len) { > 92: Objects.requireNonNull(ba, "ba"); > 93: Objects.checkFromIndexSize(off, len, ba.length); I recall core libraries intentionally avoided this because of performance problems. Is it possible for us to say trust the `len` argument to be non-negative? That allows us to simplify this to `Objects.checkIndex(off, ba.length - len)`. See this usage in perf-sensitive FFM API: https://github.com/openjdk/jdk/blob/149882416a956dec728a964c150b826dd589908f/src/java.base/share/classes/jdk/internal/foreign/AbstractMemorySegmentImpl.java#L401 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2169545990 From vyazici at openjdk.org Thu Jul 10 12:58:53 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Thu, 10 Jul 2025 12:58:53 GMT Subject: RFR: 8361842: Validate input in both Java and C++ for java.lang.StringCoding intrinsics Message-ID: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com> Validate input in `java.lang.StringCoding` intrinsic Java wrappers, improve their documentation, enhance the checks in the associated C++ methods, and adapt them to cause VM crash on invalid input. ## Implementation notes The goal of the associated umbrella issue [JDK-8156534](https://bugs.openjdk.org/browse/JDK-8156534) is to, for `java.lang.String*` classes, 1. Move `@IntrinsicCandidate`-annotated `public` methods1 (in Java code) to `private` ones, and wrap them with a `public` ["front door" method](https://github.com/openjdk/jdk/pull/24982#discussion_r2087493446) 2. Since we moved the `@IntrinsicCandidate` annotation to a new method, intrinsic mappings ? i.e., associated `do_intrinsic()` calls in `vmIntrinsics.hpp` ? need to be updated too 3. Add necessary input validation (range, null, etc.) checks to the newly created public front door method 4. Place all input validation checks in the intrinsic code (add if missing!) behind a `VerifyIntrinsicChecks` VM flag Following preliminary work needs to be carried out as well: 1. Add a new `VerifyIntrinsicChecks` VM flag 2. Update `generate_string_range_check` to produce a `HaltNode`. That is, crash the VM if `VerifyIntrinsicChecks` is set and a Java wrapper fails to spot an invalid input. 1 `@IntrinsicCandidate`-annotated constructors are not subject to this change, since they are a special case. ## Functional and performance tests - `tier1` (which includes `test/hotspot/jtreg/compiler/intrinsics/string`) passes on several platforms. Further tiers will be executed after integrating reviewer feedback. - Performance impact is still actively monitored using `test/micro/org/openjdk/bench/java/lang/String{En,De}code.java`, among other tests. If you have suggestions on benchmarks, please share in the comments. ## Verification of the VM crash I've tested the VM crash scenario as follows: 1. Created the following test program: public class StrIntri { public static void main(String[] args) { Exception lastException = null; for (int i = 0; i < 1_000_000; i++) { try { jdk.internal.access.SharedSecrets.getJavaLangAccess().countPositives(new byte[]{1,2,3}, 2, 5); } catch (Exception exception) { lastException = exception; } } if (lastException != null) { lastException.printStackTrace(); } else { System.out.println("completed"); } } } 2. Compiled the JDK and run the test: $ bash jib.sh configure -p linux-x64-slowdebug $ CONF=linux-x64-slowdebug make jdk $ ./build/linux-x64-slowdebug/jdk/bin/java -XX:+VerifyIntrinsicChecks --add-exports java.base/jdk.internal.access=ALL-UNNAMED StrIntri.java java.lang.ArrayIndexOutOfBoundsException: Range [2, 2 + 5) out of bounds for length 3 Received `AIOOBE` as expected. 3. Removed all checks in `StringCodec.java`, and re-compiled the JDK 4. Set the `countPositives(...)` arguments in the program to `(null, 1, 1)`, run it, and observed the VM crash with `unexpected null in intrinsic`. 5. Set the `countPositives(...)` arguments in the program to `(new byte[]{1,2,3}, 2, 5)`, run it, and observed the VM crash with `unexpected guard failure in intrinsic`. ------------- Commit messages: - Merge remote-tracking branch 'upstream/master' into strIntrinCheck - Fix `EUC_JP.java.template` broken due to `encodeASCII` rename - Remove `StringCodingCountPositives`, `String{En,De}code` already cover our cases - Improve intrinsics in `StringCoding` - Add `StringCodingCountPositives` benchmark - Apply review feedback - Move `StringCoding::countPositives` checks from C++ to Java Changes: https://git.openjdk.org/jdk/pull/25998/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25998&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8361842 Stats: 271 lines in 18 files changed: 157 ins; 19 del; 95 mod Patch: https://git.openjdk.org/jdk/pull/25998.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25998/head:pull/25998 PR: https://git.openjdk.org/jdk/pull/25998 From duke at openjdk.org Thu Jul 10 12:58:56 2025 From: duke at openjdk.org (ExE Boss) Date: Thu, 10 Jul 2025 12:58:56 GMT Subject: RFR: 8361842: Validate input in both Java and C++ for java.lang.StringCoding intrinsics In-Reply-To: References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com> Message-ID: On Fri, 27 Jun 2025 13:24:52 GMT, Chen Liang wrote: >> But the original code already checks for `len >= 0`, right? See `LibraryCallKit::inline_countPositives` -> `generate_string_range_check` -> `// Offset and count must not be negative` >> >> This PR is about moving the range checks from the intrinsics into the Java wrappers. Removing range checks is out of the scope and should be carefully evaluated on a case-by-case basis separately. > > My point is this is a performance-sensitive API. We are using a known-slow check method `checkFromIndexSize` which may introduce a performance regression. Maybe?use `jdk.internal.util.Preconditions` directly?instead? Suggestion: Preconditions.checkFromIndexSize(off, len, ba.length, null); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2172823303 From vyazici at openjdk.org Thu Jul 10 12:58:56 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Thu, 10 Jul 2025 12:58:56 GMT Subject: RFR: 8361842: Validate input in both Java and C++ for java.lang.StringCoding intrinsics In-Reply-To: References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com> Message-ID: On Fri, 4 Jul 2025 15:03:33 GMT, Volkan Yazici wrote: >> Maybe?use `jdk.internal.util.Preconditions` directly?instead? >> Suggestion: >> >> Preconditions.checkFromIndexSize(off, len, ba.length, null); > > @ExE-Boss, I consulted this internally and decided to stick to using public APIs, unless there is a reason not to do so. In short, given `Objects::checkFromIndexSize` directly delegates to `Preconditions::checkFromIndexSize`, I expect that C2 will do its magic. Note my remark above that, prior to promoting this draft to a PR, a comprehensive benchmark suite run will be performed when all intrinsics of concern are addressed. Doh! I've just noticed `Objects::checkFromIndexSize` throws `IndexOutOfBoundsException`, though we need `ArrayIndexOutOfBoundsException`. `Objects::checkFromIndexSize` doesn't accept an exception supplier, replacing it with `Preconditions::checkFromIndexSize`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2185930404 From vyazici at openjdk.org Thu Jul 10 12:58:56 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Thu, 10 Jul 2025 12:58:56 GMT Subject: RFR: 8361842: Validate input in both Java and C++ for java.lang.StringCoding intrinsics In-Reply-To: References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com> Message-ID: On Fri, 27 Jun 2025 13:24:52 GMT, Chen Liang wrote: >> But the original code already checks for `len >= 0`, right? See `LibraryCallKit::inline_countPositives` -> `generate_string_range_check` -> `// Offset and count must not be negative` >> >> This PR is about moving the range checks from the intrinsics into the Java wrappers. Removing range checks is out of the scope and should be carefully evaluated on a case-by-case basis separately. > > My point is this is a performance-sensitive API. We are using a known-slow check method `checkFromIndexSize` which may introduce a performance regression. @liach, thanks for sharing your feedback on this draft, much appreciated. ? In order to address your (rightful) concerns (which I also share) regarding the performance impact, in 196fc5d, I've added `StringCodingCountPositives` JMH benchmark and produced the following results: *OS:* Ubuntu 24.04.2 *CPU:* Intel Core Ultra 9 185H x 22 Mode Cnt Score Error Units avgt 10 8.617 ? 0.646 ns/op # 149882416a9 (strIntrinCheck) avgt 10 8.787 ? 0.313 ns/op # 5a1301df195 (master) AFAICT, (even though the patched version appears to be performing better ?) the scores do match. Note that I will run the entire `test/micro/org/openjdk/bench/java/lang/String*.java` suite on various platforms and make sure there are no (visible?) performance regressions, before promoting this draft to a PR. Let me know if this addresses your concerns and if there is anything else I can do to better assess the performance impact. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2185582087 From vyazici at openjdk.org Thu Jul 10 12:58:56 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Thu, 10 Jul 2025 12:58:56 GMT Subject: RFR: 8361842: Validate input in both Java and C++ for java.lang.StringCoding intrinsics In-Reply-To: References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com> Message-ID: On Fri, 27 Jun 2025 20:21:31 GMT, ExE Boss wrote: >> My point is this is a performance-sensitive API. We are using a known-slow check method `checkFromIndexSize` which may introduce a performance regression. > > Maybe?use `jdk.internal.util.Preconditions` directly?instead? > Suggestion: > > Preconditions.checkFromIndexSize(off, len, ba.length, null); @ExE-Boss, I consulted this internally and decided to stick to using public APIs, unless there is a reason not to do so. In short, given `Objects::checkFromIndexSize` directly delegates to `Preconditions::checkFromIndexSize`, I expect that C2 will do its magic. Note my remark above that, prior to promoting this draft to a PR, a comprehensive benchmark suite run will be performed when all intrinsics of concern are addressed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2185587428 From liach at openjdk.org Thu Jul 10 12:58:55 2025 From: liach at openjdk.org (Chen Liang) Date: Thu, 10 Jul 2025 12:58:55 GMT Subject: RFR: 8361842: Validate input in both Java and C++ for java.lang.StringCoding intrinsics In-Reply-To: References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com> Message-ID: On Fri, 27 Jun 2025 07:22:48 GMT, Tobias Hartmann wrote: >> src/java.base/share/classes/java/lang/StringCoding.java line 93: >> >>> 91: public static int countPositives(byte[] ba, int off, int len) { >>> 92: Objects.requireNonNull(ba, "ba"); >>> 93: Objects.checkFromIndexSize(off, len, ba.length); >> >> I recall core libraries intentionally avoided this because of performance problems. Is it possible for us to say trust the `len` argument to be non-negative? That allows us to simplify this to `Objects.checkIndex(off, ba.length - len)`. See this usage in perf-sensitive FFM API: https://github.com/openjdk/jdk/blob/149882416a956dec728a964c150b826dd589908f/src/java.base/share/classes/jdk/internal/foreign/AbstractMemorySegmentImpl.java#L401 > > But the original code already checks for `len >= 0`, right? See `LibraryCallKit::inline_countPositives` -> `generate_string_range_check` -> `// Offset and count must not be negative` > > This PR is about moving the range checks from the intrinsics into the Java wrappers. Removing range checks is out of the scope and should be carefully evaluated on a case-by-case basis separately. My point is this is a performance-sensitive API. We are using a known-slow check method `checkFromIndexSize` which may introduce a performance regression. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2172044145 From thartmann at openjdk.org Thu Jul 10 12:58:55 2025 From: thartmann at openjdk.org (Tobias Hartmann) Date: Thu, 10 Jul 2025 12:58:55 GMT Subject: RFR: 8361842: Validate input in both Java and C++ for java.lang.StringCoding intrinsics In-Reply-To: References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com> Message-ID: On Thu, 26 Jun 2025 17:26:02 GMT, Chen Liang wrote: >> Validate input in `java.lang.StringCoding` intrinsic Java wrappers, improve their documentation, enhance the checks in the associated C++ methods, and adapt them to cause VM crash on invalid input. >> >> ## Implementation notes >> >> The goal of the associated umbrella issue [JDK-8156534](https://bugs.openjdk.org/browse/JDK-8156534) is to, for `java.lang.String*` classes, >> >> 1. Move `@IntrinsicCandidate`-annotated `public` methods1 (in Java code) to `private` ones, and wrap them with a `public` ["front door" method](https://github.com/openjdk/jdk/pull/24982#discussion_r2087493446) >> 2. Since we moved the `@IntrinsicCandidate` annotation to a new method, intrinsic mappings ? i.e., associated `do_intrinsic()` calls in `vmIntrinsics.hpp` ? need to be updated too >> 3. Add necessary input validation (range, null, etc.) checks to the newly created public front door method >> 4. Place all input validation checks in the intrinsic code (add if missing!) behind a `VerifyIntrinsicChecks` VM flag >> >> Following preliminary work needs to be carried out as well: >> >> 1. Add a new `VerifyIntrinsicChecks` VM flag >> 2. Update `generate_string_range_check` to produce a `HaltNode`. That is, crash the VM if `VerifyIntrinsicChecks` is set and a Java wrapper fails to spot an invalid input. >> >> 1 `@IntrinsicCandidate`-annotated constructors are not subject to this change, since they are a special case. >> >> ## Functional and performance tests >> >> - `tier1` (which includes `test/hotspot/jtreg/compiler/intrinsics/string`) passes on several platforms. Further tiers will be executed after integrating reviewer feedback. >> >> - Performance impact is still actively monitored using `test/micro/org/openjdk/bench/java/lang/String{En,De}code.java`, among other tests. If you have suggestions on benchmarks, please share in the comments. >> >> ## Verification of the VM crash >> >> I've tested the VM crash scenario as follows: >> >> 1. Created the following test program: >> >> public class StrIntri { >> public static void main(String[] args) { >> Exception lastException = null; >> for (int i = 0; i < 1_000_000; i++) { >> try { >> jdk.internal.access.SharedSecrets.getJavaLangAccess().countPositives(new byte[]{1,2,3}, 2, 5); >> } catch (Exception exception) { >> lastException = exception; >> } >> } >> if (lastException != null) { >> lastException.printStackTrace(); >> ... > > src/java.base/share/classes/java/lang/StringCoding.java line 93: > >> 91: public static int countPositives(byte[] ba, int off, int len) { >> 92: Objects.requireNonNull(ba, "ba"); >> 93: Objects.checkFromIndexSize(off, len, ba.length); > > I recall core libraries intentionally avoided this because of performance problems. Is it possible for us to say trust the `len` argument to be non-negative? That allows us to simplify this to `Objects.checkIndex(off, ba.length - len)`. See this usage in perf-sensitive FFM API: https://github.com/openjdk/jdk/blob/149882416a956dec728a964c150b826dd589908f/src/java.base/share/classes/jdk/internal/foreign/AbstractMemorySegmentImpl.java#L401 But the original code already checks for `len >= 0`, right? See `LibraryCallKit::inline_countPositives` -> `generate_string_range_check` -> `// Offset and count must not be negative` This PR is about moving the range checks from the intrinsics into the Java wrappers. Removing range checks is out of the scope and should be carefully evaluated on a case-by-case basis separately. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2170997677 From vyazici at openjdk.org Thu Jul 10 12:58:54 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Thu, 10 Jul 2025 12:58:54 GMT Subject: RFR: 8361842: Validate input in both Java and C++ for java.lang.StringCoding intrinsics In-Reply-To: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com> References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com> Message-ID: On Thu, 26 Jun 2025 10:48:37 GMT, Volkan Yazici wrote: > Validate input in `java.lang.StringCoding` intrinsic Java wrappers, improve their documentation, enhance the checks in the associated C++ methods, and adapt them to cause VM crash on invalid input. > > ## Implementation notes > > The goal of the associated umbrella issue [JDK-8156534](https://bugs.openjdk.org/browse/JDK-8156534) is to, for `java.lang.String*` classes, > > 1. Move `@IntrinsicCandidate`-annotated `public` methods1 (in Java code) to `private` ones, and wrap them with a `public` ["front door" method](https://github.com/openjdk/jdk/pull/24982#discussion_r2087493446) > 2. Since we moved the `@IntrinsicCandidate` annotation to a new method, intrinsic mappings ? i.e., associated `do_intrinsic()` calls in `vmIntrinsics.hpp` ? need to be updated too > 3. Add necessary input validation (range, null, etc.) checks to the newly created public front door method > 4. Place all input validation checks in the intrinsic code (add if missing!) behind a `VerifyIntrinsicChecks` VM flag > > Following preliminary work needs to be carried out as well: > > 1. Add a new `VerifyIntrinsicChecks` VM flag > 2. Update `generate_string_range_check` to produce a `HaltNode`. That is, crash the VM if `VerifyIntrinsicChecks` is set and a Java wrapper fails to spot an invalid input. > > 1 `@IntrinsicCandidate`-annotated constructors are not subject to this change, since they are a special case. > > ## Functional and performance tests > > - `tier1` (which includes `test/hotspot/jtreg/compiler/intrinsics/string`) passes on several platforms. Further tiers will be executed after integrating reviewer feedback. > > - Performance impact is still actively monitored using `test/micro/org/openjdk/bench/java/lang/String{En,De}code.java`, among other tests. If you have suggestions on benchmarks, please share in the comments. > > ## Verification of the VM crash > > I've tested the VM crash scenario as follows: > > 1. Created the following test program: > > public class StrIntri { > public static void main(String[] args) { > Exception lastException = null; > for (int i = 0; i < 1_000_000; i++) { > try { > jdk.internal.access.SharedSecrets.getJavaLangAccess().countPositives(new byte[]{1,2,3}, 2, 5); > } catch (Exception exception) { > lastException = exception; > } > } > if (lastException != null) { > lastException.printStackTrace(); > } else { > System.out.println("completed"); > } > } > } > > 2. Comp... src/hotspot/share/opto/library_call.cpp line 963: > 961: > 962: if (bailout->req() > 1) { > 963: if (halt) { Toggle to force a VM crash to be used to surface intrinsic Java wrappers failing to spot invalid input. src/java.base/share/classes/java/lang/StringCoding.java line 140: > 138: * > 139: * @param sa the source byte array containing characters encoded in UTF-16 > 140: * @param sp the index of the byte (not character!) from the source array to start reading from Note the `byte (not character!)` emphasis here and below. src/java.base/share/classes/java/lang/StringCoding.java line 150: > 148: */ > 149: static int encodeISOArray(byte[] sa, int sp, byte[] da, int dp, int len) { > 150: checkFromIndexSize(sp, len << 1, requireNonNull(sa, "sa").length, AIOOBE_FORMATTER); `sa` contains 2-byte `char`s, and `sp` points to an index of this inflated array. Though, `len` denotes the codepoint count, hence the `len << 1` while checking `sp` and `len` bounds. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2197576759 PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2197566783 PR Review Comment: https://git.openjdk.org/jdk/pull/25998#discussion_r2197572078 From alanb at openjdk.org Thu Jul 10 14:22:43 2025 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 10 Jul 2025 14:22:43 GMT Subject: RFR: 8361587: AssertionError in File.listFiles() when path is empty and -esa is enabled [v3] In-Reply-To: References: Message-ID: On Wed, 9 Jul 2025 21:57:56 GMT, Brian Burkhalter wrote: >> Changes to address `File.listFiles` invoked on an empty path. This fixes an oversight in #22821. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8361587: Expand test coverage of File methods The implementation change looks good, just a few minor comments on the test additions. test/jdk/java/io/File/EmptyPath.java line 112: > 110: @Test > 111: public void getAbsoluteFile() { > 112: assertEquals(p.toAbsolutePath(), f.getAbsoluteFile().toPath()); I think it would be better to have the "actual" be f.getAbsoluteFile(), so the expected will be p.toAbsolutePath().toFile(). Same comment on the getCanonicalFile test. test/jdk/java/io/File/EmptyPath.java line 229: > 227: child.deleteOnExit(); > 228: > 229: assertTrue(Arrays.asList(f.list()).contains(child.getName())); I think would be clearer to check that ioSet contains child.getName. ------------- Marked as reviewed by alanb (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26224#pullrequestreview-3005927479 PR Review Comment: https://git.openjdk.org/jdk/pull/26224#discussion_r2197873861 PR Review Comment: https://git.openjdk.org/jdk/pull/26224#discussion_r2197877410 From missa at openjdk.org Thu Jul 10 14:33:40 2025 From: missa at openjdk.org (Mohamed Issa) Date: Thu, 10 Jul 2025 14:33:40 GMT Subject: RFR: 8360559: Optimize Math.sinh for x86 64 bit platforms In-Reply-To: References: Message-ID: On Thu, 10 Jul 2025 04:52:01 GMT, Joe Darcy wrote: > What is the accuracy of the algorithm in ulps (units the last place)? > > The java.lang.Math specification has max error and various other accuracy requirements any implementation must meet. 0.51 ulps ------------- PR Comment: https://git.openjdk.org/jdk/pull/26152#issuecomment-3057699676 From rgiulietti at openjdk.org Thu Jul 10 15:23:49 2025 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Thu, 10 Jul 2025 15:23:49 GMT Subject: RFR: 8077587: BigInteger Roots [v15] In-Reply-To: <8id1JAg7v3hZfZgSn2aRRA_V-mnpgMWrHD8xhwb7qMM=.f31152a1-23ac-43a5-b26c-21a5f53a1272@github.com> References: <8id1JAg7v3hZfZgSn2aRRA_V-mnpgMWrHD8xhwb7qMM=.f31152a1-23ac-43a5-b26c-21a5f53a1272@github.com> Message-ID: On Sat, 17 May 2025 11:25:58 GMT, fabioromano1 wrote: >> The [Rampdown Phase One](https://openjdk.org/projects/jdk/25/) for JDK 25 is about 3 weeks from now. >> >> I think it's a bit too late for API additions to be approved in due time. And even if we could rush this work for 25, it makes little sense to have this in 25 and the future one in 26. IMO, they should be released together. So this and the followup PR for `BigDecimal` will probably be integrated only in 26. >> >> In other words, take your time ;-) > > @rgiulietti Regarding the tests for _n_-th root, the tests for `sqrt()` could be extended in order to test also `nthRoot()`. @fabioromano1 IIUC, the bulk of the code in the PR is aimed at finding a good starting estimate. Algorithm 1.14 RootInt in [Brent & Zimmermann](https://maths-people.anu.edu.au/~brent/pd/mca-cup-0.5.9.pdf), p. 27-28, however, works for any initial estimate $u$ meeting $u \ge \lfloor m^{1/k}\rfloor$. Now, assume $2^{l-1} \le m < 2^l$. We have $m^{1/k} < 2^{l/k} \le 2^{\lceil l/k\rceil}$ Thus, the initial estimate could be simple as $u = 2^{\lceil l/k\rceil}$. This has the following advantages: * It's super-easy to determine. * Computing the _first_ $t = (k - 1) s + \lfloor m/s^{k-1}\rfloor$ (L.4 of RootInt) is quite efficient and can be done separately using shifts and additions. I don't know if this has some negative impact on performance in practice, but IMO the resulting code is easier to review, understand, and maintain. Maybe worth giving it a try. WDYT? ------------- PR Comment: https://git.openjdk.org/jdk/pull/24898#issuecomment-3057905134 From bpb at openjdk.org Thu Jul 10 15:26:20 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 10 Jul 2025 15:26:20 GMT Subject: RFR: 8361587: AssertionError in File.listFiles() when path is empty and -esa is enabled [v4] In-Reply-To: References: Message-ID: > Changes to address `File.listFiles` invoked on an empty path. This fixes an oversight in #22821. Brian Burkhalter has updated the pull request incrementally with two additional commits since the last revision: - 8361587: Fix omission in previous commit - 8361587: Address reviewer comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26224/files - new: https://git.openjdk.org/jdk/pull/26224/files/afaa9329..2e42c991 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26224&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26224&range=02-03 Stats: 7 lines in 1 file changed: 3 ins; 2 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/26224.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26224/head:pull/26224 PR: https://git.openjdk.org/jdk/pull/26224 From bpb at openjdk.org Thu Jul 10 15:26:20 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 10 Jul 2025 15:26:20 GMT Subject: RFR: 8361587: AssertionError in File.listFiles() when path is empty and -esa is enabled [v3] In-Reply-To: References: Message-ID: <0Ov4B1SThV5kXkLDVX4yJPXjmd2ZwW0CEZQe018sWTY=.60089096-6114-4dfb-8a6a-181448dff6b0@github.com> On Thu, 10 Jul 2025 14:18:31 GMT, Alan Bateman wrote: >> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: >> >> 8361587: Expand test coverage of File methods > > test/jdk/java/io/File/EmptyPath.java line 112: > >> 110: @Test >> 111: public void getAbsoluteFile() { >> 112: assertEquals(p.toAbsolutePath(), f.getAbsoluteFile().toPath()); > > I think it would be better to have the "actual" be f.getAbsoluteFile(), so the expected will be p.toAbsolutePath().toFile(). > > Same comment on the getCanonicalFile test. So changed in 51e3701 and 2e42c99. > test/jdk/java/io/File/EmptyPath.java line 229: > >> 227: child.deleteOnExit(); >> 228: >> 229: assertTrue(Arrays.asList(f.list()).contains(child.getName())); > > I think would be clearer to check that ioSet contains child.getName. So changed in 51e3701. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26224#discussion_r2198051943 PR Review Comment: https://git.openjdk.org/jdk/pull/26224#discussion_r2198052617 From alanb at openjdk.org Thu Jul 10 16:00:40 2025 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 10 Jul 2025 16:00:40 GMT Subject: RFR: 8361497: Scoped Values: orElse and orElseThrow do not access the cache In-Reply-To: References: Message-ID: <3sVe377DO4pygelyscKiYce786fDnIEFwbP0O6jxhcs=.b429003d-166d-4673-bc0a-be3700ddab9a@github.com> On Mon, 7 Jul 2025 16:13:08 GMT, Andrew Haley wrote: > Neither `ScopedValue.orElse` nor `ScopedValue.orElseThrow` consult the cache when searching for a binding. Neither do they update the cache when a binding is found. > While this issue does not affect spec compliance, it is surprising to users that `x.orElse(other)` should be slower than `x.isBound ? x.get() : other`. Marked as reviewed by alanb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26164#pullrequestreview-3006369629 From alanb at openjdk.org Thu Jul 10 16:03:39 2025 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 10 Jul 2025 16:03:39 GMT Subject: RFR: 8361587: AssertionError in File.listFiles() when path is empty and -esa is enabled [v4] In-Reply-To: References: Message-ID: On Thu, 10 Jul 2025 15:26:20 GMT, Brian Burkhalter wrote: >> Changes to address `File.listFiles` invoked on an empty path. This fixes an oversight in #22821. > > Brian Burkhalter has updated the pull request incrementally with two additional commits since the last revision: > > - 8361587: Fix omission in previous commit > - 8361587: Address reviewer comments Marked as reviewed by alanb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26224#pullrequestreview-3006373455 From naoto at openjdk.org Thu Jul 10 16:10:54 2025 From: naoto at openjdk.org (Naoto Sato) Date: Thu, 10 Jul 2025 16:10:54 GMT Subject: RFR: 8361717: Refactor Collections.emptyList() in Locale related classes In-Reply-To: <5o7ommmTBTXH9udy76qajqgUNSF89aiQ4ptsebC3v3o=.01b18594-1798-41a7-972f-15572d6b4ace@github.com> References: <5o7ommmTBTXH9udy76qajqgUNSF89aiQ4ptsebC3v3o=.01b18594-1798-41a7-972f-15572d6b4ace@github.com> Message-ID: On Wed, 9 Jul 2025 18:39:40 GMT, Naoto Sato wrote: > Replaced Collections.emptyList() with List.of() as part of refactoring. This was discussed in the context of investigating a CDS-related issue (https://bugs.openjdk.org/browse/JDK-8357281?focusedId=14796714&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14796714). Although the root cause was ultimately determined to be user error, modernizing the code by using List.of() is still a desirable improvement Thanks for the reviews! > except that `Collections.emptyList()` and `List.of()` unfortunately have different tolerance to calls `List.indexOf(null)` and `List.contains(null)`. True in general, but as @liach mentioned, those singletons are internal use only so the difference is not relevant here. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26225#issuecomment-3058072009 From naoto at openjdk.org Thu Jul 10 16:10:54 2025 From: naoto at openjdk.org (Naoto Sato) Date: Thu, 10 Jul 2025 16:10:54 GMT Subject: Integrated: 8361717: Refactor Collections.emptyList() in Locale related classes In-Reply-To: <5o7ommmTBTXH9udy76qajqgUNSF89aiQ4ptsebC3v3o=.01b18594-1798-41a7-972f-15572d6b4ace@github.com> References: <5o7ommmTBTXH9udy76qajqgUNSF89aiQ4ptsebC3v3o=.01b18594-1798-41a7-972f-15572d6b4ace@github.com> Message-ID: <5JciFlhCUpoKPw9lljQnP-04WwWDCQu4q5x04ln9YLI=.4766c2d7-bd7d-4e9e-8a57-4e751887d23c@github.com> On Wed, 9 Jul 2025 18:39:40 GMT, Naoto Sato wrote: > Replaced Collections.emptyList() with List.of() as part of refactoring. This was discussed in the context of investigating a CDS-related issue (https://bugs.openjdk.org/browse/JDK-8357281?focusedId=14796714&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14796714). Although the root cause was ultimately determined to be user error, modernizing the code by using List.of() is still a desirable improvement This pull request has now been integrated. Changeset: f5afbbd3 Author: Naoto Sato URL: https://git.openjdk.org/jdk/commit/f5afbbd32a0f46973664a228e6799fb1a958cd51 Stats: 5 lines in 2 files changed: 0 ins; 2 del; 3 mod 8361717: Refactor Collections.emptyList() in Locale related classes Reviewed-by: bpb, jlu, liach, cstein ------------- PR: https://git.openjdk.org/jdk/pull/26225 From duke at openjdk.org Thu Jul 10 16:38:40 2025 From: duke at openjdk.org (fabioromano1) Date: Thu, 10 Jul 2025 16:38:40 GMT Subject: RFR: 8077587: BigInteger Roots [v15] In-Reply-To: References: <8id1JAg7v3hZfZgSn2aRRA_V-mnpgMWrHD8xhwb7qMM=.f31152a1-23ac-43a5-b26c-21a5f53a1272@github.com> Message-ID: On Thu, 10 Jul 2025 15:21:10 GMT, Raffaello Giulietti wrote: >> @rgiulietti Regarding the tests for _n_-th root, the tests for `sqrt()` could be extended in order to test also `nthRoot()`. > > @fabioromano1 IIUC, the bulk of the code in the PR is aimed at finding a good starting estimate. > Algorithm 1.14 RootInt in [Brent & Zimmermann](https://maths-people.anu.edu.au/~brent/pd/mca-cup-0.5.9.pdf), p. 27-28, however, works for any initial estimate $u$ meeting $u \ge \lfloor m^{1/k}\rfloor$. > > Now, assume $2^{l-1} \le m < 2^l$. We have $m^{1/k} < 2^{l/k} \le 2^{\lceil l/k\rceil}$ > Thus, the initial estimate could be simple as $u = 2^{\lceil l/k\rceil}$. > > This has the following advantages: > * It's super-easy to determine. > * Computing the _first_ $t = (k - 1) s + \lfloor m/s^{k-1}\rfloor$ (L.4 of RootInt) is quite efficient and can be done separately using shifts and additions. > > I don't know if this has some negative impact on performance in practice, but IMO the resulting code is easier to review, understand, and maintain. > > Maybe worth giving it a try. > WDYT? @rgiulietti It should be noted that the convergence of Newton's method is quadratic, meaning the number of correct bits doubles with each iteration. This means that, to keep the number of iterations low, the larger the input, the greater the need for as many initial correct bits as possible. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24898#issuecomment-3058165927 From dlunden at openjdk.org Thu Jul 10 18:25:43 2025 From: dlunden at openjdk.org (Daniel =?UTF-8?B?THVuZMOpbg==?=) Date: Thu, 10 Jul 2025 18:25:43 GMT Subject: RFR: 8359419: AArch64: Relax min vector length to 32-bit for short vectors [v4] In-Reply-To: References: Message-ID: <375qzJdzdKWky3-EHgnSiksFYbJIPvfR27xzUTF6vRA=.9eb63509-1ec6-4cc6-bff0-782290866a4d@github.com> On Wed, 9 Jul 2025 01:23:43 GMT, Xiaohong Gong wrote: >> ### Background >> On AArch64, the minimum vector length supported is 64-bit for basic types, except for `byte` and `boolean` (32-bit and 16-bit respectively to match special Vector API features). This limitation prevents intrinsification of vector type conversions between `short` and wider types (e.g. `long/double`) in Vector API when the entire vector length is within 128 bits, resulting in degraded performance for such conversions. >> >> For example, type conversions between `ShortVector.SPECIES_128` and `LongVector.SPECIES_128` are not supported on AArch64 NEON and SVE architectures with 128-bit max vector size. This occurs because the compiler would need to generate a vector with 2 short elements, resulting in a 32-bit vector size. >> >> To intrinsify such type conversion APIs, we need to relax the min vector length constraint from 64-bit to 32-bit for short vectors. >> >> ### Impact Analysis >> #### 1. Vector types >> Vectors only with `short` element types will be affected, as we just supported 32-bit `short` vectors in this change. >> >> #### 2. Vector API >> No impact on Vector API or the vector-specific nodes. The minimum vector shape at API level remains 64-bit. It's not possible to generate a final vector IR with 32-bit vector size. Type conversions may generate intermediate 32-bit vectors, but they will be resized or cast to vectors with at least 64-bit length. >> >> #### 3. Auto-vectorization >> Enables vectorization of cases containing only 2 `short` lanes, with significant performance improvements. Since we have supported 32-bit vectors for `byte` type for a long time, extending this to `short` did not introduce additional risks. >> >> #### 4. Codegen of vector nodes >> NEON doesn't support 32-bit SIMD instructions, so we use 64-bit instructions instead. For lanewise operations, this is safe because the higher half bits can be ignored. >> >> Details: >> - Lanewise vector operations are unaffected as explained above. >> - NEON supports vector load/store instructions with 32-bit vector size, which we already use in relevant IRs (shared by SVE). >> - Cross-lane operations like reduction may be affected, potentially causing incorrect results for `min/max/mul/and` reductions. The min vector size for such operations should remain 64-bit. We've added assertions in match rules. Since it's currently not possible to generate such reductions (Vector API minimum is 64-bit, and SLP doesn't support subword type reductions), we maintain the status quo. However, addin... > > Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision: > > Disable auto-vectorization of double to short conversion for NEON and update tests @XiaohongGong The code changes look sane, although, for the record, I'm not that familiar with this part of HotSpot. Testing also looks good, details below. ### Testing - [GitHub Actions](https://github.com/dlunde/jdk/actions/runs/16165935815) - `tier1` to `tier4` (and additional Oracle-internal testing) on Windows x64, Linux x64, Linux aarch64, macOS x64, and macOS aarch64. - Performance testing on DaCapo, Renaissance, SPECjbb, and SPECjvm on Linux x64 and macOS aarch64. No observable improvements nor regressions. ------------- Marked as reviewed by dlunden (Committer). PR Review: https://git.openjdk.org/jdk/pull/26057#pullrequestreview-3006812696 From jrose at openjdk.org Thu Jul 10 20:56:38 2025 From: jrose at openjdk.org (John R Rose) Date: Thu, 10 Jul 2025 20:56:38 GMT Subject: RFR: 8361842: Validate input in both Java and C++ for java.lang.StringCoding intrinsics In-Reply-To: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com> References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com> Message-ID: <4dolSfV2QJhf4nW0zxQ3Z6hti93KWU1PD9sYvXfYDnc=.307324ef-6bad-43ce-9397-e39abcfad410@github.com> On Thu, 26 Jun 2025 10:48:37 GMT, Volkan Yazici wrote: > Validate input in `java.lang.StringCoding` intrinsic Java wrappers, improve their documentation, enhance the checks in the associated C++ methods, and adapt them to cause VM crash on invalid input. > > ## Implementation notes > > The goal of the associated umbrella issue [JDK-8156534](https://bugs.openjdk.org/browse/JDK-8156534) is to, for `java.lang.String*` classes, > > 1. Move `@IntrinsicCandidate`-annotated `public` methods1 (in Java code) to `private` ones, and wrap them with a `public` ["front door" method](https://github.com/openjdk/jdk/pull/24982#discussion_r2087493446) > 2. Since we moved the `@IntrinsicCandidate` annotation to a new method, intrinsic mappings ? i.e., associated `do_intrinsic()` calls in `vmIntrinsics.hpp` ? need to be updated too > 3. Add necessary input validation (range, null, etc.) checks to the newly created public front door method > 4. Place all input validation checks in the intrinsic code (add if missing!) behind a `VerifyIntrinsicChecks` VM flag > > Following preliminary work needs to be carried out as well: > > 1. Add a new `VerifyIntrinsicChecks` VM flag > 2. Update `generate_string_range_check` to produce a `HaltNode`. That is, crash the VM if `VerifyIntrinsicChecks` is set and a Java wrapper fails to spot an invalid input. > > 1 `@IntrinsicCandidate`-annotated constructors are not subject to this change, since they are a special case. > > ## Functional and performance tests > > - `tier1` (which includes `test/hotspot/jtreg/compiler/intrinsics/string`) passes on several platforms. Further tiers will be executed after integrating reviewer feedback. > > - Performance impact is still actively monitored using `test/micro/org/openjdk/bench/java/lang/String{En,De}code.java`, among other tests. If you have suggestions on benchmarks, please share in the comments. > > ## Verification of the VM crash > > I've tested the VM crash scenario as follows: > > 1. Created the following test program: > > public class StrIntri { > public static void main(String[] args) { > Exception lastException = null; > for (int i = 0; i < 1_000_000; i++) { > try { > jdk.internal.access.SharedSecrets.getJavaLangAccess().countPositives(new byte[]{1,2,3}, 2, 5); > } catch (Exception exception) { > lastException = exception; > } > } > if (lastException != null) { > lastException.printStackTrace(); > } else { > System.out.println("completed"); > } > } > } > > 2. Comp... I disagree with a small part of the statement of goals: > Always validate all input at the intrinsic (but preferably behind a VM flag) As formulated above, this is a violation of DRY and if embraced the wrong way will lead to code that is harder to review and prove bug-free. Performing 100% accurate range/null/validation checks is deeply impractical for an assembly-based or IR-based intrinsic. It?s too hard to verify by code review, and coverage testing is suspect. We must frankly put all the weight of verification on Java code, including Java bytecode intrinsic behaviors. Java code is high-level and can be read mostly as a declarative spec, if clearly written (as straight-line code, then the intrinsic call). Also, such simple Java code shapes (and their underlying bytecodes) are tested many orders of magnitude more than any given intrinsic. I see two bits of evidence that you agree with me on this: 1. The intrinsic-local validation (IR or assembly) is allowed to Halt instead of throw, and 2. the intrinsic-local validation is optional, turned on only by a stress test mode. This tells me that the extra optional testing is also not required to be 100%. Thus, I think the above goal would be better stated this way: > Validate input in the IR or assembly code of the intrinsic in an ad hoc manner to catch bugs in the Java validation. > Note: IR or assembly based validation code should not obscure the code or add large maintenance costs, and under a VM diagnostic flag (or debug flag), and causing a VM halt instead of a Java throw. I think I'm agreeing with you on the material points. It is important to summarize our intentions accurately at the top, for those readers that are reading only the top as a summary. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25998#issuecomment-3059044829 From darcy at openjdk.org Thu Jul 10 21:26:37 2025 From: darcy at openjdk.org (Joe Darcy) Date: Thu, 10 Jul 2025 21:26:37 GMT Subject: RFR: 8360559: Optimize Math.sinh for x86 64 bit platforms In-Reply-To: References: Message-ID: On Thu, 10 Jul 2025 14:31:02 GMT, Mohamed Issa wrote: > > What is the accuracy of the algorithm in ulps (units the last place)? > > The java.lang.Math specification has max error and various other accuracy requirements any implementation must meet. > > 0.51 ulps Please add that as a comment to the changeset. Also, if the worst-case inputs for this algorithm are known, they should the added as part of the core libraries regression tests for the math library. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26152#issuecomment-3059152934 From liach at openjdk.org Thu Jul 10 21:30:53 2025 From: liach at openjdk.org (Chen Liang) Date: Thu, 10 Jul 2025 21:30:53 GMT Subject: RFR: 8361635: Missing List length validation in the Class-File API Message-ID: The `class` file format often only stores lists up to 65535 in size because size is encoded as a u2. Currently, we truncate the list size and write all contents, creating malformed `class` files. Almost all scenarios where such oversized lists are created can be considered an error; we should eagerly reject lists that would never be encodable in the `class` file format when users construct model objects. ------------- Depends on: https://git.openjdk.org/jdk/pull/26201 Commit messages: - Specify the list IAEs individually with clear size values - Spec updates - Years - Rollback redundant label change - Add more pseudo checks, also tests - Few more places - Sanitize u2 lists wip Changes: https://git.openjdk.org/jdk/pull/26252/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26252&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8361635 Stats: 811 lines in 46 files changed: 704 ins; 20 del; 87 mod Patch: https://git.openjdk.org/jdk/pull/26252.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26252/head:pull/26252 PR: https://git.openjdk.org/jdk/pull/26252 From almatvee at openjdk.org Thu Jul 10 21:44:32 2025 From: almatvee at openjdk.org (Alexander Matveev) Date: Thu, 10 Jul 2025 21:44:32 GMT Subject: RFR: 8351073: [macos] jpackage produces invalid Java runtime DMG bundles [v3] In-Reply-To: References: Message-ID: > Re-submission of https://github.com/openjdk/jdk/pull/25314 after merge conflict was resolved. Old PR will be closed. > > All comments are addressed from old PR. Merge conflict was significant, so it is like new fix. > > Fixed jpackage to produce valid Java runtimes based on description below: > > Definitions: > > - JDK bundle defined as bundle which contains "Contents/Home", "Contents/MacOS/libjli.dylib" and "Contents/Info.plist". > - Signed JDK bundle contains all files as JDK bundle + "Contents/_CodeSignature". > - JDK image defined as content of "Contents/Home". > - Signed JDK image does not exist, since it cannot be signed as bundle. > > jpackage output based on input: > > 1. "--runtime-image" points to unsigned JDK bundle and --mac-sign is not provided: > - jpackage will copy all files as is from provided path and run ad-hoc codesign. > > 2. "--runtime-image" points to unsigned JDK bundle and --mac-sign is provided: > - jpackage will copy all files as is from provided path and run codesign with appropriate certificate based on same logic as we do for application image. > > 3. "--runtime-image" points to signed JDK bundle and --mac-sign is not provided: > - jpackage will copy all files as is from provided path including "Contents/_CodeSignature" to preserve signing. > > 4. "--runtime-image" points to signed JDK bundle and --mac-sign is provided: > - jpackage will copy all files as is from provided path including "Contents/_CodeSignature" and will re-sign bundle with appropriate certificate. > > 5. "--runtime-image" points to JDK image and --mac-sign is not provided: > - jpackage will check for libjli.dylib presence in "lib" folder. > - Create JDK bundle by putting all files from provided path to "Contents/Home", libjli.dylib from "lib" to "Contents/MacOS/libjli.dylib" and create default "Contents/Info.plist" similar to what we do for runtime in application image. > - Ad-hoc signing will done. > > 6. "--runtime-image" points to JDK image and --mac-sign is provided: > - 2 first steps from 5 and certificate signing will be done. > > Additional changes: > - The bundle's top directory name will have the ".jdk" suffix. Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: 8351073: [macos] jpackage produces invalid Java runtime DMG bundles [v2] ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26173/files - new: https://git.openjdk.org/jdk/pull/26173/files/72a1e3a9..4b2a8d94 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26173&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26173&range=01-02 Stats: 230 lines in 13 files changed: 81 ins; 96 del; 53 mod Patch: https://git.openjdk.org/jdk/pull/26173.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26173/head:pull/26173 PR: https://git.openjdk.org/jdk/pull/26173 From almatvee at openjdk.org Thu Jul 10 21:48:52 2025 From: almatvee at openjdk.org (Alexander Matveev) Date: Thu, 10 Jul 2025 21:48:52 GMT Subject: RFR: 8351073: [macos] jpackage produces invalid Java runtime DMG bundles [v2] In-Reply-To: References: Message-ID: On Tue, 8 Jul 2025 00:15:29 GMT, Alexey Semenyuk wrote: >> Alexander Matveev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: >> >> - Merge remote-tracking branch 'upstream/master' into JDK-8351073-2 >> - 8351073: [macos] jpackage produces invalid Java runtime DMG bundles > > src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacApplicationBuilder.java line 184: > >> 182: } >> 183: >> 184: public String validatedBundleIdentifier() throws ConfigException { > > This method is private on purpose. It should not be used outside of the MacApplicationBuilder class. If you need to get the valid bundle identifier, create MacApplication instance and call `MacApplication.bundleIdentifier()` on it. I need it inside `createMacApplication()` before `MacApplication` instance is created. > src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacBaseInstallerBundler.java line 80: > >> 78: if (!isRuntimeImageJDKBundle(runtimeImage) >> 79: && !isRuntimeImageJDKImage(runtimeImage)) { >> 80: throw new ConfigException( > > 1. Can be simplified: > > throw new ConfigException( > I18N.format("message.runtime-image-invalid", runtimeImage), > I18N.getString("message.runtime-image-invalid.advice")); > > > 2. This validation should be a part of `MacPackageBuilder.create()`. 1 and 2 fixed. > src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacBaseInstallerBundler.java line 120: > >> 118: return IOUtils.exists(jli); >> 119: } catch (IOException | NoSuchElementException ex) { >> 120: Log.verbose(ex); > > So if jpackage doesn't know if the given path is a JDK image or a JDK bundle, it will proceed with packaging anyway. This doesn't look right. In general, most, if not all, of the existing constructions like: > > } catch (Exception ex) { > Log.verbose(ex); > ... > } > > are wrong. Let's not add new ones. Fixed. > src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacPackagingPipeline.java line 313: > >> 311: } >> 312: >> 313: private static void writeRuntimeBundleInfoPlist(MacApplication app, BuildEnv env, Path runtimeRootDirectory) throws IOException { > > This function is almost a duplicate of writeRuntimeInfoPlist(). They can be merged together with branching: > > if (app.asApplicationLayout().isPresent()) { > // This is application bundle > } else { > // This is runtime bundle > } Fixed > src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/model/MacPackage.java line 38: > >> 36: default AppImageLayout appImageLayout() { >> 37: if (isRuntimeInstaller()) { >> 38: return RuntimeLayout.DEFAULT; > > Why is this change? It looks wrong. The layout of the output bundle should have the "Contents" folder. This is how it was before the change. `RUNTIME_PACKAGE_LAYOUT` points to "Contents/Home". Bundle is "Contents/Home", "Contents/MacOS" and "Contents/Info.plist". So we need root of bundle and not "Home". Maybe I misunderstanding something. > src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/model/MacPackage.java line 76: > >> 74: return !Files.exists(p); >> 75: } >> 76: } > > Default interface methods should operate on values returned by other interface methods. These new functions involve filesystem operations. They probably don't belong to the interface. Moved to `MacPackagingPipeline`. > src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/resources/RuntimeBundle-Info.plist.template line 1: > >> 1: > > What is the origin of this file? Based on JDK Info plist template we using. You can find original file here https://github.com/openjdk/jdk/blob/master/make/data/bundle/JDK-Info.plist.template. > src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/resources/RuntimeBundle-Info.plist.template line 6: > >> 4: >> 5: CFBundleDevelopmentRegion >> 6: English > > I'm surprised there is no standard way to override this default value. Is it not important? https://developer.apple.com/documentation/bundleresources/information-property-list/cfbundledevelopmentregion?language=objc By default it will be `en-US`. Not sure why JDK Info.plist has `English`, since it is not a documented value. Also all jpackage Info plist template files also have `English`. I think we need to file a separate bug and change it to `en-US` or remove it. I think remove it is better, since no need to set it to default value. Not sure if it is important for `runtime bundles`, but for `application bundles` it might be important in case if application does not have English localization. For example application is only in German language, then this value should be set to German language ID. I think it might make sense to file a bug to investigate if we want to provide CLI option to specify value for `CFBundleDevelopmentRegion` similar to `--mac-app-category`. Any suggestions? > src/jdk.jpackage/share/classes/jdk/jpackage/internal/model/Application.java line 101: > >> 99: */ >> 100: Optional runtimeImage(); >> 101: > > What is "the source directory of this application"? > Why is the method that returns a path to the source directory called `runtimeImage()`? Copy-paste. Forgot to update description. I fixed it. `runtimeImageDir` is a value of `--runtime-image` in case of runtime installer. > test/jdk/tools/jpackage/helpers/jdk/jpackage/test/JPackageCommand.java line 974: > >> 972: // on macOS. On macOS runtime image will be signed ad-hoc or with >> 973: // real certificate when creating runtime installers. >> 974: return !(cmd.isRuntime() && TKit.isOSX()); > > I guess the directory referenced from the `--runtime-image` option will not be signed if it is a JDK image, not a JDK bundle. So, this switch turns off verification in cases when it should be done. > > My interpretation of the PR description is that if the `-runtime-image` option references a JDK bundle, its contents will be copied, and the copy will be signed optionally. This makes this switch redundant. Yes, it is no longer needed. I removed it. > test/jdk/tools/jpackage/macosx/SigningRuntimeImagePackageTest.java line 65: > >> 63: * always allowed access to this keychain for user which runs test. >> 64: * note: >> 65: * "jpackage.openjdk.java.net" can be over-ridden by systerm property > > systerm -> system Fixed. > test/jdk/tools/jpackage/macosx/SigningRuntimeImagePackageTest.java line 134: > >> 132: } >> 133: >> 134: private static Path getRuntimeImagePath(boolean useJDKBundle, > > The name of the function is misleading. It doesn't get the runtime image. It creates it. > > It returns a path to a JDK bundle or a JDK image depending on its arguments. So the "RuntimeImagePath" part of its name is also misleading. Improved. > test/jdk/tools/jpackage/macosx/SigningRuntimeImagePackageTest.java line 180: > >> 178: ex.execute(); >> 179: >> 180: JPackageCommand dummyCMD = new JPackageCommand(); > > Why do you need a `dummyCMD`? You can configure a normal JPackageCommand command: > > var cmd = new JPackageCommand().useToolProvider(true).dumpOutput(true).addArguments(...); Fixed. > test/jdk/tools/jpackage/macosx/SigningRuntimeImagePackageTest.java line 188: > >> 186: >> 187: MacHelper.withExplodedDmg(dummyCMD, dmgImage -> { >> 188: if (dmgImage.endsWith(dummyCMD.name() + ".jdk")) { > > Can this test ever return `false`? Yes. `withExplodedDmg` is called for all content in DMG which will include link to `JavaVirtualMachines`. We have same checks for `.app` as well for exact same reason. > test/jdk/tools/jpackage/macosx/SigningRuntimeImagePackageTest.java line 189: > >> 187: MacHelper.withExplodedDmg(dummyCMD, dmgImage -> { >> 188: if (dmgImage.endsWith(dummyCMD.name() + ".jdk")) { >> 189: Executor.of("cp", "-R") > > Why noit use `FileUtils.copyRecursive()`? All our other code uses `cp` command to copy mounted DMG. I tried `FileUtils.copyRecursive()`, but test failed due to signing. I think `FileUtils.copyRecursive()` breaks file permissions or something. Will keep `cp` for consistency. > test/jdk/tools/jpackage/macosx/SigningRuntimeImagePackageTest.java line 222: > >> 220: SigningBase.CertIndex JDKBundleCert, >> 221: SigningBase.CertIndex signCert) throws Exception { >> 222: final int JDKBundleCertIndex = JDKBundleCert.value(); > > `JDKBundleCertIndex` -> `jdkBundleCertIndex`? Fixed. > test/jdk/tools/jpackage/macosx/SigningRuntimeImagePackageTest.java line 231: > >> 229: >> 230: new PackageTest() >> 231: .forTypes(PackageType.MAC) > > `.forTypes(PackageType.MAC)` is redundant. The test will only be executed on macOS Fixed. > test/jdk/tools/jpackage/share/ErrorTest.java line 98: > >> 96: // Missing "Contents/MacOS/libjli.dylib" >> 97: try { >> 98: final Path runtimePath = TKit.createTempDirectory("invalidJDKBundle"); > > The name "invalid-jdk-bundle" fits better in dash-case naming scheme for path names in jpackage tests. Fixed. > test/jdk/tools/jpackage/share/ErrorTest.java line 637: > >> 635: .addArgs("--runtime-image", Token.INVALID_MAC_JDK_BUNDLE.token()) >> 636: .error("message.runtime-image-invalid", JPackageCommand.cannedArgument(cmd -> { >> 637: return Path.of(cmd.getArgumentValue("--runtime-image")).toAbsolutePath(); > > Why do we need an absolute path in error messages? Wouldn't it make more sense to have the value of `--runtime-image` parameter as is in error messages? Not sure why. Fixed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26173#discussion_r2193668918 PR Review Comment: https://git.openjdk.org/jdk/pull/26173#discussion_r2193679404 PR Review Comment: https://git.openjdk.org/jdk/pull/26173#discussion_r2193704037 PR Review Comment: https://git.openjdk.org/jdk/pull/26173#discussion_r2193710393 PR Review Comment: https://git.openjdk.org/jdk/pull/26173#discussion_r2193718285 PR Review Comment: https://git.openjdk.org/jdk/pull/26173#discussion_r2196225026 PR Review Comment: https://git.openjdk.org/jdk/pull/26173#discussion_r2196230170 PR Review Comment: https://git.openjdk.org/jdk/pull/26173#discussion_r2196251812 PR Review Comment: https://git.openjdk.org/jdk/pull/26173#discussion_r2196314256 PR Review Comment: https://git.openjdk.org/jdk/pull/26173#discussion_r2196395258 PR Review Comment: https://git.openjdk.org/jdk/pull/26173#discussion_r2196396676 PR Review Comment: https://git.openjdk.org/jdk/pull/26173#discussion_r2196401655 PR Review Comment: https://git.openjdk.org/jdk/pull/26173#discussion_r2196404744 PR Review Comment: https://git.openjdk.org/jdk/pull/26173#discussion_r2196406257 PR Review Comment: https://git.openjdk.org/jdk/pull/26173#discussion_r2196408886 PR Review Comment: https://git.openjdk.org/jdk/pull/26173#discussion_r2196410205 PR Review Comment: https://git.openjdk.org/jdk/pull/26173#discussion_r2196411953 PR Review Comment: https://git.openjdk.org/jdk/pull/26173#discussion_r2196413148 PR Review Comment: https://git.openjdk.org/jdk/pull/26173#discussion_r2198799393 From almatvee at openjdk.org Thu Jul 10 21:48:53 2025 From: almatvee at openjdk.org (Alexander Matveev) Date: Thu, 10 Jul 2025 21:48:53 GMT Subject: RFR: 8351073: [macos] jpackage produces invalid Java runtime DMG bundles [v3] In-Reply-To: <8puqNFN9LtsrDe6xF4EmRPBrT-CR3IRcOS62YFVwZD8=.7613bce6-badf-4664-baf7-67c94037d7b7@github.com> References: <8puqNFN9LtsrDe6xF4EmRPBrT-CR3IRcOS62YFVwZD8=.7613bce6-badf-4664-baf7-67c94037d7b7@github.com> Message-ID: On Tue, 8 Jul 2025 01:13:20 GMT, Alexey Semenyuk wrote: >> Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: >> >> 8351073: [macos] jpackage produces invalid Java runtime DMG bundles [v2] > > src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacPackagingPipeline.java line 311: > >> 309: } >> 310: >> 311: private static void sign(AppImageBuildEnv env) throws IOException { > > I don't understand why individual signing functions are needed for the runtime and application bundles. They look identical to me. One is used by `appImageAction` and second by `packageAction`. Maybe I am misusing appImageAction and packageAction. These two actions requires different argument `AppImageBuildEnv` vs `PackageBuildEnv`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26173#discussion_r2193714647 From almatvee at openjdk.org Thu Jul 10 21:48:43 2025 From: almatvee at openjdk.org (Alexander Matveev) Date: Thu, 10 Jul 2025 21:48:43 GMT Subject: RFR: 8351073: [macos] jpackage produces invalid Java runtime DMG bundles [v3] In-Reply-To: References: Message-ID: On Thu, 10 Jul 2025 21:44:32 GMT, Alexander Matveev wrote: >> Re-submission of https://github.com/openjdk/jdk/pull/25314 after merge conflict was resolved. Old PR will be closed. >> >> All comments are addressed from old PR. Merge conflict was significant, so it is like new fix. >> >> Fixed jpackage to produce valid Java runtimes based on description below: >> >> Definitions: >> >> - JDK bundle defined as bundle which contains "Contents/Home", "Contents/MacOS/libjli.dylib" and "Contents/Info.plist". >> - Signed JDK bundle contains all files as JDK bundle + "Contents/_CodeSignature". >> - JDK image defined as content of "Contents/Home". >> - Signed JDK image does not exist, since it cannot be signed as bundle. >> >> jpackage output based on input: >> >> 1. "--runtime-image" points to unsigned JDK bundle and --mac-sign is not provided: >> - jpackage will copy all files as is from provided path and run ad-hoc codesign. >> >> 2. "--runtime-image" points to unsigned JDK bundle and --mac-sign is provided: >> - jpackage will copy all files as is from provided path and run codesign with appropriate certificate based on same logic as we do for application image. >> >> 3. "--runtime-image" points to signed JDK bundle and --mac-sign is not provided: >> - jpackage will copy all files as is from provided path including "Contents/_CodeSignature" to preserve signing. >> >> 4. "--runtime-image" points to signed JDK bundle and --mac-sign is provided: >> - jpackage will copy all files as is from provided path including "Contents/_CodeSignature" and will re-sign bundle with appropriate certificate. >> >> 5. "--runtime-image" points to JDK image and --mac-sign is not provided: >> - jpackage will check for libjli.dylib presence in "lib" folder. >> - Create JDK bundle by putting all files from provided path to "Contents/Home", libjli.dylib from "lib" to "Contents/MacOS/libjli.dylib" and create default "Contents/Info.plist" similar to what we do for runtime in application image. >> - Ad-hoc signing will done. >> >> 6. "--runtime-image" points to JDK image and --mac-sign is provided: >> - 2 first steps from 5 and certificate signing will be done. >> >> Additional changes: >> - The bundle's top directory name will have the ".jdk" suffix. > > Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: > > 8351073: [macos] jpackage produces invalid Java runtime DMG bundles [v2] 8351073: [macos] jpackage produces invalid Java runtime DMG bundles [v2] - Fixed latest comments. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26173#issuecomment-3059204117 From liach at openjdk.org Thu Jul 10 21:52:49 2025 From: liach at openjdk.org (Chen Liang) Date: Thu, 10 Jul 2025 21:52:49 GMT Subject: RFR: 8361908: Mix and match of dead and valid exception handler leads to malformed class file Message-ID: Noticed this error when I was verifying all sizes are u2 compatible and verified with a test that fails on mainline with ConstantPoolException (because we write a size of 2 with 1-length list content) and works in this patch. Problem wasn't discovered before because we use the `handlersSize < handlers.size()` instead of `handlersSize != handlers.size()` check. Testing: jdk/jdk/classfile ------------- Commit messages: - 8361908: Mix and match of dead and valid exception handler leads to malformed class file Changes: https://git.openjdk.org/jdk/pull/26255/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26255&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8361908 Stats: 22 lines in 2 files changed: 20 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/26255.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26255/head:pull/26255 PR: https://git.openjdk.org/jdk/pull/26255 From liach at openjdk.org Thu Jul 10 22:38:16 2025 From: liach at openjdk.org (Chen Liang) Date: Thu, 10 Jul 2025 22:38:16 GMT Subject: RFR: 8361909: ConstantPoolBuilder::loadableConstantEntry and constantValueEntry should throw NPE Message-ID: Currently, the aforementioned two methods do not throw NPE upon null input, but throw IAE. This behavior is bad for composition: `bsmEntry` actually throws IAE for nested null in the argument list/array, and other APIs are similarly affected. Given this domino effect, I think the best way is to fix the API itself to correctly throw NPE instead. A small CSR is opened to record this change. ------------- Commit messages: - 8361909: ConstantPoolBuilder::loadableConstantEntry and constantValueEntry should throw NPE Changes: https://git.openjdk.org/jdk/pull/26257/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26257&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8361909 Stats: 11 lines in 2 files changed: 8 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/26257.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26257/head:pull/26257 PR: https://git.openjdk.org/jdk/pull/26257 From bpb at openjdk.org Thu Jul 10 22:47:12 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 10 Jul 2025 22:47:12 GMT Subject: RFR: 8361587: AssertionError in File.listFiles() when path is empty and -esa is enabled [v5] In-Reply-To: References: Message-ID: > Changes to address `File.listFiles` invoked on an empty path. This fixes an oversight in #22821. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8361587: Modify mkdirs() testing ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26224/files - new: https://git.openjdk.org/jdk/pull/26224/files/2e42c991..91867701 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26224&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26224&range=03-04 Stats: 19 lines in 1 file changed: 18 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/26224.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26224/head:pull/26224 PR: https://git.openjdk.org/jdk/pull/26224 From liach at openjdk.org Thu Jul 10 23:45:14 2025 From: liach at openjdk.org (Chen Liang) Date: Thu, 10 Jul 2025 23:45:14 GMT Subject: RFR: 8315131: Clarify VarHandle set/get access on 32-bit platforms Message-ID: On 32 bit platforms, when an access to long/double is aligned, it is supported but not atomic. The original wording in `MethodHandles::byteBufferViewVarHandle` sounds as if it is not supported at all. We can fix that by borrowing the improved specification from `MemoryLayout::varHandle`. ------------- Commit messages: - 8315131: Clarify VarHandle set/get access on 32-bit platforms Changes: https://git.openjdk.org/jdk/pull/26258/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26258&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8315131 Stats: 4 lines in 1 file changed: 1 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/26258.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26258/head:pull/26258 PR: https://git.openjdk.org/jdk/pull/26258 From xgong at openjdk.org Fri Jul 11 01:45:57 2025 From: xgong at openjdk.org (Xiaohong Gong) Date: Fri, 11 Jul 2025 01:45:57 GMT Subject: RFR: 8359419: AArch64: Relax min vector length to 32-bit for short vectors [v4] In-Reply-To: References: Message-ID: <5__MowepmHboqoXdzv0AEbzawJobhlsMoAHjAmYrCno=.b42d0d72-54bd-4ccc-a29b-98877bbedcbb@github.com> On Thu, 10 Jul 2025 01:40:06 GMT, Xiaohong Gong wrote: >> Thanks for making the changes. Looks good to me. > >> Thanks for making the changes. Looks good to me. > > Thanks a lot for your review! > @XiaohongGong The code changes look sane, although, for the record, I'm not that familiar with this part of HotSpot. Testing also looks good, details below. > > ### Testing > * [GitHub Actions](https://github.com/dlunde/jdk/actions/runs/16165935815) > * `tier1` to `tier4` (and additional Oracle-internal testing) on Windows x64, Linux x64, Linux aarch64, macOS x64, and macOS aarch64. > * Performance testing on DaCapo, Renaissance, SPECjbb, and SPECjvm on Linux x64 and macOS aarch64. No observable improvements nor regressions. Great! Thanks a lot for your testing and review~ ------------- PR Comment: https://git.openjdk.org/jdk/pull/26057#issuecomment-3059921607 From xgong at openjdk.org Fri Jul 11 01:50:40 2025 From: xgong at openjdk.org (Xiaohong Gong) Date: Fri, 11 Jul 2025 01:50:40 GMT Subject: RFR: 8359419: AArch64: Relax min vector length to 32-bit for short vectors [v3] In-Reply-To: References: <7VTRz_XqYBSdQ54n7ADzTzYADZjDbgBw6XuW0jehSLI=.24d18b87-4553-47ab-8065-d92fbb5700ae@github.com> Message-ID: On Fri, 4 Jul 2025 09:11:40 GMT, Andrew Haley wrote: >> Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision: >> >> Refine the comment in ad file > > This looks good. Thanks. Hi @theRealAph , would you mind taking another look at the latest change? It needs an approval from a reviewer. Thanks a lot in advance! ------------- PR Comment: https://git.openjdk.org/jdk/pull/26057#issuecomment-3059929091 From serb at openjdk.org Fri Jul 11 02:58:47 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Fri, 11 Jul 2025 02:58:47 GMT Subject: RFR: 8361533: Apply java.io.Serial annotations in java.logging Message-ID: Please review the application of the `@Serial` annotation ([JDK-8202385](https://bugs.openjdk.org/browse/JDK-8202385)) to types in the java.logging module to enable stricter compile-time checking of serialization-related declarations. Only one class remains to be covered; all other relevant fields and methods are already annotated with `@Serial`. This annotation can be applied to these methods in the module: private void writeObject(java.io.ObjectOutputStream stream) throws IOException private void readObject(java.io.ObjectInputStream stream) throws IOException, ClassNotFoundException private void readObjectNoData() throws ObjectStreamException ANY-ACCESS-MODIFIER Object writeReplace() throws ObjectStreamException ANY-ACCESS-MODIFIER Object readResolve() throws ObjectStreamException private static final ObjectStreamField[] serialPersistentFields private static final long serialVersionUID Example of a similar change in the [java.compiler](https://github.com/openjdk/jdk/pull/24891) module. ------------- Commit messages: - 8361533: Apply java.io.Serial annotations in java.logging Changes: https://git.openjdk.org/jdk/pull/26208/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26208&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8361533 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/26208.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26208/head:pull/26208 PR: https://git.openjdk.org/jdk/pull/26208 From xgong at openjdk.org Fri Jul 11 03:50:39 2025 From: xgong at openjdk.org (Xiaohong Gong) Date: Fri, 11 Jul 2025 03:50:39 GMT Subject: RFR: 8358768: [vectorapi] Make VectorOperators.SUADD an Associative [v2] In-Reply-To: References: Message-ID: On Wed, 9 Jul 2025 22:52:58 GMT, Ian Graves wrote: >> Adding SUADD an associative operation in the Vector API. Saturated addition on fixed-width unsigned integers is provably associative. > > Ian Graves has updated the pull request incrementally with one additional commit since the last revision: > > Adding masked associative tests src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorOperators.java line 580: > 578: * @see VectorMath#addSaturatingUnsigned(int, int) > 579: */ > 580: public static final Associative SUADD = assoc("SUADD", "+", VectorSupport.VECTOR_OP_SUADD, VO_NOFP+VO_ASSOC); Suggestion: public static final Associative SUADD = assoc("SUADD", "+", VectorSupport.VECTOR_OP_SUADD, VO_NOFP + VO_ASSOC); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26099#discussion_r2199446939 From alanb at openjdk.org Fri Jul 11 07:26:44 2025 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 11 Jul 2025 07:26:44 GMT Subject: RFR: 8361587: AssertionError in File.listFiles() when path is empty and -esa is enabled [v5] In-Reply-To: References: Message-ID: On Thu, 10 Jul 2025 22:47:12 GMT, Brian Burkhalter wrote: >> Changes to address `File.listFiles` invoked on an empty path. This fixes an oversight in #22821. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8361587: Modify mkdirs() testing src/java.base/unix/classes/java/io/UnixFileSystem.java line 120: > 118: public String resolve(String parent, String child) { > 119: if (child.isEmpty()) return parent; > 120: if (parent.isEmpty()) return child; The changes to the mkdirs tests suggest this isn't right. Can you look to special casing the empty parent in the listFiles methods as that should fix the issue without the side effect that is being worked around by the newly added mkdirs tests. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26224#discussion_r2199890602 From shade at openjdk.org Fri Jul 11 08:22:40 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Fri, 11 Jul 2025 08:22:40 GMT Subject: RFR: 8315131: Clarify VarHandle set/get access on 32-bit platforms In-Reply-To: References: Message-ID: On Thu, 10 Jul 2025 23:40:15 GMT, Chen Liang wrote: > On 32 bit platforms, when an access to long/double is aligned, it is supported but not atomic. The original wording in `MethodHandles::byteBufferViewVarHandle` sounds as if it is not supported at all. We can fix that by borrowing the improved specification from `MemoryLayout::varHandle`. > > Note: This doc is copied from https://github.com/openjdk/jdk/blob/ee0d309bbd33302d8c6f35155e975db77aaea785/src/java.base/share/classes/java/lang/foreign/MemoryLayout.java#L279-L282 with slight adjustments. See the rendering at https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/lang/foreign/MemoryLayout.html#access-mode-restrictions Changes requested by shade (Reviewer). src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 4311: > 4309: * access modes {@code get} and {@code set} for {@code long}, {@code > 4310: * double} are supported but might lead to word tearing, as described in > 4311: * Section {@jls 17.7} of The Java Language Specification. ...except that JLS 17.7 is "Non-Atomic Treatment of double and long". Word tearing (JLS 17.6) should still be very much forbidden. This all means that [MemoryLayout.java](https://github.com/openjdk/jdk/blob/ee0d309bbd33302d8c6f35155e975db77aaea785/src/java.base/share/classes/java/lang/foreign/MemoryLayout.java#L279-L282) comment is also incorrect. Note how the previous paragraph talks about "support atomic access", which is a correct term here. ------------- PR Review: https://git.openjdk.org/jdk/pull/26258#pullrequestreview-3009183292 PR Review Comment: https://git.openjdk.org/jdk/pull/26258#discussion_r2200018561 From vyazici at openjdk.org Fri Jul 11 08:40:40 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Fri, 11 Jul 2025 08:40:40 GMT Subject: RFR: 8361842: Move input validation checks to Java for String-related intrinsics In-Reply-To: <4dolSfV2QJhf4nW0zxQ3Z6hti93KWU1PD9sYvXfYDnc=.307324ef-6bad-43ce-9397-e39abcfad410@github.com> References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com> <4dolSfV2QJhf4nW0zxQ3Z6hti93KWU1PD9sYvXfYDnc=.307324ef-6bad-43ce-9397-e39abcfad410@github.com> Message-ID: On Thu, 10 Jul 2025 20:54:24 GMT, John R Rose wrote: >> Validate input in `java.lang.StringCoding` intrinsic Java wrappers, improve their documentation, enhance the checks in the associated IR or assembly code, and adapt them to cause VM crash on invalid input. >> >> ## Implementation notes >> >> The goal of the associated umbrella issue [JDK-8156534](https://bugs.openjdk.org/browse/JDK-8156534) is to, for `java.lang.String*` classes, >> >> 1. Move `@IntrinsicCandidate`-annotated `public` methods1 (in Java code) to `private` ones, and wrap them with a `public` ["front door" method](https://github.com/openjdk/jdk/pull/24982#discussion_r2087493446) >> 2. Since we moved the `@IntrinsicCandidate` annotation to a new method, intrinsic mappings ? i.e., associated `do_intrinsic()` calls in `vmIntrinsics.hpp` ? need to be updated too >> 3. Add necessary input validation (range, null, etc.) checks to the newly created public front door method >> 4. Place all input validation checks in the intrinsic code (add if missing!) behind a `VerifyIntrinsicChecks` VM flag >> >> Following preliminary work needs to be carried out as well: >> >> 1. Add a new `VerifyIntrinsicChecks` VM flag >> 2. Update `generate_string_range_check` to produce a `HaltNode`. That is, crash the VM if `VerifyIntrinsicChecks` is set and a Java wrapper fails to spot an invalid input. >> >> 1 `@IntrinsicCandidate`-annotated constructors are not subject to this change, since they are a special case. >> >> ## Functional and performance tests >> >> - `tier1` (which includes `test/hotspot/jtreg/compiler/intrinsics/string`) passes on several platforms. Further tiers will be executed after integrating reviewer feedback. >> >> - Performance impact is still actively monitored using `test/micro/org/openjdk/bench/java/lang/String{En,De}code.java`, among other tests. If you have suggestions on benchmarks, please share in the comments. >> >> ## Verification of the VM crash >> >> I've tested the VM crash scenario as follows: >> >> 1. Created the following test program: >> >> public class StrIntri { >> public static void main(String[] args) { >> Exception lastException = null; >> for (int i = 0; i < 1_000_000; i++) { >> try { >> jdk.internal.access.SharedSecrets.getJavaLangAccess().countPositives(new byte[]{1,2,3}, 2, 5); >> } catch (Exception exception) { >> lastException = exception; >> } >> } >> if (lastException != null) { >> lastException.printStackTrace... > > I disagree with a small part of the statement of goals: > >> Always validate all input at the intrinsic (but preferably behind a VM flag) > > As formulated above, this is a violation of DRY and if embraced the wrong way will lead to code that is harder to review and prove bug-free. Performing 100% accurate range/null/validation checks is deeply impractical for an assembly-based or IR-based intrinsic. It?s too hard to verify by code review, and coverage testing is suspect. > > We must frankly put all the weight of verification on Java code, including Java bytecode intrinsic behaviors. Java code is high-level and can be read mostly as a declarative spec, if clearly written (as straight-line code, then the intrinsic call). Also, such simple Java code shapes (and their underlying bytecodes) are tested many orders of magnitude more than any given intrinsic. > > I see two bits of evidence that you agree with me on this: 1. The intrinsic-local validation (IR or assembly) is allowed to Halt instead of throw, and 2. the intrinsic-local validation is optional, turned on only by a stress test mode. This tells me that the extra optional testing is also not required to be 100%. > > Thus, I think the above goal would be better stated this way: > >> Validate input in the IR or assembly code of the intrinsic in an ad hoc manner to catch bugs in the Java validation. > >> Note: IR or assembly based validation code should not obscure the code or add large maintenance costs, and under a VM diagnostic flag (or debug flag), and causing a VM halt instead of a Java throw. > > I think I'm agreeing with you on the material points. It is important to summarize our intentions accurately at the top, for those readers that are reading only the top as a summary. @rose00, thanks so much for the feedback. I agree with your remarks and get your points on _"Always validate all input at the intrinsic"_ is a violation of DRY and an impractical goal. I incorporated your suggestions as follows: 1. Renamed the ticket to `Move input validation checks to Java for String-related intrinsics` (to better reflect the goal) 2. Replaced `Always validate all input at the intrinsic...` with your suggestion ------------- PR Comment: https://git.openjdk.org/jdk/pull/25998#issuecomment-3061201145 From cstein at openjdk.org Fri Jul 11 09:10:19 2025 From: cstein at openjdk.org (Christian Stein) Date: Fri, 11 Jul 2025 09:10:19 GMT Subject: RFR: JDK-8289798: Update to use jtreg 8 Message-ID: Please review the change to update to using jtreg 8. The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the requiredVersion has been updated in the various `TEST.ROOT` files. ------------- Commit messages: - 8361950: Set required version to 8+2 - 8361950: Update to use jtreg 8 Changes: https://git.openjdk.org/jdk/pull/26261/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26261&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8289798 Stats: 11 lines in 9 files changed: 0 ins; 0 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/26261.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26261/head:pull/26261 PR: https://git.openjdk.org/jdk/pull/26261 From mgronlun at openjdk.org Fri Jul 11 09:34:13 2025 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Fri, 11 Jul 2025 09:34:13 GMT Subject: RFR: 8361640: JFR: RandomAccessFile::readLine emits events for each character In-Reply-To: References: Message-ID: On Wed, 9 Jul 2025 05:45:01 GMT, Erik Gahlin wrote: > Could I have a review of the change that prevents RandomAccessFile::readLine from emitting an event per character? This leads to unnecessary overhead, both with or without JFR enabled. > > Testing: tier1 + tier2 + jdk/jdk/jfr > > Thanks > Erik Marked as reviewed by mgronlun (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26210#pullrequestreview-3009487213 From duke at openjdk.org Fri Jul 11 09:52:12 2025 From: duke at openjdk.org (Pooja-DP) Date: Fri, 11 Jul 2025 09:52:12 GMT Subject: RFR: 8361697: Remove duplicate message in MainResources.properties Message-ID: Bug reference: https://bugs.openjdk.org/browse/JDK-8361697 The following message is removed: ` MSG_BundlerFailed=Error: Bundler "{1}" ({0}) failed to produce a package` Signed-off-by: Pooja.D.P1 ------------- Commit messages: - Update MainResources.properties with duplicate message removal Changes: https://git.openjdk.org/jdk/pull/26215/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26215&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8361697 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/26215.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26215/head:pull/26215 PR: https://git.openjdk.org/jdk/pull/26215