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: <tG3KsNaA8iDVdZRT-MGKvy8uViCna0ZUJ939oJsilj0=.a12f0cc9-4e47-4fb8-92d4-291c8f211790@github.com>
References: <tG3KsNaA8iDVdZRT-MGKvy8uViCna0ZUJ939oJsilj0=.a12f0cc9-4e47-4fb8-92d4-291c8f211790@github.com>
Message-ID: <TdnuVxqRVlUzZpF7RYlOhMbsiCqssJiCgKNACfVqaJU=.190b4b40-3bad-44cd-abc8-9d436b2d3a47@github.com>

> 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: <BMzrwoK47BAqc6yjrZY0QLhxEXXkjk5KEWlYR-GRkrg=.96ca6aba-b94f-43b6-abb8-4bed4bb2e0f2@github.com>
References: <tG3KsNaA8iDVdZRT-MGKvy8uViCna0ZUJ939oJsilj0=.a12f0cc9-4e47-4fb8-92d4-291c8f211790@github.com>
 <BMzrwoK47BAqc6yjrZY0QLhxEXXkjk5KEWlYR-GRkrg=.96ca6aba-b94f-43b6-abb8-4bed4bb2e0f2@github.com>
Message-ID: <2UGoXOQvwftFaOWTuopaoo_r6XaIUp2x5SwelfFsgRw=.574d130b-8d0e-4b0b-9a66-749d2ccb00da@github.com>

On Mon, 30 Jun 2025 23:56:53 GMT, Shaojin Wen <swen at openjdk.org> 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: <tG3KsNaA8iDVdZRT-MGKvy8uViCna0ZUJ939oJsilj0=.a12f0cc9-4e47-4fb8-92d4-291c8f211790@github.com>
 <BMzrwoK47BAqc6yjrZY0QLhxEXXkjk5KEWlYR-GRkrg=.96ca6aba-b94f-43b6-abb8-4bed4bb2e0f2@github.com>
 <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 <duke at openjdk.org> 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: <TdnuVxqRVlUzZpF7RYlOhMbsiCqssJiCgKNACfVqaJU=.190b4b40-3bad-44cd-abc8-9d436b2d3a47@github.com>
References: <tG3KsNaA8iDVdZRT-MGKvy8uViCna0ZUJ939oJsilj0=.a12f0cc9-4e47-4fb8-92d4-291c8f211790@github.com>
 <TdnuVxqRVlUzZpF7RYlOhMbsiCqssJiCgKNACfVqaJU=.190b4b40-3bad-44cd-abc8-9d436b2d3a47@github.com>
Message-ID: <6ClkdyctkQbFU6oNWqEWweuKQ9Z2HCjFReka6xpM3R8=.de30d3c6-ce40-418b-be8e-76c930bb1929@github.com>

On Tue, 1 Jul 2025 00:01:21 GMT, Shaojin Wen <swen at openjdk.org> 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: <QHD4zzKMWN_h-YFLXBSBGGWV5wB4hn2Zo2zH03vJq_E=.da85dc91-ce2c-4cb1-9a5f-de9d9813558b@github.com>
References: <OOcrr-XrT-N783zTSoPF70AaZPoDlogN7Sck9p-N9nw=.98f4c5e8-fafd-48df-834b-cbb6f4bfe771@github.com>
 <QHD4zzKMWN_h-YFLXBSBGGWV5wB4hn2Zo2zH03vJq_E=.da85dc91-ce2c-4cb1-9a5f-de9d9813558b@github.com>
Message-ID: <vm78qD4LHwURQ6EPg9OSd2GbJaAIEi18tkdX80NmZ_s=.0e19a836-953f-4f90-b0ab-ed1a25cbcff9@github.com>

On Mon, 30 Jun 2025 22:11:57 GMT, Chen Liang <liach at openjdk.org> 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 <clinit> 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: <J8dgbvyvDWsGSnOpc3mFgzm6pbcaw3U-ybh7hH74OXU=.ab009065-7b0f-4c09-949c-ec8f48411d44@github.com>
References: <J8dgbvyvDWsGSnOpc3mFgzm6pbcaw3U-ybh7hH74OXU=.ab009065-7b0f-4c09-949c-ec8f48411d44@github.com>
Message-ID: <MQ7Ofp9Ek2M0C5UKmqrAV1PJG54DfrR9_s86TUY_XOU=.a62398d1-2f5d-48a4-8cd5-b209d57981b7@github.com>

On Wed, 25 Jun 2025 18:51:52 GMT, Xueming Shen <sherman at openjdk.org> 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: <J8dgbvyvDWsGSnOpc3mFgzm6pbcaw3U-ybh7hH74OXU=.ab009065-7b0f-4c09-949c-ec8f48411d44@github.com>
References: <J8dgbvyvDWsGSnOpc3mFgzm6pbcaw3U-ybh7hH74OXU=.ab009065-7b0f-4c09-949c-ec8f48411d44@github.com>
Message-ID: <BZK_y0avUYp5FexPW-LQSF6nXjM3xon7Ejtam-A8Ytw=.cd3a1d6d-00a8-4850-a207-870a8b190ce7@github.com>

On Wed, 25 Jun 2025 18:51:52 GMT, Xueming Shen <sherman at openjdk.org> 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 <sherman at openjdk.org>
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: <A1gPk7gsSnZ_947EFmBjljC7sDkbvC18DXCnoZHWSmY=.66b1501a-9e4d-4727-836e-0543fbfe5120@github.com>
References: <k-sV5p2PH-mOW5iO5bjVK3Poi_h1rUzH6OEKiXhHAHQ=.ccaf23b2-903b-4847-a26b-7e2e4a47ef7b@github.com>
 <A1gPk7gsSnZ_947EFmBjljC7sDkbvC18DXCnoZHWSmY=.66b1501a-9e4d-4727-836e-0543fbfe5120@github.com>
Message-ID: <u6xKM6nWIWia3wHIYFyNSRUwOUFy8gN7gapYUof7Ces=.7a657899-51d4-4fca-a47c-b8928baf6531@github.com>

On Mon, 30 Jun 2025 19:38:59 GMT, Brian Burkhalter <bpb at openjdk.org> 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: <A1gPk7gsSnZ_947EFmBjljC7sDkbvC18DXCnoZHWSmY=.66b1501a-9e4d-4727-836e-0543fbfe5120@github.com>
References: <k-sV5p2PH-mOW5iO5bjVK3Poi_h1rUzH6OEKiXhHAHQ=.ccaf23b2-903b-4847-a26b-7e2e4a47ef7b@github.com>
 <A1gPk7gsSnZ_947EFmBjljC7sDkbvC18DXCnoZHWSmY=.66b1501a-9e4d-4727-836e-0543fbfe5120@github.com>
Message-ID: <aMKIU-MDpANOOZleaJC5ywj_lV0DKjuAETA-5fVRpWg=.fe2ebceb-5e28-4b41-bd35-cf94928afd4c@github.com>

On Mon, 30 Jun 2025 19:38:59 GMT, Brian Burkhalter <bpb at openjdk.org> 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: <tG3KsNaA8iDVdZRT-MGKvy8uViCna0ZUJ939oJsilj0=.a12f0cc9-4e47-4fb8-92d4-291c8f211790@github.com>
 <BMzrwoK47BAqc6yjrZY0QLhxEXXkjk5KEWlYR-GRkrg=.96ca6aba-b94f-43b6-abb8-4bed4bb2e0f2@github.com>
 <2UGoXOQvwftFaOWTuopaoo_r6XaIUp2x5SwelfFsgRw=.574d130b-8d0e-4b0b-9a66-749d2ccb00da@github.com>
 <4F3WghIFVfxGPb1vRYf8Cdx4n35JwYZwOgfsColqCqQ=.4ae6c24f-3a9f-43a7-9af5-03f074c7d0a5@github.com>
Message-ID: <BYx25B4zYdZLJFjW9aK9Ja2lIFO7dB0P5R_D0LCcte8=.1369de55-cb96-4c89-80ca-20efff5c4ec0@github.com>

On Tue, 1 Jul 2025 00:10:00 GMT, Shaojin Wen <swen at openjdk.org> 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: <BYx25B4zYdZLJFjW9aK9Ja2lIFO7dB0P5R_D0LCcte8=.1369de55-cb96-4c89-80ca-20efff5c4ec0@github.com>
References: <tG3KsNaA8iDVdZRT-MGKvy8uViCna0ZUJ939oJsilj0=.a12f0cc9-4e47-4fb8-92d4-291c8f211790@github.com>
 <BMzrwoK47BAqc6yjrZY0QLhxEXXkjk5KEWlYR-GRkrg=.96ca6aba-b94f-43b6-abb8-4bed4bb2e0f2@github.com>
 <2UGoXOQvwftFaOWTuopaoo_r6XaIUp2x5SwelfFsgRw=.574d130b-8d0e-4b0b-9a66-749d2ccb00da@github.com>
 <4F3WghIFVfxGPb1vRYf8Cdx4n35JwYZwOgfsColqCqQ=.4ae6c24f-3a9f-43a7-9af5-03f074c7d0a5@github.com>
 <BYx25B4zYdZLJFjW9aK9Ja2lIFO7dB0P5R_D0LCcte8=.1369de55-cb96-4c89-80ca-20efff5c4ec0@github.com>
Message-ID: <ISQ8YWHEW37dp_fdCDLS89W2f4oGNp-sWQP7mBlgpgI=.11b8656f-16a1-4528-bb2c-7b6bb6f2846b@github.com>

On Tue, 1 Jul 2025 02:07:07 GMT, Brett Okken <duke at openjdk.org> 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: <TdnuVxqRVlUzZpF7RYlOhMbsiCqssJiCgKNACfVqaJU=.190b4b40-3bad-44cd-abc8-9d436b2d3a47@github.com>
References: <tG3KsNaA8iDVdZRT-MGKvy8uViCna0ZUJ939oJsilj0=.a12f0cc9-4e47-4fb8-92d4-291c8f211790@github.com>
 <TdnuVxqRVlUzZpF7RYlOhMbsiCqssJiCgKNACfVqaJU=.190b4b40-3bad-44cd-abc8-9d436b2d3a47@github.com>
Message-ID: <8Gw6kEDNuv2UmryKGGqW7QDndJJr29rT6dHKa9pLQLQ=.7d15c0c6-70f2-44e7-a07c-977ec66ed9c7@github.com>

On Tue, 1 Jul 2025 00:01:21 GMT, Shaojin Wen <swen at openjdk.org> 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: <tG3KsNaA8iDVdZRT-MGKvy8uViCna0ZUJ939oJsilj0=.a12f0cc9-4e47-4fb8-92d4-291c8f211790@github.com>
 <TdnuVxqRVlUzZpF7RYlOhMbsiCqssJiCgKNACfVqaJU=.190b4b40-3bad-44cd-abc8-9d436b2d3a47@github.com>
 <6ClkdyctkQbFU6oNWqEWweuKQ9Z2HCjFReka6xpM3R8=.de30d3c6-ce40-418b-be8e-76c930bb1929@github.com>
Message-ID: <BDp_GKcuOSl2rYKGmWoJ8NaLH1Fg9oF1VsGDin6_2qw=.38af4d8f-ff1b-4070-b0ca-fb37e1d5f583@github.com>

On Tue, 1 Jul 2025 00:41:03 GMT, Xueming Shen <sherman at openjdk.org> 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: <BDp_GKcuOSl2rYKGmWoJ8NaLH1Fg9oF1VsGDin6_2qw=.38af4d8f-ff1b-4070-b0ca-fb37e1d5f583@github.com>
References: <tG3KsNaA8iDVdZRT-MGKvy8uViCna0ZUJ939oJsilj0=.a12f0cc9-4e47-4fb8-92d4-291c8f211790@github.com>
 <TdnuVxqRVlUzZpF7RYlOhMbsiCqssJiCgKNACfVqaJU=.190b4b40-3bad-44cd-abc8-9d436b2d3a47@github.com>
 <6ClkdyctkQbFU6oNWqEWweuKQ9Z2HCjFReka6xpM3R8=.de30d3c6-ce40-418b-be8e-76c930bb1929@github.com>
 <BDp_GKcuOSl2rYKGmWoJ8NaLH1Fg9oF1VsGDin6_2qw=.38af4d8f-ff1b-4070-b0ca-fb37e1d5f583@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 <swen at openjdk.org> 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: <MW4PR10MB5774AA40877246F6C78068D8FF6BA@MW4PR10MB5774.namprd10.prod.outlook.com>
References: <CAKD1RYuoK07OvAn02v4qq74Q1QDfpQpf=t0J0VT-s1zi4iKRnA@mail.gmail.com>
 <MW4PR10MB5774AED3EC215ED5AB3AD52CFF62A@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAKD1RYtLy_yC+L5+q1YOkbEvUis5LJ-tJNJDbyoptq8A=+W3eg@mail.gmail.com>
 <CAKD1RYuksGCWsqj6cnu3aoHqkzAepLeNHsGSX_nCi2QryJaGMQ@mail.gmail.com>
 <SJ0PR10MB5766DAA744887EE8B0A2B991FF62A@SJ0PR10MB5766.namprd10.prod.outlook.com>
 <CAKD1RYvhpcD=yAGAvTTi+c8sdjDAi776GCPCAdvsCCVF9JQpeQ@mail.gmail.com>
 <SJ0PR10MB5766DB20AB83B1199C7987EAFF62A@SJ0PR10MB5766.namprd10.prod.outlook.com>
 <CAKD1RYst6GOErvVozZ2SD6JGhTRUAugSHZFM7aY+5Je72iF3wA@mail.gmail.com>
 <MW4PR10MB57749F82094174F71CF0BB56FF6DA@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAKD1RYu3CUT5nOj9i-cv_n7T=FXvwBpx3BQp6px6Mk2zg6GZNA@mail.gmail.com>
 <MW4PR10MB577448E6F3C06E7A0387AFAAFF6CA@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAKD1RYtf4K-r6X0dQZsXUcyZcNa5WLxKZy8p11R163GeLkYn5g@mail.gmail.com>
 <MW4PR10MB57749105268519A8984C7C3EFF6CA@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAKD1RYvM=BtM1mOo2+KqFZV6GTtPb6c+n7JOVSHN34SsV6=_Jw@mail.gmail.com>
 <MW4PR10MB5774AA40877246F6C78068D8FF6BA@MW4PR10MB5774.namprd10.prod.outlook.com>
Message-ID: <CAKD1RYtJ9zU9Uwk5nJk-iiGjRsrYdD6mL5Nw2ugHswJL1VB73w@mail.gmail.com>

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
<https://github.com/google/mug/blob/gatherers/mug-gatherers/src/main/java/com/google/mu/util/stream/gatherers/MoreGatherers.java>
that *drops the requirement of maintaining encounter order*. I then set up a
test case
<https://github.com/google/mug/blob/gatherers/mug-gatherers/src/test/java/com/google/mu/util/stream/gatherers/MoreGatherersTest.java#L106:~:text=func-,mapConcurrent_withHeartbeatTask_halts,-func>
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 <viktor.klang at oracle.com> 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 <yujige at gmail.com>
> *Sent:* Sunday, 8 June 2025 07:39
> *To:* Viktor Klang <viktor.klang at oracle.com>
> *Cc:* core-libs-dev at openjdk.org <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 <viktor.klang at oracle.com>
> 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 <yujige at gmail.com>
> *Sent:* Wednesday, 4 June 2025 18:18
> *To:* Viktor Klang <viktor.klang at oracle.com>
> *Cc:* core-libs-dev at openjdk.org <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 <viktor.klang at oracle.com>
> 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
> <https://docs.oracle.com/en/java/javase/23/docs/api/java.base/java/util/Optional.html> 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)
> <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<Callable<Result>> realTasks = ... ;
> // A long-running monitoring task
> Callable<Void> longRunningMonitoringTask = () -> {
>     while (!allRealTasksSeemDone()) { // Simplified condition
>         System.out.println("Monitoring...");
>         Thread.sleep(5000);
>     }
>     return null;
> };
>
> Stream<Callable<?>> 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 <yujige at gmail.com>
> *Sent:* Wednesday, 4 June 2025 16:20
> *To:* Viktor Klang <viktor.klang at oracle.com>
> *Cc:* core-libs-dev at openjdk.org <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<Result> 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 <viktor.klang at oracle.com>
> 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 <yujige at gmail.com>
> *Sent:* Monday, 2 June 2025 18:54
> *To:* Viktor Klang <viktor.klang at oracle.com>
> *Cc:* core-libs-dev at openjdk.org <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 <viktor.klang at oracle.com>
> 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 <yujige at gmail.com>
> *Sent:* Monday, 2 June 2025 17:05
> *To:* Viktor Klang <viktor.klang at oracle.com>
> *Cc:* core-libs-dev at openjdk.org <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 <viktor.klang at oracle.com>
> 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 <yujige at gmail.com>
> *Sent:* Monday, 2 June 2025 16:29
> *To:* Viktor Klang <viktor.klang at oracle.com>; 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 <yujige at gmail.com> 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 <viktor.klang at oracle.com>
> 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 <core-libs-dev-retn at openjdk.org> on behalf of Jige
> Yu <yujige at gmail.com>
> *Sent:* Sunday, 1 June 2025 21:08
> *To:* core-libs-dev at openjdk.org <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: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250630/c7ea4ae5/attachment-0001.htm>

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: <LQRWbokCOzo8paB0R3JzFrXWVt5mxyGpU1Xe5rTuN4Q=.a7affe6d-82e2-4115-866e-348acbe4d7f7@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_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: <DTjy5tn75B091PzQPau6hp0s3eKh0UUQGUpQQoFLSVM=.06514ff0-fdef-4266-9808-d6f6442afe8a@github.com>
References: <ukODVKiBC1LuwN3hngG_vkkhd1QJO2TpvAUSKsR6Ko0=.43b5a21d-2a39-4ac1-a9de-549abcd72d40@github.com>
 <DTjy5tn75B091PzQPau6hp0s3eKh0UUQGUpQQoFLSVM=.06514ff0-fdef-4266-9808-d6f6442afe8a@github.com>
Message-ID: <P9OyZhq2i0wpmEEBj1McFnZdXY2wd89ljAIEBo1qNaE=.4528d390-e137-4e1d-a7d4-365b84b076d3@github.com>

On Wed, 25 Jun 2025 09:16:48 GMT, Xiaohong Gong <xgong at openjdk.org> 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: <EPq2BCssdOzDASLBXt1MIab0MbwCeUA1_n9brSSmWSI=.25614944-4553-4518-be89-189453ce7347@github.com>
References: <EMxYqM4tRcDPNaQ_xEpkBi2Zew0HlDwCFXEX0U7lrsY=.4552fbbf-7dd0-491d-b0f5-59ca304b970d@github.com>
 <EPq2BCssdOzDASLBXt1MIab0MbwCeUA1_n9brSSmWSI=.25614944-4553-4518-be89-189453ce7347@github.com>
Message-ID: <sEy5zJyZZgM7ioMx24RWCIlhFUgt29y0e-UwdPgScV8=.2ba693dc-0ce0-449b-8fdb-7583d465a1a1@github.com>

On Mon, 30 Jun 2025 15:08:25 GMT, David Beaumont <duke at openjdk.org> 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: <P9OyZhq2i0wpmEEBj1McFnZdXY2wd89ljAIEBo1qNaE=.4528d390-e137-4e1d-a7d4-365b84b076d3@github.com>
References: <ukODVKiBC1LuwN3hngG_vkkhd1QJO2TpvAUSKsR6Ko0=.43b5a21d-2a39-4ac1-a9de-549abcd72d40@github.com>
 <DTjy5tn75B091PzQPau6hp0s3eKh0UUQGUpQQoFLSVM=.06514ff0-fdef-4266-9808-d6f6442afe8a@github.com>
 <P9OyZhq2i0wpmEEBj1McFnZdXY2wd89ljAIEBo1qNaE=.4528d390-e137-4e1d-a7d4-365b84b076d3@github.com>
Message-ID: <LFxGEZIjTE6Jmz8s2EklREGHhmxN61_P_Ty6iqwGUBc=.7b79a619-0459-472e-b6ce-40b77d1b306f@github.com>

On Tue, 1 Jul 2025 06:07:03 GMT, Xiaohong Gong <xgong at openjdk.org> 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: <P9OyZhq2i0wpmEEBj1McFnZdXY2wd89ljAIEBo1qNaE=.4528d390-e137-4e1d-a7d4-365b84b076d3@github.com>
References: <ukODVKiBC1LuwN3hngG_vkkhd1QJO2TpvAUSKsR6Ko0=.43b5a21d-2a39-4ac1-a9de-549abcd72d40@github.com>
 <DTjy5tn75B091PzQPau6hp0s3eKh0UUQGUpQQoFLSVM=.06514ff0-fdef-4266-9808-d6f6442afe8a@github.com>
 <P9OyZhq2i0wpmEEBj1McFnZdXY2wd89ljAIEBo1qNaE=.4528d390-e137-4e1d-a7d4-365b84b076d3@github.com>
Message-ID: <7-WqNSzjPLOsHJ4DHogxqbiInl8TIz5sxIEXbIfo2OQ=.912568b8-830d-47cc-a837-46af6be618f3@github.com>

On Tue, 1 Jul 2025 06:07:03 GMT, Xiaohong Gong <xgong at openjdk.org> 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: <ukODVKiBC1LuwN3hngG_vkkhd1QJO2TpvAUSKsR6Ko0=.43b5a21d-2a39-4ac1-a9de-549abcd72d40@github.com>
 <DTjy5tn75B091PzQPau6hp0s3eKh0UUQGUpQQoFLSVM=.06514ff0-fdef-4266-9808-d6f6442afe8a@github.com>
 <P9OyZhq2i0wpmEEBj1McFnZdXY2wd89ljAIEBo1qNaE=.4528d390-e137-4e1d-a7d4-365b84b076d3@github.com>
 <7-WqNSzjPLOsHJ4DHogxqbiInl8TIz5sxIEXbIfo2OQ=.912568b8-830d-47cc-a837-46af6be618f3@github.com>
Message-ID: <jHk0oiJdpn20vF43Mzzlu0SYupv3sHSfBJSQhIjlu2c=.99fb9125-0ee8-49d5-977c-691d998cd88b@github.com>

On Tue, 1 Jul 2025 06:41:32 GMT, Xiaohong Gong <xgong at openjdk.org> 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: <ukODVKiBC1LuwN3hngG_vkkhd1QJO2TpvAUSKsR6Ko0=.43b5a21d-2a39-4ac1-a9de-549abcd72d40@github.com>
 <DTjy5tn75B091PzQPau6hp0s3eKh0UUQGUpQQoFLSVM=.06514ff0-fdef-4266-9808-d6f6442afe8a@github.com>
 <P9OyZhq2i0wpmEEBj1McFnZdXY2wd89ljAIEBo1qNaE=.4528d390-e137-4e1d-a7d4-365b84b076d3@github.com>
 <7-WqNSzjPLOsHJ4DHogxqbiInl8TIz5sxIEXbIfo2OQ=.912568b8-830d-47cc-a837-46af6be618f3@github.com>
Message-ID: <N1M67Ae8UGs0Pcs1SUMGK4XS8pJxqZ6JCfEfbqYngDY=.d26a5b4c-2c87-4d8c-9f0a-fc976112fa2e@github.com>

On Tue, 1 Jul 2025 06:41:32 GMT, Xiaohong Gong <xgong at openjdk.org> 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: <EPq2BCssdOzDASLBXt1MIab0MbwCeUA1_n9brSSmWSI=.25614944-4553-4518-be89-189453ce7347@github.com>
References: <EMxYqM4tRcDPNaQ_xEpkBi2Zew0HlDwCFXEX0U7lrsY=.4552fbbf-7dd0-491d-b0f5-59ca304b970d@github.com>
 <EPq2BCssdOzDASLBXt1MIab0MbwCeUA1_n9brSSmWSI=.25614944-4553-4518-be89-189453ce7347@github.com>
Message-ID: <M2qvXA4FkPbt7awGXF1OyvFYP30fgDpvqws5Vm7jJwc=.6a1d2fd4-0b56-4b04-be2f-779bdbec35e6@github.com>

On Mon, 30 Jun 2025 15:08:25 GMT, David Beaumont <duke at openjdk.org> 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: <zfAyPC-xmCsYT0LtOlVqaJN17hgFb8DZhWUP1rwbSWM=.571fc63f-d165-40b6-b374-d2ab743058f0@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <kndznJZZH6s5fbZh3SdLr99uyypWihLc5VTVgvYJ-4o=.55af7211-1f2e-45a4-ab2e-33bfa87565d9@github.com>
 <zfAyPC-xmCsYT0LtOlVqaJN17hgFb8DZhWUP1rwbSWM=.571fc63f-d165-40b6-b374-d2ab743058f0@github.com>
Message-ID: <VZ6AgfVBnh4Yx_Mu0CHn84G6gBJriDp0W6XBasxcBKU=.c4404433-31b0-4dae-a159-554440309ff2@github.com>

On Thu, 26 Jun 2025 17:34:45 GMT, Daniel Fuchs <dfuchs at openjdk.org> 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: <LQRWbokCOzo8paB0R3JzFrXWVt5mxyGpU1Xe5rTuN4Q=.a7affe6d-82e2-4115-866e-348acbe4d7f7@github.com>
References: <LQRWbokCOzo8paB0R3JzFrXWVt5mxyGpU1Xe5rTuN4Q=.a7affe6d-82e2-4115-866e-348acbe4d7f7@github.com>
Message-ID: <HUOvLrn2QbxY_giCuogDNrwiIt9rc8OH1a02CKRzxp8=.dd00f487-da46-4f89-aaba-e452a2170efb@github.com>

On Tue, 1 Jul 2025 05:59:15 GMT, Xiaohong Gong <xgong at openjdk.org> 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: <XzgdqkfNb7wyrKv1uPcRKVLvYAlNuu5QECVLKvm4-TQ=.7aa9cc50-a256-48a6-8553-540bb4e24192@github.com>
References: <8yqi3J3JfLa2NNags9waBIshIMIuOJRjm-rHF--Wjws=.d04990af-5fdb-4218-a8da-60bda679b1d1@github.com>
 <mvB-1pTlzyDNr2Sp42xWPeHoeB2qwsDKieOycSH_ngE=.f2ea79f7-beb6-447d-b4d5-3deb1c7ab53b@github.com>
 <XzgdqkfNb7wyrKv1uPcRKVLvYAlNuu5QECVLKvm4-TQ=.7aa9cc50-a256-48a6-8553-540bb4e24192@github.com>
Message-ID: <5n7tsON05k7Ww6Tej-nT3P9A2fRrd76W05XMe0RPaiI=.b4300af0-1919-4b1c-9068-7964911d8133@github.com>

On Mon, 30 Jun 2025 15:55:03 GMT, Alan Bateman <alanb at openjdk.org> 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: <HUOvLrn2QbxY_giCuogDNrwiIt9rc8OH1a02CKRzxp8=.dd00f487-da46-4f89-aaba-e452a2170efb@github.com>
References: <LQRWbokCOzo8paB0R3JzFrXWVt5mxyGpU1Xe5rTuN4Q=.a7affe6d-82e2-4115-866e-348acbe4d7f7@github.com>
 <HUOvLrn2QbxY_giCuogDNrwiIt9rc8OH1a02CKRzxp8=.dd00f487-da46-4f89-aaba-e452a2170efb@github.com>
Message-ID: <bk9LGKijua26wXuUnUclTkf6uOQ_6iCt0SLrm3qfcmg=.53e6eca0-4e9d-4cb2-b8ea-315ab1c1b714@github.com>

On Tue, 1 Jul 2025 08:10:16 GMT, Andrew Haley <aph at openjdk.org> 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>
 <mvB-1pTlzyDNr2Sp42xWPeHoeB2qwsDKieOycSH_ngE=.f2ea79f7-beb6-447d-b4d5-3deb1c7ab53b@github.com>
 <XzgdqkfNb7wyrKv1uPcRKVLvYAlNuu5QECVLKvm4-TQ=.7aa9cc50-a256-48a6-8553-540bb4e24192@github.com>
 <5n7tsON05k7Ww6Tej-nT3P9A2fRrd76W05XMe0RPaiI=.b4300af0-1919-4b1c-9068-7964911d8133@github.com>
Message-ID: <kjkXCLldHc5MA2-oDTDMNiH_ed3GgsNsKNm4Btv271o=.fa96d018-7f4d-4836-81f1-a0a685837a31@github.com>

On Tue, 1 Jul 2025 08:21:10 GMT, Andrew Haley <aph at openjdk.org> 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: <tG3KsNaA8iDVdZRT-MGKvy8uViCna0ZUJ939oJsilj0=.a12f0cc9-4e47-4fb8-92d4-291c8f211790@github.com>
 <TdnuVxqRVlUzZpF7RYlOhMbsiCqssJiCgKNACfVqaJU=.190b4b40-3bad-44cd-abc8-9d436b2d3a47@github.com>
 <8Gw6kEDNuv2UmryKGGqW7QDndJJr29rT6dHKa9pLQLQ=.7d15c0c6-70f2-44e7-a07c-977ec66ed9c7@github.com>
Message-ID: <qDMgvXPFu6XFFsV0CHd3rphymURjIZDLDZ3mNI-Rulo=.54657941-8784-4125-94ec-6642562ce1cb@github.com>

On Tue, 1 Jul 2025 02:33:16 GMT, Chen Liang <liach at openjdk.org> 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: <zvTr0TD3ifqR9ew19jxJ5Ycu0eDkW-k7sghFFJuNOZQ=.cdaec567-c7a4-4046-bf92-79cf49170b7b@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 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: <kndznJZZH6s5fbZh3SdLr99uyypWihLc5VTVgvYJ-4o=.55af7211-1f2e-45a4-ab2e-33bfa87565d9@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <kndznJZZH6s5fbZh3SdLr99uyypWihLc5VTVgvYJ-4o=.55af7211-1f2e-45a4-ab2e-33bfa87565d9@github.com>
Message-ID: <2uIlI67ZuXY_FGElLjUN1wcwoPSdVrQACgyVF7AEbfk=.624e0472-4a35-4c9a-aec8-cc02e28d5632@github.com>

On Thu, 26 Jun 2025 16:36:40 GMT, Daniel Fuchs <dfuchs at openjdk.org> 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: <eqA9zD_EnXUJr7Q_xq7OZbBzAxViuUHyzy0Tw6LtZ8U=.6868ebd9-4afa-4a03-8c2d-7addef9a2ddf@github.com>
References: <eqA9zD_EnXUJr7Q_xq7OZbBzAxViuUHyzy0Tw6LtZ8U=.6868ebd9-4afa-4a03-8c2d-7addef9a2ddf@github.com>
Message-ID: <oAVD1Fs3cbeNnwB7JZLuA8bdwxLOrz5TPJt5dHexbJ0=.02f18eca-0b56-43e5-bb3b-d192651295f6@github.com>

On Tue, 3 Jun 2025 10:09:44 GMT, Nizar Benalla <nbenalla at openjdk.org> 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: <CNvBGLhlcuPWtqrYLhdsnfQYQ2_1th14ufURXeHLtQc=.f7413c0c-45b2-441e-8cfb-bdf7b09fd5e6@github.com>

On Mon, 30 Jun 2025 16:52:55 GMT, Jaikiran Pai <jpai at openjdk.org> 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: <DangVe1kkfii-gi2KjHC46QhfkzVlKCF5jXhFhenwkc=.22d9ae96-4e49-49ee-97cb-a11b6aba47ad@github.com>

On Mon, 30 Jun 2025 16:18:00 GMT, Jaikiran Pai <jpai at openjdk.org> 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 <jpai at openjdk.org>
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: <deSQhnZdKGRlBTETYyrUUWbCVQI2b1i5SI_sJh2Ro0o=.e17a7757-abd1-44e2-b690-b2a016ce5578@github.com>

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: <S5QCukHfY9v7DYMWyRaUlJPGjPrYWcVV5eMlknezS78=.84a5f517-bcbf-4f2f-801d-5768e5456c2c@github.com>
 <4b4eB1IhNlZXMVqf-aOj-IIp3kwLiqOVfeqioc2dL9Q=.8af3f74b-7b61-424a-b2c6-421fa6e0c0e6@github.com>
Message-ID: <Sxt7-OxM03P4sDMZ0YEa5O4ov5hJVtm3DI8YTPl03uE=.5588449b-d24b-4f09-99b1-92ce56963378@github.com>

On Mon, 30 Jun 2025 18:19:30 GMT, Kieran Farrell <kfarrell at openjdk.org> 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: <Q4fLpzhyF__Tixp2XVuGWgMKPywQhWR8_B4CyhvH5IE=.fc8c22d7-7dc5-4b72-a732-f79c99a81600@github.com>
References: <NUixQl_OY2xQ7VehoMd2fRm9S6T-z5qZNi2Uevslyp0=.0ef35d36-1b32-4bda-93bd-4a4f9f810614@github.com>
 <Q4fLpzhyF__Tixp2XVuGWgMKPywQhWR8_B4CyhvH5IE=.fc8c22d7-7dc5-4b72-a732-f79c99a81600@github.com>
Message-ID: <qN9pPF7_tcgKXG-bz8dywF56sjnHgrNzWfKpVgo9UpM=.df61357d-6ab0-4e6b-898b-3b8a441f97fc@github.com>

On Fri, 4 Apr 2025 10:29:43 GMT, Takuya Kiriyama <tkiriyama at openjdk.org> 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: <nHPkgGguDOyGtYHRyaAdCJbxYt_5ufhp99mcHkUGQx4=.da1cdd58-80eb-45c2-adde-ebff8932031a@github.com>
References: <NUixQl_OY2xQ7VehoMd2fRm9S6T-z5qZNi2Uevslyp0=.0ef35d36-1b32-4bda-93bd-4a4f9f810614@github.com>
 <nHPkgGguDOyGtYHRyaAdCJbxYt_5ufhp99mcHkUGQx4=.da1cdd58-80eb-45c2-adde-ebff8932031a@github.com>
Message-ID: <Bymxp9EwFIUQ84awzeUg7eufKFcMx6llm8SejJXx6LI=.0941e3f9-832a-43fa-989e-ebbe9779e326@github.com>

On Wed, 19 Mar 2025 20:07:26 GMT, Roger Riggs <rriggs at openjdk.org> 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: <S5QCukHfY9v7DYMWyRaUlJPGjPrYWcVV5eMlknezS78=.84a5f517-bcbf-4f2f-801d-5768e5456c2c@github.com>
 <4b4eB1IhNlZXMVqf-aOj-IIp3kwLiqOVfeqioc2dL9Q=.8af3f74b-7b61-424a-b2c6-421fa6e0c0e6@github.com>
Message-ID: <uhwwue-kNBVyJMVrHJFnwaAxWJ7Kg7mS0mx0kKfHMQc=.44e31d05-5cf1-4a63-95a2-805b74dd60d3@github.com>

On Mon, 30 Jun 2025 18:19:30 GMT, Kieran Farrell <kfarrell at openjdk.org> 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: <deSQhnZdKGRlBTETYyrUUWbCVQI2b1i5SI_sJh2Ro0o=.e17a7757-abd1-44e2-b690-b2a016ce5578@github.com>
References: <deSQhnZdKGRlBTETYyrUUWbCVQI2b1i5SI_sJh2Ro0o=.e17a7757-abd1-44e2-b690-b2a016ce5578@github.com>
Message-ID: <2AwBxckSavQEtCCKD20ckA_RazX5u7YSEVdgGqm8bdM=.ae0d00dd-3106-40b1-8698-abce750cffa1@github.com>

On Tue, 1 Jul 2025 11:48:30 GMT, Jaikiran Pai <jpai at openjdk.org> 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: <VtQlJ_3w2k5ewTVyVele6LRy1j6Vp_N-gZ4K0WJEDzE=.9b4ec980-a8a1-4ed2-8da8-0a1e3e58098d@github.com>

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/<module>/<path>` may come from one of two locations in the underlying jimage file; `/<module>/<path>` or `/<module>/META-INF/preview/<path>`. 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: <VtQlJ_3w2k5ewTVyVele6LRy1j6Vp_N-gZ4K0WJEDzE=.9b4ec980-a8a1-4ed2-8da8-0a1e3e58098d@github.com>
References: <VtQlJ_3w2k5ewTVyVele6LRy1j6Vp_N-gZ4K0WJEDzE=.9b4ec980-a8a1-4ed2-8da8-0a1e3e58098d@github.com>
Message-ID: <9xh9VZuuTCyFomE_TV9usc_bVDSPz6ssX5HDmj-hhSU=.18a3192c-57b1-4920-b97b-4cfd37c6fea6@github.com>

On Mon, 30 Jun 2025 23:27:49 GMT, David Beaumont <duke at openjdk.org> 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/<module>/<path>` may come from one of two locations in the underlying jimage file; `/<module>/<path>` or `/<module>/META-INF/preview/<path>`. 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<Node> 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: <CyUgfG09cnYSDOV9IHKDkY4UowM60ej_oKzYoMFKSbg=.f63b99b7-2ed7-4db7-b5a7-b03447a99553@github.com>
References: <GWKPi8D6xcR5Pxkszfod4keJeBQKxp6uRzLl3ObOpJo=.21c2951d-5928-425f-b39e-a5af8659fd05@github.com>
 <CyUgfG09cnYSDOV9IHKDkY4UowM60ej_oKzYoMFKSbg=.f63b99b7-2ed7-4db7-b5a7-b03447a99553@github.com>
Message-ID: <ml1xO8DEABmZgQreHjBi3BQWf0AD2BbQk6yX84j1tLs=.3d6d8b1c-e585-4d6d-a09f-6e21244c1b48@github.com>

On Fri, 27 Jun 2025 16:15:57 GMT, Magnus Ihse Bursie <ihse at openjdk.org> 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: <deSQhnZdKGRlBTETYyrUUWbCVQI2b1i5SI_sJh2Ro0o=.e17a7757-abd1-44e2-b690-b2a016ce5578@github.com>
 <2AwBxckSavQEtCCKD20ckA_RazX5u7YSEVdgGqm8bdM=.ae0d00dd-3106-40b1-8698-abce750cffa1@github.com>
Message-ID: <MfGPfeHC1o-zd3yvgZonQP0R287A02DUzS1PH-rK-nc=.8144b62e-fe19-4a23-aa97-ee56b774eb75@github.com>

On Tue, 1 Jul 2025 14:13:08 GMT, Daniel Fuchs <dfuchs at openjdk.org> 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: <MfGPfeHC1o-zd3yvgZonQP0R287A02DUzS1PH-rK-nc=.8144b62e-fe19-4a23-aa97-ee56b774eb75@github.com>
References: <deSQhnZdKGRlBTETYyrUUWbCVQI2b1i5SI_sJh2Ro0o=.e17a7757-abd1-44e2-b690-b2a016ce5578@github.com>
 <2AwBxckSavQEtCCKD20ckA_RazX5u7YSEVdgGqm8bdM=.ae0d00dd-3106-40b1-8698-abce750cffa1@github.com>
 <MfGPfeHC1o-zd3yvgZonQP0R287A02DUzS1PH-rK-nc=.8144b62e-fe19-4a23-aa97-ee56b774eb75@github.com>
Message-ID: <VGOF8PXBMPwpj0axpkY-7jruPYMS437ad6gtZaL5Gro=.68fa366a-6bbc-477a-97ad-abfb21ce6cf7@github.com>

On Tue, 1 Jul 2025 14:26:44 GMT, Jaikiran Pai <jpai at openjdk.org> 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: <VtQlJ_3w2k5ewTVyVele6LRy1j6Vp_N-gZ4K0WJEDzE=.9b4ec980-a8a1-4ed2-8da8-0a1e3e58098d@github.com>
References: <VtQlJ_3w2k5ewTVyVele6LRy1j6Vp_N-gZ4K0WJEDzE=.9b4ec980-a8a1-4ed2-8da8-0a1e3e58098d@github.com>
Message-ID: <QPSnXfmDTCKVY47Oh3GplxNEWrpJdvuwXKxz9lvxKSY=.8e5f77ea-1055-4830-9003-cce673330897@github.com>

On Mon, 30 Jun 2025 23:27:49 GMT, David Beaumont <duke at openjdk.org> 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/<module>/<path>` may come from one of two locations in the underlying jimage file; `/<module>/<path>` or `/<module>/META-INF/preview/<path>`. 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<ModuleInfo.Attributes> 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: <TdnuVxqRVlUzZpF7RYlOhMbsiCqssJiCgKNACfVqaJU=.190b4b40-3bad-44cd-abc8-9d436b2d3a47@github.com>
References: <tG3KsNaA8iDVdZRT-MGKvy8uViCna0ZUJ939oJsilj0=.a12f0cc9-4e47-4fb8-92d4-291c8f211790@github.com>
 <TdnuVxqRVlUzZpF7RYlOhMbsiCqssJiCgKNACfVqaJU=.190b4b40-3bad-44cd-abc8-9d436b2d3a47@github.com>
Message-ID: <hTVnFFy36kIzQ_lQrTR1Xt7GoxpgTdgfj_cL1TC-_aA=.dd2c1bf2-8d64-4d35-833f-c271b2e3337a@github.com>

On Tue, 1 Jul 2025 00:01:21 GMT, Shaojin Wen <swen at openjdk.org> 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: <Pj612tMDuN_vikjswqLr2FS-hs08JeIrtirLGK_wY8w=.fbb16038-3922-499a-a9d1-c2c940a872da@github.com>
References: <IPodt6KjRH75edJJjXja5g9wqH4oY6-EouV4Xn5SWeU=.21e726f3-7dae-47ad-9b3a-9f3118fedbda@github.com>
 <T1ReWdgWLbe0Gr6FrmG2t7jHIW2eaP8ogLOJgb8RVqQ=.e3ff1b84-ab5e-4ce6-a81e-944972700549@github.com>
 <Pj612tMDuN_vikjswqLr2FS-hs08JeIrtirLGK_wY8w=.fbb16038-3922-499a-a9d1-c2c940a872da@github.com>
Message-ID: <EktXxFIXhNxNVnqvNI9xtliTEkoaz9T2b45fh58MFxM=.b702f523-ab29-45bf-be85-9449ed1e6370@github.com>

On Mon, 23 Jun 2025 17:45:02 GMT, Lance Andersen <lancea at openjdk.org> 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: <VtQlJ_3w2k5ewTVyVele6LRy1j6Vp_N-gZ4K0WJEDzE=.9b4ec980-a8a1-4ed2-8da8-0a1e3e58098d@github.com>
References: <VtQlJ_3w2k5ewTVyVele6LRy1j6Vp_N-gZ4K0WJEDzE=.9b4ec980-a8a1-4ed2-8da8-0a1e3e58098d@github.com>
Message-ID: <wWmD8znj-bwA46ccmxwzDfdHIjLb0Ls3irrN6-o5Scg=.ffc3e9f3-fdc8-4802-b0df-e99d168e6f25@github.com>

On Mon, 30 Jun 2025 23:27:49 GMT, David Beaumont <duke at openjdk.org> 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/<module>/<path>` may come from one of two locations in the underlying jimage file; `/<module>/<path>` or `/<module>/META-INF/preview/<path>`. 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: <VtQlJ_3w2k5ewTVyVele6LRy1j6Vp_N-gZ4K0WJEDzE=.9b4ec980-a8a1-4ed2-8da8-0a1e3e58098d@github.com>
References: <VtQlJ_3w2k5ewTVyVele6LRy1j6Vp_N-gZ4K0WJEDzE=.9b4ec980-a8a1-4ed2-8da8-0a1e3e58098d@github.com>
Message-ID: <CdlBFucDBOCgehmRdZSlhW14zhZ4VdLQ8kU3ecHXqpI=.a3a94675-f4c4-4614-b665-7466f3d31345@github.com>

On Mon, 30 Jun 2025 23:27:49 GMT, David Beaumont <duke at openjdk.org> 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/<module>/<path>` may come from one of two locations in the underlying jimage file; `/<module>/<path>` or `/<module>/META-INF/preview/<path>`. 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<ImageReader.Node> 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: <S5QCukHfY9v7DYMWyRaUlJPGjPrYWcVV5eMlknezS78=.84a5f517-bcbf-4f2f-801d-5768e5456c2c@github.com>
 <4b4eB1IhNlZXMVqf-aOj-IIp3kwLiqOVfeqioc2dL9Q=.8af3f74b-7b61-424a-b2c6-421fa6e0c0e6@github.com>
Message-ID: <SM51sfCBxdd5DUJm7EJGGBzGA-IzlX4QSA4qXVS3UJk=.cf6cb877-1703-4fdf-b02e-f87a27e1d77b@github.com>

On Mon, 30 Jun 2025 18:19:30 GMT, Kieran Farrell <kfarrell at openjdk.org> 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: <SM51sfCBxdd5DUJm7EJGGBzGA-IzlX4QSA4qXVS3UJk=.cf6cb877-1703-4fdf-b02e-f87a27e1d77b@github.com>
References: <S5QCukHfY9v7DYMWyRaUlJPGjPrYWcVV5eMlknezS78=.84a5f517-bcbf-4f2f-801d-5768e5456c2c@github.com>
 <4b4eB1IhNlZXMVqf-aOj-IIp3kwLiqOVfeqioc2dL9Q=.8af3f74b-7b61-424a-b2c6-421fa6e0c0e6@github.com>
 <SM51sfCBxdd5DUJm7EJGGBzGA-IzlX4QSA4qXVS3UJk=.cf6cb877-1703-4fdf-b02e-f87a27e1d77b@github.com>
Message-ID: <Jxnfqiwb79xkySdKYFiZrXammdV53SSqGikeBO2g-0s=.6b47f449-e71e-431c-a361-f2604300a757@github.com>

On Tue, 1 Jul 2025 14:39:11 GMT, Jaikiran Pai <jpai at openjdk.org> 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: <CANBJVOFRV0drYo0DcumwZYGavzNLquhjKijmoXjzNpc4k89Yrg@mail.gmail.com>

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: <u6xKM6nWIWia3wHIYFyNSRUwOUFy8gN7gapYUof7Ces=.7a657899-51d4-4fca-a47c-b8928baf6531@github.com>
References: <k-sV5p2PH-mOW5iO5bjVK3Poi_h1rUzH6OEKiXhHAHQ=.ccaf23b2-903b-4847-a26b-7e2e4a47ef7b@github.com>
 <A1gPk7gsSnZ_947EFmBjljC7sDkbvC18DXCnoZHWSmY=.66b1501a-9e4d-4727-836e-0543fbfe5120@github.com>
 <u6xKM6nWIWia3wHIYFyNSRUwOUFy8gN7gapYUof7Ces=.7a657899-51d4-4fca-a47c-b8928baf6531@github.com>
Message-ID: <3StfS2-72iIkuHlf9HpzfC-BNoD4kDEjHY2esUnPKEM=.f7ae323f-5313-445b-bd7d-89f6743974f3@github.com>

On Tue, 1 Jul 2025 01:37:27 GMT, Roger Riggs <rriggs at openjdk.org> 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: <Jxnfqiwb79xkySdKYFiZrXammdV53SSqGikeBO2g-0s=.6b47f449-e71e-431c-a361-f2604300a757@github.com>
References: <S5QCukHfY9v7DYMWyRaUlJPGjPrYWcVV5eMlknezS78=.84a5f517-bcbf-4f2f-801d-5768e5456c2c@github.com>
 <4b4eB1IhNlZXMVqf-aOj-IIp3kwLiqOVfeqioc2dL9Q=.8af3f74b-7b61-424a-b2c6-421fa6e0c0e6@github.com>
 <SM51sfCBxdd5DUJm7EJGGBzGA-IzlX4QSA4qXVS3UJk=.cf6cb877-1703-4fdf-b02e-f87a27e1d77b@github.com>
 <Jxnfqiwb79xkySdKYFiZrXammdV53SSqGikeBO2g-0s=.6b47f449-e71e-431c-a361-f2604300a757@github.com>
Message-ID: <TBlXrG7D1XZI1v63sRUcixX1zKfS9yb1rvPXvjqUuqw=.624d2815-18e6-4d78-88cf-5c74abcbd4a7@github.com>

On Tue, 1 Jul 2025 14:48:50 GMT, Roger Riggs <rriggs at openjdk.org> 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: <TBlXrG7D1XZI1v63sRUcixX1zKfS9yb1rvPXvjqUuqw=.624d2815-18e6-4d78-88cf-5c74abcbd4a7@github.com>
References: <S5QCukHfY9v7DYMWyRaUlJPGjPrYWcVV5eMlknezS78=.84a5f517-bcbf-4f2f-801d-5768e5456c2c@github.com>
 <4b4eB1IhNlZXMVqf-aOj-IIp3kwLiqOVfeqioc2dL9Q=.8af3f74b-7b61-424a-b2c6-421fa6e0c0e6@github.com>
 <SM51sfCBxdd5DUJm7EJGGBzGA-IzlX4QSA4qXVS3UJk=.cf6cb877-1703-4fdf-b02e-f87a27e1d77b@github.com>
 <Jxnfqiwb79xkySdKYFiZrXammdV53SSqGikeBO2g-0s=.6b47f449-e71e-431c-a361-f2604300a757@github.com>
 <TBlXrG7D1XZI1v63sRUcixX1zKfS9yb1rvPXvjqUuqw=.624d2815-18e6-4d78-88cf-5c74abcbd4a7@github.com>
Message-ID: <LwJm2kHp6rHlRrTTCmmbOD0nVJRUpM5W0URzIGJsoC8=.a86b37df-2508-43f1-b64a-2c768c927ff3@github.com>

On Tue, 1 Jul 2025 15:20:07 GMT, Jaikiran Pai <jpai at openjdk.org> 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: <zvTr0TD3ifqR9ew19jxJ5Ycu0eDkW-k7sghFFJuNOZQ=.cdaec567-c7a4-4046-bf92-79cf49170b7b@github.com>
References: <8yqi3J3JfLa2NNags9waBIshIMIuOJRjm-rHF--Wjws=.d04990af-5fdb-4218-a8da-60bda679b1d1@github.com>
 <zvTr0TD3ifqR9ew19jxJ5Ycu0eDkW-k7sghFFJuNOZQ=.cdaec567-c7a4-4046-bf92-79cf49170b7b@github.com>
Message-ID: <auWyrAL5ho15wQP2N_HuYddrvIV4v5xMuQI2tzuu7eo=.f1746ff5-d12b-4f98-9d6a-ac634521698b@github.com>

On Tue, 1 Jul 2025 11:15:54 GMT, Andrew Haley <aph at openjdk.org> 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: <deSQhnZdKGRlBTETYyrUUWbCVQI2b1i5SI_sJh2Ro0o=.e17a7757-abd1-44e2-b690-b2a016ce5578@github.com>
References: <deSQhnZdKGRlBTETYyrUUWbCVQI2b1i5SI_sJh2Ro0o=.e17a7757-abd1-44e2-b690-b2a016ce5578@github.com>
Message-ID: <4sQm6D6icSMukjKohgjcevtNiAbEB1k0NmgtKFmDrdo=.8cb7b3d8-742b-4f1d-ad4b-dfa610e5b1f7@github.com>

On Tue, 1 Jul 2025 11:48:30 GMT, Jaikiran Pai <jpai at openjdk.org> 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: <CANBJVOFRV0drYo0DcumwZYGavzNLquhjKijmoXjzNpc4k89Yrg@mail.gmail.com>
References: <CANBJVOFRV0drYo0DcumwZYGavzNLquhjKijmoXjzNpc4k89Yrg@mail.gmail.com>
Message-ID: <SJ2PR10MB7669FEA3948E934C7EB92B7AA241A@SJ2PR10MB7669.namprd10.prod.outlook.com>

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 <core-libs-dev-retn at openjdk.org> on behalf of Brett Okken <brett.okken.os at gmail.com>
Sent: Tuesday, July 1, 2025 9:57 AM
To: core-libs-dev <core-libs-dev at openjdk.org>
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: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250701/c0ae30be/attachment-0001.htm>

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: <k-sV5p2PH-mOW5iO5bjVK3Poi_h1rUzH6OEKiXhHAHQ=.ccaf23b2-903b-4847-a26b-7e2e4a47ef7b@github.com>
 <A1gPk7gsSnZ_947EFmBjljC7sDkbvC18DXCnoZHWSmY=.66b1501a-9e4d-4727-836e-0543fbfe5120@github.com>
 <u6xKM6nWIWia3wHIYFyNSRUwOUFy8gN7gapYUof7Ces=.7a657899-51d4-4fca-a47c-b8928baf6531@github.com>
 <3StfS2-72iIkuHlf9HpzfC-BNoD4kDEjHY2esUnPKEM=.f7ae323f-5313-445b-bd7d-89f6743974f3@github.com>
Message-ID: <CPYC2MzNDrkaaO8yG4i84hH99ft9pGjjMnhV59J3q-8=.e2436408-a830-4aa5-b4c4-94dd630fab77@github.com>

On Tue, 1 Jul 2025 15:10:33 GMT, Brian Burkhalter <bpb at openjdk.org> 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: <deSQhnZdKGRlBTETYyrUUWbCVQI2b1i5SI_sJh2Ro0o=.e17a7757-abd1-44e2-b690-b2a016ce5578@github.com>
References: <deSQhnZdKGRlBTETYyrUUWbCVQI2b1i5SI_sJh2Ro0o=.e17a7757-abd1-44e2-b690-b2a016ce5578@github.com>
Message-ID: <UVIUyKbUyrO5OVpeEnlqNOomUzyj3QH2-tbTLAvZTAg=.5cdf3c85-7951-44c1-97d3-7a4eccda49cc@github.com>

On Tue, 1 Jul 2025 11:48:30 GMT, Jaikiran Pai <jpai at openjdk.org> 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: <M2qvXA4FkPbt7awGXF1OyvFYP30fgDpvqws5Vm7jJwc=.6a1d2fd4-0b56-4b04-be2f-779bdbec35e6@github.com>
References: <EMxYqM4tRcDPNaQ_xEpkBi2Zew0HlDwCFXEX0U7lrsY=.4552fbbf-7dd0-491d-b0f5-59ca304b970d@github.com>
 <EPq2BCssdOzDASLBXt1MIab0MbwCeUA1_n9brSSmWSI=.25614944-4553-4518-be89-189453ce7347@github.com>
 <M2qvXA4FkPbt7awGXF1OyvFYP30fgDpvqws5Vm7jJwc=.6a1d2fd4-0b56-4b04-be2f-779bdbec35e6@github.com>
Message-ID: <E4dW0zQJNkVozaAP9rjlBDv-wTEtRKMl0OotVJY-9Tg=.d96625fd-17be-4418-96ad-6de5746ea9b7@github.com>

On Tue, 1 Jul 2025 07:25:35 GMT, Alan Bateman <alanb at openjdk.org> 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: <EMxYqM4tRcDPNaQ_xEpkBi2Zew0HlDwCFXEX0U7lrsY=.4552fbbf-7dd0-491d-b0f5-59ca304b970d@github.com>
References: <EMxYqM4tRcDPNaQ_xEpkBi2Zew0HlDwCFXEX0U7lrsY=.4552fbbf-7dd0-491d-b0f5-59ca304b970d@github.com>
Message-ID: <HL9e08KU4wHaANdRVoesH2BLEHKh4BYZldySxG21WT4=.aa87928e-775d-4d7e-8489-300b1abddbf3@github.com>

> 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: <S5QCukHfY9v7DYMWyRaUlJPGjPrYWcVV5eMlknezS78=.84a5f517-bcbf-4f2f-801d-5768e5456c2c@github.com>
 <4b4eB1IhNlZXMVqf-aOj-IIp3kwLiqOVfeqioc2dL9Q=.8af3f74b-7b61-424a-b2c6-421fa6e0c0e6@github.com>
Message-ID: <rv-6nOSvRHHMKopFqizkzijoA0J1E8DxzZ0bDka-vZo=.77896a35-7b4c-457e-9140-b1ad7c3ab349@github.com>

On Mon, 30 Jun 2025 18:19:30 GMT, Kieran Farrell <kfarrell at openjdk.org> 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:      * <li>3    Name-based UUID
> 406:      * <li>4    Randomly generated UUID
> 407:      * <li>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: <S5QCukHfY9v7DYMWyRaUlJPGjPrYWcVV5eMlknezS78=.84a5f517-bcbf-4f2f-801d-5768e5456c2c@github.com>
 <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 <kfarrell at openjdk.org> 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: <DTjy5tn75B091PzQPau6hp0s3eKh0UUQGUpQQoFLSVM=.06514ff0-fdef-4266-9808-d6f6442afe8a@github.com>
References: <ukODVKiBC1LuwN3hngG_vkkhd1QJO2TpvAUSKsR6Ko0=.43b5a21d-2a39-4ac1-a9de-549abcd72d40@github.com>
 <DTjy5tn75B091PzQPau6hp0s3eKh0UUQGUpQQoFLSVM=.06514ff0-fdef-4266-9808-d6f6442afe8a@github.com>
Message-ID: <onQhCJUNZnTjjL_w5-SF4AMQxkyDiLmQEfIYmO1_3aw=.114c12cd-b577-4d69-89a9-4beea56a35a1@github.com>

On Wed, 25 Jun 2025 09:16:48 GMT, Xiaohong Gong <xgong at openjdk.org> 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: <d3920337-680f-4ddb-b3fc-09177b6e5814@oracle.com>
References: <13a-68629a80-9-779b3d00@72416994>
 <36a66421-240e-49a4-94f5-f89467eab56d@oracle.com>
 <13e-6862d180-11-2f7cd380@124222359>
 <d3920337-680f-4ddb-b3fc-09177b6e5814@oracle.com>
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 <alexey.semenyuk at oracle.com>:

?
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?
> <alexey.semenyuk at oracle.com>:
>
>> 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: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250701/be3af32a/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2759 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250701/be3af32a/smime.p7s>

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: <VtQlJ_3w2k5ewTVyVele6LRy1j6Vp_N-gZ4K0WJEDzE=.9b4ec980-a8a1-4ed2-8da8-0a1e3e58098d@github.com>
References: <VtQlJ_3w2k5ewTVyVele6LRy1j6Vp_N-gZ4K0WJEDzE=.9b4ec980-a8a1-4ed2-8da8-0a1e3e58098d@github.com>
Message-ID: <nnLiULvlgT9T3NE_bVbt1wOrepPdbNtHfy20P5UtPLE=.8c7c120e-fb4e-49c8-8c39-80506f3b8980@github.com>

On Mon, 30 Jun 2025 23:27:49 GMT, David Beaumont <duke at openjdk.org> 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/<module>/<path>` may come from one of two locations in the underlying jimage file; `/<module>/<path>` or `/<module>/META-INF/preview/<path>`. 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<ModuleReference> 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: <VtQlJ_3w2k5ewTVyVele6LRy1j6Vp_N-gZ4K0WJEDzE=.9b4ec980-a8a1-4ed2-8da8-0a1e3e58098d@github.com>
 <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 <duke at openjdk.org> 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/<module>/<path>` may come from one of two locations in the underlying jimage file; `/<module>/<path>` or `/<module>/META-INF/preview/<path>`. 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>
 <d3920337-680f-4ddb-b3fc-09177b6e5814@oracle.com>
 <13f-68642d00-3-69f4458@20238135>
Message-ID: <e6186217-7b07-4806-b72b-2f46106e4891@oracle.com>

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 
> <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 
> <alexey.semenyuk at oracle.com>:
>
>> 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
>> > <alexey.semenyuk at oracle.com>:
>> >
>> >> 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: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250701/4e82d69a/attachment.htm>

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: <CPYC2MzNDrkaaO8yG4i84hH99ft9pGjjMnhV59J3q-8=.e2436408-a830-4aa5-b4c4-94dd630fab77@github.com>
References: <k-sV5p2PH-mOW5iO5bjVK3Poi_h1rUzH6OEKiXhHAHQ=.ccaf23b2-903b-4847-a26b-7e2e4a47ef7b@github.com>
 <A1gPk7gsSnZ_947EFmBjljC7sDkbvC18DXCnoZHWSmY=.66b1501a-9e4d-4727-836e-0543fbfe5120@github.com>
 <u6xKM6nWIWia3wHIYFyNSRUwOUFy8gN7gapYUof7Ces=.7a657899-51d4-4fca-a47c-b8928baf6531@github.com>
 <3StfS2-72iIkuHlf9HpzfC-BNoD4kDEjHY2esUnPKEM=.f7ae323f-5313-445b-bd7d-89f6743974f3@github.com>
 <CPYC2MzNDrkaaO8yG4i84hH99ft9pGjjMnhV59J3q-8=.e2436408-a830-4aa5-b4c4-94dd630fab77@github.com>
Message-ID: <xyO_-BA4dkZeDIWy-sxviKYtXpMNkk8Fq4vtgim0nHY=.d6f776ba-5b56-4218-b3a5-173165c4a6ac@github.com>

On Tue, 1 Jul 2025 16:34:51 GMT, Brian Burkhalter <bpb at openjdk.org> 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: <hTVnFFy36kIzQ_lQrTR1Xt7GoxpgTdgfj_cL1TC-_aA=.dd2c1bf2-8d64-4d35-833f-c271b2e3337a@github.com>
References: <tG3KsNaA8iDVdZRT-MGKvy8uViCna0ZUJ939oJsilj0=.a12f0cc9-4e47-4fb8-92d4-291c8f211790@github.com>
 <TdnuVxqRVlUzZpF7RYlOhMbsiCqssJiCgKNACfVqaJU=.190b4b40-3bad-44cd-abc8-9d436b2d3a47@github.com>
 <hTVnFFy36kIzQ_lQrTR1Xt7GoxpgTdgfj_cL1TC-_aA=.dd2c1bf2-8d64-4d35-833f-c271b2e3337a@github.com>
Message-ID: <iS-XNMV-eUeQo6U19Jp3H6pWXpNty2yeTe0Q7Uh7Iao=.0fa2d70e-7f6f-4bd3-a8d4-71c0f39dd36c@github.com>

On Tue, 1 Jul 2025 14:33:34 GMT, Brett Okken <duke at openjdk.org> 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: <kndznJZZH6s5fbZh3SdLr99uyypWihLc5VTVgvYJ-4o=.55af7211-1f2e-45a4-ab2e-33bfa87565d9@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <kndznJZZH6s5fbZh3SdLr99uyypWihLc5VTVgvYJ-4o=.55af7211-1f2e-45a4-ab2e-33bfa87565d9@github.com>
Message-ID: <3UR7O_cfQFPcsz5GseXURHT9KVC6pUFSxa_KsNLtYNY=.d579b776-0eee-467b-b993-c1341b2dcb19@github.com>

On Thu, 26 Jun 2025 16:36:40 GMT, Daniel Fuchs <dfuchs at openjdk.org> 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<QuicStreamWriter> 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: <fsFrk-uILf3zDODjfBhMP2qOFvCPIMHSVVAf6gn-x68=.29863279-7056-4309-b5f4-1a7ea2be7ffb@github.com>
References: <Tf3bUauvymNvoeefTDY8gYfjcIAyFKv2d7_ktDemlV4=.ce8a894c-28b2-49c3-a515-2c31be1e6d6f@github.com>
 <fsFrk-uILf3zDODjfBhMP2qOFvCPIMHSVVAf6gn-x68=.29863279-7056-4309-b5f4-1a7ea2be7ffb@github.com>
Message-ID: <PYF-6W91JTgpJoUeXxsx54LT2Kk2Rfx_3ygvR4jUDXA=.0b2f430c-7f6a-494e-90eb-0e4e392e9878@github.com>

On Sun, 29 Jun 2025 20:43:56 GMT, Kim Barrett <kbarrett at openjdk.org> 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: <CdlBFucDBOCgehmRdZSlhW14zhZ4VdLQ8kU3ecHXqpI=.a3a94675-f4c4-4614-b665-7466f3d31345@github.com>
References: <VtQlJ_3w2k5ewTVyVele6LRy1j6Vp_N-gZ4K0WJEDzE=.9b4ec980-a8a1-4ed2-8da8-0a1e3e58098d@github.com>
 <CdlBFucDBOCgehmRdZSlhW14zhZ4VdLQ8kU3ecHXqpI=.a3a94675-f4c4-4614-b665-7466f3d31345@github.com>
Message-ID: <Ue32hNXP-IM8zL46moqhgSXKUcF8qxL4lbPKwyrT7Qc=.4d8330f9-57e2-4d50-a69c-cd823a3b2ce5@github.com>

On Tue, 1 Jul 2025 14:37:50 GMT, Alan Bateman <alanb at openjdk.org> 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/<module>/<path>` may come from one of two locations in the underlying jimage file; `/<module>/<path>` or `/<module>/META-INF/preview/<path>`. 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<ImageReader.Node> 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: <nnLiULvlgT9T3NE_bVbt1wOrepPdbNtHfy20P5UtPLE=.8c7c120e-fb4e-49c8-8c39-80506f3b8980@github.com>
References: <VtQlJ_3w2k5ewTVyVele6LRy1j6Vp_N-gZ4K0WJEDzE=.9b4ec980-a8a1-4ed2-8da8-0a1e3e58098d@github.com>
 <nnLiULvlgT9T3NE_bVbt1wOrepPdbNtHfy20P5UtPLE=.8c7c120e-fb4e-49c8-8c39-80506f3b8980@github.com>
Message-ID: <xOovKB-kCkARe6JeDsZAqfII5tB7uq6nPv_rOrSt-oc=.029e1a9e-e5e3-468f-bd2a-a80aef729ae7@github.com>

On Tue, 1 Jul 2025 18:38:26 GMT, Roger Riggs <rriggs at openjdk.org> 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/<module>/<path>` may come from one of two locations in the underlying jimage file; `/<module>/<path>` or `/<module>/META-INF/preview/<path>`. 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<ModuleReference> 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: <kndznJZZH6s5fbZh3SdLr99uyypWihLc5VTVgvYJ-4o=.55af7211-1f2e-45a4-ab2e-33bfa87565d9@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <kndznJZZH6s5fbZh3SdLr99uyypWihLc5VTVgvYJ-4o=.55af7211-1f2e-45a4-ab2e-33bfa87565d9@github.com>
Message-ID: <3lbVW_vZLe7AqGQprT2k4Xa0gOwgsxzBfGmlwcPHtsQ=.abb14e6f-d7ef-4f36-a420-219dde365b52@github.com>

On Thu, 26 Jun 2025 16:36:40 GMT, Daniel Fuchs <dfuchs at openjdk.org> 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<QuicStreamReader> 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<QuicStreamReader> 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: <VtQlJ_3w2k5ewTVyVele6LRy1j6Vp_N-gZ4K0WJEDzE=.9b4ec980-a8a1-4ed2-8da8-0a1e3e58098d@github.com>
References: <VtQlJ_3w2k5ewTVyVele6LRy1j6Vp_N-gZ4K0WJEDzE=.9b4ec980-a8a1-4ed2-8da8-0a1e3e58098d@github.com>
Message-ID: <PXhsuXeNQ5CfuZuUfnspqj8AKn0lz06r3IT0qD6h4KM=.6662be5c-7ffb-4dd2-a742-82e6b8801dd0@github.com>

> 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/<module>/<path>` may come from one of two locations in the underlying jimage file; `/<module>/<path>` or `/<module>/META-INF/preview/<path>`. 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: <QPSnXfmDTCKVY47Oh3GplxNEWrpJdvuwXKxz9lvxKSY=.8e5f77ea-1055-4830-9003-cce673330897@github.com>
References: <VtQlJ_3w2k5ewTVyVele6LRy1j6Vp_N-gZ4K0WJEDzE=.9b4ec980-a8a1-4ed2-8da8-0a1e3e58098d@github.com>
 <QPSnXfmDTCKVY47Oh3GplxNEWrpJdvuwXKxz9lvxKSY=.8e5f77ea-1055-4830-9003-cce673330897@github.com>
Message-ID: <jGzeK51Kmz8m1L9z2IPPnOebWqIjO6zAXMnNMVpgVuQ=.fa4d5181-a733-4b6e-a8f8-d7526c2d59e6@github.com>

On Tue, 1 Jul 2025 14:29:28 GMT, Alan Bateman <alanb at openjdk.org> 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<ModuleInfo.Attributes> 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: <Ue32hNXP-IM8zL46moqhgSXKUcF8qxL4lbPKwyrT7Qc=.4d8330f9-57e2-4d50-a69c-cd823a3b2ce5@github.com>
References: <VtQlJ_3w2k5ewTVyVele6LRy1j6Vp_N-gZ4K0WJEDzE=.9b4ec980-a8a1-4ed2-8da8-0a1e3e58098d@github.com>
 <CdlBFucDBOCgehmRdZSlhW14zhZ4VdLQ8kU3ecHXqpI=.a3a94675-f4c4-4614-b665-7466f3d31345@github.com>
 <Ue32hNXP-IM8zL46moqhgSXKUcF8qxL4lbPKwyrT7Qc=.4d8330f9-57e2-4d50-a69c-cd823a3b2ce5@github.com>
Message-ID: <a74r5FGPV32h3XRjFs5nzm53DHskjxOXyIr7OhMkov0=.fc2ed9c2-a1c7-4215-be2f-065e3778b628@github.com>

On Tue, 1 Jul 2025 19:54:10 GMT, David Beaumont <duke at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/module/SystemModuleFinders.java line 456:
>> 
>>> 454:             Optional<ImageReader.Node> 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: <VtQlJ_3w2k5ewTVyVele6LRy1j6Vp_N-gZ4K0WJEDzE=.9b4ec980-a8a1-4ed2-8da8-0a1e3e58098d@github.com>
 <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: <VyN6aaJye1o0TOiKAOh8ax1I3Yn6Y7yqSCGuj0KMhRY=.44b4e37e-fb27-458f-bac7-753868027f91@github.com>

On Tue, 1 Jul 2025 18:45:49 GMT, Roger Riggs <rriggs at openjdk.org> 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: <DTjy5tn75B091PzQPau6hp0s3eKh0UUQGUpQQoFLSVM=.06514ff0-fdef-4266-9808-d6f6442afe8a@github.com>
References: <ukODVKiBC1LuwN3hngG_vkkhd1QJO2TpvAUSKsR6Ko0=.43b5a21d-2a39-4ac1-a9de-549abcd72d40@github.com>
 <DTjy5tn75B091PzQPau6hp0s3eKh0UUQGUpQQoFLSVM=.06514ff0-fdef-4266-9808-d6f6442afe8a@github.com>
Message-ID: <RNMCq1cpE34SOYKL6NMAGIEmrA1U-iijRU9sYXqqoYY=.718064dd-8f7a-4806-92da-11d9289917bc@github.com>

On Wed, 25 Jun 2025 09:16:48 GMT, Xiaohong Gong <xgong at openjdk.org> 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: <VtQlJ_3w2k5ewTVyVele6LRy1j6Vp_N-gZ4K0WJEDzE=.9b4ec980-a8a1-4ed2-8da8-0a1e3e58098d@github.com>
References: <VtQlJ_3w2k5ewTVyVele6LRy1j6Vp_N-gZ4K0WJEDzE=.9b4ec980-a8a1-4ed2-8da8-0a1e3e58098d@github.com>
Message-ID: <TRgP-9wiSvLUy3tUX3VilS652k8kz7eDDFcsK5HNPj0=.33c25ed8-3f69-4750-b96b-03a34f22aa04@github.com>

> 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/<module>/<path>` may come from one of two locations in the underlying jimage file; `/<module>/<path>` or `/<module>/META-INF/preview/<path>`. 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: <e0or60hzq9LjzfsBz1tSOInNnC69NTOXWg-b6YUFPkY=.5b3506f1-241e-4a2e-9c58-1a42128b51fd@github.com>

> 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: <SrucQsSsfgGc20BNJYV_4gaDlMYugy1OtqDD8BVrMWM=.bdb4a63b-c29f-476a-80d5-f9c8d4a64d26@github.com>
References: <39KIPIXZDBI9tpPyXew2Ye-uzPvkLSQnOzGJFuK9E2Y=.dc8df88f-f21a-4dd6-8297-5629098bd408@github.com>
 <SrucQsSsfgGc20BNJYV_4gaDlMYugy1OtqDD8BVrMWM=.bdb4a63b-c29f-476a-80d5-f9c8d4a64d26@github.com>
Message-ID: <RCEF2vIkhHrr7xJMZ8BMFzUEVCcvUxeK9PXBgba3puQ=.a1e8ba1e-d238-40be-b95a-01617b91dbe5@github.com>

On Fri, 27 Jun 2025 19:06:22 GMT, Roger Riggs <rriggs at openjdk.org> 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: <k-sV5p2PH-mOW5iO5bjVK3Poi_h1rUzH6OEKiXhHAHQ=.ccaf23b2-903b-4847-a26b-7e2e4a47ef7b@github.com>
References: <k-sV5p2PH-mOW5iO5bjVK3Poi_h1rUzH6OEKiXhHAHQ=.ccaf23b2-903b-4847-a26b-7e2e4a47ef7b@github.com>
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: <k-sV5p2PH-mOW5iO5bjVK3Poi_h1rUzH6OEKiXhHAHQ=.ccaf23b2-903b-4847-a26b-7e2e4a47ef7b@github.com>
 <A1gPk7gsSnZ_947EFmBjljC7sDkbvC18DXCnoZHWSmY=.66b1501a-9e4d-4727-836e-0543fbfe5120@github.com>
 <u6xKM6nWIWia3wHIYFyNSRUwOUFy8gN7gapYUof7Ces=.7a657899-51d4-4fca-a47c-b8928baf6531@github.com>
 <3StfS2-72iIkuHlf9HpzfC-BNoD4kDEjHY2esUnPKEM=.f7ae323f-5313-445b-bd7d-89f6743974f3@github.com>
Message-ID: <z1xKrQxCHpjTwWRnW7LOK7X162TKDwsEhoalsCtOQP8=.02de31d3-0a37-40f9-91aa-ac2819418ec9@github.com>

On Tue, 1 Jul 2025 15:10:10 GMT, Brian Burkhalter <bpb at openjdk.org> 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: <xyO_-BA4dkZeDIWy-sxviKYtXpMNkk8Fq4vtgim0nHY=.d6f776ba-5b56-4218-b3a5-173165c4a6ac@github.com>
References: <k-sV5p2PH-mOW5iO5bjVK3Poi_h1rUzH6OEKiXhHAHQ=.ccaf23b2-903b-4847-a26b-7e2e4a47ef7b@github.com>
 <A1gPk7gsSnZ_947EFmBjljC7sDkbvC18DXCnoZHWSmY=.66b1501a-9e4d-4727-836e-0543fbfe5120@github.com>
 <u6xKM6nWIWia3wHIYFyNSRUwOUFy8gN7gapYUof7Ces=.7a657899-51d4-4fca-a47c-b8928baf6531@github.com>
 <3StfS2-72iIkuHlf9HpzfC-BNoD4kDEjHY2esUnPKEM=.f7ae323f-5313-445b-bd7d-89f6743974f3@github.com>
 <CPYC2MzNDrkaaO8yG4i84hH99ft9pGjjMnhV59J3q-8=.e2436408-a830-4aa5-b4c4-94dd630fab77@github.com>
 <xyO_-BA4dkZeDIWy-sxviKYtXpMNkk8Fq4vtgim0nHY=.d6f776ba-5b56-4218-b3a5-173165c4a6ac@github.com>
Message-ID: <m1wnV9nkGRcIcOzsSUlHfPUAx6GU5JphKafWUZFgZdg=.d489bc0c-ba9f-403c-84ed-37db3b37b78d@github.com>

On Tue, 1 Jul 2025 19:17:17 GMT, Roger Riggs <rriggs at openjdk.org> 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: <OOcrr-XrT-N783zTSoPF70AaZPoDlogN7Sck9p-N9nw=.98f4c5e8-fafd-48df-834b-cbb6f4bfe771@github.com>
References: <OOcrr-XrT-N783zTSoPF70AaZPoDlogN7Sck9p-N9nw=.98f4c5e8-fafd-48df-834b-cbb6f4bfe771@github.com>
Message-ID: <F0tob98Jk0e_a4uOwRdACwHjyXLwcC2lsn43GiixIOg=.a354dbf6-6ad3-41af-bcff-4d049702d931@github.com>

> 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 <clinit> 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: <OOcrr-XrT-N783zTSoPF70AaZPoDlogN7Sck9p-N9nw=.98f4c5e8-fafd-48df-834b-cbb6f4bfe771@github.com>
References: <OOcrr-XrT-N783zTSoPF70AaZPoDlogN7Sck9p-N9nw=.98f4c5e8-fafd-48df-834b-cbb6f4bfe771@github.com>
Message-ID: <Ptk9-MEFmYkywuQ2G2tz2dCTdKlKZg-szX8fRrIkjb4=.292ec19d-ee2b-4936-8926-1c3ca4a465e4@github.com>

> 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 <clinit> 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: <F0tob98Jk0e_a4uOwRdACwHjyXLwcC2lsn43GiixIOg=.a354dbf6-6ad3-41af-bcff-4d049702d931@github.com>
References: <OOcrr-XrT-N783zTSoPF70AaZPoDlogN7Sck9p-N9nw=.98f4c5e8-fafd-48df-834b-cbb6f4bfe771@github.com>
 <F0tob98Jk0e_a4uOwRdACwHjyXLwcC2lsn43GiixIOg=.a354dbf6-6ad3-41af-bcff-4d049702d931@github.com>
Message-ID: <gMjLTwD4DFZxwbtzqPuAPG_iwKql4n_xpFddnwjcaio=.a8fca49f-f5d9-4449-845d-c388b6dac7dd@github.com>

On Tue, 1 Jul 2025 23:03:32 GMT, Chen Liang <liach at openjdk.org> 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 <clinit> 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: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
Message-ID: <ufWpflFhdrPm4cpC-J2_5GYBXqeZoNnOd7NWZMLCc5U=.e2abe1f8-1f0c-4e54-8fbc-9c493cd99887@github.com>

> 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: <wShFgP1f2myBNCuyVnLXYiB1PEBQlkW5VcyIDmyeoRo=.fff71539-455b-4109-8f9c-81c2e16d0bc0@github.com>

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: <deSQhnZdKGRlBTETYyrUUWbCVQI2b1i5SI_sJh2Ro0o=.e17a7757-abd1-44e2-b690-b2a016ce5578@github.com>
References: <deSQhnZdKGRlBTETYyrUUWbCVQI2b1i5SI_sJh2Ro0o=.e17a7757-abd1-44e2-b690-b2a016ce5578@github.com>
Message-ID: <XXEYm-onXrmDdR2pGD0NRAMJmrHH1F3StolEKM-XyJ8=.610d04bb-9684-462a-8050-51e8fabd7a75@github.com>

On Tue, 1 Jul 2025 11:48:30 GMT, Jaikiran Pai <jpai at openjdk.org> 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: <deSQhnZdKGRlBTETYyrUUWbCVQI2b1i5SI_sJh2Ro0o=.e17a7757-abd1-44e2-b690-b2a016ce5578@github.com>
References: <deSQhnZdKGRlBTETYyrUUWbCVQI2b1i5SI_sJh2Ro0o=.e17a7757-abd1-44e2-b690-b2a016ce5578@github.com>
Message-ID: <Oe2Lc5sDmKrkIlDm0JMDwNZlQ6glAQg6QCCL3U3iW1A=.13332a8f-e954-4ba9-8fce-b69d4df29405@github.com>

On Tue, 1 Jul 2025 11:48:30 GMT, Jaikiran Pai <jpai at openjdk.org> 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 <jpai at openjdk.org>
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: <onQhCJUNZnTjjL_w5-SF4AMQxkyDiLmQEfIYmO1_3aw=.114c12cd-b577-4d69-89a9-4beea56a35a1@github.com>
References: <ukODVKiBC1LuwN3hngG_vkkhd1QJO2TpvAUSKsR6Ko0=.43b5a21d-2a39-4ac1-a9de-549abcd72d40@github.com>
 <DTjy5tn75B091PzQPau6hp0s3eKh0UUQGUpQQoFLSVM=.06514ff0-fdef-4266-9808-d6f6442afe8a@github.com>
 <onQhCJUNZnTjjL_w5-SF4AMQxkyDiLmQEfIYmO1_3aw=.114c12cd-b577-4d69-89a9-4beea56a35a1@github.com>
Message-ID: <ImOVwSUN4QJIyz7QACAltEr2IBpPrqt3uG4ePZ-ARwk=.9911135e-4bd4-410d-8699-ac1d8e7b94e8@github.com>

On Tue, 1 Jul 2025 18:03:33 GMT, Paul Sandoz <psandoz at openjdk.org> 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: <RNMCq1cpE34SOYKL6NMAGIEmrA1U-iijRU9sYXqqoYY=.718064dd-8f7a-4806-92da-11d9289917bc@github.com>
References: <ukODVKiBC1LuwN3hngG_vkkhd1QJO2TpvAUSKsR6Ko0=.43b5a21d-2a39-4ac1-a9de-549abcd72d40@github.com>
 <DTjy5tn75B091PzQPau6hp0s3eKh0UUQGUpQQoFLSVM=.06514ff0-fdef-4266-9808-d6f6442afe8a@github.com>
 <RNMCq1cpE34SOYKL6NMAGIEmrA1U-iijRU9sYXqqoYY=.718064dd-8f7a-4806-92da-11d9289917bc@github.com>
Message-ID: <7GrGfBF_v8F0v02sRHC78ofMZwpMdzQZaHeYlNvi_N0=.93defb9e-ca9b-41b4-8722-1746692e2316@github.com>

On Tue, 1 Jul 2025 21:30:20 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> 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: <LQRWbokCOzo8paB0R3JzFrXWVt5mxyGpU1Xe5rTuN4Q=.a7affe6d-82e2-4115-866e-348acbe4d7f7@github.com>
References: <LQRWbokCOzo8paB0R3JzFrXWVt5mxyGpU1Xe5rTuN4Q=.a7affe6d-82e2-4115-866e-348acbe4d7f7@github.com>
Message-ID: <hj1RBa6pRSFl5-jrRAYrgfkBOEaIRt-kfBQo1g7z6ew=.8f322947-699f-4c77-a349-689a4689f0c0@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 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: <LQRWbokCOzo8paB0R3JzFrXWVt5mxyGpU1Xe5rTuN4Q=.a7affe6d-82e2-4115-866e-348acbe4d7f7@github.com>
References: <LQRWbokCOzo8paB0R3JzFrXWVt5mxyGpU1Xe5rTuN4Q=.a7affe6d-82e2-4115-866e-348acbe4d7f7@github.com>
Message-ID: <0PdYt-pCobM5mAb4q3nDcR9PKz89QVFCsZF-jnMAv4Q=.6a5d9f1f-8b68-448c-ab72-2f7f4a12322e@github.com>

On Tue, 1 Jul 2025 05:59:15 GMT, Xiaohong Gong <xgong at openjdk.org> 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: <CABe8uE0KYeZnYP-fkmqt4pJ2JvBsdWANWw9MHgYyPjNQaF4YtA@mail.gmail.com>

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 <openjdk at icemanx.nl> 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: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250701/14c09656/attachment.htm>

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: <Ptk9-MEFmYkywuQ2G2tz2dCTdKlKZg-szX8fRrIkjb4=.292ec19d-ee2b-4936-8926-1c3ca4a465e4@github.com>
References: <OOcrr-XrT-N783zTSoPF70AaZPoDlogN7Sck9p-N9nw=.98f4c5e8-fafd-48df-834b-cbb6f4bfe771@github.com>
 <Ptk9-MEFmYkywuQ2G2tz2dCTdKlKZg-szX8fRrIkjb4=.292ec19d-ee2b-4936-8926-1c3ca4a465e4@github.com>
Message-ID: <zNTenn94yr_Ruz4DFtqDypghzxYdUBH_fLOn3wEw0bw=.e00d37ae-7173-45d6-8999-5915274b8904@github.com>

On Tue, 1 Jul 2025 23:20:59 GMT, Chen Liang <liach at openjdk.org> 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 <clinit> 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 `<clinit>`. 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 `<clinit>` 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 <S> 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: <auWyrAL5ho15wQP2N_HuYddrvIV4v5xMuQI2tzuu7eo=.f1746ff5-d12b-4f98-9d6a-ac634521698b@github.com>
References: <8yqi3J3JfLa2NNags9waBIshIMIuOJRjm-rHF--Wjws=.d04990af-5fdb-4218-a8da-60bda679b1d1@github.com>
 <zvTr0TD3ifqR9ew19jxJ5Ycu0eDkW-k7sghFFJuNOZQ=.cdaec567-c7a4-4046-bf92-79cf49170b7b@github.com>
 <auWyrAL5ho15wQP2N_HuYddrvIV4v5xMuQI2tzuu7eo=.f1746ff5-d12b-4f98-9d6a-ac634521698b@github.com>
Message-ID: <c2EHqmjj476jofNrOQRW2wiCCoH6TZZyuvvu6vtsUZg=.75724145-15c8-4fcb-9cf1-aebd182566ff@github.com>

On Tue, 1 Jul 2025 15:41:45 GMT, Alan Bateman <alanb at openjdk.org> 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: <FmP9p94joz0UZx-X4ijp-ssEuOP5866kdRKiu1scKH8=.994d9c2d-781f-481f-930b-18c4a5cc1621@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <kndznJZZH6s5fbZh3SdLr99uyypWihLc5VTVgvYJ-4o=.55af7211-1f2e-45a4-ab2e-33bfa87565d9@github.com>
 <FmP9p94joz0UZx-X4ijp-ssEuOP5866kdRKiu1scKH8=.994d9c2d-781f-481f-930b-18c4a5cc1621@github.com>
Message-ID: <uRSzkyhm2D_k01pbaWu6AMNNsjGxZcEb-UpW1pK7o2A=.69facb94-d35f-4867-af93-8769cd986288@github.com>

On Fri, 27 Jun 2025 13:21:12 GMT, Daniel Fuchs <dfuchs at openjdk.org> 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: <zNTenn94yr_Ruz4DFtqDypghzxYdUBH_fLOn3wEw0bw=.e00d37ae-7173-45d6-8999-5915274b8904@github.com>
References: <OOcrr-XrT-N783zTSoPF70AaZPoDlogN7Sck9p-N9nw=.98f4c5e8-fafd-48df-834b-cbb6f4bfe771@github.com>
 <Ptk9-MEFmYkywuQ2G2tz2dCTdKlKZg-szX8fRrIkjb4=.292ec19d-ee2b-4936-8926-1c3ca4a465e4@github.com>
 <zNTenn94yr_Ruz4DFtqDypghzxYdUBH_fLOn3wEw0bw=.e00d37ae-7173-45d6-8999-5915274b8904@github.com>
Message-ID: <l_7ON-G75qTVp_t6EiROraHT3cKb54lae1CVJ8B6OjI=.1e8aa9ec-30a8-4583-98de-972bc8403cf4@github.com>

On Wed, 2 Jul 2025 04:38:50 GMT, Ioi Lam <iklam at openjdk.org> 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 <S> 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: <Ptk9-MEFmYkywuQ2G2tz2dCTdKlKZg-szX8fRrIkjb4=.292ec19d-ee2b-4936-8926-1c3ca4a465e4@github.com>
References: <OOcrr-XrT-N783zTSoPF70AaZPoDlogN7Sck9p-N9nw=.98f4c5e8-fafd-48df-834b-cbb6f4bfe771@github.com>
 <Ptk9-MEFmYkywuQ2G2tz2dCTdKlKZg-szX8fRrIkjb4=.292ec19d-ee2b-4936-8926-1c3ca4a465e4@github.com>
Message-ID: <wK838xbUHK6qkiOmWYDANgi2B7e3o0OJ9OqyRmRGqlg=.60983c58-d1c2-4494-9115-f18d39adeccf@github.com>

On Tue, 1 Jul 2025 23:20:59 GMT, Chen Liang <liach at openjdk.org> 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 <clinit> 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: <hj1RBa6pRSFl5-jrRAYrgfkBOEaIRt-kfBQo1g7z6ew=.8f322947-699f-4c77-a349-689a4689f0c0@github.com>
References: <LQRWbokCOzo8paB0R3JzFrXWVt5mxyGpU1Xe5rTuN4Q=.a7affe6d-82e2-4115-866e-348acbe4d7f7@github.com>
 <hj1RBa6pRSFl5-jrRAYrgfkBOEaIRt-kfBQo1g7z6ew=.8f322947-699f-4c77-a349-689a4689f0c0@github.com>
Message-ID: <nXeQ9sxgQlJRStSMNhlRD-j_OL89YUgBZfXM_3yuTuQ=.3c768f41-93aa-4e16-b193-5ca703b27f81@github.com>

On Wed, 2 Jul 2025 02:39:33 GMT, Xiaohong Gong <xgong at openjdk.org> 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: <ukODVKiBC1LuwN3hngG_vkkhd1QJO2TpvAUSKsR6Ko0=.43b5a21d-2a39-4ac1-a9de-549abcd72d40@github.com>
 <DTjy5tn75B091PzQPau6hp0s3eKh0UUQGUpQQoFLSVM=.06514ff0-fdef-4266-9808-d6f6442afe8a@github.com>
 <RNMCq1cpE34SOYKL6NMAGIEmrA1U-iijRU9sYXqqoYY=.718064dd-8f7a-4806-92da-11d9289917bc@github.com>
 <7GrGfBF_v8F0v02sRHC78ofMZwpMdzQZaHeYlNvi_N0=.93defb9e-ca9b-41b4-8722-1746692e2316@github.com>
Message-ID: <SVfjXyK_qMEFq2tTBjWIckdjhNuq4vTT-afYlxKG3Fk=.7de6f1bb-c747-4474-ad8f-d4581266acd1@github.com>

On Wed, 2 Jul 2025 01:52:19 GMT, Xiaohong Gong <xgong at openjdk.org> 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: <QPSnXfmDTCKVY47Oh3GplxNEWrpJdvuwXKxz9lvxKSY=.8e5f77ea-1055-4830-9003-cce673330897@github.com>
References: <VtQlJ_3w2k5ewTVyVele6LRy1j6Vp_N-gZ4K0WJEDzE=.9b4ec980-a8a1-4ed2-8da8-0a1e3e58098d@github.com>
 <QPSnXfmDTCKVY47Oh3GplxNEWrpJdvuwXKxz9lvxKSY=.8e5f77ea-1055-4830-9003-cce673330897@github.com>
Message-ID: <_pByqz5D9z7RxpOx3JcGEwMsZ6qbW5BtE7FNb-liazQ=.c8b05e3a-13dd-4af4-9b64-2e9bae1cc40f@github.com>

On Tue, 1 Jul 2025 14:29:51 GMT, Alan Bateman <alanb at openjdk.org> 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: <nnLiULvlgT9T3NE_bVbt1wOrepPdbNtHfy20P5UtPLE=.8c7c120e-fb4e-49c8-8c39-80506f3b8980@github.com>
References: <VtQlJ_3w2k5ewTVyVele6LRy1j6Vp_N-gZ4K0WJEDzE=.9b4ec980-a8a1-4ed2-8da8-0a1e3e58098d@github.com>
 <nnLiULvlgT9T3NE_bVbt1wOrepPdbNtHfy20P5UtPLE=.8c7c120e-fb4e-49c8-8c39-80506f3b8980@github.com>
Message-ID: <vpdratnOtsBDeN1rev_dCSRjaf3qMAloIHTpTIILLh0=.e95cdcd5-6e2e-4a67-9f86-25ddd5f3c686@github.com>

On Tue, 1 Jul 2025 18:30:56 GMT, Roger Riggs <rriggs at openjdk.org> 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: <VtQlJ_3w2k5ewTVyVele6LRy1j6Vp_N-gZ4K0WJEDzE=.9b4ec980-a8a1-4ed2-8da8-0a1e3e58098d@github.com>
References: <VtQlJ_3w2k5ewTVyVele6LRy1j6Vp_N-gZ4K0WJEDzE=.9b4ec980-a8a1-4ed2-8da8-0a1e3e58098d@github.com>
Message-ID: <qhMSHNWMHoh19_AwKfSzdUDB02U1UoacWlIEZwMHPlg=.de209a23-6c05-475e-a714-fa4decebc51f@github.com>

> 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/<module>/<path>` may come from one of two locations in the underlying jimage file; `/<module>/<path>` or `/<module>/META-INF/preview/<path>`. 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: <wWmD8znj-bwA46ccmxwzDfdHIjLb0Ls3irrN6-o5Scg=.ffc3e9f3-fdc8-4802-b0df-e99d168e6f25@github.com>
References: <VtQlJ_3w2k5ewTVyVele6LRy1j6Vp_N-gZ4K0WJEDzE=.9b4ec980-a8a1-4ed2-8da8-0a1e3e58098d@github.com>
 <wWmD8znj-bwA46ccmxwzDfdHIjLb0Ls3irrN6-o5Scg=.ffc3e9f3-fdc8-4802-b0df-e99d168e6f25@github.com>
Message-ID: <Jhn3vvzylKNuDp4zU5meXUNKJ-vzgp0xOpzkjqak7Pk=.e83ef117-fd75-45ef-be61-407c1f76eb48@github.com>

On Tue, 1 Jul 2025 14:32:41 GMT, ExE Boss <duke at openjdk.org> 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: <TdnuVxqRVlUzZpF7RYlOhMbsiCqssJiCgKNACfVqaJU=.190b4b40-3bad-44cd-abc8-9d436b2d3a47@github.com>
References: <tG3KsNaA8iDVdZRT-MGKvy8uViCna0ZUJ939oJsilj0=.a12f0cc9-4e47-4fb8-92d4-291c8f211790@github.com>
 <TdnuVxqRVlUzZpF7RYlOhMbsiCqssJiCgKNACfVqaJU=.190b4b40-3bad-44cd-abc8-9d436b2d3a47@github.com>
Message-ID: <iAqmPO_vPpWwODDCQ52zwJ_1Y-ICEBFrjLcgxi2t3wI=.1bb06320-dbbb-425d-adc3-4ee5a4ea8f39@github.com>

On Tue, 1 Jul 2025 00:01:21 GMT, Shaojin Wen <swen at openjdk.org> 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: <ukODVKiBC1LuwN3hngG_vkkhd1QJO2TpvAUSKsR6Ko0=.43b5a21d-2a39-4ac1-a9de-549abcd72d40@github.com>
 <DTjy5tn75B091PzQPau6hp0s3eKh0UUQGUpQQoFLSVM=.06514ff0-fdef-4266-9808-d6f6442afe8a@github.com>
 <RNMCq1cpE34SOYKL6NMAGIEmrA1U-iijRU9sYXqqoYY=.718064dd-8f7a-4806-92da-11d9289917bc@github.com>
 <7GrGfBF_v8F0v02sRHC78ofMZwpMdzQZaHeYlNvi_N0=.93defb9e-ca9b-41b4-8722-1746692e2316@github.com>
Message-ID: <Ogar2jtCWm6qWHewe3L0M02mwXma8FA6Q4xofrIW3tA=.28b0cc65-254a-4174-9cd8-2d52d43d1840@github.com>

On Wed, 2 Jul 2025 01:52:19 GMT, Xiaohong Gong <xgong at openjdk.org> 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: <nXeQ9sxgQlJRStSMNhlRD-j_OL89YUgBZfXM_3yuTuQ=.3c768f41-93aa-4e16-b193-5ca703b27f81@github.com>
References: <LQRWbokCOzo8paB0R3JzFrXWVt5mxyGpU1Xe5rTuN4Q=.a7affe6d-82e2-4115-866e-348acbe4d7f7@github.com>
 <hj1RBa6pRSFl5-jrRAYrgfkBOEaIRt-kfBQo1g7z6ew=.8f322947-699f-4c77-a349-689a4689f0c0@github.com>
 <nXeQ9sxgQlJRStSMNhlRD-j_OL89YUgBZfXM_3yuTuQ=.3c768f41-93aa-4e16-b193-5ca703b27f81@github.com>
Message-ID: <h-04JA1nnLSqhLi-bg-8iv8MUk48PAk_wq0M-Dydw0Y=.67de075c-25cc-4ec1-a073-b8ba22462903@github.com>

On Wed, 2 Jul 2025 08:15:34 GMT, Andrew Haley <aph at openjdk.org> 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: <gICsLXMGVb3M0v0kLYdh_7jee4zl2vXDiOTAtESEcus=.cde0dac5-7170-4ede-9613-3ef5d17e965f@github.com>

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: <TBlXrG7D1XZI1v63sRUcixX1zKfS9yb1rvPXvjqUuqw=.624d2815-18e6-4d78-88cf-5c74abcbd4a7@github.com>
References: <S5QCukHfY9v7DYMWyRaUlJPGjPrYWcVV5eMlknezS78=.84a5f517-bcbf-4f2f-801d-5768e5456c2c@github.com>
 <4b4eB1IhNlZXMVqf-aOj-IIp3kwLiqOVfeqioc2dL9Q=.8af3f74b-7b61-424a-b2c6-421fa6e0c0e6@github.com>
 <SM51sfCBxdd5DUJm7EJGGBzGA-IzlX4QSA4qXVS3UJk=.cf6cb877-1703-4fdf-b02e-f87a27e1d77b@github.com>
 <Jxnfqiwb79xkySdKYFiZrXammdV53SSqGikeBO2g-0s=.6b47f449-e71e-431c-a361-f2604300a757@github.com>
 <TBlXrG7D1XZI1v63sRUcixX1zKfS9yb1rvPXvjqUuqw=.624d2815-18e6-4d78-88cf-5c74abcbd4a7@github.com>
Message-ID: <FCJXQ8VBPsuM_sLPAkb5MLutPi34oRncrt1PQmuAahE=.fdd8f726-f7d6-4c5a-8d10-52097c5d45ef@github.com>

On Tue, 1 Jul 2025 15:20:07 GMT, Jaikiran Pai <jpai at openjdk.org> 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: <FCJXQ8VBPsuM_sLPAkb5MLutPi34oRncrt1PQmuAahE=.fdd8f726-f7d6-4c5a-8d10-52097c5d45ef@github.com>
References: <S5QCukHfY9v7DYMWyRaUlJPGjPrYWcVV5eMlknezS78=.84a5f517-bcbf-4f2f-801d-5768e5456c2c@github.com>
 <4b4eB1IhNlZXMVqf-aOj-IIp3kwLiqOVfeqioc2dL9Q=.8af3f74b-7b61-424a-b2c6-421fa6e0c0e6@github.com>
 <SM51sfCBxdd5DUJm7EJGGBzGA-IzlX4QSA4qXVS3UJk=.cf6cb877-1703-4fdf-b02e-f87a27e1d77b@github.com>
 <Jxnfqiwb79xkySdKYFiZrXammdV53SSqGikeBO2g-0s=.6b47f449-e71e-431c-a361-f2604300a757@github.com>
 <TBlXrG7D1XZI1v63sRUcixX1zKfS9yb1rvPXvjqUuqw=.624d2815-18e6-4d78-88cf-5c74abcbd4a7@github.com>
 <FCJXQ8VBPsuM_sLPAkb5MLutPi34oRncrt1PQmuAahE=.fdd8f726-f7d6-4c5a-8d10-52097c5d45ef@github.com>
Message-ID: <ONnqwVmTHDsT9ZUmvL050UJ3GTaeCvubIOL42q3B3sY=.be05ccc3-be10-4ac6-b2e5-ca10cd4974a4@github.com>

On Wed, 2 Jul 2025 09:52:54 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> 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: <qhMSHNWMHoh19_AwKfSzdUDB02U1UoacWlIEZwMHPlg=.de209a23-6c05-475e-a714-fa4decebc51f@github.com>
References: <VtQlJ_3w2k5ewTVyVele6LRy1j6Vp_N-gZ4K0WJEDzE=.9b4ec980-a8a1-4ed2-8da8-0a1e3e58098d@github.com>
 <qhMSHNWMHoh19_AwKfSzdUDB02U1UoacWlIEZwMHPlg=.de209a23-6c05-475e-a714-fa4decebc51f@github.com>
Message-ID: <bmksLz07523CnkepHd3D9_FMvk7OIRJcdKH9y22Ej0U=.373dcaff-1960-46c2-9b20-ab7e369b7796@github.com>

On Wed, 2 Jul 2025 08:38:40 GMT, David Beaumont <duke at openjdk.org> 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/<module>/<path>` may come from one of two locations in the underlying jimage file; `/<module>/<path>` or `/<module>/META-INF/preview/<path>`. 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: <S5QCukHfY9v7DYMWyRaUlJPGjPrYWcVV5eMlknezS78=.84a5f517-bcbf-4f2f-801d-5768e5456c2c@github.com>
References: <S5QCukHfY9v7DYMWyRaUlJPGjPrYWcVV5eMlknezS78=.84a5f517-bcbf-4f2f-801d-5768e5456c2c@github.com>
Message-ID: <SEeLR7q5esN7pY2Cd4UII2An5CGJgXmibJDbyvzUf20=.021808fe-63f9-4ad2-8dfc-041f0cc7fb5c@github.com>

> 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: <S5QCukHfY9v7DYMWyRaUlJPGjPrYWcVV5eMlknezS78=.84a5f517-bcbf-4f2f-801d-5768e5456c2c@github.com>
References: <S5QCukHfY9v7DYMWyRaUlJPGjPrYWcVV5eMlknezS78=.84a5f517-bcbf-4f2f-801d-5768e5456c2c@github.com>
Message-ID: <RHNU92CJDovEvgJPNn0BzO_pFCWkP8aKKJbk3y3nS_A=.9599078c-3982-4cdf-9ee8-cd807b9f743c@github.com>

> 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: <HVGEzq_9ymkhHqT75nSGUyxoumvb-PggKtBNW3NckWM=.9eaadefc-b396-4b95-b276-219d2a0d3590@github.com>

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: <HVGEzq_9ymkhHqT75nSGUyxoumvb-PggKtBNW3NckWM=.9eaadefc-b396-4b95-b276-219d2a0d3590@github.com>
References: <HVGEzq_9ymkhHqT75nSGUyxoumvb-PggKtBNW3NckWM=.9eaadefc-b396-4b95-b276-219d2a0d3590@github.com>
Message-ID: <MM4XxxtnOe4wxMUppPytCUVJ07UrOr0Dx9ZisiIfc8Q=.cf5e0430-cd14-4292-98fb-e431f0139fee@github.com>

On Wed, 2 Jul 2025 11:00:44 GMT, Manuel H?ssig <mhaessig at openjdk.org> 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: <HVGEzq_9ymkhHqT75nSGUyxoumvb-PggKtBNW3NckWM=.9eaadefc-b396-4b95-b276-219d2a0d3590@github.com>
References: <HVGEzq_9ymkhHqT75nSGUyxoumvb-PggKtBNW3NckWM=.9eaadefc-b396-4b95-b276-219d2a0d3590@github.com>
Message-ID: <7TBGrTc8gKqAJfXiXhNBhXLFkWVFF0KQkJnMpN7e1Po=.d9ece700-fe5a-4c35-baa5-9ab4e4f586d2@github.com>

On Wed, 2 Jul 2025 11:00:44 GMT, Manuel H?ssig <mhaessig at openjdk.org> 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: <qhMSHNWMHoh19_AwKfSzdUDB02U1UoacWlIEZwMHPlg=.de209a23-6c05-475e-a714-fa4decebc51f@github.com>
References: <VtQlJ_3w2k5ewTVyVele6LRy1j6Vp_N-gZ4K0WJEDzE=.9b4ec980-a8a1-4ed2-8da8-0a1e3e58098d@github.com>
 <qhMSHNWMHoh19_AwKfSzdUDB02U1UoacWlIEZwMHPlg=.de209a23-6c05-475e-a714-fa4decebc51f@github.com>
Message-ID: <rBWUsTDTSeBQttPxZBDddaw5l0rK1UF5IqbonTegWHU=.d6f431f2-992e-4a42-bb22-abaf84148808@github.com>

On Wed, 2 Jul 2025 08:38:40 GMT, David Beaumont <duke at openjdk.org> 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/<module>/<path>` may come from one of two locations in the underlying jimage file; `/<module>/<path>` or `/<module>/META-INF/preview/<path>`. 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: <e0or60hzq9LjzfsBz1tSOInNnC69NTOXWg-b6YUFPkY=.5b3506f1-241e-4a2e-9c58-1a42128b51fd@github.com>
References: <39KIPIXZDBI9tpPyXew2Ye-uzPvkLSQnOzGJFuK9E2Y=.dc8df88f-f21a-4dd6-8297-5629098bd408@github.com>
 <e0or60hzq9LjzfsBz1tSOInNnC69NTOXWg-b6YUFPkY=.5b3506f1-241e-4a2e-9c58-1a42128b51fd@github.com>
Message-ID: <Bnon1dMgybFkble5Y2DlHXJXzoUEhspBcnWEQ_tRrEg=.8962d8de-f6ef-49ce-a287-fd42cbb873ce@github.com>

On Tue, 1 Jul 2025 22:30:57 GMT, Roger Riggs <rriggs at openjdk.org> 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:  * <p>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: <qhMSHNWMHoh19_AwKfSzdUDB02U1UoacWlIEZwMHPlg=.de209a23-6c05-475e-a714-fa4decebc51f@github.com>
References: <VtQlJ_3w2k5ewTVyVele6LRy1j6Vp_N-gZ4K0WJEDzE=.9b4ec980-a8a1-4ed2-8da8-0a1e3e58098d@github.com>
 <qhMSHNWMHoh19_AwKfSzdUDB02U1UoacWlIEZwMHPlg=.de209a23-6c05-475e-a714-fa4decebc51f@github.com>
Message-ID: <SLjsfTsSAPMEmzHKusOPjvL2njrbpeMGSnWL4KF7sVA=.60e2c95a-8aa3-4b9b-9b95-55772d46e120@github.com>

On Wed, 2 Jul 2025 08:38:40 GMT, David Beaumont <duke at openjdk.org> 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/<module>/<path>` may come from one of two locations in the underlying jimage file; `/<module>/<path>` or `/<module>/META-INF/preview/<path>`. 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<ImageReader.Node> 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: <e0or60hzq9LjzfsBz1tSOInNnC69NTOXWg-b6YUFPkY=.5b3506f1-241e-4a2e-9c58-1a42128b51fd@github.com>
References: <39KIPIXZDBI9tpPyXew2Ye-uzPvkLSQnOzGJFuK9E2Y=.dc8df88f-f21a-4dd6-8297-5629098bd408@github.com>
 <e0or60hzq9LjzfsBz1tSOInNnC69NTOXWg-b6YUFPkY=.5b3506f1-241e-4a2e-9c58-1a42128b51fd@github.com>
Message-ID: <K9150uSS8YBL5q9ZLn1-7KVJYO38wY7jVUeztX3vAcs=.40f8c201-6798-47b1-b794-70bedd911305@github.com>

On Tue, 1 Jul 2025 22:30:57 GMT, Roger Riggs <rriggs at openjdk.org> 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: <e0or60hzq9LjzfsBz1tSOInNnC69NTOXWg-b6YUFPkY=.5b3506f1-241e-4a2e-9c58-1a42128b51fd@github.com>
References: <39KIPIXZDBI9tpPyXew2Ye-uzPvkLSQnOzGJFuK9E2Y=.dc8df88f-f21a-4dd6-8297-5629098bd408@github.com>
 <e0or60hzq9LjzfsBz1tSOInNnC69NTOXWg-b6YUFPkY=.5b3506f1-241e-4a2e-9c58-1a42128b51fd@github.com>
Message-ID: <NY9b_JY8bxJpr9-3K4GZ-Wq3kR7o1uxlHATQ4vFo12o=.0f478191-d74a-469a-bfbb-47a021d46090@github.com>

On Tue, 1 Jul 2025 22:30:57 GMT, Roger Riggs <rriggs at openjdk.org> 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: <e0or60hzq9LjzfsBz1tSOInNnC69NTOXWg-b6YUFPkY=.5b3506f1-241e-4a2e-9c58-1a42128b51fd@github.com>
References: <39KIPIXZDBI9tpPyXew2Ye-uzPvkLSQnOzGJFuK9E2Y=.dc8df88f-f21a-4dd6-8297-5629098bd408@github.com>
 <e0or60hzq9LjzfsBz1tSOInNnC69NTOXWg-b6YUFPkY=.5b3506f1-241e-4a2e-9c58-1a42128b51fd@github.com>
Message-ID: <5aV_LR8YAhidGNtBlf5quqj9CoyqPSGg9uzNKy5j8ZQ=.115a3aef-ba2e-4840-bf88-0b45515f6f5f@github.com>

On Tue, 1 Jul 2025 22:30:57 GMT, Roger Riggs <rriggs at openjdk.org> 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:
<img width="1107" alt="javadoc" src="https://github.com/user-attachments/assets/437a37e3-5fbb-43f0-b4d1-ba49ef3a5bb8" />

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: <k-sV5p2PH-mOW5iO5bjVK3Poi_h1rUzH6OEKiXhHAHQ=.ccaf23b2-903b-4847-a26b-7e2e4a47ef7b@github.com>
 <mvYiykBBbpm9DW6eHvxjh0oqO84BxtvYuFhYIAhGHio=.5696740e-d66a-4427-8ff2-7d00a0c42b6f@github.com>
 <vCNI3BZO2Ej0swvMtDO4Kl0AzPnfQpAxVtKeCXEc7ek=.4f37c8ec-c72a-4bf4-a79f-bc6fe41ac40b@github.com>
 <49BAIrPYEOTuF3SDhHxtF3KLg-9N3YmkKp5Z0BGgMmw=.8105cebd-bc10-4de3-b6cb-81b00692fdb6@github.com>
Message-ID: <NZtIPWZj2RwjrZlR_RTFAJfiAc-783QEaE4Gp0-8-hM=.66ea4353-f98e-4cf9-ab6b-94439e9e3346@github.com>

On Fri, 27 Jun 2025 23:00:04 GMT, Brian Burkhalter <bpb at openjdk.org> 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: <VtQlJ_3w2k5ewTVyVele6LRy1j6Vp_N-gZ4K0WJEDzE=.9b4ec980-a8a1-4ed2-8da8-0a1e3e58098d@github.com>
References: <VtQlJ_3w2k5ewTVyVele6LRy1j6Vp_N-gZ4K0WJEDzE=.9b4ec980-a8a1-4ed2-8da8-0a1e3e58098d@github.com>
Message-ID: <xHDzjd4IbbYATwuK9I7oZ35Em3Rr9pfWaG3WOk_3lyk=.005270ef-7dba-459c-a653-8912f105ee6b@github.com>

> 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/<module>/<path>` may come from one of two locations in the underlying jimage file; `/<module>/<path>` or `/<module>/META-INF/preview/<path>`. 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: <rBWUsTDTSeBQttPxZBDddaw5l0rK1UF5IqbonTegWHU=.d6f431f2-992e-4a42-bb22-abaf84148808@github.com>
References: <VtQlJ_3w2k5ewTVyVele6LRy1j6Vp_N-gZ4K0WJEDzE=.9b4ec980-a8a1-4ed2-8da8-0a1e3e58098d@github.com>
 <qhMSHNWMHoh19_AwKfSzdUDB02U1UoacWlIEZwMHPlg=.de209a23-6c05-475e-a714-fa4decebc51f@github.com>
 <rBWUsTDTSeBQttPxZBDddaw5l0rK1UF5IqbonTegWHU=.d6f431f2-992e-4a42-bb22-abaf84148808@github.com>
Message-ID: <68BE8CPkVKjER9mJst7MneY26xg4zOSxaHMFjEmYW4Y=.ea7c6d86-3812-4357-a3c2-656b4d611559@github.com>

On Wed, 2 Jul 2025 12:51:27 GMT, Alan Bateman <alanb at openjdk.org> 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<ImageReader.Node> 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: <TdnuVxqRVlUzZpF7RYlOhMbsiCqssJiCgKNACfVqaJU=.190b4b40-3bad-44cd-abc8-9d436b2d3a47@github.com>
References: <tG3KsNaA8iDVdZRT-MGKvy8uViCna0ZUJ939oJsilj0=.a12f0cc9-4e47-4fb8-92d4-291c8f211790@github.com>
 <TdnuVxqRVlUzZpF7RYlOhMbsiCqssJiCgKNACfVqaJU=.190b4b40-3bad-44cd-abc8-9d436b2d3a47@github.com>
Message-ID: <8eih4k_a1QllWM_vcg81TX0F6_bp8wYJmEP77VoCqT0=.acaceaa8-9203-423b-b6ea-67dbcc61a6a7@github.com>

On Tue, 1 Jul 2025 00:01:21 GMT, Shaojin Wen <swen at openjdk.org> 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: <zH_ARPXC1OqH-rsF_PWjYCEvyqXmYuJ9YG4Yr6dOF0g=.53394867-f33d-470e-a5f0-831df7ff8512@github.com>
References: <39KIPIXZDBI9tpPyXew2Ye-uzPvkLSQnOzGJFuK9E2Y=.dc8df88f-f21a-4dd6-8297-5629098bd408@github.com>
 <zH_ARPXC1OqH-rsF_PWjYCEvyqXmYuJ9YG4Yr6dOF0g=.53394867-f33d-470e-a5f0-831df7ff8512@github.com>
Message-ID: <E8aMjBJdBnHxpCTb-6125Ez1mNJ5K1DdHqPThduSqfY=.da302dcd-22e7-41e2-8120-dd7e9a1b81c6@github.com>

On Fri, 27 Jun 2025 16:23:59 GMT, Jaikiran Pai <jpai at openjdk.org> 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: <EW5g6qGQPHbjKg70_-At6GfzzXXl3sKr3KMeR-SsUoY=.de62c927-1780-4e3f-864c-098d55453a38@github.com>

> 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: <EW5g6qGQPHbjKg70_-At6GfzzXXl3sKr3KMeR-SsUoY=.de62c927-1780-4e3f-864c-098d55453a38@github.com>
References: <39KIPIXZDBI9tpPyXew2Ye-uzPvkLSQnOzGJFuK9E2Y=.dc8df88f-f21a-4dd6-8297-5629098bd408@github.com>
 <EW5g6qGQPHbjKg70_-At6GfzzXXl3sKr3KMeR-SsUoY=.de62c927-1780-4e3f-864c-098d55453a38@github.com>
Message-ID: <16a1bcoBtoC1esI0igaE3bWOjyhhDmNkrUoYbBnNfkA=.ead94479-d75d-48da-9550-e16135cc3b04@github.com>

On Wed, 2 Jul 2025 14:49:01 GMT, Roger Riggs <rriggs at openjdk.org> 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: <K9150uSS8YBL5q9ZLn1-7KVJYO38wY7jVUeztX3vAcs=.40f8c201-6798-47b1-b794-70bedd911305@github.com>
References: <39KIPIXZDBI9tpPyXew2Ye-uzPvkLSQnOzGJFuK9E2Y=.dc8df88f-f21a-4dd6-8297-5629098bd408@github.com>
 <e0or60hzq9LjzfsBz1tSOInNnC69NTOXWg-b6YUFPkY=.5b3506f1-241e-4a2e-9c58-1a42128b51fd@github.com>
 <K9150uSS8YBL5q9ZLn1-7KVJYO38wY7jVUeztX3vAcs=.40f8c201-6798-47b1-b794-70bedd911305@github.com>
Message-ID: <GY-mBgN8S1_Xy4vKYTKgNTNh2hSTt-kxFY-C2dGU634=.40b182c8-ded4-4540-b50a-b7fc5b7d628d@github.com>

On Wed, 2 Jul 2025 13:02:04 GMT, Jaikiran Pai <jpai at openjdk.org> 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: <GY-mBgN8S1_Xy4vKYTKgNTNh2hSTt-kxFY-C2dGU634=.40b182c8-ded4-4540-b50a-b7fc5b7d628d@github.com>
References: <39KIPIXZDBI9tpPyXew2Ye-uzPvkLSQnOzGJFuK9E2Y=.dc8df88f-f21a-4dd6-8297-5629098bd408@github.com>
 <e0or60hzq9LjzfsBz1tSOInNnC69NTOXWg-b6YUFPkY=.5b3506f1-241e-4a2e-9c58-1a42128b51fd@github.com>
 <K9150uSS8YBL5q9ZLn1-7KVJYO38wY7jVUeztX3vAcs=.40f8c201-6798-47b1-b794-70bedd911305@github.com>
 <GY-mBgN8S1_Xy4vKYTKgNTNh2hSTt-kxFY-C2dGU634=.40b182c8-ded4-4540-b50a-b7fc5b7d628d@github.com>
Message-ID: <SkjWk90qlNN7D5eJ7pO1VozLGbTEzqRPrvnn5YJe3Eo=.36a12a94-27fe-462b-89ca-e49f0e2a75cc@github.com>

On Wed, 2 Jul 2025 14:46:20 GMT, Roger Riggs <rriggs at openjdk.org> 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: <TdnuVxqRVlUzZpF7RYlOhMbsiCqssJiCgKNACfVqaJU=.190b4b40-3bad-44cd-abc8-9d436b2d3a47@github.com>
References: <tG3KsNaA8iDVdZRT-MGKvy8uViCna0ZUJ939oJsilj0=.a12f0cc9-4e47-4fb8-92d4-291c8f211790@github.com>
 <TdnuVxqRVlUzZpF7RYlOhMbsiCqssJiCgKNACfVqaJU=.190b4b40-3bad-44cd-abc8-9d436b2d3a47@github.com>
Message-ID: <JuEjPqVLztex6JfoWlroOsG5-rqO1Q1kb0NEORsFanQ=.d7e62b4b-ad51-4537-afa3-d4a7d1156a40@github.com>

On Tue, 1 Jul 2025 00:01:21 GMT, Shaojin Wen <swen at openjdk.org> 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: <TdnuVxqRVlUzZpF7RYlOhMbsiCqssJiCgKNACfVqaJU=.190b4b40-3bad-44cd-abc8-9d436b2d3a47@github.com>
References: <tG3KsNaA8iDVdZRT-MGKvy8uViCna0ZUJ939oJsilj0=.a12f0cc9-4e47-4fb8-92d4-291c8f211790@github.com>
 <TdnuVxqRVlUzZpF7RYlOhMbsiCqssJiCgKNACfVqaJU=.190b4b40-3bad-44cd-abc8-9d436b2d3a47@github.com>
Message-ID: <iiYPhhUbTroTfy-WVFFn0cA_Bi4mSgz6NRxZ0X11IEM=.b597e2be-dfd8-4c53-86f9-7b7828c79338@github.com>

On Tue, 1 Jul 2025 00:01:21 GMT, Shaojin Wen <swen at openjdk.org> 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: <OOcrr-XrT-N783zTSoPF70AaZPoDlogN7Sck9p-N9nw=.98f4c5e8-fafd-48df-834b-cbb6f4bfe771@github.com>
References: <OOcrr-XrT-N783zTSoPF70AaZPoDlogN7Sck9p-N9nw=.98f4c5e8-fafd-48df-834b-cbb6f4bfe771@github.com>
Message-ID: <r4zh-c_X_ZO_wCBcs5y3MGHBg3j9sjrfD-oZZKKYeCI=.54998a86-63e6-41de-a4f5-e3175be9b116@github.com>

> 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 <clinit> 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: <l_7ON-G75qTVp_t6EiROraHT3cKb54lae1CVJ8B6OjI=.1e8aa9ec-30a8-4583-98de-972bc8403cf4@github.com>
References: <OOcrr-XrT-N783zTSoPF70AaZPoDlogN7Sck9p-N9nw=.98f4c5e8-fafd-48df-834b-cbb6f4bfe771@github.com>
 <Ptk9-MEFmYkywuQ2G2tz2dCTdKlKZg-szX8fRrIkjb4=.292ec19d-ee2b-4936-8926-1c3ca4a465e4@github.com>
 <zNTenn94yr_Ruz4DFtqDypghzxYdUBH_fLOn3wEw0bw=.e00d37ae-7173-45d6-8999-5915274b8904@github.com>
 <l_7ON-G75qTVp_t6EiROraHT3cKb54lae1CVJ8B6OjI=.1e8aa9ec-30a8-4583-98de-972bc8403cf4@github.com>
Message-ID: <4OZnYKuL_IAwNtwQZqs4LkoWGKfhKr3-_n6AVVe3Jm4=.b10c26b4-65f7-4f90-bd21-68ae3a4bad05@github.com>

On Wed, 2 Jul 2025 07:48:05 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/invoke/ClassSpecializer.java line 68:
>> 
>>> 66:  * @param <S> 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: <KO-d2RLH061W_VBdFFmGqhF-0XDwAKLyETFHa7kqAQI=.b29c8b91-0128-44b6-86d8-879f79076434@github.com>
References: <IPodt6KjRH75edJJjXja5g9wqH4oY6-EouV4Xn5SWeU=.21e726f3-7dae-47ad-9b3a-9f3118fedbda@github.com>
 <KO-d2RLH061W_VBdFFmGqhF-0XDwAKLyETFHa7kqAQI=.b29c8b91-0128-44b6-86d8-879f79076434@github.com>
Message-ID: <0UfkXxOmp7jsEH0cPOPBDoh8osWoz6Jp6A8jLh-CmDE=.57a3938f-ba6d-48ee-9caf-ecd3c10678cb@github.com>

On Mon, 23 Jun 2025 23:09:13 GMT, simon <duke at openjdk.org> 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
>> <details><summary>Using <code>git</code></summary>
>> 
>> 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`
>> 
>> </details>
>> <details><summary>Using Skara CLI tools</summary>
>> 
>> Checkout this PR locally: \
>> `$ git pr checkout 25925`
>> 
>> View PR using the GUI difftool: \
>> `$ git pr show -t 25925`
>> 
>> </details>
>> <details><summary>Using diff file</summary>
>> 
>> Download this PR as a diff file: \
>> <a href="https://git.openjdk.org/jdk/pull/25925.diff">https://git.openjdk.org/jdk/pull/25925.diff</a>
>> 
>> </details>
>> <details><summary>Using Webrev</summary>
>> 
>> [Link to Webrev Comment](https://git.openjdk.org/jdk/pull/25925#issuecomment-2993856738)
>> </details>
>
> 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: <SJ2PR10MB7669FEA3948E934C7EB92B7AA241A@SJ2PR10MB7669.namprd10.prod.outlook.com>
References: <CANBJVOFRV0drYo0DcumwZYGavzNLquhjKijmoXjzNpc4k89Yrg@mail.gmail.com>
 <SJ2PR10MB7669FEA3948E934C7EB92B7AA241A@SJ2PR10MB7669.namprd10.prod.outlook.com>
Message-ID: <CANBJVOF=Vr3qOosxsYHc+8jfz5uxiB9tYqVheWDyHV5pdea1TQ@mail.gmail.com>

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 <chen.l.liang at oracle.com> 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 <core-libs-dev-retn at openjdk.org> on behalf of Brett Okken <brett.okken.os at gmail.com>
> Sent: Tuesday, July 1, 2025 9:57 AM
> To: core-libs-dev <core-libs-dev at openjdk.org>
> 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: <CANBJVOF=Vr3qOosxsYHc+8jfz5uxiB9tYqVheWDyHV5pdea1TQ@mail.gmail.com>
References: <CANBJVOFRV0drYo0DcumwZYGavzNLquhjKijmoXjzNpc4k89Yrg@mail.gmail.com>
 <SJ2PR10MB7669FEA3948E934C7EB92B7AA241A@SJ2PR10MB7669.namprd10.prod.outlook.com>
 <CANBJVOF=Vr3qOosxsYHc+8jfz5uxiB9tYqVheWDyHV5pdea1TQ@mail.gmail.com>
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 <brett.okken.os at gmail.com> 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: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250702/e7034110/attachment.htm>

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: <CANBJVOFRV0drYo0DcumwZYGavzNLquhjKijmoXjzNpc4k89Yrg@mail.gmail.com>
 <SJ2PR10MB7669FEA3948E934C7EB92B7AA241A@SJ2PR10MB7669.namprd10.prod.outlook.com>
 <CANBJVOF=Vr3qOosxsYHc+8jfz5uxiB9tYqVheWDyHV5pdea1TQ@mail.gmail.com>
 <08950E51-883A-47E2-B013-F6F4E9B1499B@oracle.com>
Message-ID: <SJ2PR10MB7669E8BCB6179EFFB11DC0C6A240A@SJ2PR10MB7669.namprd10.prod.outlook.com>

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 <core-libs-dev-retn at openjdk.org> on behalf of Brian Burkhalter <brian.burkhalter at oracle.com>
Sent: Wednesday, July 2, 2025 10:40 AM
To: Brett Okken <brett.okken.os at gmail.com>
Cc: core-libs-dev <core-libs-dev at openjdk.org>
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 <brett.okken.os at gmail.com> 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: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250702/e1ca583e/attachment-0001.htm>

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: <CANBJVOFRV0drYo0DcumwZYGavzNLquhjKijmoXjzNpc4k89Yrg@mail.gmail.com>
 <SJ2PR10MB7669FEA3948E934C7EB92B7AA241A@SJ2PR10MB7669.namprd10.prod.outlook.com>
 <CANBJVOF=Vr3qOosxsYHc+8jfz5uxiB9tYqVheWDyHV5pdea1TQ@mail.gmail.com>
 <08950E51-883A-47E2-B013-F6F4E9B1499B@oracle.com>
Message-ID: <CANBJVOGVYfJwUxFfqx_-UrvhDCpLenD=Wi_rRMXBHpZ7F=jTTQ@mail.gmail.com>

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
<brian.burkhalter at oracle.com> 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 <brett.okken.os at gmail.com> 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: <CANBJVOGVYfJwUxFfqx_-UrvhDCpLenD=Wi_rRMXBHpZ7F=jTTQ@mail.gmail.com>
References: <CANBJVOFRV0drYo0DcumwZYGavzNLquhjKijmoXjzNpc4k89Yrg@mail.gmail.com>
 <SJ2PR10MB7669FEA3948E934C7EB92B7AA241A@SJ2PR10MB7669.namprd10.prod.outlook.com>
 <CANBJVOF=Vr3qOosxsYHc+8jfz5uxiB9tYqVheWDyHV5pdea1TQ@mail.gmail.com>
 <08950E51-883A-47E2-B013-F6F4E9B1499B@oracle.com>
 <CANBJVOGVYfJwUxFfqx_-UrvhDCpLenD=Wi_rRMXBHpZ7F=jTTQ@mail.gmail.com>
Message-ID: <CANBJVOFKS_ZqSHjDGfomW--QvXkFXf+fTJWfWy6dqD=Si==C4Q@mail.gmail.com>

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 <brett.okken.os at gmail.com> 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
> <brian.burkhalter at oracle.com> 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 <brett.okken.os at gmail.com> 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: <ONnqwVmTHDsT9ZUmvL050UJ3GTaeCvubIOL42q3B3sY=.be05ccc3-be10-4ac6-b2e5-ca10cd4974a4@github.com>
References: <S5QCukHfY9v7DYMWyRaUlJPGjPrYWcVV5eMlknezS78=.84a5f517-bcbf-4f2f-801d-5768e5456c2c@github.com>
 <4b4eB1IhNlZXMVqf-aOj-IIp3kwLiqOVfeqioc2dL9Q=.8af3f74b-7b61-424a-b2c6-421fa6e0c0e6@github.com>
 <SM51sfCBxdd5DUJm7EJGGBzGA-IzlX4QSA4qXVS3UJk=.cf6cb877-1703-4fdf-b02e-f87a27e1d77b@github.com>
 <Jxnfqiwb79xkySdKYFiZrXammdV53SSqGikeBO2g-0s=.6b47f449-e71e-431c-a361-f2604300a757@github.com>
 <TBlXrG7D1XZI1v63sRUcixX1zKfS9yb1rvPXvjqUuqw=.624d2815-18e6-4d78-88cf-5c74abcbd4a7@github.com>
 <FCJXQ8VBPsuM_sLPAkb5MLutPi34oRncrt1PQmuAahE=.fdd8f726-f7d6-4c5a-8d10-52097c5d45ef@github.com>
 <ONnqwVmTHDsT9ZUmvL050UJ3GTaeCvubIOL42q3B3sY=.be05ccc3-be10-4ac6-b2e5-ca10cd4974a4@github.com>
Message-ID: <Mg-tKv7dNT6R7k361j4ROr_oUAUeGdunWw_Am4_dT0I=.c282902f-7663-471b-a2ca-5b3a189df6ce@github.com>

On Wed, 2 Jul 2025 10:08:53 GMT, Kieran Farrell <kfarrell at openjdk.org> 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: <CANBJVOFKS_ZqSHjDGfomW--QvXkFXf+fTJWfWy6dqD=Si==C4Q@mail.gmail.com>
References: <CANBJVOFRV0drYo0DcumwZYGavzNLquhjKijmoXjzNpc4k89Yrg@mail.gmail.com>
 <SJ2PR10MB7669FEA3948E934C7EB92B7AA241A@SJ2PR10MB7669.namprd10.prod.outlook.com>
 <CANBJVOF=Vr3qOosxsYHc+8jfz5uxiB9tYqVheWDyHV5pdea1TQ@mail.gmail.com>
 <08950E51-883A-47E2-B013-F6F4E9B1499B@oracle.com>
 <CANBJVOGVYfJwUxFfqx_-UrvhDCpLenD=Wi_rRMXBHpZ7F=jTTQ@mail.gmail.com>
 <CANBJVOFKS_ZqSHjDGfomW--QvXkFXf+fTJWfWy6dqD=Si==C4Q@mail.gmail.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 <brett.okken.os at gmail.com> 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: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250702/f9c739aa/attachment-0001.htm>

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: <Mg-tKv7dNT6R7k361j4ROr_oUAUeGdunWw_Am4_dT0I=.c282902f-7663-471b-a2ca-5b3a189df6ce@github.com>
References: <S5QCukHfY9v7DYMWyRaUlJPGjPrYWcVV5eMlknezS78=.84a5f517-bcbf-4f2f-801d-5768e5456c2c@github.com>
 <4b4eB1IhNlZXMVqf-aOj-IIp3kwLiqOVfeqioc2dL9Q=.8af3f74b-7b61-424a-b2c6-421fa6e0c0e6@github.com>
 <SM51sfCBxdd5DUJm7EJGGBzGA-IzlX4QSA4qXVS3UJk=.cf6cb877-1703-4fdf-b02e-f87a27e1d77b@github.com>
 <Jxnfqiwb79xkySdKYFiZrXammdV53SSqGikeBO2g-0s=.6b47f449-e71e-431c-a361-f2604300a757@github.com>
 <TBlXrG7D1XZI1v63sRUcixX1zKfS9yb1rvPXvjqUuqw=.624d2815-18e6-4d78-88cf-5c74abcbd4a7@github.com>
 <FCJXQ8VBPsuM_sLPAkb5MLutPi34oRncrt1PQmuAahE=.fdd8f726-f7d6-4c5a-8d10-52097c5d45ef@github.com>
 <ONnqwVmTHDsT9ZUmvL050UJ3GTaeCvubIOL42q3B3sY=.be05ccc3-be10-4ac6-b2e5-ca10cd4974a4@github.com>
 <Mg-tKv7dNT6R7k361j4ROr_oUAUeGdunWw_Am4_dT0I=.c282902f-7663-471b-a2ca-5b3a189df6ce@github.com>
Message-ID: <uvzG8MoVqZKHwbPRKCkw5GHo9OWcEixCb78rhdki98E=.777e424e-d3a3-4a44-bd68-f20cb31c108c@github.com>

On Wed, 2 Jul 2025 15:59:47 GMT, Roger Riggs <rriggs at openjdk.org> 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: <CANBJVOFRV0drYo0DcumwZYGavzNLquhjKijmoXjzNpc4k89Yrg@mail.gmail.com>
 <SJ2PR10MB7669FEA3948E934C7EB92B7AA241A@SJ2PR10MB7669.namprd10.prod.outlook.com>
 <CANBJVOF=Vr3qOosxsYHc+8jfz5uxiB9tYqVheWDyHV5pdea1TQ@mail.gmail.com>
 <08950E51-883A-47E2-B013-F6F4E9B1499B@oracle.com>
 <CANBJVOGVYfJwUxFfqx_-UrvhDCpLenD=Wi_rRMXBHpZ7F=jTTQ@mail.gmail.com>
 <CANBJVOFKS_ZqSHjDGfomW--QvXkFXf+fTJWfWy6dqD=Si==C4Q@mail.gmail.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<mailto:nio-dev at openjdk.org>.

On Jul 2, 2025, at 9:03?AM, Brian Burkhalter <brian.burkhalter at oracle.com> 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 <brett.okken.os at gmail.com> 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: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250702/6b3cfd52/attachment.htm>

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: <TOEIN-RxBEAKv4Vleaa0WtyMijKUwSGuF_31bQA-pCo=.88f82538-a7ec-4dc7-b6fe-744906fbc48b@github.com>
References: <TOEIN-RxBEAKv4Vleaa0WtyMijKUwSGuF_31bQA-pCo=.88f82538-a7ec-4dc7-b6fe-744906fbc48b@github.com>
Message-ID: <qwMi_YD5Yow-pNEOATyrNKv_ANutIt16RfCk7_AXN3Q=.2078aed1-5a95-4587-ac45-b221019bd0ea@github.com>

On Fri, 27 Jun 2025 20:45:14 GMT, Naoto Sato <naoto at openjdk.org> 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: <EZ4_14iY5_yTqfv3ZYpfoVRQK4jjxPtpafox1FQjq5M=.046cbb01-5fe5-4cf9-a468-ed22f0b4acda@github.com>

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: <X0JLWafyuyum8VPF25kVst69Dog-K7frF1aVyqkRVYo=.1b7a2858-c24a-4a6a-af2c-7aa387fbf76c@github.com>
References: <wIuR7gaQWIRdb8DtEN1VXi9dNkUMuKn8zv3Myc4V2gc=.3356e893-5322-4bb4-aa37-731fb6e9a4b0@github.com>
 <KAD32In5r6VDU4e0LePqKTHv8bn7fc9xb9zAI1UBkHY=.acba81de-6332-4cf9-9a66-d6e0f488b61b@github.com>
 <xeIs7PX3HXqTdu2tRHwcZ8MUMqwQ2-npMve0hR1Kpm8=.3b639c80-f5fd-4445-a682-b1a656c8a278@github.com>
 <X0JLWafyuyum8VPF25kVst69Dog-K7frF1aVyqkRVYo=.1b7a2858-c24a-4a6a-af2c-7aa387fbf76c@github.com>
Message-ID: <evIO-3XY9zrB7yhVkvzDi60Hhk3V3H-6PH2s8Pn0QBo=.e5f55ec3-3275-4165-93f5-548abe1349fc@github.com>

On Wed, 6 Dec 2023 15:07:59 GMT, fabioromano1 <duke at openjdk.org> 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: <CANBJVOGVYfJwUxFfqx_-UrvhDCpLenD=Wi_rRMXBHpZ7F=jTTQ@mail.gmail.com>
References: <CANBJVOFRV0drYo0DcumwZYGavzNLquhjKijmoXjzNpc4k89Yrg@mail.gmail.com>
 <SJ2PR10MB7669FEA3948E934C7EB92B7AA241A@SJ2PR10MB7669.namprd10.prod.outlook.com>
 <CANBJVOF=Vr3qOosxsYHc+8jfz5uxiB9tYqVheWDyHV5pdea1TQ@mail.gmail.com>
 <08950E51-883A-47E2-B013-F6F4E9B1499B@oracle.com>
 <CANBJVOGVYfJwUxFfqx_-UrvhDCpLenD=Wi_rRMXBHpZ7F=jTTQ@mail.gmail.com>
Message-ID: <c0c3276d-4eae-4509-afbc-45f4347365d1@oracle.com>

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: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250702/ea62482a/attachment-0001.htm>

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: <OOcrr-XrT-N783zTSoPF70AaZPoDlogN7Sck9p-N9nw=.98f4c5e8-fafd-48df-834b-cbb6f4bfe771@github.com>
References: <OOcrr-XrT-N783zTSoPF70AaZPoDlogN7Sck9p-N9nw=.98f4c5e8-fafd-48df-834b-cbb6f4bfe771@github.com>
Message-ID: <ut2C23h-YNJzFBPhANthT9lrqU9n2ydqrzZT_ObHBlI=.7719b345-b553-4882-b8bc-fb3bbcaa62fa@github.com>

> 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 <clinit> 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: <OOcrr-XrT-N783zTSoPF70AaZPoDlogN7Sck9p-N9nw=.98f4c5e8-fafd-48df-834b-cbb6f4bfe771@github.com>
References: <OOcrr-XrT-N783zTSoPF70AaZPoDlogN7Sck9p-N9nw=.98f4c5e8-fafd-48df-834b-cbb6f4bfe771@github.com>
Message-ID: <CndXprPCNAIkGu9pC4Ew8ojHZAk1rfRqjvMEib41kM4=.6bb7cd66-3b09-43de-ae11-aafb39db4a6c@github.com>

> 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 <clinit> 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: <c0c3276d-4eae-4509-afbc-45f4347365d1@oracle.com>
References: <CANBJVOFRV0drYo0DcumwZYGavzNLquhjKijmoXjzNpc4k89Yrg@mail.gmail.com>
 <SJ2PR10MB7669FEA3948E934C7EB92B7AA241A@SJ2PR10MB7669.namprd10.prod.outlook.com>
 <CANBJVOF=Vr3qOosxsYHc+8jfz5uxiB9tYqVheWDyHV5pdea1TQ@mail.gmail.com>
 <08950E51-883A-47E2-B013-F6F4E9B1499B@oracle.com>
 <CANBJVOGVYfJwUxFfqx_-UrvhDCpLenD=Wi_rRMXBHpZ7F=jTTQ@mail.gmail.com>
 <c0c3276d-4eae-4509-afbc-45f4347365d1@oracle.com>
Message-ID: <892102A7-D6F7-43BE-9753-F4B70091DE76@oracle.com>


On Jul 2, 2025, at 11:19?AM, Alan Bateman <alan.bateman at oracle.com> 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: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250702/837d3c8b/attachment-0001.htm>

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: <hQqhqm1r_dSb9ThvtqEyTcbB31lJxpu7LohMCsAf5xo=.da3388a2-3033-4d95-95cf-7a40fe7e7068@github.com>

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: <hQqhqm1r_dSb9ThvtqEyTcbB31lJxpu7LohMCsAf5xo=.da3388a2-3033-4d95-95cf-7a40fe7e7068@github.com>
References: <hQqhqm1r_dSb9ThvtqEyTcbB31lJxpu7LohMCsAf5xo=.da3388a2-3033-4d95-95cf-7a40fe7e7068@github.com>
Message-ID: <icamm0ZZe_XM1aTAef4YUx2JCxCrwRDndRI8xwAQArU=.3906502e-ed8b-406e-aefa-241fe7ddd8bf@github.com>

On Tue, 24 Jun 2025 00:04:54 GMT, Chen Liang <liach at openjdk.org> 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: <hQqhqm1r_dSb9ThvtqEyTcbB31lJxpu7LohMCsAf5xo=.da3388a2-3033-4d95-95cf-7a40fe7e7068@github.com>
References: <hQqhqm1r_dSb9ThvtqEyTcbB31lJxpu7LohMCsAf5xo=.da3388a2-3033-4d95-95cf-7a40fe7e7068@github.com>
Message-ID: <KMRKByfiVEnyYE-KmTkqv6Ry-aGSIiTbUf41NLa4k2o=.068ee8d2-b7f1-4821-9d58-eccce500a094@github.com>

On Tue, 24 Jun 2025 00:04:54 GMT, Chen Liang <liach at openjdk.org> 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: <icamm0ZZe_XM1aTAef4YUx2JCxCrwRDndRI8xwAQArU=.3906502e-ed8b-406e-aefa-241fe7ddd8bf@github.com>
References: <hQqhqm1r_dSb9ThvtqEyTcbB31lJxpu7LohMCsAf5xo=.da3388a2-3033-4d95-95cf-7a40fe7e7068@github.com>
 <icamm0ZZe_XM1aTAef4YUx2JCxCrwRDndRI8xwAQArU=.3906502e-ed8b-406e-aefa-241fe7ddd8bf@github.com>
Message-ID: <-PaFLZAuGHijTUXUlAdJ3mPefIAt0TOURgPj72PamdA=.09dd4c05-ca65-48c2-b64a-0e5423a6f359@github.com>

On Tue, 24 Jun 2025 18:34:02 GMT, ExE Boss <duke at openjdk.org> 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: <hQqhqm1r_dSb9ThvtqEyTcbB31lJxpu7LohMCsAf5xo=.da3388a2-3033-4d95-95cf-7a40fe7e7068@github.com>
 <icamm0ZZe_XM1aTAef4YUx2JCxCrwRDndRI8xwAQArU=.3906502e-ed8b-406e-aefa-241fe7ddd8bf@github.com>
 <-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 <liach at openjdk.org> 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: <CANBJVOFRV0drYo0DcumwZYGavzNLquhjKijmoXjzNpc4k89Yrg@mail.gmail.com>
 <SJ2PR10MB7669FEA3948E934C7EB92B7AA241A@SJ2PR10MB7669.namprd10.prod.outlook.com>
 <CANBJVOF=Vr3qOosxsYHc+8jfz5uxiB9tYqVheWDyHV5pdea1TQ@mail.gmail.com>
 <08950E51-883A-47E2-B013-F6F4E9B1499B@oracle.com>
 <CANBJVOGVYfJwUxFfqx_-UrvhDCpLenD=Wi_rRMXBHpZ7F=jTTQ@mail.gmail.com>
 <c0c3276d-4eae-4509-afbc-45f4347365d1@oracle.com>
 <892102A7-D6F7-43BE-9753-F4B70091DE76@oracle.com>
Message-ID: <CANBJVOEshmLcYEhxtxP-2uWCyrksJeMzNepTH96f8S2uoMC7PA@mail.gmail.com>

> 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: <CANBJVOEshmLcYEhxtxP-2uWCyrksJeMzNepTH96f8S2uoMC7PA@mail.gmail.com>
References: <CANBJVOFRV0drYo0DcumwZYGavzNLquhjKijmoXjzNpc4k89Yrg@mail.gmail.com>
 <SJ2PR10MB7669FEA3948E934C7EB92B7AA241A@SJ2PR10MB7669.namprd10.prod.outlook.com>
 <CANBJVOF=Vr3qOosxsYHc+8jfz5uxiB9tYqVheWDyHV5pdea1TQ@mail.gmail.com>
 <08950E51-883A-47E2-B013-F6F4E9B1499B@oracle.com>
 <CANBJVOGVYfJwUxFfqx_-UrvhDCpLenD=Wi_rRMXBHpZ7F=jTTQ@mail.gmail.com>
 <c0c3276d-4eae-4509-afbc-45f4347365d1@oracle.com>
 <892102A7-D6F7-43BE-9753-F4B70091DE76@oracle.com>
 <CANBJVOEshmLcYEhxtxP-2uWCyrksJeMzNepTH96f8S2uoMC7PA@mail.gmail.com>
Message-ID: <07D9B721-4BEB-4070-BA6D-B8A154D15B8F@oracle.com>



> On Jul 2, 2025, at 1:05?PM, Brett Okken <brett.okken.os at gmail.com> 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: <CndXprPCNAIkGu9pC4Ew8ojHZAk1rfRqjvMEib41kM4=.6bb7cd66-3b09-43de-ae11-aafb39db4a6c@github.com>
References: <OOcrr-XrT-N783zTSoPF70AaZPoDlogN7Sck9p-N9nw=.98f4c5e8-fafd-48df-834b-cbb6f4bfe771@github.com>
 <CndXprPCNAIkGu9pC4Ew8ojHZAk1rfRqjvMEib41kM4=.6bb7cd66-3b09-43de-ae11-aafb39db4a6c@github.com>
Message-ID: <gI1EbtBhKlruOZ3KCLBrBVKk0XGTHrfdDxD7tiReSIk=.e2ba2bdc-37c5-4acf-8777-187d8ee36432@github.com>

On Wed, 2 Jul 2025 18:47:58 GMT, Chen Liang <liach at openjdk.org> 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 <clinit> 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 `<clinit>`


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: <evIO-3XY9zrB7yhVkvzDi60Hhk3V3H-6PH2s8Pn0QBo=.e5f55ec3-3275-4165-93f5-548abe1349fc@github.com>
References: <wIuR7gaQWIRdb8DtEN1VXi9dNkUMuKn8zv3Myc4V2gc=.3356e893-5322-4bb4-aa37-731fb6e9a4b0@github.com>
 <KAD32In5r6VDU4e0LePqKTHv8bn7fc9xb9zAI1UBkHY=.acba81de-6332-4cf9-9a66-d6e0f488b61b@github.com>
 <xeIs7PX3HXqTdu2tRHwcZ8MUMqwQ2-npMve0hR1Kpm8=.3b639c80-f5fd-4445-a682-b1a656c8a278@github.com>
 <X0JLWafyuyum8VPF25kVst69Dog-K7frF1aVyqkRVYo=.1b7a2858-c24a-4a6a-af2c-7aa387fbf76c@github.com>
 <evIO-3XY9zrB7yhVkvzDi60Hhk3V3H-6PH2s8Pn0QBo=.e5f55ec3-3275-4165-93f5-548abe1349fc@github.com>
Message-ID: <rg1dINeXfMxiAgKs34HzHvszZL3KQImpv6l4QPCn9MM=.46bb0bf8-f749-4460-bec6-b12327919fa9@github.com>

On Wed, 2 Jul 2025 17:50:28 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> 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: <k-sV5p2PH-mOW5iO5bjVK3Poi_h1rUzH6OEKiXhHAHQ=.ccaf23b2-903b-4847-a26b-7e2e4a47ef7b@github.com>
References: <k-sV5p2PH-mOW5iO5bjVK3Poi_h1rUzH6OEKiXhHAHQ=.ccaf23b2-903b-4847-a26b-7e2e4a47ef7b@github.com>
Message-ID: <k3n3gMBukOCNDutvHjMsAx6BNC1fL2dqJm0-EbLbhs0=.38f91fd6-6954-455c-a472-32a36fc5920a@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: 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: <KAD32In5r6VDU4e0LePqKTHv8bn7fc9xb9zAI1UBkHY=.acba81de-6332-4cf9-9a66-d6e0f488b61b@github.com>
References: <wIuR7gaQWIRdb8DtEN1VXi9dNkUMuKn8zv3Myc4V2gc=.3356e893-5322-4bb4-aa37-731fb6e9a4b0@github.com>
 <KAD32In5r6VDU4e0LePqKTHv8bn7fc9xb9zAI1UBkHY=.acba81de-6332-4cf9-9a66-d6e0f488b61b@github.com>
Message-ID: <WM_DOQehO3NGyYFYrZmNMpsQuTQ3q4L3SB4Gv6Q1Hkc=.2e359e10-210f-4d6a-98d9-c14144c30fe7@github.com>

On Sat, 2 Dec 2023 15:42:18 GMT, fabioromano1 <duke at openjdk.org> 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: <gI1EbtBhKlruOZ3KCLBrBVKk0XGTHrfdDxD7tiReSIk=.e2ba2bdc-37c5-4acf-8777-187d8ee36432@github.com>
References: <OOcrr-XrT-N783zTSoPF70AaZPoDlogN7Sck9p-N9nw=.98f4c5e8-fafd-48df-834b-cbb6f4bfe771@github.com>
 <CndXprPCNAIkGu9pC4Ew8ojHZAk1rfRqjvMEib41kM4=.6bb7cd66-3b09-43de-ae11-aafb39db4a6c@github.com>
 <gI1EbtBhKlruOZ3KCLBrBVKk0XGTHrfdDxD7tiReSIk=.e2ba2bdc-37c5-4acf-8777-187d8ee36432@github.com>
Message-ID: <yEKNDZMye8BFnABSqJv-3VwafFRAzzeZ8SUnna3RlGo=.4fedc716-7d97-46a4-bf82-8ae1032ff1a1@github.com>

On Wed, 2 Jul 2025 21:18:14 GMT, Ioi Lam <iklam at openjdk.org> 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 `<clinit>`
> 
> 
> 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: <yEKNDZMye8BFnABSqJv-3VwafFRAzzeZ8SUnna3RlGo=.4fedc716-7d97-46a4-bf82-8ae1032ff1a1@github.com>
References: <OOcrr-XrT-N783zTSoPF70AaZPoDlogN7Sck9p-N9nw=.98f4c5e8-fafd-48df-834b-cbb6f4bfe771@github.com>
 <CndXprPCNAIkGu9pC4Ew8ojHZAk1rfRqjvMEib41kM4=.6bb7cd66-3b09-43de-ae11-aafb39db4a6c@github.com>
 <gI1EbtBhKlruOZ3KCLBrBVKk0XGTHrfdDxD7tiReSIk=.e2ba2bdc-37c5-4acf-8777-187d8ee36432@github.com>
 <yEKNDZMye8BFnABSqJv-3VwafFRAzzeZ8SUnna3RlGo=.4fedc716-7d97-46a4-bf82-8ae1032ff1a1@github.com>
Message-ID: <ZaYpy95n1Es8ZEls5HHOwFDJfTLi0fe8UHC9y09_Y50=.5ac45545-8a6d-4ab9-9c20-ff6790f8f78a@github.com>

On Wed, 2 Jul 2025 23:18:38 GMT, Chen Liang <liach at openjdk.org> 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 `<clinit>`
>> 
>> 
>> 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: <CndXprPCNAIkGu9pC4Ew8ojHZAk1rfRqjvMEib41kM4=.6bb7cd66-3b09-43de-ae11-aafb39db4a6c@github.com>
References: <OOcrr-XrT-N783zTSoPF70AaZPoDlogN7Sck9p-N9nw=.98f4c5e8-fafd-48df-834b-cbb6f4bfe771@github.com>
 <CndXprPCNAIkGu9pC4Ew8ojHZAk1rfRqjvMEib41kM4=.6bb7cd66-3b09-43de-ae11-aafb39db4a6c@github.com>
Message-ID: <GXiSwpPB8Kfv053HunyiwKSRCLouHzoWo_K86jWiEV0=.a78c4783-aed5-4d0c-badf-3be939cec490@github.com>

On Wed, 2 Jul 2025 18:47:58 GMT, Chen Liang <liach at openjdk.org> 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 <clinit> 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: <IPodt6KjRH75edJJjXja5g9wqH4oY6-EouV4Xn5SWeU=.21e726f3-7dae-47ad-9b3a-9f3118fedbda@github.com>
 <KO-d2RLH061W_VBdFFmGqhF-0XDwAKLyETFHa7kqAQI=.b29c8b91-0128-44b6-86d8-879f79076434@github.com>
 <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 <lancea at openjdk.org> 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: <IPodt6KjRH75edJJjXja5g9wqH4oY6-EouV4Xn5SWeU=.21e726f3-7dae-47ad-9b3a-9f3118fedbda@github.com>
References: <IPodt6KjRH75edJJjXja5g9wqH4oY6-EouV4Xn5SWeU=.21e726f3-7dae-47ad-9b3a-9f3118fedbda@github.com>
Message-ID: <okj2gzq2rRcoIFPZgcv9LLaFjlkG6P6ejvgd4lIho5A=.0be2f340-c90a-4dd4-b785-217fae7f032e@github.com>

> 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
> <details><summary>Using <code>git</code></summary>
> 
> 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`
> 
> </details>
> <details><summary>Using Skara CLI tools</summary>
> 
> Checkout this PR locally: \
> `$ git pr checkout 25925`
> 
> View PR using the GUI difftool: \
> `$ git pr show -t 25925`
> 
> </details>
> <details><summary>Using diff file</summary>
> 
> Download this PR as a diff file: \
> <a href="https://git.openjdk.org/jdk/pull/25925.diff">https://git.openjdk.org/jdk/pull/25925.diff</a>
> 
> </details>
> <details><summary>Using Webrev</summary>
> 
> [Link to Webrev Comment](https://git.openjdk.org/jdk/pull/25925#issuecomment-2993856738)
> </details>

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: <IPodt6KjRH75edJJjXja5g9wqH4oY6-EouV4Xn5SWeU=.21e726f3-7dae-47ad-9b3a-9f3118fedbda@github.com>
 <KO-d2RLH061W_VBdFFmGqhF-0XDwAKLyETFHa7kqAQI=.b29c8b91-0128-44b6-86d8-879f79076434@github.com>
 <0UfkXxOmp7jsEH0cPOPBDoh8osWoz6Jp6A8jLh-CmDE=.57a3938f-ba6d-48ee-9caf-ecd3c10678cb@github.com>
Message-ID: <yCoE6ZiTG7dagO9dhwRj__-zYfiX-8FLY9K-UoT6jKw=.6f8e4089-2bb0-44b6-ac61-272aa5bb429c@github.com>

On Wed, 2 Jul 2025 15:14:47 GMT, Lance Andersen <lancea at openjdk.org> 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: <Pj612tMDuN_vikjswqLr2FS-hs08JeIrtirLGK_wY8w=.fbb16038-3922-499a-a9d1-c2c940a872da@github.com>
References: <IPodt6KjRH75edJJjXja5g9wqH4oY6-EouV4Xn5SWeU=.21e726f3-7dae-47ad-9b3a-9f3118fedbda@github.com>
 <T1ReWdgWLbe0Gr6FrmG2t7jHIW2eaP8ogLOJgb8RVqQ=.e3ff1b84-ab5e-4ce6-a81e-944972700549@github.com>
 <Pj612tMDuN_vikjswqLr2FS-hs08JeIrtirLGK_wY8w=.fbb16038-3922-499a-a9d1-c2c940a872da@github.com>
Message-ID: <J2t7XpIRu3RpYNTqKwkbJsMj1EBsh4eIoaak0iRIVXs=.27b846f8-7e8d-4fa9-ba52-df858c13eacb@github.com>

On Mon, 23 Jun 2025 17:45:02 GMT, Lance Andersen <lancea at openjdk.org> 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: <oy3WZBhOMCmlmi4lOK5S1u5cNcc5XVzZ4JGzXj6Hopw=.5cf6ac0f-5779-4805-bb48-466c948b1ce5@github.com>

On Sat, 5 Apr 2025 17:36:29 GMT, Markus KARG <duke at openjdk.org> 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: <hQqhqm1r_dSb9ThvtqEyTcbB31lJxpu7LohMCsAf5xo=.da3388a2-3033-4d95-95cf-7a40fe7e7068@github.com>
References: <hQqhqm1r_dSb9ThvtqEyTcbB31lJxpu7LohMCsAf5xo=.da3388a2-3033-4d95-95cf-7a40fe7e7068@github.com>
Message-ID: <UcfSv9H_AL6Woi55RasPtf3LAbDaZcaOLSyHcsEkJyA=.7a484db2-b6e4-4e8d-9c5a-105207ce4b33@github.com>

On Tue, 24 Jun 2025 00:04:54 GMT, Chen Liang <liach at openjdk.org> 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: <LQRWbokCOzo8paB0R3JzFrXWVt5mxyGpU1Xe5rTuN4Q=.a7affe6d-82e2-4115-866e-348acbe4d7f7@github.com>
References: <LQRWbokCOzo8paB0R3JzFrXWVt5mxyGpU1Xe5rTuN4Q=.a7affe6d-82e2-4115-866e-348acbe4d7f7@github.com>
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: <Q4fLpzhyF__Tixp2XVuGWgMKPywQhWR8_B4CyhvH5IE=.fc8c22d7-7dc5-4b72-a732-f79c99a81600@github.com>
References: <NUixQl_OY2xQ7VehoMd2fRm9S6T-z5qZNi2Uevslyp0=.0ef35d36-1b32-4bda-93bd-4a4f9f810614@github.com>
 <Q4fLpzhyF__Tixp2XVuGWgMKPywQhWR8_B4CyhvH5IE=.fc8c22d7-7dc5-4b72-a732-f79c99a81600@github.com>
Message-ID: <UR_Ualj2Sd7-dTMnlDs4EY6zhqGkBPvdd9aO_OQIpiM=.4b8d5f50-3778-4bbf-a2c2-4d786b4ba261@github.com>

On Fri, 4 Apr 2025 10:29:43 GMT, Takuya Kiriyama <tkiriyama at openjdk.org> 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: <NUixQl_OY2xQ7VehoMd2fRm9S6T-z5qZNi2Uevslyp0=.0ef35d36-1b32-4bda-93bd-4a4f9f810614@github.com>
References: <NUixQl_OY2xQ7VehoMd2fRm9S6T-z5qZNi2Uevslyp0=.0ef35d36-1b32-4bda-93bd-4a4f9f810614@github.com>
Message-ID: <0fbqyQH-sLdVi3yh_qUvtD78lJRb-7rhicLoNexmJtQ=.8fa636b5-904b-4649-8342-6910e1e7d3c6@github.com>

On Fri, 14 Mar 2025 09:17:06 GMT, Takuya Kiriyama <tkiriyama at openjdk.org> 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 <tkiriyama at openjdk.org>
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: <mWHKJozX3YTvBOjLDUa1_2QQiNm6xVc2rb1FtXcZzPc=.e2405ec4-09ed-46c1-acd5-3f39083fce3f@github.com>
 <dCstHcUFS9A79fKEf3RWnPrxvnzKjyVfbBzyT_iyzYo=.19255391-54fb-445e-b7e8-faf016e8a79f@github.com>
 <jc11aMooMRS54e6I3rd0HyobUW38VG_SbP60BoHUu48=.6ad63307-03bb-4171-bfa6-4f40741a1fc6@github.com>
 <NOSjg9nd8YCpTLPchcVXO2KxOzfTmYuxaQHqZhmHGUo=.e98cf933-0c08-4761-8210-75d56ece7542@github.com>
 <tLkj61MwZSaQEeLO3reAqAWfAMbs_hcR4wVXuUNpu5E=.197c558b-665f-4d7d-8f0c-97031a0ccf16@github.com>
 <15TW6hiffz65NhHevPefL_6swSC07UD-GwiJ4tPDtFs=.b83081df-8abd-4756-b4e0-1d969678a0d2@github.com>
Message-ID: <wIuhs2e4LaQgZNezMNpqtuCLq7zJUQKJ0ZYev2bzKpc=.16d57644-2322-440d-af3f-bb7f1001a8f1@github.com>

On Thu, 5 Jun 2025 11:05:48 GMT, Emanuel Peter <epeter at openjdk.org> 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: <RHNU92CJDovEvgJPNn0BzO_pFCWkP8aKKJbk3y3nS_A=.9599078c-3982-4cdf-9ee8-cd807b9f743c@github.com>
References: <S5QCukHfY9v7DYMWyRaUlJPGjPrYWcVV5eMlknezS78=.84a5f517-bcbf-4f2f-801d-5768e5456c2c@github.com>
 <RHNU92CJDovEvgJPNn0BzO_pFCWkP8aKKJbk3y3nS_A=.9599078c-3982-4cdf-9ee8-cd807b9f743c@github.com>
Message-ID: <0aWMgDcLLb77dhbIH-gZgRyxjBS0xi9Rt9XvrPSqXqU=.aed892d2-e248-42f7-aa6a-948e2ed65151@github.com>

On Wed, 2 Jul 2025 10:46:56 GMT, Kieran Farrell <kfarrell at openjdk.org> 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: <TdnuVxqRVlUzZpF7RYlOhMbsiCqssJiCgKNACfVqaJU=.190b4b40-3bad-44cd-abc8-9d436b2d3a47@github.com>
References: <tG3KsNaA8iDVdZRT-MGKvy8uViCna0ZUJ939oJsilj0=.a12f0cc9-4e47-4fb8-92d4-291c8f211790@github.com>
 <TdnuVxqRVlUzZpF7RYlOhMbsiCqssJiCgKNACfVqaJU=.190b4b40-3bad-44cd-abc8-9d436b2d3a47@github.com>
Message-ID: <6o5VBnWWZEpIwPsRrXFWwRO6S7hwnfPQVMhrnD97FkM=.f9e3d344-2757-48fd-957c-d92e5e83e8e8@github.com>

On Tue, 1 Jul 2025 00:01:21 GMT, Shaojin Wen <swen at openjdk.org> 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: <S5QCukHfY9v7DYMWyRaUlJPGjPrYWcVV5eMlknezS78=.84a5f517-bcbf-4f2f-801d-5768e5456c2c@github.com>
References: <S5QCukHfY9v7DYMWyRaUlJPGjPrYWcVV5eMlknezS78=.84a5f517-bcbf-4f2f-801d-5768e5456c2c@github.com>
Message-ID: <ocW9CVM3lNYmfK2thvLhuUU3ln6skBZXHaNZ7SZ-RgU=.e425fe03-25cb-428b-ad06-b96afa3ae95b@github.com>

> 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 <strong> 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: <S5QCukHfY9v7DYMWyRaUlJPGjPrYWcVV5eMlknezS78=.84a5f517-bcbf-4f2f-801d-5768e5456c2c@github.com>
 <RHNU92CJDovEvgJPNn0BzO_pFCWkP8aKKJbk3y3nS_A=.9599078c-3982-4cdf-9ee8-cd807b9f743c@github.com>
 <0aWMgDcLLb77dhbIH-gZgRyxjBS0xi9Rt9XvrPSqXqU=.aed892d2-e248-42f7-aa6a-948e2ed65151@github.com>
Message-ID: <wyl6C_9a6hdnHOi6HuDxWhiJQb1ZYR8i0YF12_2Ns-o=.d3a195c4-8fad-4f64-a3ce-59bf294b55b6@github.com>

On Thu, 3 Jul 2025 07:03:19 GMT, Alan Bateman <alanb at openjdk.org> 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: <EW5g6qGQPHbjKg70_-At6GfzzXXl3sKr3KMeR-SsUoY=.de62c927-1780-4e3f-864c-098d55453a38@github.com>
References: <39KIPIXZDBI9tpPyXew2Ye-uzPvkLSQnOzGJFuK9E2Y=.dc8df88f-f21a-4dd6-8297-5629098bd408@github.com>
 <EW5g6qGQPHbjKg70_-At6GfzzXXl3sKr3KMeR-SsUoY=.de62c927-1780-4e3f-864c-098d55453a38@github.com>
Message-ID: <k_7SLNDNHGjskEsmPtXYABx08oulLN173LwaUyWcVbg=.f7b2f9db-05c5-49a0-9c33-9888efaee852@github.com>

On Wed, 2 Jul 2025 14:52:06 GMT, Roger Riggs <rriggs at openjdk.org> 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:  * <p>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: <k3n3gMBukOCNDutvHjMsAx6BNC1fL2dqJm0-EbLbhs0=.38f91fd6-6954-455c-a472-32a36fc5920a@github.com>
References: <k-sV5p2PH-mOW5iO5bjVK3Poi_h1rUzH6OEKiXhHAHQ=.ccaf23b2-903b-4847-a26b-7e2e4a47ef7b@github.com>
 <k3n3gMBukOCNDutvHjMsAx6BNC1fL2dqJm0-EbLbhs0=.38f91fd6-6954-455c-a472-32a36fc5920a@github.com>
Message-ID: <PAoy1SEo4QKjjotOlrwU0neDXaGUU5RjaWfnDbURsFM=.8a1dd28c-871f-4d89-8306-fd94059b1a88@github.com>

On Wed, 2 Jul 2025 21:37:00 GMT, Brian Burkhalter <bpb at openjdk.org> 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: <YAzO8X5dqBy4BL3lTS3luonLm9A2RO25tHqcSfPunxo=.df2704c5-148d-49c8-9782-215362b3b034@github.com>
References: <YAzO8X5dqBy4BL3lTS3luonLm9A2RO25tHqcSfPunxo=.df2704c5-148d-49c8-9782-215362b3b034@github.com>
Message-ID: <CR9SL_8QfaRIkg4yyD2zsBzyLyJCHevsJJQkLmyGyOM=.e060bbf3-9ddf-4934-bcb4-61fa7572291f@github.com>

> 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 <lukellmann at gmail.com>
 - 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: <hQqhqm1r_dSb9ThvtqEyTcbB31lJxpu7LohMCsAf5xo=.da3388a2-3033-4d95-95cf-7a40fe7e7068@github.com>
References: <hQqhqm1r_dSb9ThvtqEyTcbB31lJxpu7LohMCsAf5xo=.da3388a2-3033-4d95-95cf-7a40fe7e7068@github.com>
Message-ID: <HYGscfKXAsb1ATPo_ig7_7gwCANKntxgF8USO5PGI9E=.ddc71536-c9ed-49b2-94bf-39184f1059cd@github.com>

> 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: <hQqhqm1r_dSb9ThvtqEyTcbB31lJxpu7LohMCsAf5xo=.da3388a2-3033-4d95-95cf-7a40fe7e7068@github.com>
References: <hQqhqm1r_dSb9ThvtqEyTcbB31lJxpu7LohMCsAf5xo=.da3388a2-3033-4d95-95cf-7a40fe7e7068@github.com>
Message-ID: <SsmUQu-L-1Eyqr2aFcxdRiUQm5Nykl7Aa3SYQ2SRzCA=.e0eb379d-1e4c-48aa-9fa0-0fc730375fd6@github.com>

> 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: <HYGscfKXAsb1ATPo_ig7_7gwCANKntxgF8USO5PGI9E=.ddc71536-c9ed-49b2-94bf-39184f1059cd@github.com>
References: <hQqhqm1r_dSb9ThvtqEyTcbB31lJxpu7LohMCsAf5xo=.da3388a2-3033-4d95-95cf-7a40fe7e7068@github.com>
 <HYGscfKXAsb1ATPo_ig7_7gwCANKntxgF8USO5PGI9E=.ddc71536-c9ed-49b2-94bf-39184f1059cd@github.com>
Message-ID: <Zx-0EppZ-IyE-MHgNYkAnsv_XnLh7G3qaeZ9E6D4d9A=.afe9ce5f-03c5-482d-a3a1-725476bf5f17@github.com>

On Thu, 3 Jul 2025 13:56:24 GMT, Chen Liang <liach at openjdk.org> 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 <aph at openjdk.org> 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: <k_7SLNDNHGjskEsmPtXYABx08oulLN173LwaUyWcVbg=.f7b2f9db-05c5-49a0-9c33-9888efaee852@github.com>
References: <39KIPIXZDBI9tpPyXew2Ye-uzPvkLSQnOzGJFuK9E2Y=.dc8df88f-f21a-4dd6-8297-5629098bd408@github.com>
 <EW5g6qGQPHbjKg70_-At6GfzzXXl3sKr3KMeR-SsUoY=.de62c927-1780-4e3f-864c-098d55453a38@github.com>
 <k_7SLNDNHGjskEsmPtXYABx08oulLN173LwaUyWcVbg=.f7b2f9db-05c5-49a0-9c33-9888efaee852@github.com>
Message-ID: <RTbPz3CM7PXO6Aj9eF-zlLWSHKF21h0W_UCk6-crLvk=.e1757a9c-536a-4a33-add4-9c9b02d2452d@github.com>

On Thu, 3 Jul 2025 11:46:32 GMT, Jaikiran Pai <jpai at openjdk.org> 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:  * <p>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: <ZaYpy95n1Es8ZEls5HHOwFDJfTLi0fe8UHC9y09_Y50=.5ac45545-8a6d-4ab9-9c20-ff6790f8f78a@github.com>
References: <OOcrr-XrT-N783zTSoPF70AaZPoDlogN7Sck9p-N9nw=.98f4c5e8-fafd-48df-834b-cbb6f4bfe771@github.com>
 <CndXprPCNAIkGu9pC4Ew8ojHZAk1rfRqjvMEib41kM4=.6bb7cd66-3b09-43de-ae11-aafb39db4a6c@github.com>
 <gI1EbtBhKlruOZ3KCLBrBVKk0XGTHrfdDxD7tiReSIk=.e2ba2bdc-37c5-4acf-8777-187d8ee36432@github.com>
 <yEKNDZMye8BFnABSqJv-3VwafFRAzzeZ8SUnna3RlGo=.4fedc716-7d97-46a4-bf82-8ae1032ff1a1@github.com>
 <ZaYpy95n1Es8ZEls5HHOwFDJfTLi0fe8UHC9y09_Y50=.5ac45545-8a6d-4ab9-9c20-ff6790f8f78a@github.com>
Message-ID: <_33LVgbvoF-SWOlZNwVbaxNxhGWc7HmZf8sW4qd3gww=.66d0a41b-3c26-4a05-9f4d-0fddb2ac4a72@github.com>

On Thu, 3 Jul 2025 00:09:14 GMT, Ioi Lam <iklam at openjdk.org> 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: <CAKD1RYv+g1L=ifA-_+Whrqb9cEHuH0zqFVSzW7AFg5Smahx2Bw@mail.gmail.com>

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: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250703/3ffc0441/attachment.htm>

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: <CALxaVtbzcHy4FJ9aSyRBjHzcCpGYUFECDWY+Mz0GrgmV6RgvNQ@mail.gmail.com>

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<UnicodeCharacter> {

    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<UnicodeCharacter> 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: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250703/9bb1112b/attachment.htm>

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: <CUehLlzYEtZP61JouVWGITfxKffR6PwvwLITSwYV0y8=.618036f1-3aaa-4605-91fd-53581671e15d@github.com>

On Thu, 3 Jul 2025 13:34:23 GMT, Andrew Haley <aph at openjdk.org> 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: <OOcrr-XrT-N783zTSoPF70AaZPoDlogN7Sck9p-N9nw=.98f4c5e8-fafd-48df-834b-cbb6f4bfe771@github.com>
References: <OOcrr-XrT-N783zTSoPF70AaZPoDlogN7Sck9p-N9nw=.98f4c5e8-fafd-48df-834b-cbb6f4bfe771@github.com>
Message-ID: <aDKxT2BNBfinqhaWg24t2vANW8GTxogAZPlu39iXqJ0=.9095018b-c3f4-496e-9447-8d06a006a898@github.com>

> 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 <clinit> 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: <CAKD1RYv+g1L=ifA-_+Whrqb9cEHuH0zqFVSzW7AFg5Smahx2Bw@mail.gmail.com>
References: <CAKD1RYv+g1L=ifA-_+Whrqb9cEHuH0zqFVSzW7AFg5Smahx2Bw@mail.gmail.com>
Message-ID: <CAA9v-_PnVORvTpvVMx99+-kp_3rAg-rfhwECXndk9t9TGUeZZA@mail.gmail.com>

These questions necessitate runnable examples. Do you have any

On Thu, Jul 3, 2025, 10:37?AM Jige Yu <yujige at gmail.com> 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: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250703/662feda1/attachment.htm>

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: <fsFrk-uILf3zDODjfBhMP2qOFvCPIMHSVVAf6gn-x68=.29863279-7056-4309-b5f4-1a7ea2be7ffb@github.com>
References: <Tf3bUauvymNvoeefTDY8gYfjcIAyFKv2d7_ktDemlV4=.ce8a894c-28b2-49c3-a515-2c31be1e6d6f@github.com>
 <fsFrk-uILf3zDODjfBhMP2qOFvCPIMHSVVAf6gn-x68=.29863279-7056-4309-b5f4-1a7ea2be7ffb@github.com>
Message-ID: <9rki3teH2JS04QJZA4zEmory8F8vnRhRnh9bBOIEey0=.3ac76f66-e9e0-45dd-bc5e-0c8bec56632c@github.com>

On Sun, 29 Jun 2025 20:43:56 GMT, Kim Barrett <kbarrett at openjdk.org> 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: <k3n3gMBukOCNDutvHjMsAx6BNC1fL2dqJm0-EbLbhs0=.38f91fd6-6954-455c-a472-32a36fc5920a@github.com>
References: <k-sV5p2PH-mOW5iO5bjVK3Poi_h1rUzH6OEKiXhHAHQ=.ccaf23b2-903b-4847-a26b-7e2e4a47ef7b@github.com>
 <k3n3gMBukOCNDutvHjMsAx6BNC1fL2dqJm0-EbLbhs0=.38f91fd6-6954-455c-a472-32a36fc5920a@github.com>
Message-ID: <DtOtPIpAmPuSha44vv69oL68y-eXvu0vIhfHfOfcTbU=.5b168ee6-7997-49c9-a48f-ad2fda897910@github.com>

On Wed, 2 Jul 2025 21:37:00 GMT, Brian Burkhalter <bpb at openjdk.org> 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: <PAoy1SEo4QKjjotOlrwU0neDXaGUU5RjaWfnDbURsFM=.8a1dd28c-871f-4d89-8306-fd94059b1a88@github.com>
References: <k-sV5p2PH-mOW5iO5bjVK3Poi_h1rUzH6OEKiXhHAHQ=.ccaf23b2-903b-4847-a26b-7e2e4a47ef7b@github.com>
 <k3n3gMBukOCNDutvHjMsAx6BNC1fL2dqJm0-EbLbhs0=.38f91fd6-6954-455c-a472-32a36fc5920a@github.com>
 <PAoy1SEo4QKjjotOlrwU0neDXaGUU5RjaWfnDbURsFM=.8a1dd28c-871f-4d89-8306-fd94059b1a88@github.com>
Message-ID: <PCFwXEO8h8sg26vU6FbfkicJjtwWNqZO5vXHAeOsxo0=.212a73fc-1238-4d2b-b2c8-b86dc7289e17@github.com>

On Thu, 3 Jul 2025 13:41:02 GMT, Roger Riggs <rriggs at openjdk.org> 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: <hQqhqm1r_dSb9ThvtqEyTcbB31lJxpu7LohMCsAf5xo=.da3388a2-3033-4d95-95cf-7a40fe7e7068@github.com>
References: <hQqhqm1r_dSb9ThvtqEyTcbB31lJxpu7LohMCsAf5xo=.da3388a2-3033-4d95-95cf-7a40fe7e7068@github.com>
Message-ID: <ry3bOAIy2G3MTSidAx9GU7rllzdPjR8a9Dl4xuimirM=.bf9a1c65-b2ff-4c21-b4c0-c77ef49d7cb3@github.com>

> 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: <icamm0ZZe_XM1aTAef4YUx2JCxCrwRDndRI8xwAQArU=.3906502e-ed8b-406e-aefa-241fe7ddd8bf@github.com>
References: <hQqhqm1r_dSb9ThvtqEyTcbB31lJxpu7LohMCsAf5xo=.da3388a2-3033-4d95-95cf-7a40fe7e7068@github.com>
 <icamm0ZZe_XM1aTAef4YUx2JCxCrwRDndRI8xwAQArU=.3906502e-ed8b-406e-aefa-241fe7ddd8bf@github.com>
Message-ID: <GJfFXSIwca_AuKIDZbFA2poCYPkPQrLiHyJPKPSVGow=.9b1c0028-8b14-4e14-ab77-239ee5433ffa@github.com>

On Thu, 26 Jun 2025 05:42:24 GMT, ExE Boss <duke at openjdk.org> 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: <LQRWbokCOzo8paB0R3JzFrXWVt5mxyGpU1Xe5rTuN4Q=.a7affe6d-82e2-4115-866e-348acbe4d7f7@github.com>
 <7VTRz_XqYBSdQ54n7ADzTzYADZjDbgBw6XuW0jehSLI=.24d18b87-4553-47ab-8065-d92fbb5700ae@github.com>
Message-ID: <k6FN6qEpXpyB1U8VlCs143plcfmnFeapGiQm7zANKTY=.1fe5f6fd-e5d9-4f4a-a8a4-f03cc069aabf@github.com>

On Thu, 3 Jul 2025 06:10:28 GMT, Xiaohong Gong <xgong at openjdk.org> 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: <RTbPz3CM7PXO6Aj9eF-zlLWSHKF21h0W_UCk6-crLvk=.e1757a9c-536a-4a33-add4-9c9b02d2452d@github.com>
References: <39KIPIXZDBI9tpPyXew2Ye-uzPvkLSQnOzGJFuK9E2Y=.dc8df88f-f21a-4dd6-8297-5629098bd408@github.com>
 <EW5g6qGQPHbjKg70_-At6GfzzXXl3sKr3KMeR-SsUoY=.de62c927-1780-4e3f-864c-098d55453a38@github.com>
 <k_7SLNDNHGjskEsmPtXYABx08oulLN173LwaUyWcVbg=.f7b2f9db-05c5-49a0-9c33-9888efaee852@github.com>
 <RTbPz3CM7PXO6Aj9eF-zlLWSHKF21h0W_UCk6-crLvk=.e1757a9c-536a-4a33-add4-9c9b02d2452d@github.com>
Message-ID: <l6q8j9WGZ4h562LLincPh7EF82oziTPwA9XHpMnj2ms=.15c67184-4103-4659-b14e-ca4f9eb2b44d@github.com>

On Thu, 3 Jul 2025 14:23:00 GMT, Roger Riggs <rriggs at openjdk.org> 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:  * <p>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: <fsFrk-uILf3zDODjfBhMP2qOFvCPIMHSVVAf6gn-x68=.29863279-7056-4309-b5f4-1a7ea2be7ffb@github.com>
References: <Tf3bUauvymNvoeefTDY8gYfjcIAyFKv2d7_ktDemlV4=.ce8a894c-28b2-49c3-a515-2c31be1e6d6f@github.com>
 <fsFrk-uILf3zDODjfBhMP2qOFvCPIMHSVVAf6gn-x68=.29863279-7056-4309-b5f4-1a7ea2be7ffb@github.com>
Message-ID: <96W7Z-kXZQxhp4r-tSvQ8d3T0UjPF4wqt8tKvnATxqw=.9d641157-375c-4f87-acab-cb8e4adb746a@github.com>

On Sun, 29 Jun 2025 20:43:56 GMT, Kim Barrett <kbarrett at openjdk.org> 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: <Tf3bUauvymNvoeefTDY8gYfjcIAyFKv2d7_ktDemlV4=.ce8a894c-28b2-49c3-a515-2c31be1e6d6f@github.com>
 <fsFrk-uILf3zDODjfBhMP2qOFvCPIMHSVVAf6gn-x68=.29863279-7056-4309-b5f4-1a7ea2be7ffb@github.com>
 <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 <rriggs at openjdk.org> 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: <Tf3bUauvymNvoeefTDY8gYfjcIAyFKv2d7_ktDemlV4=.ce8a894c-28b2-49c3-a515-2c31be1e6d6f@github.com>
References: <Tf3bUauvymNvoeefTDY8gYfjcIAyFKv2d7_ktDemlV4=.ce8a894c-28b2-49c3-a515-2c31be1e6d6f@github.com>
Message-ID: <e2Cn6EXWN9GlXf3sVF3FPLHKZ4FlmiuWn-smzoGrxeE=.935becee-1978-48d0-ba11-02a3180eb89b@github.com>

On Sun, 18 May 2025 11:35:55 GMT, Kim Barrett <kbarrett at openjdk.org> 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 <kbarrett at openjdk.org>
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: <i1cu_VA2najjcZHepAbvkWGtVzuLMsdYFKssI5s-TFA=.be96a1ac-1eba-4b7f-bde9-1214082eb6c6@github.com>
References: <918oCEfFu2JweXfV-afD1l_AGDDuc7dJwAxip-Ze6ZI=.8d5e9692-23db-47e4-9586-99e53b9cfbb6@github.com>
 <i1cu_VA2najjcZHepAbvkWGtVzuLMsdYFKssI5s-TFA=.be96a1ac-1eba-4b7f-bde9-1214082eb6c6@github.com>
Message-ID: <m_Vwr6jjREPH9qgNOdPJ0TxFrQJTDB6mFYbbJTSskKM=.fd2d994d-b9a1-4e4f-bee8-8e3b0b019e3f@github.com>

On Sun, 22 Oct 2023 17:26:52 GMT, Laurent Bourg?s <lbourges at openjdk.org> 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: <LQRWbokCOzo8paB0R3JzFrXWVt5mxyGpU1Xe5rTuN4Q=.a7affe6d-82e2-4115-866e-348acbe4d7f7@github.com>
 <7VTRz_XqYBSdQ54n7ADzTzYADZjDbgBw6XuW0jehSLI=.24d18b87-4553-47ab-8065-d92fbb5700ae@github.com>
Message-ID: <FxpYMyFQVYy18ZaAXJUgY06Aa8_nx7iL8k3iNCxd7NQ=.cb4f0902-e1c9-40ad-8440-1e7624e9a822@github.com>

On Thu, 3 Jul 2025 06:10:28 GMT, Xiaohong Gong <xgong at openjdk.org> 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: <FxpYMyFQVYy18ZaAXJUgY06Aa8_nx7iL8k3iNCxd7NQ=.cb4f0902-e1c9-40ad-8440-1e7624e9a822@github.com>
References: <LQRWbokCOzo8paB0R3JzFrXWVt5mxyGpU1Xe5rTuN4Q=.a7affe6d-82e2-4115-866e-348acbe4d7f7@github.com>
 <7VTRz_XqYBSdQ54n7ADzTzYADZjDbgBw6XuW0jehSLI=.24d18b87-4553-47ab-8065-d92fbb5700ae@github.com>
 <FxpYMyFQVYy18ZaAXJUgY06Aa8_nx7iL8k3iNCxd7NQ=.cb4f0902-e1c9-40ad-8440-1e7624e9a822@github.com>
Message-ID: <inTdz3qZhm6cE-jJzmcigOHfOBrDr-ujIyL2pv3lHbk=.5d8687f8-f0d9-4f64-9f3c-b8951f5c8722@github.com>

On Fri, 4 Jul 2025 09:11:40 GMT, Andrew Haley <aph at openjdk.org> 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: <uRSzkyhm2D_k01pbaWu6AMNNsjGxZcEb-UpW1pK7o2A=.69facb94-d35f-4867-af93-8769cd986288@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <kndznJZZH6s5fbZh3SdLr99uyypWihLc5VTVgvYJ-4o=.55af7211-1f2e-45a4-ab2e-33bfa87565d9@github.com>
 <FmP9p94joz0UZx-X4ijp-ssEuOP5866kdRKiu1scKH8=.994d9c2d-781f-481f-930b-18c4a5cc1621@github.com>
 <uRSzkyhm2D_k01pbaWu6AMNNsjGxZcEb-UpW1pK7o2A=.69facb94-d35f-4867-af93-8769cd986288@github.com>
Message-ID: <M9Emj44W8uptXRtEHwyL9LVfFpQVtpFuNM4c-Nw-UoM=.be6ca8bb-826d-41d8-b032-4328418775a6@github.com>

On Wed, 2 Jul 2025 07:47:31 GMT, Daniel Jeli?ski <djelinski at openjdk.org> 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: <xHDzjd4IbbYATwuK9I7oZ35Em3Rr9pfWaG3WOk_3lyk=.005270ef-7dba-459c-a653-8912f105ee6b@github.com>
References: <VtQlJ_3w2k5ewTVyVele6LRy1j6Vp_N-gZ4K0WJEDzE=.9b4ec980-a8a1-4ed2-8da8-0a1e3e58098d@github.com>
 <xHDzjd4IbbYATwuK9I7oZ35Em3Rr9pfWaG3WOk_3lyk=.005270ef-7dba-459c-a653-8912f105ee6b@github.com>
Message-ID: <Up5dXvSL6OJUERTIkXI0VnrvwcSwmbNyn8Pjaxl5Sbk=.bfec5c6d-a5c8-44e8-bbb0-5d95f639bfde@github.com>

On Wed, 2 Jul 2025 13:54:02 GMT, David Beaumont <duke at openjdk.org> 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/<module>/<path>` may come from one of two locations in the underlying jimage file; `/<module>/<path>` or `/<module>/META-INF/preview/<path>`. 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: <HVGEzq_9ymkhHqT75nSGUyxoumvb-PggKtBNW3NckWM=.9eaadefc-b396-4b95-b276-219d2a0d3590@github.com>
References: <HVGEzq_9ymkhHqT75nSGUyxoumvb-PggKtBNW3NckWM=.9eaadefc-b396-4b95-b276-219d2a0d3590@github.com>
Message-ID: <B50VrFF4cosZr3-q5epTDQUfy5jUu6xAc10_SMuZGvE=.e5048402-b44e-43c7-abfe-891a9c1141f1@github.com>

On Wed, 2 Jul 2025 11:00:44 GMT, Manuel H?ssig <mhaessig at openjdk.org> 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: <HVGEzq_9ymkhHqT75nSGUyxoumvb-PggKtBNW3NckWM=.9eaadefc-b396-4b95-b276-219d2a0d3590@github.com>
References: <HVGEzq_9ymkhHqT75nSGUyxoumvb-PggKtBNW3NckWM=.9eaadefc-b396-4b95-b276-219d2a0d3590@github.com>
Message-ID: <oqmJs3clVaLgoT4gTT3pk3nRp6EybIbvzIctSkyM2ZI=.03539e5f-a6aa-4d14-ba43-c26703a65f9f@github.com>

On Wed, 2 Jul 2025 11:00:44 GMT, Manuel H?ssig <mhaessig at openjdk.org> 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 <mhaessig at openjdk.org>
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: <CAA9v-_PnVORvTpvVMx99+-kp_3rAg-rfhwECXndk9t9TGUeZZA@mail.gmail.com>
References: <CAKD1RYv+g1L=ifA-_+Whrqb9cEHuH0zqFVSzW7AFg5Smahx2Bw@mail.gmail.com>
 <CAA9v-_PnVORvTpvVMx99+-kp_3rAg-rfhwECXndk9t9TGUeZZA@mail.gmail.com>
Message-ID: <CAKD1RYsNskYHgiUSozfNNrhp+McjQXWZLz0DWFOkwNGnteoKEQ@mail.gmail.com>

Yes.

I got two tests that show the behavior difference between downstream
exception and upstream exception:


@Test public void mapConcurrently_upstreamFailureDoesNotInterrupt() {

ConcurrentLinkedQueue<Integer> started = new ConcurrentLinkedQueue<>();

ConcurrentLinkedQueue<Integer> 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<Integer> started = new ConcurrentLinkedQueue<>();

ConcurrentLinkedQueue<Integer> 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 <davidalayachew at gmail.com>
wrote:

> These questions necessitate runnable examples. Do you have any
>
> On Thu, Jul 3, 2025, 10:37?AM Jige Yu <yujige at gmail.com> 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: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250704/bc1e91fe/attachment-0001.htm>

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: <wKrHfyjmzcMC0AKQosqSjKJj70vkFCTpJzgZTmQpEOI=.6d1e2d88-bd1d-449c-a576-1aac7c4fd751@github.com>

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: <CAKD1RYsNskYHgiUSozfNNrhp+McjQXWZLz0DWFOkwNGnteoKEQ@mail.gmail.com>
References: <CAKD1RYv+g1L=ifA-_+Whrqb9cEHuH0zqFVSzW7AFg5Smahx2Bw@mail.gmail.com>
 <CAA9v-_PnVORvTpvVMx99+-kp_3rAg-rfhwECXndk9t9TGUeZZA@mail.gmail.com>
 <CAKD1RYsNskYHgiUSozfNNrhp+McjQXWZLz0DWFOkwNGnteoKEQ@mail.gmail.com>
Message-ID: <CAKD1RYt4ZLRQ_f_-QtAjXS1R7RN32UGenWkTano-BJ1dtjW1dQ@mail.gmail.com>

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 <yujige at gmail.com> wrote:

> Yes.
>
> I got two tests that show the behavior difference between downstream
> exception and upstream exception:
>
>
> @Test public void mapConcurrently_upstreamFailureDoesNotInterrupt() {
>
> ConcurrentLinkedQueue<Integer> started = new ConcurrentLinkedQueue<>();
>
> ConcurrentLinkedQueue<Integer> 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<Integer> started = new ConcurrentLinkedQueue<>();
>
> ConcurrentLinkedQueue<Integer> 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 <davidalayachew at gmail.com>
> wrote:
>
>> These questions necessitate runnable examples. Do you have any
>>
>> On Thu, Jul 3, 2025, 10:37?AM Jige Yu <yujige at gmail.com> 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: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250704/29c0d541/attachment-0001.htm>

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: <inTdz3qZhm6cE-jJzmcigOHfOBrDr-ujIyL2pv3lHbk=.5d8687f8-f0d9-4f64-9f3c-b8951f5c8722@github.com>
References: <LQRWbokCOzo8paB0R3JzFrXWVt5mxyGpU1Xe5rTuN4Q=.a7affe6d-82e2-4115-866e-348acbe4d7f7@github.com>
 <7VTRz_XqYBSdQ54n7ADzTzYADZjDbgBw6XuW0jehSLI=.24d18b87-4553-47ab-8065-d92fbb5700ae@github.com>
 <FxpYMyFQVYy18ZaAXJUgY06Aa8_nx7iL8k3iNCxd7NQ=.cb4f0902-e1c9-40ad-8440-1e7624e9a822@github.com>
 <inTdz3qZhm6cE-jJzmcigOHfOBrDr-ujIyL2pv3lHbk=.5d8687f8-f0d9-4f64-9f3c-b8951f5c8722@github.com>
Message-ID: <Ava3MXit2kp6s-8Hrct90vCscN1qkpt2ZLfOAh2qd4s=.2cb53c53-e1a5-4b18-ba14-07729d51dc31@github.com>

On Fri, 4 Jul 2025 09:15:14 GMT, Xiaohong Gong <xgong at openjdk.org> 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: <LQRWbokCOzo8paB0R3JzFrXWVt5mxyGpU1Xe5rTuN4Q=.a7affe6d-82e2-4115-866e-348acbe4d7f7@github.com>
 <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 <xgong at openjdk.org> 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: <ry3bOAIy2G3MTSidAx9GU7rllzdPjR8a9Dl4xuimirM=.bf9a1c65-b2ff-4c21-b4c0-c77ef49d7cb3@github.com>
References: <hQqhqm1r_dSb9ThvtqEyTcbB31lJxpu7LohMCsAf5xo=.da3388a2-3033-4d95-95cf-7a40fe7e7068@github.com>
 <ry3bOAIy2G3MTSidAx9GU7rllzdPjR8a9Dl4xuimirM=.bf9a1c65-b2ff-4c21-b4c0-c77ef49d7cb3@github.com>
Message-ID: <LC2C5wpRyFbOWJ_hsa4koQm-XSMg-D1yECG7ZwFpzPw=.1c2eb8ad-4154-43ad-9b75-6bf1b90f3ed4@github.com>

On Thu, 3 Jul 2025 18:41:27 GMT, Chen Liang <liach at openjdk.org> 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: <LC2C5wpRyFbOWJ_hsa4koQm-XSMg-D1yECG7ZwFpzPw=.1c2eb8ad-4154-43ad-9b75-6bf1b90f3ed4@github.com>
References: <hQqhqm1r_dSb9ThvtqEyTcbB31lJxpu7LohMCsAf5xo=.da3388a2-3033-4d95-95cf-7a40fe7e7068@github.com>
 <ry3bOAIy2G3MTSidAx9GU7rllzdPjR8a9Dl4xuimirM=.bf9a1c65-b2ff-4c21-b4c0-c77ef49d7cb3@github.com>
 <LC2C5wpRyFbOWJ_hsa4koQm-XSMg-D1yECG7ZwFpzPw=.1c2eb8ad-4154-43ad-9b75-6bf1b90f3ed4@github.com>
Message-ID: <Y6HgBN3Sw7J0hcYU5Welu927sAt87E-YCKazjYkuf2Y=.111e6330-344c-4083-ab25-0c19bbd7cc6c@github.com>

On Sun, 6 Jul 2025 18:32:56 GMT, ExE Boss <duke at openjdk.org> 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: <SVfjXyK_qMEFq2tTBjWIckdjhNuq4vTT-afYlxKG3Fk=.7de6f1bb-c747-4474-ad8f-d4581266acd1@github.com>
References: <ukODVKiBC1LuwN3hngG_vkkhd1QJO2TpvAUSKsR6Ko0=.43b5a21d-2a39-4ac1-a9de-549abcd72d40@github.com>
 <DTjy5tn75B091PzQPau6hp0s3eKh0UUQGUpQQoFLSVM=.06514ff0-fdef-4266-9808-d6f6442afe8a@github.com>
 <RNMCq1cpE34SOYKL6NMAGIEmrA1U-iijRU9sYXqqoYY=.718064dd-8f7a-4806-92da-11d9289917bc@github.com>
 <7GrGfBF_v8F0v02sRHC78ofMZwpMdzQZaHeYlNvi_N0=.93defb9e-ca9b-41b4-8722-1746692e2316@github.com>
 <SVfjXyK_qMEFq2tTBjWIckdjhNuq4vTT-afYlxKG3Fk=.7de6f1bb-c747-4474-ad8f-d4581266acd1@github.com>
Message-ID: <fG1xZcCJ7R5kUjEtm6qMh8rMakKdlWRyoc0wI9Vk3j4=.848beb34-16fb-4127-bcf3-8e375aa49fb5@github.com>

On Wed, 2 Jul 2025 08:24:22 GMT, Emanuel Peter <epeter at openjdk.org> 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: <IYi6FEmJKMBIp5of9J8EB-cRTYIDKSQ7IK-3O6_-qNM=.02af83af-bf47-4e47-a400-cec89cba031f@github.com>

On Sun, 13 Apr 2025 09:49:46 GMT, Chen Liang <liach at openjdk.org> 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: <hYGdx19wuXXTQBsA4nRLu7pgyi0DD5Ytyz5Y-FgyMmQ=.a953cbeb-a310-48d3-818c-fd8d1caafd7d@github.com>

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: <hYGdx19wuXXTQBsA4nRLu7pgyi0DD5Ytyz5Y-FgyMmQ=.a953cbeb-a310-48d3-818c-fd8d1caafd7d@github.com>
References: <hYGdx19wuXXTQBsA4nRLu7pgyi0DD5Ytyz5Y-FgyMmQ=.a953cbeb-a310-48d3-818c-fd8d1caafd7d@github.com>
Message-ID: <iKunJDdbxkVFRFCxTAC6vlRnGuqlB4MZskt4ICBBY2U=.8cb33aea-1270-4822-8053-900cdfe78bc0@github.com>

On Mon, 7 Jul 2025 03:05:15 GMT, Mohamed Issa <missa at openjdk.org> 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: <DTjy5tn75B091PzQPau6hp0s3eKh0UUQGUpQQoFLSVM=.06514ff0-fdef-4266-9808-d6f6442afe8a@github.com>
References: <ukODVKiBC1LuwN3hngG_vkkhd1QJO2TpvAUSKsR6Ko0=.43b5a21d-2a39-4ac1-a9de-549abcd72d40@github.com>
 <DTjy5tn75B091PzQPau6hp0s3eKh0UUQGUpQQoFLSVM=.06514ff0-fdef-4266-9808-d6f6442afe8a@github.com>
Message-ID: <NU_HOObJ9KM0ZPI7xd1DcwxCDKe4-dC9cIjb05W5Pv4=.5dd9c192-cee8-4ad6-b8d2-0f33350b434a@github.com>

On Wed, 25 Jun 2025 09:16:48 GMT, Xiaohong Gong <xgong at openjdk.org> 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: <V32l6pOUkSgvcOnQ4-o4qeQxrYw2EeRNwLI1njc4CVE=.a39617e9-4a38-465c-9916-0404345dc873@github.com>
References: <mWHKJozX3YTvBOjLDUa1_2QQiNm6xVc2rb1FtXcZzPc=.e2405ec4-09ed-46c1-acd5-3f39083fce3f@github.com>
 <V32l6pOUkSgvcOnQ4-o4qeQxrYw2EeRNwLI1njc4CVE=.a39617e9-4a38-465c-9916-0404345dc873@github.com>
Message-ID: <f_NhsjsNCsL7uj5OwKbyka28mWKGsYz5itt9ndBxzZk=.c9a79d39-e5e2-4842-a6e1-2727c47e96ea@github.com>

On Wed, 25 Jun 2025 10:08:23 GMT, erifan <duke at openjdk.org> 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: <fG1xZcCJ7R5kUjEtm6qMh8rMakKdlWRyoc0wI9Vk3j4=.848beb34-16fb-4127-bcf3-8e375aa49fb5@github.com>
References: <ukODVKiBC1LuwN3hngG_vkkhd1QJO2TpvAUSKsR6Ko0=.43b5a21d-2a39-4ac1-a9de-549abcd72d40@github.com>
 <DTjy5tn75B091PzQPau6hp0s3eKh0UUQGUpQQoFLSVM=.06514ff0-fdef-4266-9808-d6f6442afe8a@github.com>
 <RNMCq1cpE34SOYKL6NMAGIEmrA1U-iijRU9sYXqqoYY=.718064dd-8f7a-4806-92da-11d9289917bc@github.com>
 <7GrGfBF_v8F0v02sRHC78ofMZwpMdzQZaHeYlNvi_N0=.93defb9e-ca9b-41b4-8722-1746692e2316@github.com>
 <SVfjXyK_qMEFq2tTBjWIckdjhNuq4vTT-afYlxKG3Fk=.7de6f1bb-c747-4474-ad8f-d4581266acd1@github.com>
 <fG1xZcCJ7R5kUjEtm6qMh8rMakKdlWRyoc0wI9Vk3j4=.848beb34-16fb-4127-bcf3-8e375aa49fb5@github.com>
Message-ID: <bKwajvXZFu-D6bLQG39IgAgYq3QggUV-aPVRVs5h5X0=.0928f80e-2552-48cb-a659-7ffe8714f2e4@github.com>

On Mon, 7 Jul 2025 02:05:06 GMT, Xiaohong Gong <xgong at openjdk.org> 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: <ukODVKiBC1LuwN3hngG_vkkhd1QJO2TpvAUSKsR6Ko0=.43b5a21d-2a39-4ac1-a9de-549abcd72d40@github.com>
References: <ukODVKiBC1LuwN3hngG_vkkhd1QJO2TpvAUSKsR6Ko0=.43b5a21d-2a39-4ac1-a9de-549abcd72d40@github.com>
Message-ID: <XjmOn7QfH9R0A9aKHatn9SN4XDHrEi_o3uN1j0JtPRw=.81ccd8fb-55d0-49e3-abb8-cc9092745ad9@github.com>

On Fri, 9 May 2025 07:35:41 GMT, Xiaohong Gong <xgong at openjdk.org> 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 <xgong at openjdk.org>
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: <LQRWbokCOzo8paB0R3JzFrXWVt5mxyGpU1Xe5rTuN4Q=.a7affe6d-82e2-4115-866e-348acbe4d7f7@github.com>
 <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 <fgao at openjdk.org> 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: <aaNvKy2H8IvUkHAcggVbgtjJwnrRmljxdTDhXu3HZPo=.ec889fee-c52d-465a-873c-cf3a0f4d7868@github.com>

On Fri, 27 Jun 2025 14:32:11 GMT, Andrew Haley <aph at openjdk.org> 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 <aph at openjdk.org>
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: <CAKD1RYv+g1L=ifA-_+Whrqb9cEHuH0zqFVSzW7AFg5Smahx2Bw@mail.gmail.com>
References: <CAKD1RYv+g1L=ifA-_+Whrqb9cEHuH0zqFVSzW7AFg5Smahx2Bw@mail.gmail.com>
Message-ID: <MW4PR10MB57740D5C55846B248FD24B4DFF4FA@MW4PR10MB5774.namprd10.prod.outlook.com>

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 <core-libs-dev-retn at openjdk.org> on behalf of Jige Yu <yujige at gmail.com>
Sent: Thursday, 3 July 2025 16:36
To: core-libs-dev at openjdk.org <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: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250707/dcc3130a/attachment-0001.htm>

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: <f_NhsjsNCsL7uj5OwKbyka28mWKGsYz5itt9ndBxzZk=.c9a79d39-e5e2-4842-a6e1-2727c47e96ea@github.com>
References: <mWHKJozX3YTvBOjLDUa1_2QQiNm6xVc2rb1FtXcZzPc=.e2405ec4-09ed-46c1-acd5-3f39083fce3f@github.com>
 <V32l6pOUkSgvcOnQ4-o4qeQxrYw2EeRNwLI1njc4CVE=.a39617e9-4a38-465c-9916-0404345dc873@github.com>
 <f_NhsjsNCsL7uj5OwKbyka28mWKGsYz5itt9ndBxzZk=.c9a79d39-e5e2-4842-a6e1-2727c47e96ea@github.com>
Message-ID: <Nw61IEd87pKfazr9DVWXHq1Ap71bndo5VscValJpqTs=.f593ada6-ef21-4d9b-9f91-faaf1f7947a2@github.com>

On Mon, 7 Jul 2025 06:19:15 GMT, Emanuel Peter <epeter at openjdk.org> 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: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
Message-ID: <ClKLGAkhleLM-G6MbjUEcX0_Y8vQD6UcJc67yxBeFdk=.70554fcf-8f8e-488c-874e-76ba7372843b@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 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: <ry3bOAIy2G3MTSidAx9GU7rllzdPjR8a9Dl4xuimirM=.bf9a1c65-b2ff-4c21-b4c0-c77ef49d7cb3@github.com>
References: <hQqhqm1r_dSb9ThvtqEyTcbB31lJxpu7LohMCsAf5xo=.da3388a2-3033-4d95-95cf-7a40fe7e7068@github.com>
 <ry3bOAIy2G3MTSidAx9GU7rllzdPjR8a9Dl4xuimirM=.bf9a1c65-b2ff-4c21-b4c0-c77ef49d7cb3@github.com>
Message-ID: <rYXSnbM_L_gYi6HtWacqGzKVxh9FutK3xvqNKleIcIE=.7c02c7e2-3305-4c47-b80b-e1c695e507c1@github.com>

On Thu, 3 Jul 2025 18:41:27 GMT, Chen Liang <liach at openjdk.org> 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: <ry3bOAIy2G3MTSidAx9GU7rllzdPjR8a9Dl4xuimirM=.bf9a1c65-b2ff-4c21-b4c0-c77ef49d7cb3@github.com>
References: <hQqhqm1r_dSb9ThvtqEyTcbB31lJxpu7LohMCsAf5xo=.da3388a2-3033-4d95-95cf-7a40fe7e7068@github.com>
 <ry3bOAIy2G3MTSidAx9GU7rllzdPjR8a9Dl4xuimirM=.bf9a1c65-b2ff-4c21-b4c0-c77ef49d7cb3@github.com>
Message-ID: <mzp3EIZUsjV-ygc0JzQp6TgqGIIuZGW8Wkk6ae5Wmwc=.a4140bf6-d2a5-4e3c-b3e9-193287674d10@github.com>

On Thu, 3 Jul 2025 18:41:27 GMT, Chen Liang <liach at openjdk.org> 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: <mzp3EIZUsjV-ygc0JzQp6TgqGIIuZGW8Wkk6ae5Wmwc=.a4140bf6-d2a5-4e3c-b3e9-193287674d10@github.com>
References: <hQqhqm1r_dSb9ThvtqEyTcbB31lJxpu7LohMCsAf5xo=.da3388a2-3033-4d95-95cf-7a40fe7e7068@github.com>
 <ry3bOAIy2G3MTSidAx9GU7rllzdPjR8a9Dl4xuimirM=.bf9a1c65-b2ff-4c21-b4c0-c77ef49d7cb3@github.com>
 <mzp3EIZUsjV-ygc0JzQp6TgqGIIuZGW8Wkk6ae5Wmwc=.a4140bf6-d2a5-4e3c-b3e9-193287674d10@github.com>
Message-ID: <wY6pmYZnJEqyByXwBgM1VoI_CQnucGuRDrPUoPs8w4k=.e1bcad19-bc25-4b37-829f-b80c85d1d671@github.com>

On Mon, 7 Jul 2025 09:56:07 GMT, Alan Bateman <alanb at openjdk.org> 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: <LQRWbokCOzo8paB0R3JzFrXWVt5mxyGpU1Xe5rTuN4Q=.a7affe6d-82e2-4115-866e-348acbe4d7f7@github.com>
 <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: <bPQmfuq84oQdo1Kn0UphJstQpeOiiwGXgpES1t7BmDg=.b064e28b-cdcb-43ed-afcf-886b662df91c@github.com>

On Mon, 7 Jul 2025 06:59:20 GMT, Xiaohong Gong <xgong at openjdk.org> 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: <rYXSnbM_L_gYi6HtWacqGzKVxh9FutK3xvqNKleIcIE=.7c02c7e2-3305-4c47-b80b-e1c695e507c1@github.com>
References: <hQqhqm1r_dSb9ThvtqEyTcbB31lJxpu7LohMCsAf5xo=.da3388a2-3033-4d95-95cf-7a40fe7e7068@github.com>
 <ry3bOAIy2G3MTSidAx9GU7rllzdPjR8a9Dl4xuimirM=.bf9a1c65-b2ff-4c21-b4c0-c77ef49d7cb3@github.com>
 <rYXSnbM_L_gYi6HtWacqGzKVxh9FutK3xvqNKleIcIE=.7c02c7e2-3305-4c47-b80b-e1c695e507c1@github.com>
Message-ID: <KTciYdwCgUJ1otXc_7HjgGHWqLioPuVWVnhEeTFpQxw=.afc39270-80d2-443e-888d-cf98260519d5@github.com>

On Mon, 7 Jul 2025 09:54:28 GMT, Per Minborg <pminborg at openjdk.org> 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: <wY6pmYZnJEqyByXwBgM1VoI_CQnucGuRDrPUoPs8w4k=.e1bcad19-bc25-4b37-829f-b80c85d1d671@github.com>
References: <hQqhqm1r_dSb9ThvtqEyTcbB31lJxpu7LohMCsAf5xo=.da3388a2-3033-4d95-95cf-7a40fe7e7068@github.com>
 <ry3bOAIy2G3MTSidAx9GU7rllzdPjR8a9Dl4xuimirM=.bf9a1c65-b2ff-4c21-b4c0-c77ef49d7cb3@github.com>
 <mzp3EIZUsjV-ygc0JzQp6TgqGIIuZGW8Wkk6ae5Wmwc=.a4140bf6-d2a5-4e3c-b3e9-193287674d10@github.com>
 <wY6pmYZnJEqyByXwBgM1VoI_CQnucGuRDrPUoPs8w4k=.e1bcad19-bc25-4b37-829f-b80c85d1d671@github.com>
Message-ID: <3stoVvRmIX7pk8ehqJSYzQwDu2MgQHPnezsoCgEo9Xo=.64f6a467-d0eb-47be-993d-e64a53a7e442@github.com>

On Mon, 7 Jul 2025 09:58:15 GMT, Viktor Klang <vklang at openjdk.org> 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: <FzgwQVIvxa7Cj-styZff78lzcHRNo0_whXyTvVpGE50=.b10dd9d4-04e9-4baa-a7af-b708e8b13b9f@github.com>
References: <FzgwQVIvxa7Cj-styZff78lzcHRNo0_whXyTvVpGE50=.b10dd9d4-04e9-4baa-a7af-b708e8b13b9f@github.com>
Message-ID: <YkQ9TsZJQjDwfg3U-x1Jy7tFSM-A_TK3K7WiZ3FaqD0=.7b3c9e7d-2bd0-4bdc-858c-fd7a05b0e7df@github.com>

On Wed, 28 May 2025 03:03:45 GMT, Stuart Marks <smarks at openjdk.org> 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: <tt7smwtk5Lj4CC0R41IyWe6aLXA2JZPrJT3Bq1ILHr0=.abd86704-19f0-4350-b218-184ee0917f1f@github.com>
References: <tt7smwtk5Lj4CC0R41IyWe6aLXA2JZPrJT3Bq1ILHr0=.abd86704-19f0-4350-b218-184ee0917f1f@github.com>
Message-ID: <OC28lPKl-HlNSudW-YrzcXjUBkIXHRhLwtai_ybCJxw=.33df09f3-67dc-458b-bb6a-72060db5d99f@github.com>

> 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: <FzgwQVIvxa7Cj-styZff78lzcHRNo0_whXyTvVpGE50=.b10dd9d4-04e9-4baa-a7af-b708e8b13b9f@github.com>
References: <FzgwQVIvxa7Cj-styZff78lzcHRNo0_whXyTvVpGE50=.b10dd9d4-04e9-4baa-a7af-b708e8b13b9f@github.com>
Message-ID: <UdAffQb4f-lcn1_K6fPUIJTcWq97ZdNL0-SPVDjKCII=.471fe703-c7e1-4422-a857-dfbbdf113fe9@github.com>

On Wed, 28 May 2025 03:03:45 GMT, Stuart Marks <smarks at openjdk.org> 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<E> 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: <FzgwQVIvxa7Cj-styZff78lzcHRNo0_whXyTvVpGE50=.b10dd9d4-04e9-4baa-a7af-b708e8b13b9f@github.com>
References: <FzgwQVIvxa7Cj-styZff78lzcHRNo0_whXyTvVpGE50=.b10dd9d4-04e9-4baa-a7af-b708e8b13b9f@github.com>
Message-ID: <KkUUQqqjDZFcm-sPf4nMYlku3-6Hr_2KqZmbfJ51aEo=.b3467f51-03a2-4cd1-aee3-b39f3b5ea480@github.com>

On Wed, 28 May 2025 03:03:45 GMT, Stuart Marks <smarks at openjdk.org> 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: <d7o_FmQ7sBVnMSOrmQnN6oAMmgrZRuYg01W7zYDP5d4=.6c483004-7cb9-4703-9f9b-ccdbac9eb881@github.com>

On Wed, 18 Jun 2025 20:16:18 GMT, Roger Riggs <rriggs at openjdk.org> 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 <rriggs at openjdk.org>
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: <FzgwQVIvxa7Cj-styZff78lzcHRNo0_whXyTvVpGE50=.b10dd9d4-04e9-4baa-a7af-b708e8b13b9f@github.com>
References: <FzgwQVIvxa7Cj-styZff78lzcHRNo0_whXyTvVpGE50=.b10dd9d4-04e9-4baa-a7af-b708e8b13b9f@github.com>
Message-ID: <93htmEhZdx-X66IxK5qMvJMC4MT7zQJe4vhUf1QPkzk=.c5bee49c-478e-42e6-a7e4-c7dceef86870@github.com>

On Wed, 28 May 2025 03:03:45 GMT, Stuart Marks <smarks at openjdk.org> 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<E> 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: <FzgwQVIvxa7Cj-styZff78lzcHRNo0_whXyTvVpGE50=.b10dd9d4-04e9-4baa-a7af-b708e8b13b9f@github.com>
References: <FzgwQVIvxa7Cj-styZff78lzcHRNo0_whXyTvVpGE50=.b10dd9d4-04e9-4baa-a7af-b708e8b13b9f@github.com>
Message-ID: <TGox35uNLWMLwuFX_yf6bc5Lrn4pQpFG_iZBGPz6fGs=.3eebcbf4-167e-4a5f-9f9d-387e7e2b8725@github.com>

On Wed, 28 May 2025 03:03:45 GMT, Stuart Marks <smarks at openjdk.org> 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: <TGox35uNLWMLwuFX_yf6bc5Lrn4pQpFG_iZBGPz6fGs=.3eebcbf4-167e-4a5f-9f9d-387e7e2b8725@github.com>
References: <FzgwQVIvxa7Cj-styZff78lzcHRNo0_whXyTvVpGE50=.b10dd9d4-04e9-4baa-a7af-b708e8b13b9f@github.com>
 <TGox35uNLWMLwuFX_yf6bc5Lrn4pQpFG_iZBGPz6fGs=.3eebcbf4-167e-4a5f-9f9d-387e7e2b8725@github.com>
Message-ID: <bxbOmts0svv4Oc6cuNHVq5d0MR-vGCMudnPcsFQW5cQ=.ebc0db59-ec1b-44f0-84b8-2379f718462a@github.com>

On Mon, 7 Jul 2025 12:58:39 GMT, Jaikiran Pai <jpai at openjdk.org> 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: <LQRWbokCOzo8paB0R3JzFrXWVt5mxyGpU1Xe5rTuN4Q=.a7affe6d-82e2-4115-866e-348acbe4d7f7@github.com>
 <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: <x62Oc0s14YVHv3PWiS2P1XZnwZCPq3ZP3XJcPyykpzc=.2581c202-e462-4a8b-a788-19ce02d7e294@github.com>

On Mon, 7 Jul 2025 06:59:20 GMT, Xiaohong Gong <xgong at openjdk.org> 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: <pRLwzmItSydBfbThg4hoOE_eNwBa2rnxLYB0-sEZPis=.1e90ff84-af12-4949-9151-cca0a6a9eb9a@github.com>

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: <NoXw4JZ1pEpfRd-hlC_5GdTwHNZQVQ9pwxamN_KX7fo=.43be73f7-c027-4af7-9e1f-3b8bfeb87a19@github.com>

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: <NoXw4JZ1pEpfRd-hlC_5GdTwHNZQVQ9pwxamN_KX7fo=.43be73f7-c027-4af7-9e1f-3b8bfeb87a19@github.com>
References: <NoXw4JZ1pEpfRd-hlC_5GdTwHNZQVQ9pwxamN_KX7fo=.43be73f7-c027-4af7-9e1f-3b8bfeb87a19@github.com>
Message-ID: <I1RsOyovZBEeF4JCIbDA53cg0hANod3GcDDf5kpo-mI=.0c323da9-015e-4c4e-87be-143911196d19@github.com>

On Mon, 7 Jul 2025 16:13:08 GMT, Andrew Haley <aph at openjdk.org> 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: <NoXw4JZ1pEpfRd-hlC_5GdTwHNZQVQ9pwxamN_KX7fo=.43be73f7-c027-4af7-9e1f-3b8bfeb87a19@github.com>
References: <NoXw4JZ1pEpfRd-hlC_5GdTwHNZQVQ9pwxamN_KX7fo=.43be73f7-c027-4af7-9e1f-3b8bfeb87a19@github.com>
Message-ID: <-wBBj6wgMQayipWS3L3-L5ItuUX0OeHcjQR22tci3pg=.a340f85a-683b-40e5-9cec-afa62efe11fb@github.com>

On Mon, 7 Jul 2025 16:13:08 GMT, Andrew Haley <aph at openjdk.org> 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: <hYGdx19wuXXTQBsA4nRLu7pgyi0DD5Ytyz5Y-FgyMmQ=.a953cbeb-a310-48d3-818c-fd8d1caafd7d@github.com>
References: <hYGdx19wuXXTQBsA4nRLu7pgyi0DD5Ytyz5Y-FgyMmQ=.a953cbeb-a310-48d3-818c-fd8d1caafd7d@github.com>
Message-ID: <yyN0jPn_XoNypYbnSd4IZqOwTGBArdUT_AVuHAalmA4=.71b030d8-281a-4ea3-8790-85ad7c8bb8fa@github.com>

On Mon, 7 Jul 2025 03:05:15 GMT, Mohamed Issa <missa at openjdk.org> 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: <hYGdx19wuXXTQBsA4nRLu7pgyi0DD5Ytyz5Y-FgyMmQ=.a953cbeb-a310-48d3-818c-fd8d1caafd7d@github.com>
References: <hYGdx19wuXXTQBsA4nRLu7pgyi0DD5Ytyz5Y-FgyMmQ=.a953cbeb-a310-48d3-818c-fd8d1caafd7d@github.com>
Message-ID: <rF2JkysAnRhQJe6P2RLD0H94OFzaY2vIXyaTQJVa42c=.3d07381b-3c2e-49d4-8446-a91ea50c5ae8@github.com>

On Mon, 7 Jul 2025 03:05:15 GMT, Mohamed Issa <missa at openjdk.org> 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: <sjjmTxOVrKbRe-569fhfmuG_37DS-TQbP0LyhjcH4Ec=.eed618ba-0e4e-479e-8356-c2a9206d4f23@github.com>

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: <sjjmTxOVrKbRe-569fhfmuG_37DS-TQbP0LyhjcH4Ec=.eed618ba-0e4e-479e-8356-c2a9206d4f23@github.com>
References: <sjjmTxOVrKbRe-569fhfmuG_37DS-TQbP0LyhjcH4Ec=.eed618ba-0e4e-479e-8356-c2a9206d4f23@github.com>
Message-ID: <c_mVujk1Ss_CucknS4b0XA-2fR9OTkY0imGREyDFhMM=.ab370eb1-3ad5-482f-81ee-1392607f9ff9@github.com>

On Mon, 7 Jul 2025 18:29:34 GMT, Roger Riggs <rriggs at openjdk.org> 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: <rwUkW0OqmfUERgNGYbOFQAmQaarEBkP0HuUdFByPq5Y=.79d4b106-123c-4d38-b06e-c2c986a4337d@github.com>

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: <rwUkW0OqmfUERgNGYbOFQAmQaarEBkP0HuUdFByPq5Y=.79d4b106-123c-4d38-b06e-c2c986a4337d@github.com>
References: <rwUkW0OqmfUERgNGYbOFQAmQaarEBkP0HuUdFByPq5Y=.79d4b106-123c-4d38-b06e-c2c986a4337d@github.com>
Message-ID: <p9NaoU7fE_8fOhUxVKkv9iQzOer-guAQwLvRm2JFL70=.80f86330-0fd0-49b6-ba1e-36f8b97d0021@github.com>

On Mon, 7 Jul 2025 19:08:22 GMT, Naoto Sato <naoto at openjdk.org> 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: <rwUkW0OqmfUERgNGYbOFQAmQaarEBkP0HuUdFByPq5Y=.79d4b106-123c-4d38-b06e-c2c986a4337d@github.com>
References: <rwUkW0OqmfUERgNGYbOFQAmQaarEBkP0HuUdFByPq5Y=.79d4b106-123c-4d38-b06e-c2c986a4337d@github.com>
Message-ID: <VnnQjaCmPw5sLDsF7HHJm4NFNCVJZ9ZytC63qnTp3HE=.6b36cdab-99f0-47cb-ac5d-7f07ba81d8b6@github.com>

> 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: <VnnQjaCmPw5sLDsF7HHJm4NFNCVJZ9ZytC63qnTp3HE=.6b36cdab-99f0-47cb-ac5d-7f07ba81d8b6@github.com>
References: <rwUkW0OqmfUERgNGYbOFQAmQaarEBkP0HuUdFByPq5Y=.79d4b106-123c-4d38-b06e-c2c986a4337d@github.com>
 <VnnQjaCmPw5sLDsF7HHJm4NFNCVJZ9ZytC63qnTp3HE=.6b36cdab-99f0-47cb-ac5d-7f07ba81d8b6@github.com>
Message-ID: <5C6YrFFpsog2GZHoVNYRi_6J9cHeKSxYaaXKUdX7Pnw=.891f3c24-5ae3-409a-ab06-098500034f1d@github.com>

On Mon, 7 Jul 2025 20:24:21 GMT, Naoto Sato <naoto at openjdk.org> 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: <tcZkZgScJXJYpRK68NSRUTl7gcOhePhABSQz0DOzArI=.137600e0-7656-4c7a-85de-c340173467fc@github.com>
References: <tcZkZgScJXJYpRK68NSRUTl7gcOhePhABSQz0DOzArI=.137600e0-7656-4c7a-85de-c340173467fc@github.com>
Message-ID: <qo6413IipMwAHrTk2AUKTjLSM5Ea-czi3MfwYkduTe0=.6ba4abfa-2a69-4b67-99f0-b297e03f4dd2@github.com>

On Tue, 29 Apr 2025 17:02:38 GMT, kabutz <duke at openjdk.org> 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: <sjjmTxOVrKbRe-569fhfmuG_37DS-TQbP0LyhjcH4Ec=.eed618ba-0e4e-479e-8356-c2a9206d4f23@github.com>
References: <sjjmTxOVrKbRe-569fhfmuG_37DS-TQbP0LyhjcH4Ec=.eed618ba-0e4e-479e-8356-c2a9206d4f23@github.com>
Message-ID: <_wb5geiCD8EHh1mi6wCwBSfJ43hqtxY7l2ifEhUFd-U=.4463188e-d82c-43f5-9e10-674e70a140df@github.com>

On Mon, 7 Jul 2025 18:29:34 GMT, Roger Riggs <rriggs at openjdk.org> 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 <rriggs at openjdk.org>
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 <almatvee at openjdk.org> 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: <B8hl437Phlq-605VfbqQXM8Fbzcfb3NWXGzKV6QehkI=.ef2aa4a8-455c-42a6-9fad-38c376fbc4db@github.com>

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: <B8hl437Phlq-605VfbqQXM8Fbzcfb3NWXGzKV6QehkI=.ef2aa4a8-455c-42a6-9fad-38c376fbc4db@github.com>
References: <B8hl437Phlq-605VfbqQXM8Fbzcfb3NWXGzKV6QehkI=.ef2aa4a8-455c-42a6-9fad-38c376fbc4db@github.com>
Message-ID: <F4F43BFD-AD00-48E2-ACE8-968977996D4A@gmail.com>

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 <almatvee at openjdk.org> wrote:
> 
> Additional changes:
> - The bundle's top directory name will have the ".jdk" suffix.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250707/6114d1a6/attachment-0001.htm>

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: <B8hl437Phlq-605VfbqQXM8Fbzcfb3NWXGzKV6QehkI=.ef2aa4a8-455c-42a6-9fad-38c376fbc4db@github.com>
References: <B8hl437Phlq-605VfbqQXM8Fbzcfb3NWXGzKV6QehkI=.ef2aa4a8-455c-42a6-9fad-38c376fbc4db@github.com>
Message-ID: <h0x3LysInvyEMcWkU8e8PxdSSkCeC4gzTNSzfemtzTw=.f8be7351-6e98-45bd-a807-3e54a0e83a0d@github.com>

> 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: <F4F43BFD-AD00-48E2-ACE8-968977996D4A@gmail.com>
References: <B8hl437Phlq-605VfbqQXM8Fbzcfb3NWXGzKV6QehkI=.ef2aa4a8-455c-42a6-9fad-38c376fbc4db@github.com>
 <F4F43BFD-AD00-48E2-ACE8-968977996D4A@gmail.com>
Message-ID: <quAnS8W0L7KQv049YwLsb_dMysIk0Hwbu_1DzALeE-I=.dfedd58c-01fc-4f20-b64d-8b0674ede8cb@github.com>

On Mon, 7 Jul 2025 22:54:32 GMT, Michael Hall <mik3hall at gmail.com> 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: <mgnQ7Zo-OFTIYUoAJH5tJy0_67MHBajuxtcfXr2PnXI=.ff7d9863-c8b8-4976-9dc5-d494a9526b0c@github.com>

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: <rF2JkysAnRhQJe6P2RLD0H94OFzaY2vIXyaTQJVa42c=.3d07381b-3c2e-49d4-8446-a91ea50c5ae8@github.com>
References: <hYGdx19wuXXTQBsA4nRLu7pgyi0DD5Ytyz5Y-FgyMmQ=.a953cbeb-a310-48d3-818c-fd8d1caafd7d@github.com>
 <rF2JkysAnRhQJe6P2RLD0H94OFzaY2vIXyaTQJVa42c=.3d07381b-3c2e-49d4-8446-a91ea50c5ae8@github.com>
Message-ID: <DhH0T1l6DljbZXq4tstMPUjmUeLSqE7HCDFCHyL-7A0=.d5b0e360-3f53-440b-9226-3d21e0619745@github.com>

On Mon, 7 Jul 2025 18:03:54 GMT, Joe Darcy <darcy at openjdk.org> 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: <h0x3LysInvyEMcWkU8e8PxdSSkCeC4gzTNSzfemtzTw=.f8be7351-6e98-45bd-a807-3e54a0e83a0d@github.com>
References: <B8hl437Phlq-605VfbqQXM8Fbzcfb3NWXGzKV6QehkI=.ef2aa4a8-455c-42a6-9fad-38c376fbc4db@github.com>
 <h0x3LysInvyEMcWkU8e8PxdSSkCeC4gzTNSzfemtzTw=.f8be7351-6e98-45bd-a807-3e54a0e83a0d@github.com>
Message-ID: <Se9tlANKIhKj7MUn2eZNK9CvH2QEQE8WLAjgUZ3OeSQ=.df38ab16-3918-4cc2-b7ed-839e3a43cdfc@github.com>

On Mon, 7 Jul 2025 23:20:08 GMT, Alexander Matveev <almatvee at openjdk.org> 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: <yyN0jPn_XoNypYbnSd4IZqOwTGBArdUT_AVuHAalmA4=.71b030d8-281a-4ea3-8790-85ad7c8bb8fa@github.com>
References: <hYGdx19wuXXTQBsA4nRLu7pgyi0DD5Ytyz5Y-FgyMmQ=.a953cbeb-a310-48d3-818c-fd8d1caafd7d@github.com>
 <yyN0jPn_XoNypYbnSd4IZqOwTGBArdUT_AVuHAalmA4=.71b030d8-281a-4ea3-8790-85ad7c8bb8fa@github.com>
Message-ID: <Drup9Nkvcw7CHLGlJGtJmzSvYFQZd7dIU6qmnzBLXPQ=.940e6988-52d1-43fc-804c-30e87220a0a4@github.com>

On Mon, 7 Jul 2025 18:01:26 GMT, Joe Darcy <darcy at openjdk.org> 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: <h0x3LysInvyEMcWkU8e8PxdSSkCeC4gzTNSzfemtzTw=.f8be7351-6e98-45bd-a807-3e54a0e83a0d@github.com>
References: <B8hl437Phlq-605VfbqQXM8Fbzcfb3NWXGzKV6QehkI=.ef2aa4a8-455c-42a6-9fad-38c376fbc4db@github.com>
 <h0x3LysInvyEMcWkU8e8PxdSSkCeC4gzTNSzfemtzTw=.f8be7351-6e98-45bd-a807-3e54a0e83a0d@github.com>
Message-ID: <sZuRYhvgvkoUas8P4fvzvEX_UnADMpmteWA2FaG4ybk=.f4746fbe-3cb3-433c-8e84-95947eaeeae2@github.com>

On Mon, 7 Jul 2025 23:20:08 GMT, Alexander Matveev <almatvee at openjdk.org> 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<Path> 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: <iKunJDdbxkVFRFCxTAC6vlRnGuqlB4MZskt4ICBBY2U=.8cb33aea-1270-4822-8053-900cdfe78bc0@github.com>
References: <hYGdx19wuXXTQBsA4nRLu7pgyi0DD5Ytyz5Y-FgyMmQ=.a953cbeb-a310-48d3-818c-fd8d1caafd7d@github.com>
 <iKunJDdbxkVFRFCxTAC6vlRnGuqlB4MZskt4ICBBY2U=.8cb33aea-1270-4822-8053-900cdfe78bc0@github.com>
Message-ID: <Wse6mX1Slo3KvItTvCLqE_BMswyGSTDinY-Lp9Y-6nw=.54164a56-2d48-4c8a-8dcf-98c4e85fcbc5@github.com>

On Mon, 7 Jul 2025 04:48:18 GMT, Florian Weimer <fweimer at openjdk.org> 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: <h0x3LysInvyEMcWkU8e8PxdSSkCeC4gzTNSzfemtzTw=.f8be7351-6e98-45bd-a807-3e54a0e83a0d@github.com>
References: <B8hl437Phlq-605VfbqQXM8Fbzcfb3NWXGzKV6QehkI=.ef2aa4a8-455c-42a6-9fad-38c376fbc4db@github.com>
 <h0x3LysInvyEMcWkU8e8PxdSSkCeC4gzTNSzfemtzTw=.f8be7351-6e98-45bd-a807-3e54a0e83a0d@github.com>
Message-ID: <gvM68WRMpFJgzmMa5ziZG67h9oiJE57dDt2ed7ZkyXA=.bc719263-63fb-4a9f-84a7-52f8a46640cf@github.com>

On Mon, 7 Jul 2025 23:20:08 GMT, Alexander Matveev <almatvee at openjdk.org> 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: <h0x3LysInvyEMcWkU8e8PxdSSkCeC4gzTNSzfemtzTw=.f8be7351-6e98-45bd-a807-3e54a0e83a0d@github.com>
References: <B8hl437Phlq-605VfbqQXM8Fbzcfb3NWXGzKV6QehkI=.ef2aa4a8-455c-42a6-9fad-38c376fbc4db@github.com>
 <h0x3LysInvyEMcWkU8e8PxdSSkCeC4gzTNSzfemtzTw=.f8be7351-6e98-45bd-a807-3e54a0e83a0d@github.com>
Message-ID: <GcIbQX-YCGxqMeJVgoyWXXvRf6v3oyOnl5RknePcF2o=.9d0b4aa9-e34f-4ee9-bfbd-96e9e85b9312@github.com>

On Mon, 7 Jul 2025 23:20:08 GMT, Alexander Matveev <almatvee at openjdk.org> 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: <h0x3LysInvyEMcWkU8e8PxdSSkCeC4gzTNSzfemtzTw=.f8be7351-6e98-45bd-a807-3e54a0e83a0d@github.com>
References: <B8hl437Phlq-605VfbqQXM8Fbzcfb3NWXGzKV6QehkI=.ef2aa4a8-455c-42a6-9fad-38c376fbc4db@github.com>
 <h0x3LysInvyEMcWkU8e8PxdSSkCeC4gzTNSzfemtzTw=.f8be7351-6e98-45bd-a807-3e54a0e83a0d@github.com>
Message-ID: <j99XMHJeh3KbbW9vaa6KtBKdQQ0KkRiqZjloYgApotc=.3bf77203-1562-49a0-9c47-a4f3c867a4c4@github.com>

On Mon, 7 Jul 2025 23:20:08 GMT, Alexander Matveev <almatvee at openjdk.org> 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: <h0x3LysInvyEMcWkU8e8PxdSSkCeC4gzTNSzfemtzTw=.f8be7351-6e98-45bd-a807-3e54a0e83a0d@github.com>
References: <B8hl437Phlq-605VfbqQXM8Fbzcfb3NWXGzKV6QehkI=.ef2aa4a8-455c-42a6-9fad-38c376fbc4db@github.com>
 <h0x3LysInvyEMcWkU8e8PxdSSkCeC4gzTNSzfemtzTw=.f8be7351-6e98-45bd-a807-3e54a0e83a0d@github.com>
Message-ID: <r2D6Ru3qwVCjLpesxfDs43PJOU1Sb-ItLBGXRPVJD8k=.e33096e1-2dcf-4805-85d1-53b7cf962b5d@github.com>

On Mon, 7 Jul 2025 23:20:08 GMT, Alexander Matveev <almatvee at openjdk.org> 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: <h0x3LysInvyEMcWkU8e8PxdSSkCeC4gzTNSzfemtzTw=.f8be7351-6e98-45bd-a807-3e54a0e83a0d@github.com>
References: <B8hl437Phlq-605VfbqQXM8Fbzcfb3NWXGzKV6QehkI=.ef2aa4a8-455c-42a6-9fad-38c376fbc4db@github.com>
 <h0x3LysInvyEMcWkU8e8PxdSSkCeC4gzTNSzfemtzTw=.f8be7351-6e98-45bd-a807-3e54a0e83a0d@github.com>
Message-ID: <DleDJ3rlPFv61rsJ_rR8EahY83VEn5rhJhDMmREeTBQ=.5f895b4f-45a9-4311-a2b1-d4a7096feaa4@github.com>

On Mon, 7 Jul 2025 23:20:08 GMT, Alexander Matveev <almatvee at openjdk.org> 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: <h0x3LysInvyEMcWkU8e8PxdSSkCeC4gzTNSzfemtzTw=.f8be7351-6e98-45bd-a807-3e54a0e83a0d@github.com>
References: <B8hl437Phlq-605VfbqQXM8Fbzcfb3NWXGzKV6QehkI=.ef2aa4a8-455c-42a6-9fad-38c376fbc4db@github.com>
 <h0x3LysInvyEMcWkU8e8PxdSSkCeC4gzTNSzfemtzTw=.f8be7351-6e98-45bd-a807-3e54a0e83a0d@github.com>
Message-ID: <19xKrPQKXJ273i03KCYPSxiYAUQGNVTm49cP2VkMkHk=.7080a74d-34da-4a2d-b844-6cce78782989@github.com>

On Mon, 7 Jul 2025 23:20:08 GMT, Alexander Matveev <almatvee at openjdk.org> 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: <h0x3LysInvyEMcWkU8e8PxdSSkCeC4gzTNSzfemtzTw=.f8be7351-6e98-45bd-a807-3e54a0e83a0d@github.com>
References: <B8hl437Phlq-605VfbqQXM8Fbzcfb3NWXGzKV6QehkI=.ef2aa4a8-455c-42a6-9fad-38c376fbc4db@github.com>
 <h0x3LysInvyEMcWkU8e8PxdSSkCeC4gzTNSzfemtzTw=.f8be7351-6e98-45bd-a807-3e54a0e83a0d@github.com>
Message-ID: <LJZbmK9TMdsN1khO5ssTNXAhSOEHunMNUOYJ2BE2BSc=.07e6acac-ec95-4d0f-8415-ae8f1271223b@github.com>

On Mon, 7 Jul 2025 23:20:08 GMT, Alexander Matveev <almatvee at openjdk.org> 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: <h0x3LysInvyEMcWkU8e8PxdSSkCeC4gzTNSzfemtzTw=.f8be7351-6e98-45bd-a807-3e54a0e83a0d@github.com>
References: <B8hl437Phlq-605VfbqQXM8Fbzcfb3NWXGzKV6QehkI=.ef2aa4a8-455c-42a6-9fad-38c376fbc4db@github.com>
 <h0x3LysInvyEMcWkU8e8PxdSSkCeC4gzTNSzfemtzTw=.f8be7351-6e98-45bd-a807-3e54a0e83a0d@github.com>
Message-ID: <djehxEHC2zfrOsvBIHvsKoyhWnmS4k-aUc5pN1_pFn0=.f1cee960-9c35-472f-a54a-08075b0026e5@github.com>

On Mon, 7 Jul 2025 23:20:08 GMT, Alexander Matveev <almatvee at openjdk.org> 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: <h0x3LysInvyEMcWkU8e8PxdSSkCeC4gzTNSzfemtzTw=.f8be7351-6e98-45bd-a807-3e54a0e83a0d@github.com>
References: <B8hl437Phlq-605VfbqQXM8Fbzcfb3NWXGzKV6QehkI=.ef2aa4a8-455c-42a6-9fad-38c376fbc4db@github.com>
 <h0x3LysInvyEMcWkU8e8PxdSSkCeC4gzTNSzfemtzTw=.f8be7351-6e98-45bd-a807-3e54a0e83a0d@github.com>
Message-ID: <BwdvYUDW2rxkfafmCOeoTaSuNbmzsTDxhWRpb2IQ5pQ=.13d73745-afb9-491d-aed7-47901123cfc9@github.com>

On Mon, 7 Jul 2025 23:20:08 GMT, Alexander Matveev <almatvee at openjdk.org> 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: <h0x3LysInvyEMcWkU8e8PxdSSkCeC4gzTNSzfemtzTw=.f8be7351-6e98-45bd-a807-3e54a0e83a0d@github.com>
References: <B8hl437Phlq-605VfbqQXM8Fbzcfb3NWXGzKV6QehkI=.ef2aa4a8-455c-42a6-9fad-38c376fbc4db@github.com>
 <h0x3LysInvyEMcWkU8e8PxdSSkCeC4gzTNSzfemtzTw=.f8be7351-6e98-45bd-a807-3e54a0e83a0d@github.com>
Message-ID: <3UY0AddcQaqsoR6CqIV-2umUboVxbaCirghaeS5PQxo=.fee06abf-df37-493e-9639-6548855c1dc2@github.com>

On Mon, 7 Jul 2025 23:20:08 GMT, Alexander Matveev <almatvee at openjdk.org> 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: <?xml version="1.0" encoding="UTF-8"?>

What is the origin of this file?

src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/resources/RuntimeBundle-Info.plist.template line 6:

> 4: <dict>
> 5:         <key>CFBundleDevelopmentRegion</key>
> 6:         <string>English</string>

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: <h0x3LysInvyEMcWkU8e8PxdSSkCeC4gzTNSzfemtzTw=.f8be7351-6e98-45bd-a807-3e54a0e83a0d@github.com>
References: <B8hl437Phlq-605VfbqQXM8Fbzcfb3NWXGzKV6QehkI=.ef2aa4a8-455c-42a6-9fad-38c376fbc4db@github.com>
 <h0x3LysInvyEMcWkU8e8PxdSSkCeC4gzTNSzfemtzTw=.f8be7351-6e98-45bd-a807-3e54a0e83a0d@github.com>
Message-ID: <8puqNFN9LtsrDe6xF4EmRPBrT-CR3IRcOS62YFVwZD8=.7613bce6-badf-4664-baf7-67c94037d7b7@github.com>

On Mon, 7 Jul 2025 23:20:08 GMT, Alexander Matveev <almatvee at openjdk.org> 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<MacApplication, MacApplicationLayout> 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: <h0x3LysInvyEMcWkU8e8PxdSSkCeC4gzTNSzfemtzTw=.f8be7351-6e98-45bd-a807-3e54a0e83a0d@github.com>
References: <B8hl437Phlq-605VfbqQXM8Fbzcfb3NWXGzKV6QehkI=.ef2aa4a8-455c-42a6-9fad-38c376fbc4db@github.com>
 <h0x3LysInvyEMcWkU8e8PxdSSkCeC4gzTNSzfemtzTw=.f8be7351-6e98-45bd-a807-3e54a0e83a0d@github.com>
Message-ID: <_jJCDxm7G2TtaxeCPJFhENFZfFM5Ach8bBu9F6q0YZ8=.9c4ca1a8-5c2c-4a23-9c18-09dc53ff3493@github.com>

On Mon, 7 Jul 2025 23:20:08 GMT, Alexander Matveev <almatvee at openjdk.org> 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: <iXLvZEu6nm6K4U2AEmPsEAUQFE0a8dLjbg3nORen0_I=.1e6dbd0d-aaa0-4d6e-894b-c1e1b749d7d5@github.com>
References: <iXLvZEu6nm6K4U2AEmPsEAUQFE0a8dLjbg3nORen0_I=.1e6dbd0d-aaa0-4d6e-894b-c1e1b749d7d5@github.com>
Message-ID: <-TK5ziYVLfu1MOHf70wFHbnT7bhXhOq0mXLI4HOphJE=.37fea4b0-0383-4e9d-baf6-60f437ac92d1@github.com>

On Mon, 21 Oct 2024 14:34:30 GMT, Julian Waters <jwaters at openjdk.org> 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 <jwaters at openjdk.org>
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: <vT6zJlWPUg235GuAHNJbyAxkoONF2vljAuFTVygBoGk=.05690f62-9641-4990-855a-c908df24e064@github.com>
References: <otTjiRgCFQEeUbpfFTMzhXUVBU1cal8q_i7IrGs_n94=.c2f02ad8-6b0c-4daa-9995-8e4b42131eb4@github.com>
 <vT6zJlWPUg235GuAHNJbyAxkoONF2vljAuFTVygBoGk=.05690f62-9641-4990-855a-c908df24e064@github.com>
Message-ID: <rfLuoC6GYaQTru1_jqseSC266NbVP4Kxe2J6FikGXeQ=.97a3a13d-4f90-41f4-b210-a0080351cc06@github.com>

On Thu, 31 Oct 2024 05:43:11 GMT, Julian Waters <jwaters at openjdk.org> 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: <otTjiRgCFQEeUbpfFTMzhXUVBU1cal8q_i7IrGs_n94=.c2f02ad8-6b0c-4daa-9995-8e4b42131eb4@github.com>
References: <otTjiRgCFQEeUbpfFTMzhXUVBU1cal8q_i7IrGs_n94=.c2f02ad8-6b0c-4daa-9995-8e4b42131eb4@github.com>
Message-ID: <BiH2aLfK4drXAlv019OG10zJ7EVuyuXLB-U6VpprXkw=.d9de799f-7607-4ff2-b033-5614fdda16f7@github.com>

On Wed, 23 Oct 2024 04:40:50 GMT, Julian Waters <jwaters at openjdk.org> 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 <jwaters at openjdk.org>
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: <rfLuoC6GYaQTru1_jqseSC266NbVP4Kxe2J6FikGXeQ=.97a3a13d-4f90-41f4-b210-a0080351cc06@github.com>
References: <otTjiRgCFQEeUbpfFTMzhXUVBU1cal8q_i7IrGs_n94=.c2f02ad8-6b0c-4daa-9995-8e4b42131eb4@github.com>
 <vT6zJlWPUg235GuAHNJbyAxkoONF2vljAuFTVygBoGk=.05690f62-9641-4990-855a-c908df24e064@github.com>
 <rfLuoC6GYaQTru1_jqseSC266NbVP4Kxe2J6FikGXeQ=.97a3a13d-4f90-41f4-b210-a0080351cc06@github.com>
Message-ID: <lZLJ957P7sONaS2DMlqED9bApOqJk3jhx910dFjSdTs=.09ca21d0-f864-4f7e-b48b-a0c9c39cebef@github.com>

On Tue, 8 Jul 2025 01:28:04 GMT, Julian Waters <jwaters at openjdk.org> 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: <LQRWbokCOzo8paB0R3JzFrXWVt5mxyGpU1Xe5rTuN4Q=.a7affe6d-82e2-4115-866e-348acbe4d7f7@github.com>
 <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: <fSpa3gA9Zl7urXYYKaxCKD7pKFoomIdv31EOIb9Bfjg=.4dc05854-90b3-4044-90d9-303d4a834c38@github.com>

On Mon, 7 Jul 2025 06:59:20 GMT, Xiaohong Gong <xgong at openjdk.org> 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: <x62Oc0s14YVHv3PWiS2P1XZnwZCPq3ZP3XJcPyykpzc=.2581c202-e462-4a8b-a788-19ce02d7e294@github.com>
References: <LQRWbokCOzo8paB0R3JzFrXWVt5mxyGpU1Xe5rTuN4Q=.a7affe6d-82e2-4115-866e-348acbe4d7f7@github.com>
 <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>
 <x62Oc0s14YVHv3PWiS2P1XZnwZCPq3ZP3XJcPyykpzc=.2581c202-e462-4a8b-a788-19ce02d7e294@github.com>
Message-ID: <0vdCJFYxCI6hFnTL6rm3oKQcPuuIR2EbuyAOa0muqcw=.d5c249cb-9bf0-415d-ab22-de7387d8d8d1@github.com>

On Mon, 7 Jul 2025 13:23:15 GMT, Fei Gao <fgao at openjdk.org> 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: <MW4PR10MB57740D5C55846B248FD24B4DFF4FA@MW4PR10MB5774.namprd10.prod.outlook.com>
References: <CAKD1RYv+g1L=ifA-_+Whrqb9cEHuH0zqFVSzW7AFg5Smahx2Bw@mail.gmail.com>
 <MW4PR10MB57740D5C55846B248FD24B4DFF4FA@MW4PR10MB5774.namprd10.prod.outlook.com>
Message-ID: <CAKD1RYt_NrHVV4nEc3gZ4szCvhXzHLVWMKdAoxNj7jh4aGT7dQ@mail.gmail.com>

Thanks for the quick reply, Viktor!

On Mon, Jul 7, 2025 at 2:35?AM Viktor Klang <viktor.klang at oracle.com> 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 <core-libs-dev-retn at openjdk.org> on behalf of Jige
> Yu <yujige at gmail.com>
> *Sent:* Thursday, 3 July 2025 16:36
> *To:* core-libs-dev at openjdk.org <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: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250707/ee6028aa/attachment.htm>

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: <vT6zJlWPUg235GuAHNJbyAxkoONF2vljAuFTVygBoGk=.05690f62-9641-4990-855a-c908df24e064@github.com>
References: <otTjiRgCFQEeUbpfFTMzhXUVBU1cal8q_i7IrGs_n94=.c2f02ad8-6b0c-4daa-9995-8e4b42131eb4@github.com>
 <vT6zJlWPUg235GuAHNJbyAxkoONF2vljAuFTVygBoGk=.05690f62-9641-4990-855a-c908df24e064@github.com>
Message-ID: <AL7IdqZqHz7sM-oppG4NW7umIRhri6uP6EHbCiC3f8c=.9a16c98f-f47a-488c-83cf-cbefa6f4b206@github.com>

On Thu, 31 Oct 2024 05:43:11 GMT, Julian Waters <jwaters at openjdk.org> 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: <wKrHfyjmzcMC0AKQosqSjKJj70vkFCTpJzgZTmQpEOI=.6d1e2d88-bd1d-449c-a576-1aac7c4fd751@github.com>
References: <wKrHfyjmzcMC0AKQosqSjKJj70vkFCTpJzgZTmQpEOI=.6d1e2d88-bd1d-449c-a576-1aac7c4fd751@github.com>
Message-ID: <Chi3AesG1KOkXIpzMau3h9cI913osOzjumXYDdr371o=.3949d985-2347-42e1-bf46-7f03d7d1ef49@github.com>

On Sat, 5 Jul 2025 00:05:39 GMT, Kim Barrett <kbarrett at openjdk.org> 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: <eqA9zD_EnXUJr7Q_xq7OZbBzAxViuUHyzy0Tw6LtZ8U=.6868ebd9-4afa-4a03-8c2d-7addef9a2ddf@github.com>
References: <eqA9zD_EnXUJr7Q_xq7OZbBzAxViuUHyzy0Tw6LtZ8U=.6868ebd9-4afa-4a03-8c2d-7addef9a2ddf@github.com>
Message-ID: <faljFxtY2lMBqSxFK6WWmord2G6-X4aUf7JD1ROoxFY=.34fd5af8-62cf-46f2-994e-cebc3491b0f7@github.com>

On Tue, 3 Jun 2025 10:09:44 GMT, Nizar Benalla <nbenalla at openjdk.org> 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: <DFG37HcVVzx9JTGiYtjEt_E9hn9yjnUD7JwoakGsnh8=.e13460fe-a723-42c8-be1c-917d63246990@github.com>
References: <DFG37HcVVzx9JTGiYtjEt_E9hn9yjnUD7JwoakGsnh8=.e13460fe-a723-42c8-be1c-917d63246990@github.com>
Message-ID: <84bqpOT-0Mvgqr3173feXu3KGIdl3RIFMK9Kxrr3w1Q=.2bf8673e-1bc1-4c7f-a01a-f2ff51f9cc48@github.com>

On Thu, 3 Apr 2025 18:47:43 GMT, Matthew Donovan <mdonovan at openjdk.org> 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 <pid> 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: <mcPF1ypiHlYI3H4kgl0bwvU3KF_YO40Yo6aY6w1LX4c=.4376bebf-3397-4354-be3e-9fd0719b24db@github.com>
References: <mcPF1ypiHlYI3H4kgl0bwvU3KF_YO40Yo6aY6w1LX4c=.4376bebf-3397-4354-be3e-9fd0719b24db@github.com>
Message-ID: <iFFsM7h9mLR7B9Vz1sE0aCSqvw0vn3vbeCkLJp5X-Yc=.c13ada22-b782-4c0a-8819-79e7d88037cb@github.com>

On Tue, 17 Jun 2025 15:22:24 GMT, Nizar Benalla <nbenalla at openjdk.org> 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: <mWHKJozX3YTvBOjLDUa1_2QQiNm6xVc2rb1FtXcZzPc=.e2405ec4-09ed-46c1-acd5-3f39083fce3f@github.com>
References: <mWHKJozX3YTvBOjLDUa1_2QQiNm6xVc2rb1FtXcZzPc=.e2405ec4-09ed-46c1-acd5-3f39083fce3f@github.com>
Message-ID: <g_2l9E0iB1KAoGuG0xvmqESsmsCodHlM_6fbgm28qok=.afd923bb-b6b7-4b95-a0ca-6e05b0f317f0@github.com>

> 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: <Nw61IEd87pKfazr9DVWXHq1Ap71bndo5VscValJpqTs=.f593ada6-ef21-4d9b-9f91-faaf1f7947a2@github.com>
References: <mWHKJozX3YTvBOjLDUa1_2QQiNm6xVc2rb1FtXcZzPc=.e2405ec4-09ed-46c1-acd5-3f39083fce3f@github.com>
 <V32l6pOUkSgvcOnQ4-o4qeQxrYw2EeRNwLI1njc4CVE=.a39617e9-4a38-465c-9916-0404345dc873@github.com>
 <f_NhsjsNCsL7uj5OwKbyka28mWKGsYz5itt9ndBxzZk=.c9a79d39-e5e2-4842-a6e1-2727c47e96ea@github.com>
 <Nw61IEd87pKfazr9DVWXHq1Ap71bndo5VscValJpqTs=.f593ada6-ef21-4d9b-9f91-faaf1f7947a2@github.com>
Message-ID: <y3lv9aAjpkH6byEi6hfui6sWXm_Qu-0MjnG3jwIvvTA=.8d7a960f-1e03-4ed9-ad3b-120074880a23@github.com>

On Mon, 7 Jul 2025 09:32:42 GMT, erifan <duke at openjdk.org> 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: <LQRWbokCOzo8paB0R3JzFrXWVt5mxyGpU1Xe5rTuN4Q=.a7affe6d-82e2-4115-866e-348acbe4d7f7@github.com>
 <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>
 <x62Oc0s14YVHv3PWiS2P1XZnwZCPq3ZP3XJcPyykpzc=.2581c202-e462-4a8b-a788-19ce02d7e294@github.com>
 <0vdCJFYxCI6hFnTL6rm3oKQcPuuIR2EbuyAOa0muqcw=.d5c249cb-9bf0-415d-ab22-de7387d8d8d1@github.com>
Message-ID: <DAO5QxekBRX7Wl4erYM_Y4d-KPxiK_VGedZsFB75mLg=.36565202-256c-4e02-855d-471030976b87@github.com>

On Tue, 8 Jul 2025 01:55:55 GMT, Xiaohong Gong <xgong at openjdk.org> 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: <LQRWbokCOzo8paB0R3JzFrXWVt5mxyGpU1Xe5rTuN4Q=.a7affe6d-82e2-4115-866e-348acbe4d7f7@github.com>
 <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>
 <x62Oc0s14YVHv3PWiS2P1XZnwZCPq3ZP3XJcPyykpzc=.2581c202-e462-4a8b-a788-19ce02d7e294@github.com>
 <0vdCJFYxCI6hFnTL6rm3oKQcPuuIR2EbuyAOa0muqcw=.d5c249cb-9bf0-415d-ab22-de7387d8d8d1@github.com>
Message-ID: <MeudVeLgZvALZy5XKUEtjVoLGxqgrll0fatZM_EoMHk=.b8ff7c82-ca00-4e9e-b61f-973e6a2cbf51@github.com>

On Tue, 8 Jul 2025 01:55:55 GMT, Xiaohong Gong <xgong at openjdk.org> 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: <mgnQ7Zo-OFTIYUoAJH5tJy0_67MHBajuxtcfXr2PnXI=.ff7d9863-c8b8-4976-9dc5-d494a9526b0c@github.com>
References: <mgnQ7Zo-OFTIYUoAJH5tJy0_67MHBajuxtcfXr2PnXI=.ff7d9863-c8b8-4976-9dc5-d494a9526b0c@github.com>
Message-ID: <RiBOv6o2zsVp9bIO8vfe0mENTGm-tTVpz24H9xQl2es=.7a247a6d-6616-41e1-8517-9cec6c9afdba@github.com>

On Mon, 7 Jul 2025 23:21:58 GMT, Chen Liang <liach at openjdk.org> 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: <y3lv9aAjpkH6byEi6hfui6sWXm_Qu-0MjnG3jwIvvTA=.8d7a960f-1e03-4ed9-ad3b-120074880a23@github.com>
References: <mWHKJozX3YTvBOjLDUa1_2QQiNm6xVc2rb1FtXcZzPc=.e2405ec4-09ed-46c1-acd5-3f39083fce3f@github.com>
 <V32l6pOUkSgvcOnQ4-o4qeQxrYw2EeRNwLI1njc4CVE=.a39617e9-4a38-465c-9916-0404345dc873@github.com>
 <f_NhsjsNCsL7uj5OwKbyka28mWKGsYz5itt9ndBxzZk=.c9a79d39-e5e2-4842-a6e1-2727c47e96ea@github.com>
 <Nw61IEd87pKfazr9DVWXHq1Ap71bndo5VscValJpqTs=.f593ada6-ef21-4d9b-9f91-faaf1f7947a2@github.com>
 <y3lv9aAjpkH6byEi6hfui6sWXm_Qu-0MjnG3jwIvvTA=.8d7a960f-1e03-4ed9-ad3b-120074880a23@github.com>
Message-ID: <TJ5Jb8kV3XmVsQ6iHEy7LHj4TkRePg1PHI4PVebaEZA=.cf9e091b-bc94-4f82-a347-5d3aea86e501@github.com>

On Tue, 8 Jul 2025 05:56:58 GMT, erifan <duke at openjdk.org> 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: <MeudVeLgZvALZy5XKUEtjVoLGxqgrll0fatZM_EoMHk=.b8ff7c82-ca00-4e9e-b61f-973e6a2cbf51@github.com>
References: <LQRWbokCOzo8paB0R3JzFrXWVt5mxyGpU1Xe5rTuN4Q=.a7affe6d-82e2-4115-866e-348acbe4d7f7@github.com>
 <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>
 <x62Oc0s14YVHv3PWiS2P1XZnwZCPq3ZP3XJcPyykpzc=.2581c202-e462-4a8b-a788-19ce02d7e294@github.com>
 <0vdCJFYxCI6hFnTL6rm3oKQcPuuIR2EbuyAOa0muqcw=.d5c249cb-9bf0-415d-ab22-de7387d8d8d1@github.com>
 <MeudVeLgZvALZy5XKUEtjVoLGxqgrll0fatZM_EoMHk=.b8ff7c82-ca00-4e9e-b61f-973e6a2cbf51@github.com>
Message-ID: <c4DazuI_3P2LPvKaizWSW2I_51HEJFEXooYzR9JMJC8=.69aa62c9-4774-4011-be10-548314d8cbe4@github.com>

On Tue, 8 Jul 2025 08:18:57 GMT, Fei Gao <fgao at openjdk.org> 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: <c4DazuI_3P2LPvKaizWSW2I_51HEJFEXooYzR9JMJC8=.69aa62c9-4774-4011-be10-548314d8cbe4@github.com>
References: <LQRWbokCOzo8paB0R3JzFrXWVt5mxyGpU1Xe5rTuN4Q=.a7affe6d-82e2-4115-866e-348acbe4d7f7@github.com>
 <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>
 <x62Oc0s14YVHv3PWiS2P1XZnwZCPq3ZP3XJcPyykpzc=.2581c202-e462-4a8b-a788-19ce02d7e294@github.com>
 <0vdCJFYxCI6hFnTL6rm3oKQcPuuIR2EbuyAOa0muqcw=.d5c249cb-9bf0-415d-ab22-de7387d8d8d1@github.com>
 <MeudVeLgZvALZy5XKUEtjVoLGxqgrll0fatZM_EoMHk=.b8ff7c82-ca00-4e9e-b61f-973e6a2cbf51@github.com>
 <c4DazuI_3P2LPvKaizWSW2I_51HEJFEXooYzR9JMJC8=.69aa62c9-4774-4011-be10-548314d8cbe4@github.com>
Message-ID: <1bwEx4HAqqmfw9DrslwrZH1cYfIKi-5p9AgelJrIB94=.f46dd942-2102-4fd3-adfd-7f7ec3c3dbc0@github.com>

On Tue, 8 Jul 2025 09:00:53 GMT, Xiaohong Gong <xgong at openjdk.org> 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: <NoXw4JZ1pEpfRd-hlC_5GdTwHNZQVQ9pwxamN_KX7fo=.43be73f7-c027-4af7-9e1f-3b8bfeb87a19@github.com>
 <-wBBj6wgMQayipWS3L3-L5ItuUX0OeHcjQR22tci3pg=.a340f85a-683b-40e5-9cec-afa62efe11fb@github.com>
Message-ID: <werliar9WH2jX80KBv6mqz2v6tIKv8BlKpYkV0MRFG0=.102dd1cb-8c00-43b0-9c88-d3bb02b65fdd@github.com>

On Mon, 7 Jul 2025 16:33:22 GMT, Chen Liang <liach at openjdk.org> 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: <CAKD1RYt_NrHVV4nEc3gZ4szCvhXzHLVWMKdAoxNj7jh4aGT7dQ@mail.gmail.com>
References: <CAKD1RYv+g1L=ifA-_+Whrqb9cEHuH0zqFVSzW7AFg5Smahx2Bw@mail.gmail.com>
 <MW4PR10MB57740D5C55846B248FD24B4DFF4FA@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAKD1RYt_NrHVV4nEc3gZ4szCvhXzHLVWMKdAoxNj7jh4aGT7dQ@mail.gmail.com>
Message-ID: <MW4PR10MB577497AFA09E4E48E813F1CFFF4EA@MW4PR10MB5774.namprd10.prod.outlook.com>

>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 <yujige at gmail.com>
Sent: Tuesday, 8 July 2025 04:26
To: Viktor Klang <viktor.klang at oracle.com>
Cc: core-libs-dev at openjdk.org <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 <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>> 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 <core-libs-dev-retn at openjdk.org<mailto:core-libs-dev-retn at openjdk.org>> on behalf of Jige Yu <yujige at gmail.com<mailto:yujige at gmail.com>>
Sent: Thursday, 3 July 2025 16:36
To: core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org> <core-libs-dev at openjdk.org<mailto: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: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250708/3f548ddb/attachment-0001.htm>

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: <TJ5Jb8kV3XmVsQ6iHEy7LHj4TkRePg1PHI4PVebaEZA=.cf9e091b-bc94-4f82-a347-5d3aea86e501@github.com>
References: <mWHKJozX3YTvBOjLDUa1_2QQiNm6xVc2rb1FtXcZzPc=.e2405ec4-09ed-46c1-acd5-3f39083fce3f@github.com>
 <V32l6pOUkSgvcOnQ4-o4qeQxrYw2EeRNwLI1njc4CVE=.a39617e9-4a38-465c-9916-0404345dc873@github.com>
 <f_NhsjsNCsL7uj5OwKbyka28mWKGsYz5itt9ndBxzZk=.c9a79d39-e5e2-4842-a6e1-2727c47e96ea@github.com>
 <Nw61IEd87pKfazr9DVWXHq1Ap71bndo5VscValJpqTs=.f593ada6-ef21-4d9b-9f91-faaf1f7947a2@github.com>
 <y3lv9aAjpkH6byEi6hfui6sWXm_Qu-0MjnG3jwIvvTA=.8d7a960f-1e03-4ed9-ad3b-120074880a23@github.com>
 <TJ5Jb8kV3XmVsQ6iHEy7LHj4TkRePg1PHI4PVebaEZA=.cf9e091b-bc94-4f82-a347-5d3aea86e501@github.com>
Message-ID: <HTSGvd4RbqtETATLAWfiRI4SlUOzQKkkYOYARUr81l0=.b0e8cdb9-8332-4333-87ed-6f14b681f156@github.com>

On Tue, 8 Jul 2025 08:56:44 GMT, Emanuel Peter <epeter at openjdk.org> 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: <HTSGvd4RbqtETATLAWfiRI4SlUOzQKkkYOYARUr81l0=.b0e8cdb9-8332-4333-87ed-6f14b681f156@github.com>
References: <mWHKJozX3YTvBOjLDUa1_2QQiNm6xVc2rb1FtXcZzPc=.e2405ec4-09ed-46c1-acd5-3f39083fce3f@github.com>
 <V32l6pOUkSgvcOnQ4-o4qeQxrYw2EeRNwLI1njc4CVE=.a39617e9-4a38-465c-9916-0404345dc873@github.com>
 <f_NhsjsNCsL7uj5OwKbyka28mWKGsYz5itt9ndBxzZk=.c9a79d39-e5e2-4842-a6e1-2727c47e96ea@github.com>
 <Nw61IEd87pKfazr9DVWXHq1Ap71bndo5VscValJpqTs=.f593ada6-ef21-4d9b-9f91-faaf1f7947a2@github.com>
 <y3lv9aAjpkH6byEi6hfui6sWXm_Qu-0MjnG3jwIvvTA=.8d7a960f-1e03-4ed9-ad3b-120074880a23@github.com>
 <TJ5Jb8kV3XmVsQ6iHEy7LHj4TkRePg1PHI4PVebaEZA=.cf9e091b-bc94-4f82-a347-5d3aea86e501@github.com>
 <HTSGvd4RbqtETATLAWfiRI4SlUOzQKkkYOYARUr81l0=.b0e8cdb9-8332-4333-87ed-6f14b681f156@github.com>
Message-ID: <Ou-ZY7HPV3A7YmbgCTqOUb2xtPSsLjUgH9YBg7d0Hjw=.d60901dc-f21c-4cc6-a3bd-42dec5ea9476@github.com>

On Tue, 8 Jul 2025 09:49:30 GMT, erifan <duke at openjdk.org> 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: <c4DazuI_3P2LPvKaizWSW2I_51HEJFEXooYzR9JMJC8=.69aa62c9-4774-4011-be10-548314d8cbe4@github.com>
References: <LQRWbokCOzo8paB0R3JzFrXWVt5mxyGpU1Xe5rTuN4Q=.a7affe6d-82e2-4115-866e-348acbe4d7f7@github.com>
 <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>
 <x62Oc0s14YVHv3PWiS2P1XZnwZCPq3ZP3XJcPyykpzc=.2581c202-e462-4a8b-a788-19ce02d7e294@github.com>
 <0vdCJFYxCI6hFnTL6rm3oKQcPuuIR2EbuyAOa0muqcw=.d5c249cb-9bf0-415d-ab22-de7387d8d8d1@github.com>
 <MeudVeLgZvALZy5XKUEtjVoLGxqgrll0fatZM_EoMHk=.b8ff7c82-ca00-4e9e-b61f-973e6a2cbf51@github.com>
 <c4DazuI_3P2LPvKaizWSW2I_51HEJFEXooYzR9JMJC8=.69aa62c9-4774-4011-be10-548314d8cbe4@github.com>
Message-ID: <g-xoSGLCus40xGFBbYjgtIhig8UN58iUvdioc3vI6uk=.9a2a5b9e-0803-4f00-8202-54620b267619@github.com>

On Tue, 8 Jul 2025 09:00:53 GMT, Xiaohong Gong <xgong at openjdk.org> 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: <LQRWbokCOzo8paB0R3JzFrXWVt5mxyGpU1Xe5rTuN4Q=.a7affe6d-82e2-4115-866e-348acbe4d7f7@github.com>
 <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>
 <x62Oc0s14YVHv3PWiS2P1XZnwZCPq3ZP3XJcPyykpzc=.2581c202-e462-4a8b-a788-19ce02d7e294@github.com>
 <0vdCJFYxCI6hFnTL6rm3oKQcPuuIR2EbuyAOa0muqcw=.d5c249cb-9bf0-415d-ab22-de7387d8d8d1@github.com>
 <MeudVeLgZvALZy5XKUEtjVoLGxqgrll0fatZM_EoMHk=.b8ff7c82-ca00-4e9e-b61f-973e6a2cbf51@github.com>
 <c4DazuI_3P2LPvKaizWSW2I_51HEJFEXooYzR9JMJC8=.69aa62c9-4774-4011-be10-548314d8cbe4@github.com>
 <1bwEx4HAqqmfw9DrslwrZH1cYfIKi-5p9AgelJrIB94=.f46dd942-2102-4fd3-adfd-7f7ec3c3dbc0@github.com>
Message-ID: <rCmqOVwOgThwSwJUdSVp5KVDYX95VKzBjxT1TySJ-EY=.0a9429f2-db05-4e7d-8122-6f580c4e55e2@github.com>

On Tue, 8 Jul 2025 09:07:00 GMT, Xiaohong Gong <xgong at openjdk.org> 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: <Chi3AesG1KOkXIpzMau3h9cI913osOzjumXYDdr371o=.3949d985-2347-42e1-bf46-7f03d7d1ef49@github.com>
References: <wKrHfyjmzcMC0AKQosqSjKJj70vkFCTpJzgZTmQpEOI=.6d1e2d88-bd1d-449c-a576-1aac7c4fd751@github.com>
 <Chi3AesG1KOkXIpzMau3h9cI913osOzjumXYDdr371o=.3949d985-2347-42e1-bf46-7f03d7d1ef49@github.com>
Message-ID: <cPLZcUgSbvWRod4IWXf7QK9uNaXs03puXHUROhg9kqY=.b62a6489-a2cb-4fe1-a1c9-c1b77cd7904e@github.com>

On Tue, 8 Jul 2025 04:59:04 GMT, Jaikiran Pai <jpai at openjdk.org> 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: <AL7IdqZqHz7sM-oppG4NW7umIRhri6uP6EHbCiC3f8c=.9a16c98f-f47a-488c-83cf-cbefa6f4b206@github.com>
References: <otTjiRgCFQEeUbpfFTMzhXUVBU1cal8q_i7IrGs_n94=.c2f02ad8-6b0c-4daa-9995-8e4b42131eb4@github.com>
 <vT6zJlWPUg235GuAHNJbyAxkoONF2vljAuFTVygBoGk=.05690f62-9641-4990-855a-c908df24e064@github.com>
 <AL7IdqZqHz7sM-oppG4NW7umIRhri6uP6EHbCiC3f8c=.9a16c98f-f47a-488c-83cf-cbefa6f4b206@github.com>
Message-ID: <WVnsaTB9LG9tXyWUvvwkTJwB_tURy3D8emcDgm6MLYc=.20d504a2-5f0b-4ba9-83ad-58dd8bacf2f5@github.com>

On Tue, 8 Jul 2025 04:20:32 GMT, Jaikiran Pai <jpai at openjdk.org> 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: <lZLJ957P7sONaS2DMlqED9bApOqJk3jhx910dFjSdTs=.09ca21d0-f864-4f7e-b48b-a0c9c39cebef@github.com>
References: <otTjiRgCFQEeUbpfFTMzhXUVBU1cal8q_i7IrGs_n94=.c2f02ad8-6b0c-4daa-9995-8e4b42131eb4@github.com>
 <vT6zJlWPUg235GuAHNJbyAxkoONF2vljAuFTVygBoGk=.05690f62-9641-4990-855a-c908df24e064@github.com>
 <rfLuoC6GYaQTru1_jqseSC266NbVP4Kxe2J6FikGXeQ=.97a3a13d-4f90-41f4-b210-a0080351cc06@github.com>
 <lZLJ957P7sONaS2DMlqED9bApOqJk3jhx910dFjSdTs=.09ca21d0-f864-4f7e-b48b-a0c9c39cebef@github.com>
Message-ID: <wbmC__Bvok7OvAVrLnNhrdyEHS4w2MGwbBT3GVhKwls=.a2c90515-9d50-4e76-b18b-94018f35fa33@github.com>

On Tue, 8 Jul 2025 01:49:14 GMT, David Holmes <dholmes at openjdk.org> 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: <g_2l9E0iB1KAoGuG0xvmqESsmsCodHlM_6fbgm28qok=.afd923bb-b6b7-4b95-a0ca-6e05b0f317f0@github.com>
References: <mWHKJozX3YTvBOjLDUa1_2QQiNm6xVc2rb1FtXcZzPc=.e2405ec4-09ed-46c1-acd5-3f39083fce3f@github.com>
 <g_2l9E0iB1KAoGuG0xvmqESsmsCodHlM_6fbgm28qok=.afd923bb-b6b7-4b95-a0ca-6e05b0f317f0@github.com>
Message-ID: <FQnM7QVeQxvNZUsCTbwzDIfYy1qlku7_-c-yrw3Q0QQ=.f146f891-42c7-44b8-8805-0ddc549fd780@github.com>

On Tue, 8 Jul 2025 06:00:38 GMT, erifan <duke at openjdk.org> 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: <Ou-ZY7HPV3A7YmbgCTqOUb2xtPSsLjUgH9YBg7d0Hjw=.d60901dc-f21c-4cc6-a3bd-42dec5ea9476@github.com>
References: <mWHKJozX3YTvBOjLDUa1_2QQiNm6xVc2rb1FtXcZzPc=.e2405ec4-09ed-46c1-acd5-3f39083fce3f@github.com>
 <V32l6pOUkSgvcOnQ4-o4qeQxrYw2EeRNwLI1njc4CVE=.a39617e9-4a38-465c-9916-0404345dc873@github.com>
 <f_NhsjsNCsL7uj5OwKbyka28mWKGsYz5itt9ndBxzZk=.c9a79d39-e5e2-4842-a6e1-2727c47e96ea@github.com>
 <Nw61IEd87pKfazr9DVWXHq1Ap71bndo5VscValJpqTs=.f593ada6-ef21-4d9b-9f91-faaf1f7947a2@github.com>
 <y3lv9aAjpkH6byEi6hfui6sWXm_Qu-0MjnG3jwIvvTA=.8d7a960f-1e03-4ed9-ad3b-120074880a23@github.com>
 <TJ5Jb8kV3XmVsQ6iHEy7LHj4TkRePg1PHI4PVebaEZA=.cf9e091b-bc94-4f82-a347-5d3aea86e501@github.com>
 <HTSGvd4RbqtETATLAWfiRI4SlUOzQKkkYOYARUr81l0=.b0e8cdb9-8332-4333-87ed-6f14b681f156@github.com>
 <Ou-ZY7HPV3A7YmbgCTqOUb2xtPSsLjUgH9YBg7d0Hjw=.d60901dc-f21c-4cc6-a3bd-42dec5ea9476@github.com>
Message-ID: <YV3c1O6-ux9NidA-aULsjx6lFqSXHCM8gBuJCBJMqlU=.9fc1aa35-ceeb-458c-baf0-1594195c4132@github.com>

On Tue, 8 Jul 2025 10:21:03 GMT, erifan <duke at openjdk.org> 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: <YV3c1O6-ux9NidA-aULsjx6lFqSXHCM8gBuJCBJMqlU=.9fc1aa35-ceeb-458c-baf0-1594195c4132@github.com>
References: <mWHKJozX3YTvBOjLDUa1_2QQiNm6xVc2rb1FtXcZzPc=.e2405ec4-09ed-46c1-acd5-3f39083fce3f@github.com>
 <V32l6pOUkSgvcOnQ4-o4qeQxrYw2EeRNwLI1njc4CVE=.a39617e9-4a38-465c-9916-0404345dc873@github.com>
 <f_NhsjsNCsL7uj5OwKbyka28mWKGsYz5itt9ndBxzZk=.c9a79d39-e5e2-4842-a6e1-2727c47e96ea@github.com>
 <Nw61IEd87pKfazr9DVWXHq1Ap71bndo5VscValJpqTs=.f593ada6-ef21-4d9b-9f91-faaf1f7947a2@github.com>
 <y3lv9aAjpkH6byEi6hfui6sWXm_Qu-0MjnG3jwIvvTA=.8d7a960f-1e03-4ed9-ad3b-120074880a23@github.com>
 <TJ5Jb8kV3XmVsQ6iHEy7LHj4TkRePg1PHI4PVebaEZA=.cf9e091b-bc94-4f82-a347-5d3aea86e501@github.com>
 <HTSGvd4RbqtETATLAWfiRI4SlUOzQKkkYOYARUr81l0=.b0e8cdb9-8332-4333-87ed-6f14b681f156@github.com>
 <Ou-ZY7HPV3A7YmbgCTqOUb2xtPSsLjUgH9YBg7d0Hjw=.d60901dc-f21c-4cc6-a3bd-42dec5ea9476@github.com>
 <YV3c1O6-ux9NidA-aULsjx6lFqSXHCM8gBuJCBJMqlU=.9fc1aa35-ceeb-458c-baf0-1594195c4132@github.com>
Message-ID: <2UzxnawLUtlwIr5aaEdTfn4OEMt_z1HTfAaDBHCeZFU=.a70d1360-574a-4ca9-adae-7dec030ed2b7@github.com>

On Tue, 8 Jul 2025 11:41:01 GMT, Emanuel Peter <epeter at openjdk.org> 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: <NoXw4JZ1pEpfRd-hlC_5GdTwHNZQVQ9pwxamN_KX7fo=.43be73f7-c027-4af7-9e1f-3b8bfeb87a19@github.com>
References: <NoXw4JZ1pEpfRd-hlC_5GdTwHNZQVQ9pwxamN_KX7fo=.43be73f7-c027-4af7-9e1f-3b8bfeb87a19@github.com>
Message-ID: <qk86S_NDaaXFdMDkxxU8v3M-MarHetGTJBNEPiJivBU=.f4701288-ee03-44b8-9fa9-98bde6f480ce@github.com>

On Mon, 7 Jul 2025 16:13:08 GMT, Andrew Haley <aph at openjdk.org> 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: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
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: <TM-kE1ikMg1jSOq2BzhnFO1lOqzLv8WGy1xxrMEtCbw=.09124cfc-c08f-4c12-822a-084e6fc22579@github.com>

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: <TM-kE1ikMg1jSOq2BzhnFO1lOqzLv8WGy1xxrMEtCbw=.09124cfc-c08f-4c12-822a-084e6fc22579@github.com>
References: <TM-kE1ikMg1jSOq2BzhnFO1lOqzLv8WGy1xxrMEtCbw=.09124cfc-c08f-4c12-822a-084e6fc22579@github.com>
Message-ID: <6NSMDqRy9CiytH25pQDGergFr8o7ofTDKe0151cIi3M=.a92d424e-5ee6-4945-9a7d-3a56f8545c7e@github.com>

On Fri, 30 May 2025 12:00:28 GMT, Darragh Clarke <dclarke at openjdk.org> 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: <TM-kE1ikMg1jSOq2BzhnFO1lOqzLv8WGy1xxrMEtCbw=.09124cfc-c08f-4c12-822a-084e6fc22579@github.com>
 <6NSMDqRy9CiytH25pQDGergFr8o7ofTDKe0151cIi3M=.a92d424e-5ee6-4945-9a7d-3a56f8545c7e@github.com>
Message-ID: <CAUA-5Kouk3oFWDX2g28AX3_v96yPyPRS15nYJG_YUQ=.e0473680-b68e-4200-9281-51354bb93002@github.com>

On Thu, 19 Jun 2025 08:19:55 GMT, Per Minborg <pminborg at openjdk.org> 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: <TM-kE1ikMg1jSOq2BzhnFO1lOqzLv8WGy1xxrMEtCbw=.09124cfc-c08f-4c12-822a-084e6fc22579@github.com>
References: <TM-kE1ikMg1jSOq2BzhnFO1lOqzLv8WGy1xxrMEtCbw=.09124cfc-c08f-4c12-822a-084e6fc22579@github.com>
Message-ID: <LhFU7gwSkKsCsQXHIx3vT1hx_nZpDb0u5n4tMkpPyy0=.6dca580e-40a0-42c3-858b-cd178211e057@github.com>

On Fri, 30 May 2025 12:00:28 GMT, Darragh Clarke <dclarke at openjdk.org> 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: <TM-kE1ikMg1jSOq2BzhnFO1lOqzLv8WGy1xxrMEtCbw=.09124cfc-c08f-4c12-822a-084e6fc22579@github.com>
References: <TM-kE1ikMg1jSOq2BzhnFO1lOqzLv8WGy1xxrMEtCbw=.09124cfc-c08f-4c12-822a-084e6fc22579@github.com>
Message-ID: <y_Uajk8J8-UKIidMzhVQWZGLJf2AhLrH2cm5cmYn2-8=.f7b6f6e1-e383-4980-9ce2-61c060592d2d@github.com>

On Fri, 30 May 2025 12:00:28 GMT, Darragh Clarke <dclarke at openjdk.org> 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: <y_Uajk8J8-UKIidMzhVQWZGLJf2AhLrH2cm5cmYn2-8=.f7b6f6e1-e383-4980-9ce2-61c060592d2d@github.com>
References: <TM-kE1ikMg1jSOq2BzhnFO1lOqzLv8WGy1xxrMEtCbw=.09124cfc-c08f-4c12-822a-084e6fc22579@github.com>
 <y_Uajk8J8-UKIidMzhVQWZGLJf2AhLrH2cm5cmYn2-8=.f7b6f6e1-e383-4980-9ce2-61c060592d2d@github.com>
Message-ID: <q8Pxi-gMRw-wvEJciu7H7bPrUd4dp7qfXGKdt_FN4-g=.bf01b2c5-2912-424f-b39a-7cab8c8e845e@github.com>

On Sat, 31 May 2025 02:07:40 GMT, Chen Liang <liach at openjdk.org> 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: <wKrHfyjmzcMC0AKQosqSjKJj70vkFCTpJzgZTmQpEOI=.6d1e2d88-bd1d-449c-a576-1aac7c4fd751@github.com>
References: <wKrHfyjmzcMC0AKQosqSjKJj70vkFCTpJzgZTmQpEOI=.6d1e2d88-bd1d-449c-a576-1aac7c4fd751@github.com>
Message-ID: <eCF7KvoZeVTu7iMHMCVHG__z0rgmx3tJ0dvOHuQEXcU=.1bf9f6aa-cc03-471e-a066-a5011554f714@github.com>

On Sat, 5 Jul 2025 00:05:39 GMT, Kim Barrett <kbarrett at openjdk.org> 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: <TM-kE1ikMg1jSOq2BzhnFO1lOqzLv8WGy1xxrMEtCbw=.09124cfc-c08f-4c12-822a-084e6fc22579@github.com>
References: <TM-kE1ikMg1jSOq2BzhnFO1lOqzLv8WGy1xxrMEtCbw=.09124cfc-c08f-4c12-822a-084e6fc22579@github.com>
Message-ID: <NRKKo4sm-LdyM_dDmAllsw6OVh0AuCkr4o1uWc52Ns4=.7a37e85b-d1be-40a5-ac94-b357a008b2e3@github.com>

On Fri, 30 May 2025 12:00:28 GMT, Darragh Clarke <dclarke at openjdk.org> 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: <iFFsM7h9mLR7B9Vz1sE0aCSqvw0vn3vbeCkLJp5X-Yc=.c13ada22-b782-4c0a-8819-79e7d88037cb@github.com>
References: <mcPF1ypiHlYI3H4kgl0bwvU3KF_YO40Yo6aY6w1LX4c=.4376bebf-3397-4354-be3e-9fd0719b24db@github.com>
 <iFFsM7h9mLR7B9Vz1sE0aCSqvw0vn3vbeCkLJp5X-Yc=.c13ada22-b782-4c0a-8819-79e7d88037cb@github.com>
Message-ID: <QFt8QCfhCaXSdiZ1rimjt24GqIM7EKYFqva7oeqrlSU=.28676a3b-9b03-4a97-8ede-cc16b4fee114@github.com>

On Tue, 8 Jul 2025 05:18:31 GMT, Jaikiran Pai <jpai at openjdk.org> 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: <mgnQ7Zo-OFTIYUoAJH5tJy0_67MHBajuxtcfXr2PnXI=.ff7d9863-c8b8-4976-9dc5-d494a9526b0c@github.com>
References: <mgnQ7Zo-OFTIYUoAJH5tJy0_67MHBajuxtcfXr2PnXI=.ff7d9863-c8b8-4976-9dc5-d494a9526b0c@github.com>
Message-ID: <Edupn5wOHHp26EY-MXQn6ZurDE3TXLiOzDFcLLsu0k0=.f62ad6d0-7cf1-4f3a-baf6-51af7e4de04b@github.com>

On Mon, 7 Jul 2025 23:21:58 GMT, Chen Liang <liach at openjdk.org> 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: <Edupn5wOHHp26EY-MXQn6ZurDE3TXLiOzDFcLLsu0k0=.f62ad6d0-7cf1-4f3a-baf6-51af7e4de04b@github.com>
References: <mgnQ7Zo-OFTIYUoAJH5tJy0_67MHBajuxtcfXr2PnXI=.ff7d9863-c8b8-4976-9dc5-d494a9526b0c@github.com>
 <Edupn5wOHHp26EY-MXQn6ZurDE3TXLiOzDFcLLsu0k0=.f62ad6d0-7cf1-4f3a-baf6-51af7e4de04b@github.com>
Message-ID: <cc8MXtVuQsL1jHih7adWCPZMVH_hB3aYbcHhRGvyQgA=.6d9b98d3-cd4d-461e-b34b-30dbda732cc3@github.com>

On Tue, 8 Jul 2025 16:28:45 GMT, ExE Boss <duke at openjdk.org> 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: <VnnQjaCmPw5sLDsF7HHJm4NFNCVJZ9ZytC63qnTp3HE=.6b36cdab-99f0-47cb-ac5d-7f07ba81d8b6@github.com>
References: <rwUkW0OqmfUERgNGYbOFQAmQaarEBkP0HuUdFByPq5Y=.79d4b106-123c-4d38-b06e-c2c986a4337d@github.com>
 <VnnQjaCmPw5sLDsF7HHJm4NFNCVJZ9ZytC63qnTp3HE=.6b36cdab-99f0-47cb-ac5d-7f07ba81d8b6@github.com>
Message-ID: <aoW977m8RifSIOnOIaLvJJ_sGY0OOlgJXLYeGeyFzTc=.e404ae24-27c7-4043-852f-53107ef27feb@github.com>

On Mon, 7 Jul 2025 20:24:21 GMT, Naoto Sato <naoto at openjdk.org> 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: <rwUkW0OqmfUERgNGYbOFQAmQaarEBkP0HuUdFByPq5Y=.79d4b106-123c-4d38-b06e-c2c986a4337d@github.com>
References: <rwUkW0OqmfUERgNGYbOFQAmQaarEBkP0HuUdFByPq5Y=.79d4b106-123c-4d38-b06e-c2c986a4337d@github.com>
Message-ID: <iHcIgsOCQ-CGIGG3b07F0kYE2qUCjSUONt6qpdzC4e8=.bf77a51c-dd18-4b80-8b37-c7494238adc7@github.com>

On Mon, 7 Jul 2025 19:08:22 GMT, Naoto Sato <naoto at openjdk.org> 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 <naoto at openjdk.org>
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: <OOcrr-XrT-N783zTSoPF70AaZPoDlogN7Sck9p-N9nw=.98f4c5e8-fafd-48df-834b-cbb6f4bfe771@github.com>
References: <OOcrr-XrT-N783zTSoPF70AaZPoDlogN7Sck9p-N9nw=.98f4c5e8-fafd-48df-834b-cbb6f4bfe771@github.com>
Message-ID: <TSYw_DYu6eJzPBtjA67WcN2FrBrIwyeibKVbFsjFwoI=.5c05ce95-0cb8-4c1e-aa83-cb5d3d4b758b@github.com>

> 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 <clinit> 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: <ry3bOAIy2G3MTSidAx9GU7rllzdPjR8a9Dl4xuimirM=.bf9a1c65-b2ff-4c21-b4c0-c77ef49d7cb3@github.com>
References: <hQqhqm1r_dSb9ThvtqEyTcbB31lJxpu7LohMCsAf5xo=.da3388a2-3033-4d95-95cf-7a40fe7e7068@github.com>
 <ry3bOAIy2G3MTSidAx9GU7rllzdPjR8a9Dl4xuimirM=.bf9a1c65-b2ff-4c21-b4c0-c77ef49d7cb3@github.com>
Message-ID: <QdYbtDlqxruOpqbbGUmoEZi8hGODVjrFCNaPZ2vuKOE=.303ce90e-6a09-4d58-8bb0-cfd2dc6c00d7@github.com>

On Thu, 3 Jul 2025 18:41:27 GMT, Chen Liang <liach at openjdk.org> 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: <TSYw_DYu6eJzPBtjA67WcN2FrBrIwyeibKVbFsjFwoI=.5c05ce95-0cb8-4c1e-aa83-cb5d3d4b758b@github.com>
References: <OOcrr-XrT-N783zTSoPF70AaZPoDlogN7Sck9p-N9nw=.98f4c5e8-fafd-48df-834b-cbb6f4bfe771@github.com>
 <TSYw_DYu6eJzPBtjA67WcN2FrBrIwyeibKVbFsjFwoI=.5c05ce95-0cb8-4c1e-aa83-cb5d3d4b758b@github.com>
Message-ID: <j3Dh34dJHg7713HCdvhsflN0nvwrylyMaxO-th3NfN0=.cd1465ba-01ca-49e4-8876-b7437db7ade9@github.com>

On Tue, 8 Jul 2025 17:20:34 GMT, Chen Liang <liach at openjdk.org> 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 <clinit> 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: <hQqhqm1r_dSb9ThvtqEyTcbB31lJxpu7LohMCsAf5xo=.da3388a2-3033-4d95-95cf-7a40fe7e7068@github.com>
 <ry3bOAIy2G3MTSidAx9GU7rllzdPjR8a9Dl4xuimirM=.bf9a1c65-b2ff-4c21-b4c0-c77ef49d7cb3@github.com>
 <mzp3EIZUsjV-ygc0JzQp6TgqGIIuZGW8Wkk6ae5Wmwc=.a4140bf6-d2a5-4e3c-b3e9-193287674d10@github.com>
 <wY6pmYZnJEqyByXwBgM1VoI_CQnucGuRDrPUoPs8w4k=.e1bcad19-bc25-4b37-829f-b80c85d1d671@github.com>
 <3stoVvRmIX7pk8ehqJSYzQwDu2MgQHPnezsoCgEo9Xo=.64f6a467-d0eb-47be-993d-e64a53a7e442@github.com>
Message-ID: <m63jl5rT_cEyxPY3ZJsjgptoxwcbcGFJwiS5MMEbpqo=.9e1c2c03-2688-4d33-a14a-57dc0693ee53@github.com>

On Mon, 7 Jul 2025 12:06:54 GMT, Chen Liang <liach at openjdk.org> 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: <NoXw4JZ1pEpfRd-hlC_5GdTwHNZQVQ9pwxamN_KX7fo=.43be73f7-c027-4af7-9e1f-3b8bfeb87a19@github.com>
References: <NoXw4JZ1pEpfRd-hlC_5GdTwHNZQVQ9pwxamN_KX7fo=.43be73f7-c027-4af7-9e1f-3b8bfeb87a19@github.com>
Message-ID: <_mO-m_nW9KXKJl99YILs4QTPxrHaDc0vqV2bJaCJtWU=.c9b5e047-ba11-42c2-8059-e32ac34bea3f@github.com>

On Mon, 7 Jul 2025 16:13:08 GMT, Andrew Haley <aph at openjdk.org> 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: <m63jl5rT_cEyxPY3ZJsjgptoxwcbcGFJwiS5MMEbpqo=.9e1c2c03-2688-4d33-a14a-57dc0693ee53@github.com>
References: <hQqhqm1r_dSb9ThvtqEyTcbB31lJxpu7LohMCsAf5xo=.da3388a2-3033-4d95-95cf-7a40fe7e7068@github.com>
 <ry3bOAIy2G3MTSidAx9GU7rllzdPjR8a9Dl4xuimirM=.bf9a1c65-b2ff-4c21-b4c0-c77ef49d7cb3@github.com>
 <mzp3EIZUsjV-ygc0JzQp6TgqGIIuZGW8Wkk6ae5Wmwc=.a4140bf6-d2a5-4e3c-b3e9-193287674d10@github.com>
 <wY6pmYZnJEqyByXwBgM1VoI_CQnucGuRDrPUoPs8w4k=.e1bcad19-bc25-4b37-829f-b80c85d1d671@github.com>
 <3stoVvRmIX7pk8ehqJSYzQwDu2MgQHPnezsoCgEo9Xo=.64f6a467-d0eb-47be-993d-e64a53a7e442@github.com>
 <m63jl5rT_cEyxPY3ZJsjgptoxwcbcGFJwiS5MMEbpqo=.9e1c2c03-2688-4d33-a14a-57dc0693ee53@github.com>
Message-ID: <zgWJk5dLOoXeRmpc0y_xjgRktbKqh3L8fDiGtQfkUh4=.0b92c1b4-8119-4b13-8654-268aa06adf15@github.com>

On Tue, 8 Jul 2025 17:59:32 GMT, Alan Bateman <alanb at openjdk.org> 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: <OmniqsoewrvdfpMhuDJ78Qfhpqu-9SX3A4em1eiuyxo=.46ce4fbd-4ce9-4eef-9e89-4629b8a09e55@github.com>

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: <IPodt6KjRH75edJJjXja5g9wqH4oY6-EouV4Xn5SWeU=.21e726f3-7dae-47ad-9b3a-9f3118fedbda@github.com>
 <KO-d2RLH061W_VBdFFmGqhF-0XDwAKLyETFHa7kqAQI=.b29c8b91-0128-44b6-86d8-879f79076434@github.com>
 <0UfkXxOmp7jsEH0cPOPBDoh8osWoz6Jp6A8jLh-CmDE=.57a3938f-ba6d-48ee-9caf-ecd3c10678cb@github.com>
 <_YDKPqPvEXlcYuTlaYEiXd9JHJeYmjZMt2fMOOK1QAY=.f29c7bff-9c72-4347-beda-7c4a186190ee@github.com>
Message-ID: <NyVjt7moik0R9AUdOZyeO6kiIuCd2ajQzKTnkr7X2r4=.a39fa404-a697-4a07-9bb9-5c965645619f@github.com>

On Thu, 3 Jul 2025 01:44:27 GMT, simon <duke at openjdk.org> 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: <Chi3AesG1KOkXIpzMau3h9cI913osOzjumXYDdr371o=.3949d985-2347-42e1-bf46-7f03d7d1ef49@github.com>
References: <wKrHfyjmzcMC0AKQosqSjKJj70vkFCTpJzgZTmQpEOI=.6d1e2d88-bd1d-449c-a576-1aac7c4fd751@github.com>
 <Chi3AesG1KOkXIpzMau3h9cI913osOzjumXYDdr371o=.3949d985-2347-42e1-bf46-7f03d7d1ef49@github.com>
Message-ID: <fE4rm-o-HjWr6rmE78jpboJQMDzazoY04II04D-2KHg=.131e9b67-315e-4446-a4a0-c44031ad0807@github.com>

On Tue, 8 Jul 2025 04:59:04 GMT, Jaikiran Pai <jpai at openjdk.org> 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: <wKrHfyjmzcMC0AKQosqSjKJj70vkFCTpJzgZTmQpEOI=.6d1e2d88-bd1d-449c-a576-1aac7c4fd751@github.com>
References: <wKrHfyjmzcMC0AKQosqSjKJj70vkFCTpJzgZTmQpEOI=.6d1e2d88-bd1d-449c-a576-1aac7c4fd751@github.com>
Message-ID: <uN29AEwDYvlMmflPE0ChBrEACx9E1RU945KH_q7BxjQ=.3b39e9c2-406c-4549-a5ab-6fd1407538f0@github.com>

On Sat, 5 Jul 2025 00:05:39 GMT, Kim Barrett <kbarrett at openjdk.org> 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 <kbarrett at openjdk.org>
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: <uJfr8RQBE0nk26hcVMgU6JXU6cfPbSd1b8HCGgazH1s=.7916f354-c513-4c39-b999-6769b28551d6@github.com>

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: <uJfr8RQBE0nk26hcVMgU6JXU6cfPbSd1b8HCGgazH1s=.7916f354-c513-4c39-b999-6769b28551d6@github.com>
References: <uJfr8RQBE0nk26hcVMgU6JXU6cfPbSd1b8HCGgazH1s=.7916f354-c513-4c39-b999-6769b28551d6@github.com>
Message-ID: <Vw-EIPnplQrhWRudq57l2YyHC3Gg0CSbE5EgNpP3G70=.3a8ba9ad-b6a6-483f-af30-9059ef378c36@github.com>

> 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: <IPodt6KjRH75edJJjXja5g9wqH4oY6-EouV4Xn5SWeU=.21e726f3-7dae-47ad-9b3a-9f3118fedbda@github.com>
References: <IPodt6KjRH75edJJjXja5g9wqH4oY6-EouV4Xn5SWeU=.21e726f3-7dae-47ad-9b3a-9f3118fedbda@github.com>
Message-ID: <Sh2CHVAms0GUtdWALBJnvO5vD9xiFiL3Q8DPRWedTdQ=.144e2b38-f977-442b-8ad1-a2d38aabb395@github.com>

> 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
> <details><summary>Using <code>git</code></summary>
> 
> 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`
> 
> </details>
> <details><summary>Using Skara CLI tools</summary>
> 
> Checkout this PR locally: \
> `$ git pr checkout 25925`
> 
> View PR using the GUI difftool: \
> `$ git pr show -t 25925`
> 
> </details>
> <details><summary>Using diff file</summary>
> 
> Download this PR as a diff file: \
> <a href="https://git.openjdk.org/jdk/pull/25925.diff">https://git.openjdk.org/jdk/pull/25925.diff</a>
> 
> </details>
> <details><summary>Using Webrev</summary>
> 
> [Link to Webrev Comment](https://git.openjdk.org/jdk/pull/25925#issuecomment-2993856738)
> </details>

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: <NyVjt7moik0R9AUdOZyeO6kiIuCd2ajQzKTnkr7X2r4=.a39fa404-a697-4a07-9bb9-5c965645619f@github.com>
References: <IPodt6KjRH75edJJjXja5g9wqH4oY6-EouV4Xn5SWeU=.21e726f3-7dae-47ad-9b3a-9f3118fedbda@github.com>
 <KO-d2RLH061W_VBdFFmGqhF-0XDwAKLyETFHa7kqAQI=.b29c8b91-0128-44b6-86d8-879f79076434@github.com>
 <0UfkXxOmp7jsEH0cPOPBDoh8osWoz6Jp6A8jLh-CmDE=.57a3938f-ba6d-48ee-9caf-ecd3c10678cb@github.com>
 <_YDKPqPvEXlcYuTlaYEiXd9JHJeYmjZMt2fMOOK1QAY=.f29c7bff-9c72-4347-beda-7c4a186190ee@github.com>
 <NyVjt7moik0R9AUdOZyeO6kiIuCd2ajQzKTnkr7X2r4=.a39fa404-a697-4a07-9bb9-5c965645619f@github.com>
Message-ID: <ylElPzb6jmJ-FtVK7C4u2ey9SbHGDJP9UGWe0qlCnDY=.10914ee0-f844-4ab7-9de0-715a9b68a1ac@github.com>

On Tue, 8 Jul 2025 18:53:08 GMT, Lance Andersen <lancea at openjdk.org> 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: <g-xoSGLCus40xGFBbYjgtIhig8UN58iUvdioc3vI6uk=.9a2a5b9e-0803-4f00-8202-54620b267619@github.com>
References: <LQRWbokCOzo8paB0R3JzFrXWVt5mxyGpU1Xe5rTuN4Q=.a7affe6d-82e2-4115-866e-348acbe4d7f7@github.com>
 <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>
 <x62Oc0s14YVHv3PWiS2P1XZnwZCPq3ZP3XJcPyykpzc=.2581c202-e462-4a8b-a788-19ce02d7e294@github.com>
 <0vdCJFYxCI6hFnTL6rm3oKQcPuuIR2EbuyAOa0muqcw=.d5c249cb-9bf0-415d-ab22-de7387d8d8d1@github.com>
 <MeudVeLgZvALZy5XKUEtjVoLGxqgrll0fatZM_EoMHk=.b8ff7c82-ca00-4e9e-b61f-973e6a2cbf51@github.com>
 <c4DazuI_3P2LPvKaizWSW2I_51HEJFEXooYzR9JMJC8=.69aa62c9-4774-4011-be10-548314d8cbe4@github.com>
 <g-xoSGLCus40xGFBbYjgtIhig8UN58iUvdioc3vI6uk=.9a2a5b9e-0803-4f00-8202-54620b267619@github.com>
Message-ID: <sP2oYE1FdQATeLi7pFbRtuEyuqCHAtgftbdxW5rdHvQ=.56475766-ca3c-498e-a837-cd3377213fff@github.com>

On Tue, 8 Jul 2025 10:33:50 GMT, Fei Gao <fgao at openjdk.org> 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: <LQRWbokCOzo8paB0R3JzFrXWVt5mxyGpU1Xe5rTuN4Q=.a7affe6d-82e2-4115-866e-348acbe4d7f7@github.com>
References: <LQRWbokCOzo8paB0R3JzFrXWVt5mxyGpU1Xe5rTuN4Q=.a7affe6d-82e2-4115-866e-348acbe4d7f7@github.com>
Message-ID: <AmBFKMPlYw61TAK96M1JnZ7XFjGdicZcL4MVJ6GvNjo=.544eab42-4050-4317-b54d-999512605720@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:

  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: <LQRWbokCOzo8paB0R3JzFrXWVt5mxyGpU1Xe5rTuN4Q=.a7affe6d-82e2-4115-866e-348acbe4d7f7@github.com>
 <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>
 <x62Oc0s14YVHv3PWiS2P1XZnwZCPq3ZP3XJcPyykpzc=.2581c202-e462-4a8b-a788-19ce02d7e294@github.com>
 <0vdCJFYxCI6hFnTL6rm3oKQcPuuIR2EbuyAOa0muqcw=.d5c249cb-9bf0-415d-ab22-de7387d8d8d1@github.com>
 <MeudVeLgZvALZy5XKUEtjVoLGxqgrll0fatZM_EoMHk=.b8ff7c82-ca00-4e9e-b61f-973e6a2cbf51@github.com>
 <c4DazuI_3P2LPvKaizWSW2I_51HEJFEXooYzR9JMJC8=.69aa62c9-4774-4011-be10-548314d8cbe4@github.com>
 <1bwEx4HAqqmfw9DrslwrZH1cYfIKi-5p9AgelJrIB94=.f46dd942-2102-4fd3-adfd-7f7ec3c3dbc0@github.com>
Message-ID: <nErd6aGuRtnrG7sbubeGuu-LOmZ7ijVZCfs9QglbYcQ=.356f44e4-3734-4cc0-a5cd-232a897fe5cb@github.com>

On Tue, 8 Jul 2025 09:07:00 GMT, Xiaohong Gong <xgong at openjdk.org> 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: <g-xoSGLCus40xGFBbYjgtIhig8UN58iUvdioc3vI6uk=.9a2a5b9e-0803-4f00-8202-54620b267619@github.com>
References: <LQRWbokCOzo8paB0R3JzFrXWVt5mxyGpU1Xe5rTuN4Q=.a7affe6d-82e2-4115-866e-348acbe4d7f7@github.com>
 <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>
 <x62Oc0s14YVHv3PWiS2P1XZnwZCPq3ZP3XJcPyykpzc=.2581c202-e462-4a8b-a788-19ce02d7e294@github.com>
 <0vdCJFYxCI6hFnTL6rm3oKQcPuuIR2EbuyAOa0muqcw=.d5c249cb-9bf0-415d-ab22-de7387d8d8d1@github.com>
 <MeudVeLgZvALZy5XKUEtjVoLGxqgrll0fatZM_EoMHk=.b8ff7c82-ca00-4e9e-b61f-973e6a2cbf51@github.com>
 <c4DazuI_3P2LPvKaizWSW2I_51HEJFEXooYzR9JMJC8=.69aa62c9-4774-4011-be10-548314d8cbe4@github.com>
 <g-xoSGLCus40xGFBbYjgtIhig8UN58iUvdioc3vI6uk=.9a2a5b9e-0803-4f00-8202-54620b267619@github.com>
Message-ID: <1Zh7gvEryldv1xZZWYETiDjUzK_i1ea4H6U1EFEoeZU=.ef8296ca-f14f-4f4a-98c0-3b6b6d0721ed@github.com>

On Tue, 8 Jul 2025 10:33:50 GMT, Fei Gao <fgao at openjdk.org> 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: <mgnQ7Zo-OFTIYUoAJH5tJy0_67MHBajuxtcfXr2PnXI=.ff7d9863-c8b8-4976-9dc5-d494a9526b0c@github.com>
References: <mgnQ7Zo-OFTIYUoAJH5tJy0_67MHBajuxtcfXr2PnXI=.ff7d9863-c8b8-4976-9dc5-d494a9526b0c@github.com>
Message-ID: <VVWRXxR9G5Nbl8iB2eXt-NCN4C70H7uCDryJ3s76FUM=.2ea767c6-f3ee-4570-a376-77b89866d925@github.com>

On Mon, 7 Jul 2025 23:21:58 GMT, Chen Liang <liach at openjdk.org> 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: <mgnQ7Zo-OFTIYUoAJH5tJy0_67MHBajuxtcfXr2PnXI=.ff7d9863-c8b8-4976-9dc5-d494a9526b0c@github.com>
References: <mgnQ7Zo-OFTIYUoAJH5tJy0_67MHBajuxtcfXr2PnXI=.ff7d9863-c8b8-4976-9dc5-d494a9526b0c@github.com>
Message-ID: <g6ZqCCEs1nPLhlXGfllADjVNqR7RBFMkEgwfrEXlKlQ=.29609c16-07f2-4575-8057-3dc918339dd6@github.com>

On Mon, 7 Jul 2025 23:21:58 GMT, Chen Liang <liach at openjdk.org> 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 <liach at openjdk.org>
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: <mWHKJozX3YTvBOjLDUa1_2QQiNm6xVc2rb1FtXcZzPc=.e2405ec4-09ed-46c1-acd5-3f39083fce3f@github.com>
References: <mWHKJozX3YTvBOjLDUa1_2QQiNm6xVc2rb1FtXcZzPc=.e2405ec4-09ed-46c1-acd5-3f39083fce3f@github.com>
Message-ID: <HKiejePdRHy-xJNBBNnw09SHkkOpY0EWaVIvS-xg36E=.55c2c30d-f84b-4ca0-a4a8-a25ffbd31236@github.com>

> 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: <FQnM7QVeQxvNZUsCTbwzDIfYy1qlku7_-c-yrw3Q0QQ=.f146f891-42c7-44b8-8805-0ddc549fd780@github.com>
References: <mWHKJozX3YTvBOjLDUa1_2QQiNm6xVc2rb1FtXcZzPc=.e2405ec4-09ed-46c1-acd5-3f39083fce3f@github.com>
 <g_2l9E0iB1KAoGuG0xvmqESsmsCodHlM_6fbgm28qok=.afd923bb-b6b7-4b95-a0ca-6e05b0f317f0@github.com>
 <FQnM7QVeQxvNZUsCTbwzDIfYy1qlku7_-c-yrw3Q0QQ=.f146f891-42c7-44b8-8805-0ddc549fd780@github.com>
Message-ID: <CqCt-FcSH8-qLBndTTmmKmY4J1wg47hmYgNtlCvxEWo=.a362a214-9552-46d8-897b-38527c332f27@github.com>

On Tue, 8 Jul 2025 11:42:02 GMT, Emanuel Peter <epeter at openjdk.org> 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: <mWHKJozX3YTvBOjLDUa1_2QQiNm6xVc2rb1FtXcZzPc=.e2405ec4-09ed-46c1-acd5-3f39083fce3f@github.com>
 <V32l6pOUkSgvcOnQ4-o4qeQxrYw2EeRNwLI1njc4CVE=.a39617e9-4a38-465c-9916-0404345dc873@github.com>
 <f_NhsjsNCsL7uj5OwKbyka28mWKGsYz5itt9ndBxzZk=.c9a79d39-e5e2-4842-a6e1-2727c47e96ea@github.com>
 <Nw61IEd87pKfazr9DVWXHq1Ap71bndo5VscValJpqTs=.f593ada6-ef21-4d9b-9f91-faaf1f7947a2@github.com>
 <y3lv9aAjpkH6byEi6hfui6sWXm_Qu-0MjnG3jwIvvTA=.8d7a960f-1e03-4ed9-ad3b-120074880a23@github.com>
 <TJ5Jb8kV3XmVsQ6iHEy7LHj4TkRePg1PHI4PVebaEZA=.cf9e091b-bc94-4f82-a347-5d3aea86e501@github.com>
 <HTSGvd4RbqtETATLAWfiRI4SlUOzQKkkYOYARUr81l0=.b0e8cdb9-8332-4333-87ed-6f14b681f156@github.com>
 <Ou-ZY7HPV3A7YmbgCTqOUb2xtPSsLjUgH9YBg7d0Hjw=.d60901dc-f21c-4cc6-a3bd-42dec5ea9476@github.com>
 <YV3c1O6-ux9NidA-aULsjx6lFqSXHCM8gBuJCBJMqlU=.9fc1aa35-ceeb-458c-baf0-1594195c4132@github.com>
 <2UzxnawLUtlwIr5aaEdTfn4OEMt_z1HTfAaDBHCeZFU=.a70d1360-574a-4ca9-adae-7dec030ed2b7@github.com>
Message-ID: <Q2K2a1bBHhIcsyNejk0tSBu24dqQ8JI-1OTkFttXVdE=.c8bb7617-f5fb-4964-b061-78bcd0e85d9d@github.com>

On Tue, 8 Jul 2025 11:42:18 GMT, Emanuel Peter <epeter at openjdk.org> 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: <pPPnPKcSZXzHKsahik6zbmQUd5_6n0OWudfgkPDrO1s=.bc7a154e-dd31-437c-8290-634be07624d4@github.com>

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: <AmBFKMPlYw61TAK96M1JnZ7XFjGdicZcL4MVJ6GvNjo=.544eab42-4050-4317-b54d-999512605720@github.com>
References: <LQRWbokCOzo8paB0R3JzFrXWVt5mxyGpU1Xe5rTuN4Q=.a7affe6d-82e2-4115-866e-348acbe4d7f7@github.com>
 <AmBFKMPlYw61TAK96M1JnZ7XFjGdicZcL4MVJ6GvNjo=.544eab42-4050-4317-b54d-999512605720@github.com>
Message-ID: <FCO6alZO9z6AI1LV6lApfifpU4qCgVCjj3BSZxUGjKE=.e8e17f97-7193-4d58-85d3-575cc98e4477@github.com>

On Wed, 9 Jul 2025 01:23:43 GMT, Xiaohong Gong <xgong at openjdk.org> 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: <pPPnPKcSZXzHKsahik6zbmQUd5_6n0OWudfgkPDrO1s=.bc7a154e-dd31-437c-8290-634be07624d4@github.com>
References: <pPPnPKcSZXzHKsahik6zbmQUd5_6n0OWudfgkPDrO1s=.bc7a154e-dd31-437c-8290-634be07624d4@github.com>
Message-ID: <ZD6DDRqnniOHb0Sy8RJ6ZsjHcxVi_Hx_VIudZvhhd6c=.a7dcc689-b1e7-4833-b2c7-f95bae36e52b@github.com>

On Wed, 9 Jul 2025 05:45:01 GMT, Erik Gahlin <egahlin at openjdk.org> 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: <AmBFKMPlYw61TAK96M1JnZ7XFjGdicZcL4MVJ6GvNjo=.544eab42-4050-4317-b54d-999512605720@github.com>
References: <LQRWbokCOzo8paB0R3JzFrXWVt5mxyGpU1Xe5rTuN4Q=.a7affe6d-82e2-4115-866e-348acbe4d7f7@github.com>
 <AmBFKMPlYw61TAK96M1JnZ7XFjGdicZcL4MVJ6GvNjo=.544eab42-4050-4317-b54d-999512605720@github.com>
Message-ID: <o726U71eKG_hPapdYZ06jnisNAygEBePbUjoN15wkCU=.0020d2a0-a8e8-4b27-bedb-d9cc271ee1f0@github.com>

On Wed, 9 Jul 2025 01:23:43 GMT, Xiaohong Gong <xgong at openjdk.org> 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: <o726U71eKG_hPapdYZ06jnisNAygEBePbUjoN15wkCU=.0020d2a0-a8e8-4b27-bedb-d9cc271ee1f0@github.com>
References: <LQRWbokCOzo8paB0R3JzFrXWVt5mxyGpU1Xe5rTuN4Q=.a7affe6d-82e2-4115-866e-348acbe4d7f7@github.com>
 <AmBFKMPlYw61TAK96M1JnZ7XFjGdicZcL4MVJ6GvNjo=.544eab42-4050-4317-b54d-999512605720@github.com>
 <o726U71eKG_hPapdYZ06jnisNAygEBePbUjoN15wkCU=.0020d2a0-a8e8-4b27-bedb-d9cc271ee1f0@github.com>
Message-ID: <h_FdXyMPzksRp9CF1l-JkKHbHtbAnM3nM9VaqtGF6VY=.d82b8bf4-3c99-453d-a575-419166b0d420@github.com>

On Wed, 9 Jul 2025 09:06:44 GMT, Xiaohong Gong <xgong at openjdk.org> 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: <o726U71eKG_hPapdYZ06jnisNAygEBePbUjoN15wkCU=.0020d2a0-a8e8-4b27-bedb-d9cc271ee1f0@github.com>
References: <LQRWbokCOzo8paB0R3JzFrXWVt5mxyGpU1Xe5rTuN4Q=.a7affe6d-82e2-4115-866e-348acbe4d7f7@github.com>
 <AmBFKMPlYw61TAK96M1JnZ7XFjGdicZcL4MVJ6GvNjo=.544eab42-4050-4317-b54d-999512605720@github.com>
 <o726U71eKG_hPapdYZ06jnisNAygEBePbUjoN15wkCU=.0020d2a0-a8e8-4b27-bedb-d9cc271ee1f0@github.com>
Message-ID: <vYWVSLIIo6_O6TFDKHRHvyKWw__naMrVamnitkvhnV0=.69146fdb-e19a-4b1e-96a5-8ffef1ada16f@github.com>

On Wed, 9 Jul 2025 09:06:44 GMT, Xiaohong Gong <xgong at openjdk.org> 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: <OmniqsoewrvdfpMhuDJ78Qfhpqu-9SX3A4em1eiuyxo=.46ce4fbd-4ce9-4eef-9e89-4629b8a09e55@github.com>
References: <OmniqsoewrvdfpMhuDJ78Qfhpqu-9SX3A4em1eiuyxo=.46ce4fbd-4ce9-4eef-9e89-4629b8a09e55@github.com>
Message-ID: <cNjzWlphF8b9XQB05bONioNt-j8l7mMQrTZThSh5vgA=.29d845b1-851f-459e-a1a6-bdaa90950519@github.com>

On Tue, 8 Jul 2025 18:46:00 GMT, Chen Liang <liach at openjdk.org> 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: <Vw-EIPnplQrhWRudq57l2YyHC3Gg0CSbE5EgNpP3G70=.3a8ba9ad-b6a6-483f-af30-9059ef378c36@github.com>
References: <uJfr8RQBE0nk26hcVMgU6JXU6cfPbSd1b8HCGgazH1s=.7916f354-c513-4c39-b999-6769b28551d6@github.com>
 <Vw-EIPnplQrhWRudq57l2YyHC3Gg0CSbE5EgNpP3G70=.3a8ba9ad-b6a6-483f-af30-9059ef378c36@github.com>
Message-ID: <k0iU3CHKUQ0rmbLAmKQFK7z1QCLaVMlgdko4lg7jUx8=.ab44c54a-54ef-4779-8b20-991fe29d3fba@github.com>

On Tue, 8 Jul 2025 20:28:23 GMT, Chen Liang <liach at openjdk.org> 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: <AmBFKMPlYw61TAK96M1JnZ7XFjGdicZcL4MVJ6GvNjo=.544eab42-4050-4317-b54d-999512605720@github.com>
References: <LQRWbokCOzo8paB0R3JzFrXWVt5mxyGpU1Xe5rTuN4Q=.a7affe6d-82e2-4115-866e-348acbe4d7f7@github.com>
 <AmBFKMPlYw61TAK96M1JnZ7XFjGdicZcL4MVJ6GvNjo=.544eab42-4050-4317-b54d-999512605720@github.com>
Message-ID: <aoIOe2CyWENc2TWome47D_TGPSBZgorlJdHOG16Qia0=.1dc17628-73ce-41de-ae33-af9b2188fcb7@github.com>

On Wed, 9 Jul 2025 01:23:43 GMT, Xiaohong Gong <xgong at openjdk.org> 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: <vYWVSLIIo6_O6TFDKHRHvyKWw__naMrVamnitkvhnV0=.69146fdb-e19a-4b1e-96a5-8ffef1ada16f@github.com>
References: <LQRWbokCOzo8paB0R3JzFrXWVt5mxyGpU1Xe5rTuN4Q=.a7affe6d-82e2-4115-866e-348acbe4d7f7@github.com>
 <AmBFKMPlYw61TAK96M1JnZ7XFjGdicZcL4MVJ6GvNjo=.544eab42-4050-4317-b54d-999512605720@github.com>
 <o726U71eKG_hPapdYZ06jnisNAygEBePbUjoN15wkCU=.0020d2a0-a8e8-4b27-bedb-d9cc271ee1f0@github.com>
 <vYWVSLIIo6_O6TFDKHRHvyKWw__naMrVamnitkvhnV0=.69146fdb-e19a-4b1e-96a5-8ffef1ada16f@github.com>
Message-ID: <Kapm_2_HiHEfhqqxM9y8lboz3fqalKGIfMtFoMWpiVw=.3c2d52d8-0c0b-4cbb-bf32-f451ad405885@github.com>

On Wed, 9 Jul 2025 09:17:13 GMT, Xiaohong Gong <xgong at openjdk.org> 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: <CAKD1RYtJ9zU9Uwk5nJk-iiGjRsrYdD6mL5Nw2ugHswJL1VB73w@mail.gmail.com>
References: <CAKD1RYuoK07OvAn02v4qq74Q1QDfpQpf=t0J0VT-s1zi4iKRnA@mail.gmail.com>
 <MW4PR10MB5774AED3EC215ED5AB3AD52CFF62A@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAKD1RYtLy_yC+L5+q1YOkbEvUis5LJ-tJNJDbyoptq8A=+W3eg@mail.gmail.com>
 <CAKD1RYuksGCWsqj6cnu3aoHqkzAepLeNHsGSX_nCi2QryJaGMQ@mail.gmail.com>
 <SJ0PR10MB5766DAA744887EE8B0A2B991FF62A@SJ0PR10MB5766.namprd10.prod.outlook.com>
 <CAKD1RYvhpcD=yAGAvTTi+c8sdjDAi776GCPCAdvsCCVF9JQpeQ@mail.gmail.com>
 <SJ0PR10MB5766DB20AB83B1199C7987EAFF62A@SJ0PR10MB5766.namprd10.prod.outlook.com>
 <CAKD1RYst6GOErvVozZ2SD6JGhTRUAugSHZFM7aY+5Je72iF3wA@mail.gmail.com>
 <MW4PR10MB57749F82094174F71CF0BB56FF6DA@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAKD1RYu3CUT5nOj9i-cv_n7T=FXvwBpx3BQp6px6Mk2zg6GZNA@mail.gmail.com>
 <MW4PR10MB577448E6F3C06E7A0387AFAAFF6CA@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAKD1RYtf4K-r6X0dQZsXUcyZcNa5WLxKZy8p11R163GeLkYn5g@mail.gmail.com>
 <MW4PR10MB57749105268519A8984C7C3EFF6CA@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAKD1RYvM=BtM1mOo2+KqFZV6GTtPb6c+n7JOVSHN34SsV6=_Jw@mail.gmail.com>
 <MW4PR10MB5774AA40877246F6C78068D8FF6BA@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAKD1RYtJ9zU9Uwk5nJk-iiGjRsrYdD6mL5Nw2ugHswJL1VB73w@mail.gmail.com>
Message-ID: <MW4PR10MB57741A5E26E8EB538153FDCEFF49A@MW4PR10MB5774.namprd10.prod.outlook.com>

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 <yujige at gmail.com>
Sent: Tuesday, 1 July 2025 06:55
To: Viktor Klang <viktor.klang at oracle.com>
Cc: core-libs-dev at openjdk.org <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<https://urldefense.com/v3/__https://github.com/google/mug/blob/gatherers/mug-gatherers/src/main/java/com/google/mu/util/stream/gatherers/MoreGatherers.java__;!!ACWV5N9M2RV99hQ!N4nJauH92Kb7kIcuQ9VbB7iYLku9Sfttc8eK_QrtI1iGswYOcU4ZNwbM1jAm1CFJtGN0T3BTzbae8NnW$> that drops the requirement of maintaining encounter order. I then set up a test case<https://urldefense.com/v3/__https://github.com/google/mug/blob/gatherers/mug-gatherers/src/test/java/com/google/mu/util/stream/gatherers/MoreGatherersTest.java*L106:*:text=func-,mapConcurrent_withHeartbeatTask_halts,-func__;I34!!ACWV5N9M2RV99hQ!N4nJauH92Kb7kIcuQ9VbB7iYLku9Sfttc8eK_QrtI1iGswYOcU4ZNwbM1jAm1CFJtGN0T3BTzcuoKYnU$> 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 <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>> 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 <yujige at gmail.com<mailto:yujige at gmail.com>>
Sent: Sunday, 8 June 2025 07:39
To: Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>>
Cc: core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org> <core-libs-dev at openjdk.org<mailto: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 <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>> 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 <yujige at gmail.com<mailto:yujige at gmail.com>>
Sent: Wednesday, 4 June 2025 18:18
To: Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>>
Cc: core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org> <core-libs-dev at openjdk.org<mailto: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 <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>> 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<https://docs.oracle.com/en/java/javase/23/docs/api/java.base/java/util/Optional.html> 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<Callable<Result>> realTasks = ... ;

// A long-running monitoring task
Callable<Void> longRunningMonitoringTask = () -> {
    while (!allRealTasksSeemDone()) { // Simplified condition
        System.out.println("Monitoring...");
        Thread.sleep(5000);
    }
    return null;
};

Stream<Callable<?>> 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 <yujige at gmail.com<mailto:yujige at gmail.com>>
Sent: Wednesday, 4 June 2025 16:20
To: Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>>
Cc: core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org> <core-libs-dev at openjdk.org<mailto: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<Result> 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 <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>> 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 <yujige at gmail.com<mailto:yujige at gmail.com>>
Sent: Monday, 2 June 2025 18:54
To: Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>>
Cc: core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org> <core-libs-dev at openjdk.org<mailto: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 <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>> 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 <yujige at gmail.com<mailto:yujige at gmail.com>>
Sent: Monday, 2 June 2025 17:05
To: Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>>
Cc: core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org> <core-libs-dev at openjdk.org<mailto: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 <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>> 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 <yujige at gmail.com<mailto:yujige at gmail.com>>
Sent: Monday, 2 June 2025 16:29
To: Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>>; core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org> <core-libs-dev at openjdk.org<mailto: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 <yujige at gmail.com<mailto:yujige at gmail.com>> 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 <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>> 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 <core-libs-dev-retn at openjdk.org<mailto:core-libs-dev-retn at openjdk.org>> on behalf of Jige Yu <yujige at gmail.com<mailto:yujige at gmail.com>>
Sent: Sunday, 1 June 2025 21:08
To: core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org> <core-libs-dev at openjdk.org<mailto: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: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250709/4c602a7f/attachment-0001.htm>

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: <OOcrr-XrT-N783zTSoPF70AaZPoDlogN7Sck9p-N9nw=.98f4c5e8-fafd-48df-834b-cbb6f4bfe771@github.com>
References: <OOcrr-XrT-N783zTSoPF70AaZPoDlogN7Sck9p-N9nw=.98f4c5e8-fafd-48df-834b-cbb6f4bfe771@github.com>
Message-ID: <l-0nLv2m8lEdI6wI7ukOFW4p-bDMASeWseu7gmYtUYU=.56c3fb4f-9d49-476d-91c3-e97e9bf89b73@github.com>

> 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 <clinit> 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: <ZD6DDRqnniOHb0Sy8RJ6ZsjHcxVi_Hx_VIudZvhhd6c=.a7dcc689-b1e7-4833-b2c7-f95bae36e52b@github.com>
References: <pPPnPKcSZXzHKsahik6zbmQUd5_6n0OWudfgkPDrO1s=.bc7a154e-dd31-437c-8290-634be07624d4@github.com>
 <ZD6DDRqnniOHb0Sy8RJ6ZsjHcxVi_Hx_VIudZvhhd6c=.a7dcc689-b1e7-4833-b2c7-f95bae36e52b@github.com>
Message-ID: <nhBqTyzEsfSsaLBIQKN8zLaBuTuYbv_NT7AHbAioAuY=.2642023c-7185-4838-a468-ab886635ec03@github.com>

On Wed, 9 Jul 2025 09:01:52 GMT, Alan Bateman <alanb at openjdk.org> 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: <eqA9zD_EnXUJr7Q_xq7OZbBzAxViuUHyzy0Tw6LtZ8U=.6868ebd9-4afa-4a03-8c2d-7addef9a2ddf@github.com>
References: <eqA9zD_EnXUJr7Q_xq7OZbBzAxViuUHyzy0Tw6LtZ8U=.6868ebd9-4afa-4a03-8c2d-7addef9a2ddf@github.com>
Message-ID: <wvGbuwIzSIg8bAOUGSKrNWgzlzIMGfm-yx_DewY-YZY=.afcfcf07-bce9-4369-aada-4ffb51391be9@github.com>

On Tue, 3 Jun 2025 10:09:44 GMT, Nizar Benalla <nbenalla at openjdk.org> 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: <eqA9zD_EnXUJr7Q_xq7OZbBzAxViuUHyzy0Tw6LtZ8U=.6868ebd9-4afa-4a03-8c2d-7addef9a2ddf@github.com>
References: <eqA9zD_EnXUJr7Q_xq7OZbBzAxViuUHyzy0Tw6LtZ8U=.6868ebd9-4afa-4a03-8c2d-7addef9a2ddf@github.com>
Message-ID: <RQcY9Eu6tqonvjFp7PUPTuyW-UOXqnQkw5_Lcm8d87E=.ff1abdef-597a-4265-b5b5-ab9e7a184672@github.com>

On Tue, 3 Jun 2025 10:09:44 GMT, Nizar Benalla <nbenalla at openjdk.org> 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 <nbenalla at openjdk.org>
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: <rQRIb68ZkYfE9XH_ldLszvS1gA-WBOMvzNOEmka-Rcg=.4ba58aa4-c8b9-4f6e-bf08-0c6965f3dd70@github.com>

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: <rQRIb68ZkYfE9XH_ldLszvS1gA-WBOMvzNOEmka-Rcg=.4ba58aa4-c8b9-4f6e-bf08-0c6965f3dd70@github.com>
References: <rQRIb68ZkYfE9XH_ldLszvS1gA-WBOMvzNOEmka-Rcg=.4ba58aa4-c8b9-4f6e-bf08-0c6965f3dd70@github.com>
Message-ID: <_2lC8mmCVHe3H3Rx3-whw2W_Lnqf1o4fljII_lH9lks=.e645e94a-30b9-4b5a-93f8-a20d8e15069a@github.com>

On Tue, 8 Jul 2025 16:10:17 GMT, Darragh Conway <duke at openjdk.org> 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: <rQRIb68ZkYfE9XH_ldLszvS1gA-WBOMvzNOEmka-Rcg=.4ba58aa4-c8b9-4f6e-bf08-0c6965f3dd70@github.com>
 <_2lC8mmCVHe3H3Rx3-whw2W_Lnqf1o4fljII_lH9lks=.e645e94a-30b9-4b5a-93f8-a20d8e15069a@github.com>
Message-ID: <SZ6U1UPb2i6kCq_GH3uZHjKDyn0XKKpTvCY76mUleRE=.66362541-bf89-4229-94a2-bdc4dd767f63@github.com>

On Tue, 8 Jul 2025 16:34:47 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> 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: <k-sV5p2PH-mOW5iO5bjVK3Poi_h1rUzH6OEKiXhHAHQ=.ccaf23b2-903b-4847-a26b-7e2e4a47ef7b@github.com>
References: <k-sV5p2PH-mOW5iO5bjVK3Poi_h1rUzH6OEKiXhHAHQ=.ccaf23b2-903b-4847-a26b-7e2e4a47ef7b@github.com>
Message-ID: <hazqGxIXxDEhRZIBkcbQBttxNFQfyTRccig7efEAFhk=.db954041-dd65-4176-8e7c-3b2f3e74639b@github.com>

On Wed, 18 Jun 2025 00:04:37 GMT, Brian Burkhalter <bpb at openjdk.org> 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 <bpb at openjdk.org>
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: <l-0nLv2m8lEdI6wI7ukOFW4p-bDMASeWseu7gmYtUYU=.56c3fb4f-9d49-476d-91c3-e97e9bf89b73@github.com>
References: <OOcrr-XrT-N783zTSoPF70AaZPoDlogN7Sck9p-N9nw=.98f4c5e8-fafd-48df-834b-cbb6f4bfe771@github.com>
 <l-0nLv2m8lEdI6wI7ukOFW4p-bDMASeWseu7gmYtUYU=.56c3fb4f-9d49-476d-91c3-e97e9bf89b73@github.com>
Message-ID: <ZR-8R65WmuyXoHcnIhr7ufAl-Vgdim1MUE3m_TsQFi0=.113e9e73-d235-472a-8ab8-ed20e568a50e@github.com>

On Wed, 9 Jul 2025 13:25:22 GMT, Chen Liang <liach at openjdk.org> 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 <clinit> 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: <ZD6DDRqnniOHb0Sy8RJ6ZsjHcxVi_Hx_VIudZvhhd6c=.a7dcc689-b1e7-4833-b2c7-f95bae36e52b@github.com>
References: <pPPnPKcSZXzHKsahik6zbmQUd5_6n0OWudfgkPDrO1s=.bc7a154e-dd31-437c-8290-634be07624d4@github.com>
 <ZD6DDRqnniOHb0Sy8RJ6ZsjHcxVi_Hx_VIudZvhhd6c=.a7dcc689-b1e7-4833-b2c7-f95bae36e52b@github.com>
Message-ID: <JNqPDNF2OHnOrtRHYqLXgS2pwGbTVQS6Nwh21-euqXM=.47dd77f5-0ab0-409e-8b39-ad9a877462ce@github.com>

On Wed, 9 Jul 2025 09:01:00 GMT, Alan Bateman <alanb at openjdk.org> 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: <eaK1VaqI5R-YFSllob_PPzuvM9IMa9L8PQtVkhtkyqo=.ba92d7fc-cbe2-42a3-af7b-04c2dcf8bcdc@github.com>

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: <eaK1VaqI5R-YFSllob_PPzuvM9IMa9L8PQtVkhtkyqo=.ba92d7fc-cbe2-42a3-af7b-04c2dcf8bcdc@github.com>
References: <eaK1VaqI5R-YFSllob_PPzuvM9IMa9L8PQtVkhtkyqo=.ba92d7fc-cbe2-42a3-af7b-04c2dcf8bcdc@github.com>
Message-ID: <k0uj0MEu3VRQr4i5gprDcuG-YrPOAPsp0J1WcQ7vc8U=.8c0978e3-2b5d-4a80-ba15-bd44a8d8f668@github.com>

On Wed, 9 Jul 2025 18:04:08 GMT, Brian Burkhalter <bpb at openjdk.org> 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<String> ioNames =
> 215:             Arrays.asList(files).stream().map(f -> f.toString()).toList();
> 216:         Set<String> ioSet = new HashSet(ioNames);

You can simplify this by collecting into the set, e.g.

Set<String> 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: <SZ6U1UPb2i6kCq_GH3uZHjKDyn0XKKpTvCY76mUleRE=.66362541-bf89-4229-94a2-bdc4dd767f63@github.com>
References: <rQRIb68ZkYfE9XH_ldLszvS1gA-WBOMvzNOEmka-Rcg=.4ba58aa4-c8b9-4f6e-bf08-0c6965f3dd70@github.com>
 <_2lC8mmCVHe3H3Rx3-whw2W_Lnqf1o4fljII_lH9lks=.e645e94a-30b9-4b5a-93f8-a20d8e15069a@github.com>
 <SZ6U1UPb2i6kCq_GH3uZHjKDyn0XKKpTvCY76mUleRE=.66362541-bf89-4229-94a2-bdc4dd767f63@github.com>
Message-ID: <NKXfwbN8uhVNCOfL_zCQFh6qXEZOlsTnoAY-vnzuonQ=.7dc81749-d088-4f9d-baf0-8ffb401499fe@github.com>

On Wed, 9 Jul 2025 12:11:10 GMT, Darragh Conway <duke at openjdk.org> 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: <eaK1VaqI5R-YFSllob_PPzuvM9IMa9L8PQtVkhtkyqo=.ba92d7fc-cbe2-42a3-af7b-04c2dcf8bcdc@github.com>
References: <eaK1VaqI5R-YFSllob_PPzuvM9IMa9L8PQtVkhtkyqo=.ba92d7fc-cbe2-42a3-af7b-04c2dcf8bcdc@github.com>
Message-ID: <r3pllCioL-pI10YRLfLx9e6rc7CGZDQkF2CRXiCoJYI=.ccee9f09-9e80-41d2-ae8f-3038fdf411c2@github.com>

On Wed, 9 Jul 2025 18:04:08 GMT, Brian Burkhalter <bpb at openjdk.org> 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: <eaK1VaqI5R-YFSllob_PPzuvM9IMa9L8PQtVkhtkyqo=.ba92d7fc-cbe2-42a3-af7b-04c2dcf8bcdc@github.com>
References: <eaK1VaqI5R-YFSllob_PPzuvM9IMa9L8PQtVkhtkyqo=.ba92d7fc-cbe2-42a3-af7b-04c2dcf8bcdc@github.com>
Message-ID: <JbQIR28xp_LgxTkms5i_vd7nzQhP5uNCwUvnIHigo9o=.94b3b920-5171-4146-b7be-b3f41126a395@github.com>

> 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: <r3pllCioL-pI10YRLfLx9e6rc7CGZDQkF2CRXiCoJYI=.ccee9f09-9e80-41d2-ae8f-3038fdf411c2@github.com>
References: <eaK1VaqI5R-YFSllob_PPzuvM9IMa9L8PQtVkhtkyqo=.ba92d7fc-cbe2-42a3-af7b-04c2dcf8bcdc@github.com>
 <r3pllCioL-pI10YRLfLx9e6rc7CGZDQkF2CRXiCoJYI=.ccee9f09-9e80-41d2-ae8f-3038fdf411c2@github.com>
Message-ID: <bv6RPB1Q76F1R7J-ubnBDYlpV8ALdqyp7WhR-bJzLJY=.bc5fc2c4-d9b5-4881-a7c1-3154eda5c76b@github.com>

On Wed, 9 Jul 2025 18:22:51 GMT, Johannes D?bler <duke at openjdk.org> 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: <k0uj0MEu3VRQr4i5gprDcuG-YrPOAPsp0J1WcQ7vc8U=.8c0978e3-2b5d-4a80-ba15-bd44a8d8f668@github.com>
References: <eaK1VaqI5R-YFSllob_PPzuvM9IMa9L8PQtVkhtkyqo=.ba92d7fc-cbe2-42a3-af7b-04c2dcf8bcdc@github.com>
 <k0uj0MEu3VRQr4i5gprDcuG-YrPOAPsp0J1WcQ7vc8U=.8c0978e3-2b5d-4a80-ba15-bd44a8d8f668@github.com>
Message-ID: <sIy_exxEFtCwa6aTi6ydAztD-YKwGCVSsHmFvHG13yQ=.bf94c1c2-2816-4f99-9bc3-35de816b8969@github.com>

On Wed, 9 Jul 2025 18:16:44 GMT, Alan Bateman <alanb at openjdk.org> 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<String> ioNames =
>> 215:             Arrays.asList(files).stream().map(f -> f.toString()).toList();
>> 216:         Set<String> ioSet = new HashSet(ioNames);
> 
> You can simplify this by collecting into the set, e.g.
> 
> Set<String> 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: <EqR5a4iSY0WvNbJZ2Y_R_IaqXT3EefeaCcU5IZaFGc4=.3107f71a-f458-48e0-ac7b-315a998989ea@github.com>

On Wed, 9 Jul 2025 18:39:40 GMT, Naoto Sato <naoto at openjdk.org> 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: <yRds9wZ6413xkB4PRKT4VK_eA3tAhlnLbzdfMr9YTN8=.e13d9ab7-4d2f-4b3c-914c-e5a0209e50b1@github.com>

On Wed, 9 Jul 2025 18:39:40 GMT, Naoto Sato <naoto at openjdk.org> 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: <Sh2CHVAms0GUtdWALBJnvO5vD9xiFiL3Q8DPRWedTdQ=.144e2b38-f977-442b-8ad1-a2d38aabb395@github.com>
References: <IPodt6KjRH75edJJjXja5g9wqH4oY6-EouV4Xn5SWeU=.21e726f3-7dae-47ad-9b3a-9f3118fedbda@github.com>
 <Sh2CHVAms0GUtdWALBJnvO5vD9xiFiL3Q8DPRWedTdQ=.144e2b38-f977-442b-8ad1-a2d38aabb395@github.com>
Message-ID: <CUmWOKtO7pCyCWeIwdXgqClJSL9yFApoQrnjla8MYyY=.480504cf-2708-4fe6-b653-f2df1ed58aeb@github.com>

On Tue, 8 Jul 2025 20:45:20 GMT, simon <duke at openjdk.org> 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
>> <details><summary>Using <code>git</code></summary>
>> 
>> 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`
>> 
>> </details>
>> <details><summary>Using Skara CLI tools</summary>
>> 
>> Checkout this PR locally: \
>> `$ git pr checkout 25925`
>> 
>> View PR using the GUI difftool: \
>> `$ git pr show -t 25925`
>> 
>> </details>
>> <details><summary>Using diff file</summary>
>> 
>> Download this PR as a diff file: \
>> <a href="https://git.openjdk.org/jdk/pull/25925.diff">https://git.openjdk.org/jdk/pull/25925.diff</a>
>> 
>> </details>
>> <details><summary>Using Webrev</summary>
>> 
>> [Link to Webrev Comment](https://git.openjdk.org/jdk/pull/25925#issuecomment-2993856738)
>> </details>
>
> 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: <WrYJZ7s0R_IKUoALMDofC526GU9VwgKgWHUn0chf91A=.f36dd784-56f2-47a9-b005-33919e7a93d0@github.com>

On Wed, 9 Jul 2025 18:39:40 GMT, Naoto Sato <naoto at openjdk.org> 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: <PUaSI-IzsOc_xv9j2cIkeEtfG1ke_xW7lbUBb_N956Y=.8e99536c-5b32-4a40-9468-3183aab0a6c6@github.com>

On Wed, 9 Jul 2025 18:39:40 GMT, Naoto Sato <naoto at openjdk.org> 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: <OmniqsoewrvdfpMhuDJ78Qfhpqu-9SX3A4em1eiuyxo=.46ce4fbd-4ce9-4eef-9e89-4629b8a09e55@github.com>
References: <OmniqsoewrvdfpMhuDJ78Qfhpqu-9SX3A4em1eiuyxo=.46ce4fbd-4ce9-4eef-9e89-4629b8a09e55@github.com>
Message-ID: <SC4kvPEYzQNpAp8ecuSN9CbTNLK8FdKhkOhNCuXdgY8=.cf1be4ff-ed12-4d19-a4aa-75aa02b76290@github.com>

On Tue, 8 Jul 2025 18:46:00 GMT, Chen Liang <liach at openjdk.org> 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: <OmniqsoewrvdfpMhuDJ78Qfhpqu-9SX3A4em1eiuyxo=.46ce4fbd-4ce9-4eef-9e89-4629b8a09e55@github.com>
References: <OmniqsoewrvdfpMhuDJ78Qfhpqu-9SX3A4em1eiuyxo=.46ce4fbd-4ce9-4eef-9e89-4629b8a09e55@github.com>
Message-ID: <_5mCZRadhFZlFEn_9JNQcBO4WRKslhGFSXhjmjbsF5I=.66c88c6f-308e-4734-898c-b5b1a5be2852@github.com>

On Tue, 8 Jul 2025 18:46:00 GMT, Chen Liang <liach at openjdk.org> 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 <liach at openjdk.org>
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: <Wa-bsIyI8nCk5SR7km2j7QjcTvKfXi1OBklmo_RRzck=.f632f9c8-69ab-4e9e-a86b-4a2cfb47dd35@github.com>

On Wed, 9 Jul 2025 18:39:40 GMT, Naoto Sato <naoto at openjdk.org> 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: <u9Rl9fu8sx5U4aG54h8rLseSdcwjfnxiuLVDf507WME=.6a57b760-ee9d-4767-8632-4f50201b2029@github.com>

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: <OmniqsoewrvdfpMhuDJ78Qfhpqu-9SX3A4em1eiuyxo=.46ce4fbd-4ce9-4eef-9e89-4629b8a09e55@github.com>
References: <OmniqsoewrvdfpMhuDJ78Qfhpqu-9SX3A4em1eiuyxo=.46ce4fbd-4ce9-4eef-9e89-4629b8a09e55@github.com>
Message-ID: <JAnYf8hYI858eQ1GE-w6fJYn79MRIIKP6kv1MCJqIic=.f8f4247c-b799-4aa2-a0f7-f9dcf9842ceb@github.com>

On Tue, 8 Jul 2025 18:46:00 GMT, Chen Liang <liach at openjdk.org> 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: <CUmWOKtO7pCyCWeIwdXgqClJSL9yFApoQrnjla8MYyY=.480504cf-2708-4fe6-b653-f2df1ed58aeb@github.com>
References: <IPodt6KjRH75edJJjXja5g9wqH4oY6-EouV4Xn5SWeU=.21e726f3-7dae-47ad-9b3a-9f3118fedbda@github.com>
 <Sh2CHVAms0GUtdWALBJnvO5vD9xiFiL3Q8DPRWedTdQ=.144e2b38-f977-442b-8ad1-a2d38aabb395@github.com>
 <CUmWOKtO7pCyCWeIwdXgqClJSL9yFApoQrnjla8MYyY=.480504cf-2708-4fe6-b653-f2df1ed58aeb@github.com>
Message-ID: <W4EYCVTnuO3IJRLgxKtpujqklIQfeB8Uw-68hVPxrZQ=.3292cbe9-ec3b-488a-a1a5-b67265ae244b@github.com>

On Wed, 9 Jul 2025 18:59:49 GMT, Lance Andersen <lancea at openjdk.org> 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: <W4EYCVTnuO3IJRLgxKtpujqklIQfeB8Uw-68hVPxrZQ=.3292cbe9-ec3b-488a-a1a5-b67265ae244b@github.com>
References: <IPodt6KjRH75edJJjXja5g9wqH4oY6-EouV4Xn5SWeU=.21e726f3-7dae-47ad-9b3a-9f3118fedbda@github.com>
 <Sh2CHVAms0GUtdWALBJnvO5vD9xiFiL3Q8DPRWedTdQ=.144e2b38-f977-442b-8ad1-a2d38aabb395@github.com>
 <CUmWOKtO7pCyCWeIwdXgqClJSL9yFApoQrnjla8MYyY=.480504cf-2708-4fe6-b653-f2df1ed58aeb@github.com>
 <W4EYCVTnuO3IJRLgxKtpujqklIQfeB8Uw-68hVPxrZQ=.3292cbe9-ec3b-488a-a1a5-b67265ae244b@github.com>
Message-ID: <qw39eDAlC3dHJmV8udZRU4eVijn2mn_y3Pk2qO-tM6s=.58d2717f-6382-4f68-a4fd-58578202101d@github.com>

On Wed, 9 Jul 2025 19:35:54 GMT, simon <duke at openjdk.org> 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: <qw39eDAlC3dHJmV8udZRU4eVijn2mn_y3Pk2qO-tM6s=.58d2717f-6382-4f68-a4fd-58578202101d@github.com>
References: <IPodt6KjRH75edJJjXja5g9wqH4oY6-EouV4Xn5SWeU=.21e726f3-7dae-47ad-9b3a-9f3118fedbda@github.com>
 <Sh2CHVAms0GUtdWALBJnvO5vD9xiFiL3Q8DPRWedTdQ=.144e2b38-f977-442b-8ad1-a2d38aabb395@github.com>
 <CUmWOKtO7pCyCWeIwdXgqClJSL9yFApoQrnjla8MYyY=.480504cf-2708-4fe6-b653-f2df1ed58aeb@github.com>
 <W4EYCVTnuO3IJRLgxKtpujqklIQfeB8Uw-68hVPxrZQ=.3292cbe9-ec3b-488a-a1a5-b67265ae244b@github.com>
 <qw39eDAlC3dHJmV8udZRU4eVijn2mn_y3Pk2qO-tM6s=.58d2717f-6382-4f68-a4fd-58578202101d@github.com>
Message-ID: <91eSLp7wiGrcC3geQYPFJlCVGBHmNj5KrK1lffyJ_YQ=.933a1269-216b-4cff-820c-1760803e09f2@github.com>

On Wed, 9 Jul 2025 19:38:21 GMT, Chen Liang <liach at openjdk.org> 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: <Sh2CHVAms0GUtdWALBJnvO5vD9xiFiL3Q8DPRWedTdQ=.144e2b38-f977-442b-8ad1-a2d38aabb395@github.com>
References: <IPodt6KjRH75edJJjXja5g9wqH4oY6-EouV4Xn5SWeU=.21e726f3-7dae-47ad-9b3a-9f3118fedbda@github.com>
 <Sh2CHVAms0GUtdWALBJnvO5vD9xiFiL3Q8DPRWedTdQ=.144e2b38-f977-442b-8ad1-a2d38aabb395@github.com>
Message-ID: <adbAIxCdPnmehtn2WAiex8IbjPDlLrJEie_v-myMUOY=.abf867c1-4e6c-4655-abbe-88c3a7fe543c@github.com>

On Tue, 8 Jul 2025 20:45:20 GMT, simon <duke at openjdk.org> 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
>> <details><summary>Using <code>git</code></summary>
>> 
>> 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`
>> 
>> </details>
>> <details><summary>Using Skara CLI tools</summary>
>> 
>> Checkout this PR locally: \
>> `$ git pr checkout 25925`
>> 
>> View PR using the GUI difftool: \
>> `$ git pr show -t 25925`
>> 
>> </details>
>> <details><summary>Using diff file</summary>
>> 
>> Download this PR as a diff file: \
>> <a href="https://git.openjdk.org/jdk/pull/25925.diff">https://git.openjdk.org/jdk/pull/25925.diff</a>
>> 
>> </details>
>> <details><summary>Using Webrev</summary>
>> 
>> [Link to Webrev Comment](https://git.openjdk.org/jdk/pull/25925#issuecomment-2993856738)
>> </details>
>
> 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: <Sh2CHVAms0GUtdWALBJnvO5vD9xiFiL3Q8DPRWedTdQ=.144e2b38-f977-442b-8ad1-a2d38aabb395@github.com>
References: <IPodt6KjRH75edJJjXja5g9wqH4oY6-EouV4Xn5SWeU=.21e726f3-7dae-47ad-9b3a-9f3118fedbda@github.com>
 <Sh2CHVAms0GUtdWALBJnvO5vD9xiFiL3Q8DPRWedTdQ=.144e2b38-f977-442b-8ad1-a2d38aabb395@github.com>
Message-ID: <vPGt10wROghOjytLmJ6H7rkYbXYFwZ83j3otIOew2Tk=.eb166146-ca7c-40bf-a603-b5f25f5579f1@github.com>

On Tue, 8 Jul 2025 20:45:20 GMT, simon <duke at openjdk.org> 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
>> <details><summary>Using <code>git</code></summary>
>> 
>> 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`
>> 
>> </details>
>> <details><summary>Using Skara CLI tools</summary>
>> 
>> Checkout this PR locally: \
>> `$ git pr checkout 25925`
>> 
>> View PR using the GUI difftool: \
>> `$ git pr show -t 25925`
>> 
>> </details>
>> <details><summary>Using diff file</summary>
>> 
>> Download this PR as a diff file: \
>> <a href="https://git.openjdk.org/jdk/pull/25925.diff">https://git.openjdk.org/jdk/pull/25925.diff</a>
>> 
>> </details>
>> <details><summary>Using Webrev</summary>
>> 
>> [Link to Webrev Comment](https://git.openjdk.org/jdk/pull/25925#issuecomment-2993856738)
>> </details>
>
> 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: <IPodt6KjRH75edJJjXja5g9wqH4oY6-EouV4Xn5SWeU=.21e726f3-7dae-47ad-9b3a-9f3118fedbda@github.com>
References: <IPodt6KjRH75edJJjXja5g9wqH4oY6-EouV4Xn5SWeU=.21e726f3-7dae-47ad-9b3a-9f3118fedbda@github.com>
Message-ID: <Isi5IDKV31n7C5UELtQ-rq80PmYeHAycDmRyRyY_dtg=.728d1365-4987-486b-b76b-1e48ae137de9@github.com>

On Sun, 22 Jun 2025 01:13:26 GMT, simon <duke at openjdk.org> 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
> <details><summary>Using <code>git</code></summary>
> 
> 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`
> 
> </details>
> <details><summary>Using Skara CLI tools</summary>
> 
> Checkout this PR locally: \
> `$ git pr checkout 25925`
> 
> View PR using the GUI difftool: \
> `$ git pr show -t 25925`
> 
> </details>
> <details><summary>Using diff file</summary>
> 
> Download this PR as a diff file: \
> <a href="https://git.openjdk.org/jdk/pull/25925.diff">https://git.openjdk.org/jdk/pull/25925.diff</a>
> 
> </details>
> <details><summary>Using Webrev</summary>
> 
> [Link to Webrev Comment](https://git.openjdk.org/jdk/pull/25925#issuecomment-2993856738)
> </details>

This pull request has now been integrated.

Changeset: 0f7808f3
Author:    Gustavo Simon <gustavo.andre.simon at hotmail.com>
Committer: Chen Liang <liach at openjdk.org>
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: <f49PHIpcw05j1O5KpVLwxWq7eHftNjLKkVG2830sKBc=.2bbf5b02-e06a-41a9-bf2b-d8ea671a6341@github.com>
 <-mnTMxvetLwkde03sxvgoVHtnNrrBEUWHwoXuf6wRqA=.94d9759b-a2d9-4eff-afb0-562892b14c15@github.com>
Message-ID: <cF2uhAWmgB0MfjxFCQX_qLTPPtcSjsYCV27mTSKljgc=.e72c82ba-ea71-4fd6-ab9b-000b466aeb88@github.com>

On Fri, 9 May 2025 17:42:14 GMT, Benjamin Peterson <duke at openjdk.org> 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: <GmDnpyc6viSAmg523u-dhD1U4_Wfp5w2mYFqPI7Vel0=.cfc3cbe1-9944-4dd0-beec-3ce95d6bc026@github.com>

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: <eaK1VaqI5R-YFSllob_PPzuvM9IMa9L8PQtVkhtkyqo=.ba92d7fc-cbe2-42a3-af7b-04c2dcf8bcdc@github.com>
References: <eaK1VaqI5R-YFSllob_PPzuvM9IMa9L8PQtVkhtkyqo=.ba92d7fc-cbe2-42a3-af7b-04c2dcf8bcdc@github.com>
Message-ID: <iT9Z_EI7hljcY6ze7nUGmP4eFmo6hpNMp1eX-0CLOjA=.4e50df35-8c75-4049-895b-c3a3e58748ba@github.com>

> 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: <EZ4_14iY5_yTqfv3ZYpfoVRQK4jjxPtpafox1FQjq5M=.046cbb01-5fe5-4cf9-a468-ed22f0b4acda@github.com>
References: <EZ4_14iY5_yTqfv3ZYpfoVRQK4jjxPtpafox1FQjq5M=.046cbb01-5fe5-4cf9-a468-ed22f0b4acda@github.com>
Message-ID: <qiamVCoEtua2wUct97zOCtoCY0ICCUkNXIjiwK0uwTY=.8f4fcdce-a569-4d0f-b364-bd9ff642ffee@github.com>

> 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: <sjhU6Zpc2khfBwukRyY5B4Zoe_pKRrDB7XpE8Dmo0HY=.fce3d90b-a879-4c1c-92cc-e59cd893d144@github.com>

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: <vYWVSLIIo6_O6TFDKHRHvyKWw__naMrVamnitkvhnV0=.69146fdb-e19a-4b1e-96a5-8ffef1ada16f@github.com>
References: <LQRWbokCOzo8paB0R3JzFrXWVt5mxyGpU1Xe5rTuN4Q=.a7affe6d-82e2-4115-866e-348acbe4d7f7@github.com>
 <AmBFKMPlYw61TAK96M1JnZ7XFjGdicZcL4MVJ6GvNjo=.544eab42-4050-4317-b54d-999512605720@github.com>
 <o726U71eKG_hPapdYZ06jnisNAygEBePbUjoN15wkCU=.0020d2a0-a8e8-4b27-bedb-d9cc271ee1f0@github.com>
 <vYWVSLIIo6_O6TFDKHRHvyKWw__naMrVamnitkvhnV0=.69146fdb-e19a-4b1e-96a5-8ffef1ada16f@github.com>
Message-ID: <mPQI0j448AHt3tJpAuhf66fwlVnSsYXKP8Gz7rIJ4Gg=.482b2f21-5250-48c9-b498-846e1606dd87@github.com>

On Wed, 9 Jul 2025 09:17:13 GMT, Xiaohong Gong <xgong at openjdk.org> 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: <aoIOe2CyWENc2TWome47D_TGPSBZgorlJdHOG16Qia0=.1dc17628-73ce-41de-ae33-af9b2188fcb7@github.com>
References: <LQRWbokCOzo8paB0R3JzFrXWVt5mxyGpU1Xe5rTuN4Q=.a7affe6d-82e2-4115-866e-348acbe4d7f7@github.com>
 <AmBFKMPlYw61TAK96M1JnZ7XFjGdicZcL4MVJ6GvNjo=.544eab42-4050-4317-b54d-999512605720@github.com>
 <aoIOe2CyWENc2TWome47D_TGPSBZgorlJdHOG16Qia0=.1dc17628-73ce-41de-ae33-af9b2188fcb7@github.com>
Message-ID: <emPnGEURM6nbE4FViHz9laYirOlCvEFMqaUt6XAY1Yg=.8eea22fe-5917-4c4e-b2be-9e87fa2d47f3@github.com>

On Wed, 9 Jul 2025 10:43:07 GMT, Bhavana Kilambi <bkilambi at openjdk.org> 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: <sjhU6Zpc2khfBwukRyY5B4Zoe_pKRrDB7XpE8Dmo0HY=.fce3d90b-a879-4c1c-92cc-e59cd893d144@github.com>
References: <sjhU6Zpc2khfBwukRyY5B4Zoe_pKRrDB7XpE8Dmo0HY=.fce3d90b-a879-4c1c-92cc-e59cd893d144@github.com>
Message-ID: <Gxua895IDlJNb2mqXVI2_YIZVJDvnjD92kvbjyFkahI=.4bc1ac82-f412-4cda-b845-9922a8558c3b@github.com>

> 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: <hYGdx19wuXXTQBsA4nRLu7pgyi0DD5Ytyz5Y-FgyMmQ=.a953cbeb-a310-48d3-818c-fd8d1caafd7d@github.com>
References: <hYGdx19wuXXTQBsA4nRLu7pgyi0DD5Ytyz5Y-FgyMmQ=.a953cbeb-a310-48d3-818c-fd8d1caafd7d@github.com>
Message-ID: <dCpmSHM3jCC2P5nQRFYiTCD_zlym31x__ufmRRn63c4=.15521520-2756-4930-a591-a3cacb349c34@github.com>

On Mon, 7 Jul 2025 03:05:15 GMT, Mohamed Issa <missa at openjdk.org> 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: <U9S84JnmeHBnNPY0lqdqVZ-5fpabbeJzV4xlIsKmino=.615c6c1b-935b-47dd-85ee-1d456b78f540@github.com>

On Wed, 9 Jul 2025 18:39:40 GMT, Naoto Sato <naoto at openjdk.org> 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: <Gxua895IDlJNb2mqXVI2_YIZVJDvnjD92kvbjyFkahI=.4bc1ac82-f412-4cda-b845-9922a8558c3b@github.com>
References: <sjhU6Zpc2khfBwukRyY5B4Zoe_pKRrDB7XpE8Dmo0HY=.fce3d90b-a879-4c1c-92cc-e59cd893d144@github.com>
 <Gxua895IDlJNb2mqXVI2_YIZVJDvnjD92kvbjyFkahI=.4bc1ac82-f412-4cda-b845-9922a8558c3b@github.com>
Message-ID: <stiZFnNoex8PJSQ_K0539v-sFsstRhTpNK5SiQCR0V4=.55327920-ce3d-4480-82be-d07e3ae41dc2@github.com>

On Thu, 10 Jul 2025 03:12:27 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> 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: <Wse6mX1Slo3KvItTvCLqE_BMswyGSTDinY-Lp9Y-6nw=.54164a56-2d48-4c8a-8dcf-98c4e85fcbc5@github.com>
References: <hYGdx19wuXXTQBsA4nRLu7pgyi0DD5Ytyz5Y-FgyMmQ=.a953cbeb-a310-48d3-818c-fd8d1caafd7d@github.com>
 <iKunJDdbxkVFRFCxTAC6vlRnGuqlB4MZskt4ICBBY2U=.8cb33aea-1270-4822-8053-900cdfe78bc0@github.com>
 <Wse6mX1Slo3KvItTvCLqE_BMswyGSTDinY-Lp9Y-6nw=.54164a56-2d48-4c8a-8dcf-98c4e85fcbc5@github.com>
Message-ID: <pjgNDrlkQfhfDwybzk2t0HJ2pTBNIDKmWNjt7jVOi9A=.a757ed01-fb48-4f25-ac6d-828cccb4c723@github.com>

On Mon, 7 Jul 2025 23:53:14 GMT, Mohamed Issa <missa at openjdk.org> 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: <qt_re8hCJWCBb_gOvspbQwUyZQyAbicpKmLVrR7qinw=.290845bc-095e-465c-a581-20fa2ecbf76d@github.com>

On Thu, 26 Jun 2025 10:48:37 GMT, Volkan Yazici <vyazici at openjdk.org> 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` methods<sup>1</sup> (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.
> 
> <sup>1</sup>  `@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` methods<sup>1</sup> (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.

<sup>1</sup>  `@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: <B5CEqdO8Aa5UoZt02P5hx34eeeXlos2g9grRKWWYZqs=.a6ce317b-7113-49f8-81b6-0916b44d6a5c@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
 <qt_re8hCJWCBb_gOvspbQwUyZQyAbicpKmLVrR7qinw=.290845bc-095e-465c-a581-20fa2ecbf76d@github.com>
 <a4xK289_lOoYn1hWHEhpP2o00KVJzUjrLpTSrqwb22o=.3506c4d2-7cd1-440c-8a09-5ddc123c5158@github.com>
 <B5CEqdO8Aa5UoZt02P5hx34eeeXlos2g9grRKWWYZqs=.a6ce317b-7113-49f8-81b6-0916b44d6a5c@github.com>
Message-ID: <bHUzEccK20qHUzuoA5--ufb5jqFTUsswGnN9p65EITM=.716b9b13-986d-4c12-9ad7-8cac07ad92fb@github.com>

On Fri, 27 Jun 2025 13:24:52 GMT, Chen Liang <liach at openjdk.org> 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: <vtqgBq-5e9-5EF_Co_DeFx3gSp4n1n_kZ-GvtZBUqcc=.aa4d90b1-b154-4cbc-bf63-44b27d02fe18@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
 <qt_re8hCJWCBb_gOvspbQwUyZQyAbicpKmLVrR7qinw=.290845bc-095e-465c-a581-20fa2ecbf76d@github.com>
 <a4xK289_lOoYn1hWHEhpP2o00KVJzUjrLpTSrqwb22o=.3506c4d2-7cd1-440c-8a09-5ddc123c5158@github.com>
 <B5CEqdO8Aa5UoZt02P5hx34eeeXlos2g9grRKWWYZqs=.a6ce317b-7113-49f8-81b6-0916b44d6a5c@github.com>
 <bHUzEccK20qHUzuoA5--ufb5jqFTUsswGnN9p65EITM=.716b9b13-986d-4c12-9ad7-8cac07ad92fb@github.com>
 <vtqgBq-5e9-5EF_Co_DeFx3gSp4n1n_kZ-GvtZBUqcc=.aa4d90b1-b154-4cbc-bf63-44b27d02fe18@github.com>
Message-ID: <WSlx76BipS-RhuSlJyR8jV_uiWs5_ZJ5PrxD8toqhaw=.44efab1a-c960-4b56-90b1-a0af0e64c5bd@github.com>

On Fri, 4 Jul 2025 15:03:33 GMT, Volkan Yazici <vyazici at openjdk.org> 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: <B5CEqdO8Aa5UoZt02P5hx34eeeXlos2g9grRKWWYZqs=.a6ce317b-7113-49f8-81b6-0916b44d6a5c@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
 <qt_re8hCJWCBb_gOvspbQwUyZQyAbicpKmLVrR7qinw=.290845bc-095e-465c-a581-20fa2ecbf76d@github.com>
 <a4xK289_lOoYn1hWHEhpP2o00KVJzUjrLpTSrqwb22o=.3506c4d2-7cd1-440c-8a09-5ddc123c5158@github.com>
 <B5CEqdO8Aa5UoZt02P5hx34eeeXlos2g9grRKWWYZqs=.a6ce317b-7113-49f8-81b6-0916b44d6a5c@github.com>
Message-ID: <bAdxgImspJYrluIITQe3keO4y7QC4SRR_pO-dWvcdFk=.a4d45d2f-bffa-4762-be24-868901cad785@github.com>

On Fri, 27 Jun 2025 13:24:52 GMT, Chen Liang <liach at openjdk.org> 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: <bHUzEccK20qHUzuoA5--ufb5jqFTUsswGnN9p65EITM=.716b9b13-986d-4c12-9ad7-8cac07ad92fb@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
 <qt_re8hCJWCBb_gOvspbQwUyZQyAbicpKmLVrR7qinw=.290845bc-095e-465c-a581-20fa2ecbf76d@github.com>
 <a4xK289_lOoYn1hWHEhpP2o00KVJzUjrLpTSrqwb22o=.3506c4d2-7cd1-440c-8a09-5ddc123c5158@github.com>
 <B5CEqdO8Aa5UoZt02P5hx34eeeXlos2g9grRKWWYZqs=.a6ce317b-7113-49f8-81b6-0916b44d6a5c@github.com>
 <bHUzEccK20qHUzuoA5--ufb5jqFTUsswGnN9p65EITM=.716b9b13-986d-4c12-9ad7-8cac07ad92fb@github.com>
Message-ID: <vtqgBq-5e9-5EF_Co_DeFx3gSp4n1n_kZ-GvtZBUqcc=.aa4d90b1-b154-4cbc-bf63-44b27d02fe18@github.com>

On Fri, 27 Jun 2025 20:21:31 GMT, ExE Boss <duke at openjdk.org> 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: <a4xK289_lOoYn1hWHEhpP2o00KVJzUjrLpTSrqwb22o=.3506c4d2-7cd1-440c-8a09-5ddc123c5158@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
 <qt_re8hCJWCBb_gOvspbQwUyZQyAbicpKmLVrR7qinw=.290845bc-095e-465c-a581-20fa2ecbf76d@github.com>
 <a4xK289_lOoYn1hWHEhpP2o00KVJzUjrLpTSrqwb22o=.3506c4d2-7cd1-440c-8a09-5ddc123c5158@github.com>
Message-ID: <B5CEqdO8Aa5UoZt02P5hx34eeeXlos2g9grRKWWYZqs=.a6ce317b-7113-49f8-81b6-0916b44d6a5c@github.com>

On Fri, 27 Jun 2025 07:22:48 GMT, Tobias Hartmann <thartmann at openjdk.org> 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: <qt_re8hCJWCBb_gOvspbQwUyZQyAbicpKmLVrR7qinw=.290845bc-095e-465c-a581-20fa2ecbf76d@github.com>
References: <-o9qy_Jsa4tvizzy8WgngfPuz9tx8Cwcztzl9AXiB70=.9ddb14d6-ee47-448d-a5a5-9c9ac4db3e0c@github.com>
 <qt_re8hCJWCBb_gOvspbQwUyZQyAbicpKmLVrR7qinw=.290845bc-095e-465c-a581-20fa2ecbf76d@github.com>
Message-ID: <a4xK289_lOoYn1hWHEhpP2o00KVJzUjrLpTSrqwb22o=.3506c4d2-7cd1-440c-8a09-5ddc123c5158@github.com>

On Thu, 26 Jun 2025 17:26:02 GMT, Chen Liang <liach at openjdk.org> 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` methods<sup>1</sup> (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.
>> 
>> <sup>1</sup>  `@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: <KQtuK8Xsq6sHPd9dvHfg3UielCYIPlWI-Cg2U9Gq0qo=.15fea423-2502-4389-98b4-c503028f35ec@github.com>

On Thu, 26 Jun 2025 10:48:37 GMT, Volkan Yazici <vyazici at openjdk.org> 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` methods<sup>1</sup> (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.
> 
> <sup>1</sup>  `@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 <em>byte (not character!)</em> 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: <iT9Z_EI7hljcY6ze7nUGmP4eFmo6hpNMp1eX-0CLOjA=.4e50df35-8c75-4049-895b-c3a3e58748ba@github.com>
References: <eaK1VaqI5R-YFSllob_PPzuvM9IMa9L8PQtVkhtkyqo=.ba92d7fc-cbe2-42a3-af7b-04c2dcf8bcdc@github.com>
 <iT9Z_EI7hljcY6ze7nUGmP4eFmo6hpNMp1eX-0CLOjA=.4e50df35-8c75-4049-895b-c3a3e58748ba@github.com>
Message-ID: <WK9awC9zsQbWJtcMrOXRYZCVgrnvoVmb-zfPTEG_2t4=.09e97443-38c7-43cf-a6a2-927f08eab9fb@github.com>

On Wed, 9 Jul 2025 21:57:56 GMT, Brian Burkhalter <bpb at openjdk.org> 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: <dCpmSHM3jCC2P5nQRFYiTCD_zlym31x__ufmRRn63c4=.15521520-2756-4930-a591-a3cacb349c34@github.com>
References: <hYGdx19wuXXTQBsA4nRLu7pgyi0DD5Ytyz5Y-FgyMmQ=.a953cbeb-a310-48d3-818c-fd8d1caafd7d@github.com>
 <dCpmSHM3jCC2P5nQRFYiTCD_zlym31x__ufmRRn63c4=.15521520-2756-4930-a591-a3cacb349c34@github.com>
Message-ID: <cY9ttT-U1oP-t5VCY5oVTvvUGB6kTVg4rMHrB8yc3nE=.f34a882f-8082-409c-b8be-c68e7caf9eef@github.com>

On Thu, 10 Jul 2025 04:52:01 GMT, Joe Darcy <darcy at openjdk.org> 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: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
 <NepVSdYvhMG501_Fjefgk_ezwqK3FT2rOfIfcKiQ8O4=.1b994e30-acd2-488c-b876-ed7b95d3c4bb@github.com>
 <V4he0DJLrCSGDVnq5JmOWXh4OcEIwlUUH7R-vLno3VA=.3ba1b7e6-237d-48bf-9d2d-88b0bf830083@github.com>
 <8id1JAg7v3hZfZgSn2aRRA_V-mnpgMWrHD8xhwb7qMM=.f31152a1-23ac-43a5-b26c-21a5f53a1272@github.com>
Message-ID: <MjiTE_Axfr2hk_cYVTDpdDjL-xD9RWHtt5szjK51nc4=.cdc8c6f8-c73b-4fcc-8033-9d2392bdd92a@github.com>

On Sat, 17 May 2025 11:25:58 GMT, fabioromano1 <duke at openjdk.org> 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: <eaK1VaqI5R-YFSllob_PPzuvM9IMa9L8PQtVkhtkyqo=.ba92d7fc-cbe2-42a3-af7b-04c2dcf8bcdc@github.com>
References: <eaK1VaqI5R-YFSllob_PPzuvM9IMa9L8PQtVkhtkyqo=.ba92d7fc-cbe2-42a3-af7b-04c2dcf8bcdc@github.com>
Message-ID: <LsmbwZDmQk01PYqPks4bMOGATp73iMfUX-jVgxTgMeA=.2cd44262-cfed-4dd8-a67b-87f4a8b60128@github.com>

> 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: <WK9awC9zsQbWJtcMrOXRYZCVgrnvoVmb-zfPTEG_2t4=.09e97443-38c7-43cf-a6a2-927f08eab9fb@github.com>
References: <eaK1VaqI5R-YFSllob_PPzuvM9IMa9L8PQtVkhtkyqo=.ba92d7fc-cbe2-42a3-af7b-04c2dcf8bcdc@github.com>
 <iT9Z_EI7hljcY6ze7nUGmP4eFmo6hpNMp1eX-0CLOjA=.4e50df35-8c75-4049-895b-c3a3e58748ba@github.com>
 <WK9awC9zsQbWJtcMrOXRYZCVgrnvoVmb-zfPTEG_2t4=.09e97443-38c7-43cf-a6a2-927f08eab9fb@github.com>
Message-ID: <0Ov4B1SThV5kXkLDVX4yJPXjmd2ZwW0CEZQe018sWTY=.60089096-6114-4dfb-8a6a-181448dff6b0@github.com>

On Thu, 10 Jul 2025 14:18:31 GMT, Alan Bateman <alanb at openjdk.org> 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: <NoXw4JZ1pEpfRd-hlC_5GdTwHNZQVQ9pwxamN_KX7fo=.43be73f7-c027-4af7-9e1f-3b8bfeb87a19@github.com>
References: <NoXw4JZ1pEpfRd-hlC_5GdTwHNZQVQ9pwxamN_KX7fo=.43be73f7-c027-4af7-9e1f-3b8bfeb87a19@github.com>
Message-ID: <3sVe377DO4pygelyscKiYce786fDnIEFwbP0O6jxhcs=.b429003d-166d-4673-bc0a-be3700ddab9a@github.com>

On Mon, 7 Jul 2025 16:13:08 GMT, Andrew Haley <aph at openjdk.org> 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: <LsmbwZDmQk01PYqPks4bMOGATp73iMfUX-jVgxTgMeA=.2cd44262-cfed-4dd8-a67b-87f4a8b60128@github.com>
References: <eaK1VaqI5R-YFSllob_PPzuvM9IMa9L8PQtVkhtkyqo=.ba92d7fc-cbe2-42a3-af7b-04c2dcf8bcdc@github.com>
 <LsmbwZDmQk01PYqPks4bMOGATp73iMfUX-jVgxTgMeA=.2cd44262-cfed-4dd8-a67b-87f4a8b60128@github.com>
Message-ID: <hzCT7HYT0ZoX-11beXK3VGBIMUyyfPGKsoQ-HAXPU8k=.992d2372-51d2-427e-bb22-515feec7652a@github.com>

On Thu, 10 Jul 2025 15:26:20 GMT, Brian Burkhalter <bpb at openjdk.org> 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: <BVM7bxoSLARfYQWZ_RYLPKlNWpcJJocIgXVqO7jQq5I=.7c5a81ff-fd2c-4054-a407-6517a8da5b60@github.com>

On Wed, 9 Jul 2025 18:39:40 GMT, Naoto Sato <naoto at openjdk.org> 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 <naoto at openjdk.org> 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 <naoto at openjdk.org>
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: <MjiTE_Axfr2hk_cYVTDpdDjL-xD9RWHtt5szjK51nc4=.cdc8c6f8-c73b-4fcc-8033-9d2392bdd92a@github.com>
References: <mBhSi9zaQ4MfM0tM3zB5ynStkQ1bpSfblPD7DHPfaAA=.0fbbd7e9-63c3-4193-a898-accb9975890c@github.com>
 <NepVSdYvhMG501_Fjefgk_ezwqK3FT2rOfIfcKiQ8O4=.1b994e30-acd2-488c-b876-ed7b95d3c4bb@github.com>
 <V4he0DJLrCSGDVnq5JmOWXh4OcEIwlUUH7R-vLno3VA=.3ba1b7e6-237d-48bf-9d2d-88b0bf830083@github.com>
 <8id1JAg7v3hZfZgSn2aRRA_V-mnpgMWrHD8xhwb7qMM=.f31152a1-23ac-43a5-b26c-21a5f53a1272@github.com>
 <MjiTE_Axfr2hk_cYVTDpdDjL-xD9RWHtt5szjK51nc4=.cdc8c6f8-c73b-4fcc-8033-9d2392bdd92a@github.com>
Message-ID: <dpEEadBlxpprTNG-ghuG-QT95Ntw4z_1wBtWAWykpuQ=.e36d182a-6362-4356-b083-f96f38c5c5e0@github.com>

On Thu, 10 Jul 2025 15:21:10 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> 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: <AmBFKMPlYw61TAK96M1JnZ7XFjGdicZcL4MVJ6GvNjo=.544eab42-4050-4317-b54d-999512605720@github.com>
References: <LQRWbokCOzo8paB0R3JzFrXWVt5mxyGpU1Xe5rTuN4Q=.a7affe6d-82e2-4115-866e-348acbe4d7f7@github.com>
 <AmBFKMPlYw61TAK96M1JnZ7XFjGdicZcL4MVJ6GvNjo=.544eab42-4050-4317-b54d-999512605720@github.com>
Message-ID: <375qzJdzdKWky3-EHgnSiksFYbJIPvfR27xzUTF6vRA=.9eb63509-1ec6-4cc6-bff0-782290866a4d@github.com>

On Wed, 9 Jul 2025 01:23:43 GMT, Xiaohong Gong <xgong at openjdk.org> 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 <vyazici at openjdk.org> 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` methods<sup>1</sup> (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.
> 
> <sup>1</sup>  `@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: <cY9ttT-U1oP-t5VCY5oVTvvUGB6kTVg4rMHrB8yc3nE=.f34a882f-8082-409c-b8be-c68e7caf9eef@github.com>
References: <hYGdx19wuXXTQBsA4nRLu7pgyi0DD5Ytyz5Y-FgyMmQ=.a953cbeb-a310-48d3-818c-fd8d1caafd7d@github.com>
 <dCpmSHM3jCC2P5nQRFYiTCD_zlym31x__ufmRRn63c4=.15521520-2756-4930-a591-a3cacb349c34@github.com>
 <cY9ttT-U1oP-t5VCY5oVTvvUGB6kTVg4rMHrB8yc3nE=.f34a882f-8082-409c-b8be-c68e7caf9eef@github.com>
Message-ID: <fuR6ms-rfPnU-30v-gBJpQE0xKOk-a9_qgx0TTrZ7bA=.f13bb99f-2863-4776-9fec-1e8b8c3873e7@github.com>

On Thu, 10 Jul 2025 14:31:02 GMT, Mohamed Issa <missa at openjdk.org> 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: <YqhNILbevQ2LlcvsLTnXgduP17cXTHdxToS6tbGlwSE=.e092145a-c661-473c-9be1-ffb523de06fc@github.com>

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: <B8hl437Phlq-605VfbqQXM8Fbzcfb3NWXGzKV6QehkI=.ef2aa4a8-455c-42a6-9fad-38c376fbc4db@github.com>
References: <B8hl437Phlq-605VfbqQXM8Fbzcfb3NWXGzKV6QehkI=.ef2aa4a8-455c-42a6-9fad-38c376fbc4db@github.com>
Message-ID: <S__QdVq7FnbHHbNTj2eEcqxH58GuyhijftxZ2DSeOJA=.8103a083-3570-4c8e-a3d8-485944beec83@github.com>

> 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: <r2D6Ru3qwVCjLpesxfDs43PJOU1Sb-ItLBGXRPVJD8k=.e33096e1-2dcf-4805-85d1-53b7cf962b5d@github.com>
References: <B8hl437Phlq-605VfbqQXM8Fbzcfb3NWXGzKV6QehkI=.ef2aa4a8-455c-42a6-9fad-38c376fbc4db@github.com>
 <h0x3LysInvyEMcWkU8e8PxdSSkCeC4gzTNSzfemtzTw=.f8be7351-6e98-45bd-a807-3e54a0e83a0d@github.com>
 <r2D6Ru3qwVCjLpesxfDs43PJOU1Sb-ItLBGXRPVJD8k=.e33096e1-2dcf-4805-85d1-53b7cf962b5d@github.com>
Message-ID: <YugxvKu8OSSx0JLzZoEutLfGJHpHCYtSIEeV5mHyD9Q=.b12b2e72-6ac3-4346-9be0-04c72404f418@github.com>

On Tue, 8 Jul 2025 00:15:29 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> 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: <?xml version="1.0" encoding="UTF-8"?>
> 
> 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: <dict>
>> 5:         <key>CFBundleDevelopmentRegion</key>
>> 6:         <string>English</string>
> 
> 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<Path> 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: <B8hl437Phlq-605VfbqQXM8Fbzcfb3NWXGzKV6QehkI=.ef2aa4a8-455c-42a6-9fad-38c376fbc4db@github.com>
 <h0x3LysInvyEMcWkU8e8PxdSSkCeC4gzTNSzfemtzTw=.f8be7351-6e98-45bd-a807-3e54a0e83a0d@github.com>
 <8puqNFN9LtsrDe6xF4EmRPBrT-CR3IRcOS62YFVwZD8=.7613bce6-badf-4664-baf7-67c94037d7b7@github.com>
Message-ID: <Rqjl9y0pqY-kiAV0BA9ik-vBIahRO5jn7Wg4QoMYn0s=.7a39146b-3e54-4595-b7c8-0d09e9904d88@github.com>

On Tue, 8 Jul 2025 01:13:20 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> 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<MacApplication, MacApplicationLayout> 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: <S__QdVq7FnbHHbNTj2eEcqxH58GuyhijftxZ2DSeOJA=.8103a083-3570-4c8e-a3d8-485944beec83@github.com>
References: <B8hl437Phlq-605VfbqQXM8Fbzcfb3NWXGzKV6QehkI=.ef2aa4a8-455c-42a6-9fad-38c376fbc4db@github.com>
 <S__QdVq7FnbHHbNTj2eEcqxH58GuyhijftxZ2DSeOJA=.8103a083-3570-4c8e-a3d8-485944beec83@github.com>
Message-ID: <oQfJHTLQCoTatzjI5_oAnKxbnWyKL2UBbjBRye_M24A=.0909fa3f-5f8e-4d35-b8ba-47d4f88b4cc8@github.com>

On Thu, 10 Jul 2025 21:44:32 GMT, Alexander Matveev <almatvee at openjdk.org> 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: <udEtYLdfL6agJTB3aTFfe7xdAhpBzdKEP_uWn-xalH8=.39d23c00-7a88-4d79-bb31-eb6ff8674fa9@github.com>

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: <jQUgadsvemj8_Wu1vIidHAde3v3llybuTr6vxdneP-4=.82b28b63-27e6-46c2-8f62-c0aaf85b3c02@github.com>

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: <eaK1VaqI5R-YFSllob_PPzuvM9IMa9L8PQtVkhtkyqo=.ba92d7fc-cbe2-42a3-af7b-04c2dcf8bcdc@github.com>
References: <eaK1VaqI5R-YFSllob_PPzuvM9IMa9L8PQtVkhtkyqo=.ba92d7fc-cbe2-42a3-af7b-04c2dcf8bcdc@github.com>
Message-ID: <uM6Bmm5rwcMo6PdyeZJudSBZ4eIUTpfiEsGcmBBMWYA=.21d11e7e-9b04-42ec-9381-dbed0d763a52@github.com>

> 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: <zDd1bTMk6HjfVMpzFV_dnl9eWjFz6kbQ4qRhvGPyvJ8=.8cf05fd8-fd1d-4aa9-8e91-a3fa02eb7140@github.com>

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: <emPnGEURM6nbE4FViHz9laYirOlCvEFMqaUt6XAY1Yg=.8eea22fe-5917-4c4e-b2be-9e87fa2d47f3@github.com>
References: <LQRWbokCOzo8paB0R3JzFrXWVt5mxyGpU1Xe5rTuN4Q=.a7affe6d-82e2-4115-866e-348acbe4d7f7@github.com>
 <AmBFKMPlYw61TAK96M1JnZ7XFjGdicZcL4MVJ6GvNjo=.544eab42-4050-4317-b54d-999512605720@github.com>
 <aoIOe2CyWENc2TWome47D_TGPSBZgorlJdHOG16Qia0=.1dc17628-73ce-41de-ae33-af9b2188fcb7@github.com>
 <emPnGEURM6nbE4FViHz9laYirOlCvEFMqaUt6XAY1Yg=.8eea22fe-5917-4c4e-b2be-9e87fa2d47f3@github.com>
Message-ID: <5__MowepmHboqoXdzv0AEbzawJobhlsMoAHjAmYrCno=.b42d0d72-54bd-4ccc-a29b-98877bbedcbb@github.com>

On Thu, 10 Jul 2025 01:40:06 GMT, Xiaohong Gong <xgong at openjdk.org> 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: <FxpYMyFQVYy18ZaAXJUgY06Aa8_nx7iL8k3iNCxd7NQ=.cb4f0902-e1c9-40ad-8440-1e7624e9a822@github.com>
References: <LQRWbokCOzo8paB0R3JzFrXWVt5mxyGpU1Xe5rTuN4Q=.a7affe6d-82e2-4115-866e-348acbe4d7f7@github.com>
 <7VTRz_XqYBSdQ54n7ADzTzYADZjDbgBw6XuW0jehSLI=.24d18b87-4553-47ab-8065-d92fbb5700ae@github.com>
 <FxpYMyFQVYy18ZaAXJUgY06Aa8_nx7iL8k3iNCxd7NQ=.cb4f0902-e1c9-40ad-8440-1e7624e9a822@github.com>
Message-ID: <sH3xKPEPfOuAcjdq5ymoaKhVMRf20uTo244h7-E_WcE=.0f388e88-5de0-43ee-9598-d257963b53c8@github.com>

On Fri, 4 Jul 2025 09:11:40 GMT, Andrew Haley <aph at openjdk.org> 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: <v6eZBS5s4FryKFbdnWdLb8lruzbR1GcfjQOn16PALwg=.5ab0f52d-5a90-4a96-a630-12086772f629@github.com>

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: <qiamVCoEtua2wUct97zOCtoCY0ICCUkNXIjiwK0uwTY=.8f4fcdce-a569-4d0f-b364-bd9ff642ffee@github.com>
References: <EZ4_14iY5_yTqfv3ZYpfoVRQK4jjxPtpafox1FQjq5M=.046cbb01-5fe5-4cf9-a468-ed22f0b4acda@github.com>
 <qiamVCoEtua2wUct97zOCtoCY0ICCUkNXIjiwK0uwTY=.8f4fcdce-a569-4d0f-b364-bd9ff642ffee@github.com>
Message-ID: <p1IgQSvH5cYmNbBfoOBkJBDBPWDZ11OSp4lsUDAGzTM=.0815a03f-50f5-4dec-a0cc-ff879977a700@github.com>

On Wed, 9 Jul 2025 22:52:58 GMT, Ian Graves <igraves at openjdk.org> 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: <uM6Bmm5rwcMo6PdyeZJudSBZ4eIUTpfiEsGcmBBMWYA=.21d11e7e-9b04-42ec-9381-dbed0d763a52@github.com>
References: <eaK1VaqI5R-YFSllob_PPzuvM9IMa9L8PQtVkhtkyqo=.ba92d7fc-cbe2-42a3-af7b-04c2dcf8bcdc@github.com>
 <uM6Bmm5rwcMo6PdyeZJudSBZ4eIUTpfiEsGcmBBMWYA=.21d11e7e-9b04-42ec-9381-dbed0d763a52@github.com>
Message-ID: <omhJ4IRKTVIbbj1YXXysc5t5QV2VWZ5d6ZJhOWFYAeE=.30c25ad9-0d0c-4046-a125-ea0559f9e85b@github.com>

On Thu, 10 Jul 2025 22:47:12 GMT, Brian Burkhalter <bpb at openjdk.org> 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: <zDd1bTMk6HjfVMpzFV_dnl9eWjFz6kbQ4qRhvGPyvJ8=.8cf05fd8-fd1d-4aa9-8e91-a3fa02eb7140@github.com>
References: <zDd1bTMk6HjfVMpzFV_dnl9eWjFz6kbQ4qRhvGPyvJ8=.8cf05fd8-fd1d-4aa9-8e91-a3fa02eb7140@github.com>
Message-ID: <JyFXnnkzrbOSXSsVUmDwkKfm-F3UlWHRkWzOsl8CMko=.d8c23079-1ace-4df9-88b7-7628576570a7@github.com>

On Thu, 10 Jul 2025 23:40:15 GMT, Chen Liang <liach at openjdk.org> 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 <cite>The Java Language Specification</cite>.

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